Team:Heidelberg/HEARTBEAT gui
From 2009.igem.org
(→Further remarks) |
(→The secret romance between biologists and text editors) |
||
Line 43: | Line 43: | ||
==Point of departure== | ==Point of departure== | ||
- | === | + | === Biologists and text editors=== |
The conventional way to make the [[Team:Heidelberg/HEARTBEAT|HEARTBEAT]] project accessible to the synthetic biology community would be to publish the modeling part and | The conventional way to make the [[Team:Heidelberg/HEARTBEAT|HEARTBEAT]] project accessible to the synthetic biology community would be to publish the modeling part and |
Latest revision as of 03:47, 22 October 2009
HEARTBEAT-GUI: Your promoters your rulesContentsAbstractOnly after the development of interfaces which could translate between binary machine code and human language computers could unfold their full potential. Synthetic biology would greatly benefit from similarly interfaces for the quaternary code in which DNA saves genetic information. With HEARTBEAT (Heidelberg Artificial Transcription Factor Binding Site Engineering and Assembly Tool) we have conceived guidelines for the linguistic representation of genetic information. The proposed format is unambiguous enough for direct, computer based translation into DNA code. At the same time, it is abstract enough to be intelligible to humans. The notions used for this concept are built upon our propositions for the subpart-based modeling of the properties of biological parts. We have developed several perl algorithms to translate definitions of synthetic promoters into the proposed linguistic system and further into DNA-code. To facilitate the handling of this "language to DNA compiler", we created an interactive graphical interface (GUI) (HEARTBEAT-GUI). This GUI guides the user through the whole process of the promoter design, automatically providing the necessary information from the HEARTBEAT-database (DB) as well as real-time control of the user inputs. The interface allows the definition of general features of the desired promoter such as its length as well as the transcription factor binding sites (TFBS) to be inserted into the promoter. The input data is subsequently compiled into DNA-code which undergoes further optimization processes. The user can modify the DNA sequence between these steps with the help of a manual sequence curator embedded in the wiki.
HEARTBEAT logic IntroductionWhy do you spend too much time reading quaternary code?Computers save and process information in binary code whereas humans use completely different semantic systems comprising speech, alphanumerical texts and graphics. However, communication with computers is fairly easy because of interfaces which can translate between binary code and human language. Only after this abstraction of binary code was accomplished, computers could unfold their full potential. We believe that synthetic biology would greatly benefit from an analogous paradigm shift in the handling of genetic information: Cells save and process genetic information in the form of DNA and RNA representing i.e. quaternary code. Because this code is as unintelligible to us as binary code we need interfaces to translate between human language and DNA-code. Based on our proposition for the subpart-based modeling of the properties of biological parts, we have developed a concept to meet this challenge. Although this concept is versatilely applicable we will explain our approach on the basis of our implementation of this concept in the HEARTBEAT (Heidelberg Artificial Transcription Factor Binding Site Engineering and Assembly Tool) project. [TOP] Point of departureBiologists and text editorsThe conventional way to make the HEARTBEAT project accessible to the synthetic biology community would be to publish the modeling part and create an interface to access the parameters in the HEARTBEAT-database (DB). In order to be able to design a synthetic promoter, researchers would then need to acquaint themselves with the model, retrieve the data they are interested in and open their favorite text editor to implement the following algorithm:
Why is the design of synthetic promoters so complicated although we can resort to an elaborate model of their functional structure? Because in this example, the genetic information has mainly been processed in the form of quaternary DNA-Code. [TOP] The theoretical solutionDo you speak "subparts"?The example given above highlights the need for a representation of genetic information which can be better understood and easier edited than ACTG-code. The key to this problem is the ability to translate between a human semantic system and DNA-code. Bioinformatics have partially succeeded in the translation of DNA-code to human language. An example in the context of our project is the online tool Match [1] which receives a DNA-sequence as input and displays the TFBS in the sequence represented in alphanumeric code. But so far, there are only a very few tools to translate a linguistic representation of genetic information into DNA-code. One reason for this might be that the terms used to describe genetic informations have not provided the right level of abstraction: “A promoter which is active under hypoxic conditions and apoptotic cellular behavior” is an abstract representation of a functional unit of genetic information. But it is not possible to compile this information into DNA-code. It is too ambiguous – although this information is already described on the level of biological parts. Obviously, a linguistic representation of DNA-code on a lower level of abstraction – the level of subparts – is needed. To stick with the example above: If we describe the same promoter with subpart-notions, we achieve a balance of abstraction and unambiguousness intelligible for both computers and humans: “A promoter with only the following subparts: core promoter: TATA-Box; proximal promoter: "1 x TFBS for HIF (hypoxia induced factor) at optimal position, 1 x TFBS for NF". This subpart-based linguistic representation of genetic information achieves a balance of abstraction and unambiguousness intelligible for both computers and humans. We therefore defined the subpart notion as fundament of the input format for a DNA-code – human language interface. [TOP] Practical implementation(inter)action guarenteedThe straight forward solution would be to turn this input format into a full programming language. For this purpose the subpart-based input logic would have to be extended with a collection of functions and commands related to the creation and processing of genetic information. Furthermore a compiler which is able to directly translate the input format into DNA-code would be necessary. To design a promoter scientists would simply have to write a program code which could start like this:
This textfile would subsequently be interpreted by the compiler and the corresponding quaternary DNA code would be displayed. Second, the interface could be implemented as a graphical user interface (GUI) which would collect the necessary information through interactive formulars. This solution has major advantages over the use of a mere DNA programming language: The syntax for the assembly of subparts to valid genetic information is highly complex. The final function of a concatenation of subparts can for example be influenced by the positioning of or the interaction between different subparts. In addition, biological processes exhibit a variety of context dependent exceptions. An illustrative example is the context sensitivity of the biobrick alpha cloning standard [http://partsregistry.org/Assembly:RBS-CDS_issues]. Because of these difficulties, the work with a mere DNA programming language becomes very unhandy. Interactive graphical user interfaces can reduce this complexity: They can provide real-time control of user inputs. Moreover, the interface can display graphical information in order to support the current design step. They can also compute the implications of the input parameters that the user has already supplied. The final compilation of the input data into DNA-code can be carried out in separated steps allowing the user to control the process. [TOP] The HEARTBEAT-databaseNo more expression problems!The HEARBEAT GUI uses all these advantages to facilitate the design of synthetic promoters: The software ensures that the user provides all necessary input. In this context it checks whether the input data are reasonable in a biological context and if they can be matched by parameters in the data base. The user interface is permanently updated with helpful informations while the user is guided through the design process. For example, after a transcription factor is selected, the interface automatically provides the corresponding HEARTBEAT diagrams and auxiliary transcription factors. The compilation of the input data and the subsequent optimization of the DNA sequence is accomplished in several steps. The user can modify the DNA sequence between these steps with the help of an embedded manual sequence curator. A comprehensive documentation of the features of HEARTBEAT can be found here. [TOP] HEARTBEAT FeaturesSelecting initial parametersOn the first page of our GUI the users are requested to enter basic parameters determining the primary assembly of the promoter. The users only have to provide the final length of the construct assuming that the users will take the CMV core promoter from Part:BBa K203113 to complete their construct. In this case the length of the core is 80 bases and the transcription start site is 20 bases upstream regarding the end of the CMV promoter. Users who already possess a preferred promoter have the opportunity to specify its length and the location of the TSS in the advanced mode. The users are not able to enter values over 1000 base, since the frequency distributions for each transcription factor binding site (TFBS) stored in the HEARTBEAT-database (DB) range from 0 to 1000 bases upstream of the TSS. [TOP] Selecting main and auxiliary transcription factorsAs soon as the users submit their selected parameters, they are forwarded to the selection of the main transcription factor (TF), whose binding site is supposed to be integrated into the construct. The users have the possibility to choose between 144 different binding sites (respectively 144 TFs) which they can build in into their promoter. Before designing the promoter, one should be aware of a mechanism to exclusively induce the pathway where the TF is involved in. For further recommendations and information on how to create an experiment fulfilling this requirement, please read Induction. Once a primary TF is chosen two plots become visible. The first one shows the frequency histogram deduced from the HEARTBEAT-DB. The solid red line depicts the probability density function ( pdf) smoothing the TFBS distribution. The position of the vertical red line is stored in the background and later used in the final promoter assembly. After the sequence is automatically assembled the users will be able to modify the sequence by their own account. In case of multiple maxima the users can manually introduce further binding sites influenced by the pdf. In the second plot the frequencies of all co-occurring TFBS can be seen. The five most frequent occurring TFBS can be chosen in the next frames. Again the maxima of the respective pdf are stored by the program. [TOP] Selecting or entering a consensus motiveWhen all favored TFBS are chosen, the users are asked to either enter a known binding motive or select one out of the calculated possibilities. The selection comprises one possible binding motive of the chosen TFBS for each consensus matrix found in the Transfac database. Therefore all bases, which have only been defined by excluding other bases at that position (see [http://insilico.ehu.es/restriction/Nucleotide_ambiguity_code.html Ambiguity Code] e.g. M, R, W etc.) are replaced by either A, C, G or T in random process. This might lead to different selection each time this function is used. In order to determine the quality of a particular TF binding motive, we recommend to test the sequence with the open-source program TRAP and to use only binding motives with a high binding affinity. The selected or entered motive is together with the other earlier defined parameters finally transmitted to the crucial sequence assembly algorithm. [TOP] The assembly algorithmThe assembly algorithm represents the central program of the HEARTBEAT-GUI. As input parameters the algorithm needs the absolute promoter length, the core-promoter length, the TSS position relative to the end of the core-promoter, the chosen binding motives and their distance to the TSS. In an iterative process the algorithm attempts to locate first the main TFBS and then the auxiliary TFBSs at the position of their pdf-maxima. If the consecutive TFBS overlaps with the preceding one, the consecutive TFBS is randomly moved 1 base either to the left or to the right until a valid position is found. Every repositioning done by the algorithm can be read in a warning message in the output window. The final sequence is transferred into a TyneMCE open source web-editor in the end. Within this editor, the users can manually modify their sequence. If the users want to introduce new binding sites, they have to highlight the position in a different color in order to enable the program to recognize the position that should be changed. [TOP] Adding spacer sequence to the constructBy pushing the button add spacer sequence a small perl-based program introduces every chosen TFBS into a deposited random sequence at the pre-defined positions. From this sequence every restriction site used in any BioBrick standard has been removed. Furthermore we also eliminated every TFBS detected by the Transfac Match tool assuming the sequence to be TFBS free. [TOP] Test for restriction sitesWith this feature the users are enabled to test their final sequence for every restriction site used in BioBrick format. This program addresses the problem of newly evolving restriction sites at the cutting sites between random sequence and biding motive. The restriction site is manipulated systematically by altering single bases without touching the original binding motive. [TOP] Further remarksThe HEARTBEAT GUI pages provide an even more detailed documentation of the GUI features. Here you will also find a tutorial video which explains how to make optimal use of the GUI functions. The HEARTBEAT project will be continued beyond the iGEM competition. To always provide the most recent algorithm codes we decided to document the software of the GUI in a special section of the GUI web pages. [TOP] |