Ilia Kats

One of our team members, the secret chief-nerd of our group, Ilia Kats had the initial idea for our project and inspired us all with his dream of easy and fast recycling of gold. He also came up with the concept to exploit the NRPS modularity for setting up the NRPS designer.
Besides all of his brain work Ilia was indispensable for all of the wetlab work for the different sub projects. He was single-handedly responsible for cloning the methylmalonyl-CoA patwhay for the delftibactin project. In the Tyrocidine and indigoidine subproject he was involved in the pilot experiments. And last but not least, his programming skills were essential for the successful implementation of our NRPS-Designer software where he used his supernatural force to eliminate even the toughest bugs.
A big THANK U from the whole team for the inspiration and great humor.

Gold Recycling
Delftibactin

The cloning strategies and amplification of the Del-cluster were in general performed and developed by Florian Schmidt, Sophie Rabe, Nils Kurzawa and Johanna Meichsner. The experiments started with the amplification of DelH executed by Johanna Meichsner which turned out to be one of the most challenging parts of our project. Johanna proved to be extremely resilient to recurrent setbacks and her power of endurance gave a great example to the whole team. Florian Schmidt, Sophie Rabe and Nils Kurzawa took care of the plasmid assembly of the other genes from the Del-cluster. After DelRest was succesfully amplified Florian Schmidt and Sophie Rabe worked as well on the plasmid creation of DelH. Sophie Rabe had also the responsibility of proteins assays, delftibactin purification and Maldi-TOF. All of them were extremely dedicated to their work and happily cloned day and night.
Ilia Kats cloned the pIK8 plasmid and all prior plasmids necessary for the establishment of the methylmalonyl-CoA pathway. He performed all steps of the cloning procedure of these plasmids from primer design up to electroporation and screening.
Here we want to give a special thank you to our advisors Dominik Niopek, Fanny Georgi and Katharina Genreith for their great help in planning the cloning strategies and introducing us to the world of primer design!

Software-Safety

Our software team developed the NRPSDesigner, a web application capable of suggesting cloning strategies for the creation of artificial NRP-synthetases, which can synthesize a peptide of choice. This software is built upon a database of domains, origins and products. The very nature of this project meant that we were confronted with safety issues all web developers face, as well as by issues specific to the biological underpinnings of our software. The latter overlapped in many cases with our considerations throughout the wetlab projects.
Any web application has to deal with diverse attacks of malicious intent. Dealing with these was simplified by using Django, a stable web framework. Such frameworks try to trivialize common tasks in the work of a web developer and of course safety issues fall into this category. For example, Django provides a mechanism for protection against cross site request forgery attempts, in which a malicious site can cause actions in the server by using the credentials of a logged-in user. The Django development team also uses a very strict process for dealing with new security issues in a timely and safe fashion by initially fixing these through private, confidential channels. Once the patches have been applied, the security issue is publicly disclosed, so that server maintainers can update to the latest Django version. As an example, this September a set of security releases were issued by the Django development team in order to remedy a problem with denial-of-service (DoS) attacks. Of course, after being informed of this release, we immediately updated the Django version running on our server to the latest one.
A second issue arising during web development, is the safety of a user's confidential data. Again Django provides an in-built authentication system which encrypts the password of all registered users using PBKDF2 (Password-Based Key Derivation Function 2). Beyond the Django security features, we also used a password protected storage server for the MySQL NRPSDesigner database.
In regards to the biological background of the NRPSDesigner software, we were particularly troubled about not leading a user astray with the organisms suggested for the cloning, especially in case they were not of the S1 safety level. This is particular important in the case of NRPS, because many interesting NRPS such as Pyoverdine, a fluorescent siderophore, are produced by pathogenic microorganisms (e.g. Pseudomonas aeruginosa). As of the European wiki freeze, the NRPSDesigner database includes only S1 organisms. Nevertheless, as in the future the database may be expanded with S2 organisms, we intend to handle such cases by issuing appropriate alert messages to the end-user and also allowing him to filter the domains available to his constructs based on the safety level.
A second consideration arises from the extensibility of the NRPSDesigner database, which means that any user can enter new NRPS domain sequences. These in turn are fed into the algorithm for the design of synthetic NRPS constructs. Thus it is important to ensure that no malicious sequence can be entered, which could then be returned as the output of the NRPSDesigner to an unsuspecting user. This is achieved by ensuring the correct domains have been entered by use of the automated domain prediction pipeline using Hidden Markov Models. Additionally, a user that wants to be particularly safe, can filter the domains available to the NRPSDesigner algorithm according to curation status. (Curated domains have been entered or validated by an iGEM Heidelberg or Edinburgh 2013 team member or by another NRPS specialist in contrast to domains that have been entered by other end-users.) The other non-NRPS sequences, such as backbones, promoters etc., which can be added to the constructs after the domains have been determined by the software, are specific to the user that entered them (e.g. by the automated interface to the API of the Parts Registry) and hence pose no danger to other users.
Another important safety issue arising from the theoretical underpinnings of the NRPSDesigner is its use for the malicious synthesis of toxic peptides. Thus in a future version we want to integrate information from databases on toxins in order disable the design of NRPS domains for toxic peptides. We also searched for peptide toxicity prediction tools which could be integrated with the NRPSDesigner. One such tool, called ToxinPred [gupta2013], uses machine learning methods and a dataset of 1805 toxic peptides in order to accomplish this very task. Unfortunately, the current implementation only considers peptides consisting of proteinogenic amino acids and not the variety of modified or D-amino acids available to NRP-synthetases.

Download Safety Form