Database redesign

The domains are now saved all in one table and they each have a domain type specified. Due to this setup the database can now also cover modification domains.

GUI extension

The php scripts were extended to allow for entries to the new database. Additionally an XML export funciton was added to the design interface.

Draft of PFAM querying

In the experimental parts, we determined a first rough estimate of NRPS domain boundaries based on Pfam. Thus we also wanted our software to use the Pfam predictions to make it easier to semi-automatically add new domains into our database. A first test Python script was written which queried the Pfam API using the Requests library according to the online documentation and then parsed the XML output. The Biopython library also proved to be of great help.

Concept transferred to django framework

Having distributed diverse tasks e.g. to write php scripts, we figured out that we would be constantly be reinventing the wheel and doing web-development like it was done a decade ago. Thus, we started looking at different web frameworks, which would make a lot of standardized tasks such as user login easy. We then decided to use Django, a Python framework, mainly because of the language. Some of us already knew Python, it is in general a language that is very easy to pick up and the Biopython project is pretty comprehensive. Additionally, a previously very successful iGEM Project (Gibthon) also used Django. Compared to most other choices (except Ruby on Rails, which has the disadvantage of being written in Ruby) it also seemed to be the most mature choice. We also thought of using a Perl or a Haskell framework, such as Yesod, but some team members disliked those languages (Haskellers disliked Perl and vice versa; the fact that the first Perl6 compiler was written in Haskell could not convince the Perl people either).

We then started reading the Django tutorials and the (great!) documentation and started porting our previous MySQL database designs to Django models. This was made a lot easier by an automated Django utility which converts a database into a draft models file, which we could then adapt to our needs. The rest of the team was impressed after seeing the admin site, which again was very easy to get up and running with Django. This week our official lab-youtube-song was this [http://www.youtube.com/watch?v=jMq5joFVxpQ one.]

Concept visualisation

For presentation purposes and in order to have a visual representation of all the different aspects of our project we drew a huge graphic on the blackboard. After two days of revision we redrew the whole thing using inkscape. The result is displayed in figure 16.1.

Monomer selection page aesthetic improvements

This week we focused on improving the aesthetics of the NRP selection page. Most of the page layout was shuffled around, so that everything important (Monomer selection, buttons, peptide graphic) fit onto a laptop screen and no scrolling around is necessary. For this we also removed the help text, which added a lot of bloat to the page. We'll try to find a fancier way to document things and help the user later on. We also used a nice feature of s[http://ivaynberg.github.io/select2/ select2], which basically allows you to determine how the dropdown selection options are styled. More specifically, each monomer is displayed together with its 2d structure as generated by the OpenBabel script we had already written.

AJAX functionality

In order to facilitate the communication of the web interface with the C++ code, we started testing the AJAX functionality. One thing we noticed was that the (otherwise great) Dajaxice library, can actually cause problems due to relative URLs, as it does not correctly utilize the wsgi settings. This was especially problematic, as the development and production environments differed, so that a very ugly hack would have to be written for this to work. Instead, we decided to use a more barebones/standard AJAX implementation by actually using jQuery. A test was written with the monomer selection being passed via AJAX and then a popup alert (yay!) which produced an XML out of this selection. This XML could be passed into the C++ function.

Designer interface - modifications

A selection box for the modifications a substrate can have was added to the designer interface. This will also be adopted for the chemical structure and the domains will be included in the NRPS design.

Tool selection for domain prediciton

We tried to determine, which tool would be most appropriate for automated determination of domains. Thus we used the first CDS of the teicoplanin NRPS, as curated in the NRPS-PKS (SBSPKS) database. We then compared the automated prediction with the tool of Maryland, as well as antiSMASH2.

Note that Pfam can't differentiate between C and E domains. Pfam also does not return any predictions in regard to A-domain specificity. antiSMASH is able to predict the A-domain specificities as annotated in NRPS-PKS, while Maryland's tool can only predict the second A-domain (Tyrosine), while the first is incorrectly predicted to be specific for Leucine (curated: HpG, 4-hydroxyphenyl glycine).

The same analysis was also repeated for thaxtomin.

In this case, both tools correctly predict the L-Phenylalanine specificity of the A-domain.

Analysis of tycC from the tyrocidine-cluster.

In regards to prediction of A-domain specificity, antiSMASH predictions and the curated NRPS-PKS amino acids were the same. On the other hand, Maryland predicted did not get any hit for A6 (Leu) and for A1/A3 respectively it predicted to possible amino acids (Asn+Asp compared to Asn / Tyr + Trp compared to Tyr in antiSMASH and NRPS-PKS).

TycB3 C-A domain

Clustal Omega MSA of different C-A domain borders of Tyrocidine cluster with annotation (prediction) of the start of the A domain according to different tools.

Clustal Omega MSA of different C-A domain borders of Tyrocidine cluster with annotation (prediction) of the end of the C domain according to different tools.

== Inegration of antiSMASH ==

Please see our documentation for our final results.

Please see our documentation for our final results.

SBOL and GenBank

Proper output of the designed NRPS as well as the primers, was created both for GenBank and for SBOL. Moreover the tool internal communication was shifted to SBOL.

Database Curation

The final state of the database after a major portion of SBSPKS was curated is displayed in the table below.