|
|
(3 intermediate revisions not shown) |
Line 1,577: |
Line 1,577: |
| <div class="text"> | | <div class="text"> |
| <h2>Database Standardization</h2> | | <h2>Database Standardization</h2> |
| + | <a href="https://static.igem.org/mediawiki/2010/6/6a/Metu_Turkey_Software_ER3.jpg"><img src="https://static.igem.org/mediawiki/igem.org/7/71/Metu_Software_ER3.png" /></a> |
| <p>Two main focuses of our project was the organization of the available | | <p>Two main focuses of our project was the organization of the available |
| information about Biobricks on iGEM’s website and development of a software | | information about Biobricks on iGEM’s website and development of a software |
Line 1,618: |
Line 1,619: |
| Information</h3> | | Information</h3> |
| <p>=========================================</p> | | <p>=========================================</p> |
- | <p>PartID:</p>
| + | <img src="https://static.igem.org/mediawiki/2010/d/d8/Character.png" /> |
- | <p>PartName:</p>
| + | |
- | <p>Bricks:</p>
| + | |
- | <p>BrickIDs:</p>
| + | |
- | <p>ImageIDs:</p>
| + | |
- | <p>RFC10:</p>
| + | |
- | <p>RFC21:</p>
| + | |
- | <p>RFC23:</p>
| + | |
- | <p>RFC25:</p> | + | |
| <p>=========================================</p> | | <p>=========================================</p> |
| <p><span>Table 1: The table above basically describes and designates | | <p><span>Table 1: The table above basically describes and designates |
Line 2,171: |
Line 2,166: |
| with more than 60% team participation. </li> | | with more than 60% team participation. </li> |
| </ul> | | </ul> |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <script type="text/javascript">if (window.runOnloadHook) runOnloadHook();</script>
| |
- | <div id="menu">
| |
- | <ul class="navmenu">
| |
- | <li>
| |
- | <div class="menutop menusingle">
| |
- | <a class="panel" href="#home">Home</a></div>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop menusingle panel">
| |
- | <a class="panel" href="#team">Team</a></div>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop menusingle panel">
| |
- | <a class="panel" href="#motivation">Motivation</a></div>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop menusingle panel">
| |
- | <a class="panel" href="#scope">Scope</a></div>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop">
| |
- | <a class="panel" href="#project">Project</a><div class="toggle toggle-closed">
| |
- | +</div>
| |
- | </div>
| |
- | <ul class="submenu">
| |
- | <li><a class="panel" href="#project">Introduction</a></li>
| |
- | <li><a class="panel" href="#project2">Design</a></li>
| |
- | <li><a class="panel" href="#project3">Material</a></li>
| |
- | <li><a class="panel" href="#project4">Methods</a></li>
| |
- | <li><a class="panel" href="#project5">Database Standardization</a></li>
| |
- | <li><a class="panel" href="#project6">Algorithm</a></li>
| |
- | <li><a class="panel" href="#project7">Modeling</a></li>
| |
- | <li><a class="panel" href="#project8">Results</a></li>
| |
- | </ul>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop menusingle panel">
| |
- | <a class="panel" href="#notebook">Notebook</a></div>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop panel">
| |
- | <a class="panel" href="#download">Download</a><div class="toggle toggle-closed">
| |
- | +</div>
| |
- | </div>
| |
- | <ul class="submenu">
| |
- | <li><a class="panel" href="#download">Executable</a></li>
| |
- | <li><a class="panel" href="#download2">Code</a></li>
| |
- | <li><a class="panel" href="#download3">User Guide</a></li>
| |
- | <li><a class="panel" href="#download4">Supporting Tools</a></li>
| |
- | <li><a class="panel" href="#download5">Contact</a></li>
| |
- | </ul>
| |
- | </li>
| |
- | <li>
| |
- | <div class="menutop panel">
| |
- | <a class="panel" href="#miscellaneous">Miscellaneous</a><div class="toggle toggle-closed">
| |
- | +</div>
| |
- | </div>
| |
- | <ul class="submenu">
| |
- | <li><a class="panel" href="#miscellaneous">Collaboration</a></li>
| |
- | <li><a class="panel" href="#miscellaneous2">Human Practices</a></li>
| |
- | <li><a class="panel" href="#miscellaneous3">Safety</a></li>
| |
- | <li><a class="panel" href="#miscellaneous4">Future Plan</a></li>
| |
- | </ul>
| |
- | </li>
| |
- | </ul>
| |
- | </div>
| |
- |
| |
- | </body>
| |
- |
| |
- | </html>
| |
- | for. </li>
| |
- | <li><strong>89% of participants have same opinion with us, which
| |
- | is that iGEM should sub-categorize the “WORKS” comment into 1) “Quantitative”
| |
- | for parts which are characterized with experiments and 2) “Qualitative”
| |
- | for parts which are not characterized will be an appropriate measure
| |
- | for standardization of Biobrick database.</strong> </li>
| |
- | </ul>
| |
- | <p><i>In order to overcome these problems we suggest enforcing the working
| |
- | conditions title for the registry entrance, in order to collect quantitative
| |
- | experimental details on submitted parts, which might slow down the registration
| |
- | process but will definitely increase the quality of the database.</i>
| |
- | </p>
| |
- | <ul>
| |
- | <li><strong>61% of participants agree that POPS (Polymerase Per
| |
- | Second) should be assigned to every part or biobricks with a promoter,
| |
- | where appropriate. - 57% of participants have been agree that RIPS
| |
- | (Ribosome per Second) should be assigned to every part or biobricks
| |
- | with a RBS brick.</strong> </li>
| |
- | </ul>
| |
- | <p>Though most participants agree the need for POPS and RBS information
| |
- | , they are concerned about the workload it would bring to individual
| |
- | labs. </p>
| |
- | <p>“To do this, the Registry need to define a reliable and easy method
| |
- | of determining the PoPS for teams to use. However, I would say that
| |
- | there are better systems for quantifying promoter output than PoPS,
| |
- | and they should be used instead, if possible”. </p>
| |
- | <ul>
| |
- | <li><strong>67% of participants have thought that entering POPS
| |
- | information should not be mandatory while submitting new parts.
| |
- | Similarly, 65% of participants disagree that entering RIBS information
| |
- | should be mandatory while submitting new parts </strong></li>
| |
- | </ul>
| |
- | <p>Even though the researchers feeling the need for this information
| |
- | they are shying away from requesting it as a mandatory title for parts
| |
- | registry as it would be difficult for underfunded and inexperienced
| |
- | groups to perform these measurements. </p>
| |
- | <p><i>We strongly suggest starting a forum on how to quantify the performance
| |
- | of promoters and genes to bring an easy to measure standard for the
| |
- | efficiency of the parts. Additionally iGEM should the responsibility
| |
- | and provide the measurements for the each promoter and gene included
| |
- | in the distributions. The second choice would be even better in terms
| |
- | of standardization as all the measurement will be performed by one center
| |
- | under similar conditions and with experienced researchers, which will
| |
- | allow user to compare and contrast the efficiencies of the parts more
| |
- | accurately. </i></p>
| |
- | <ul>
| |
- | <li><strong>82% of participants have thought that information on
| |
- | working conditions of the parts should be mandatory while submitting
| |
- | new parts.</strong> Most find submiting the detailed experimental
| |
- | information and working conditions is crucial and even easier than
| |
- | submitting measurements of POPS or RBS. </li>
| |
- | </ul>
| |
- | <h4>Definitions you would like to see at the Registry of Standard Parts
| |
- | </h4>
| |
- | <ul>
| |
- | <li><strong>Transcriptional efficiency 13%</strong> </li>
| |
- | <li><strong>Protein lifetime 10%</strong> </li>
| |
- | <li><strong>Ribosome binding efficiency 10%</strong> </li>
| |
- | <li><strong>mRNA lifetime 9%</strong> </li>
| |
- | <li><strong>Translation initiation and efficiency 9%</strong>
| |
- | </li>
| |
- | <li><strong>Protein concentration 9%</strong> </li>
| |
- | <li><strong>Cooperative effects with other molecules 9%</strong>
| |
- | </li>
| |
- | <li><strong>Protein-DNA binding rates and efficiencies 8%</strong>
| |
- | </li>
| |
- | <li><strong>RNA polymerase affects 8% </strong></li>
| |
- | <li><strong>System copy count 8%</strong> </li>
| |
- | <li><strong>Protein multimerization 6%</strong> </li>
| |
- | </ul>
| |
- | <p>Additional titles includes: Catalytic rates and affinities for substrates,
| |
- | leakiness of promoter in lack of stimulus, POPS at various inducer/repressor
| |
- | concentrations. </p>
| |
- | <h4>Efficiency of the Database Entries </h4>
| |
- | <ul>
| |
- | <li><strong>86% of participants would like to see a ranking/rating
| |
- | system for the parts by the other iGEM users which will be one indication
| |
- | of if a part is working and how well in different laboratories.</strong>
| |
- | Few had concerns about how well the rating system will work for
| |
- | rarely used parts while the widely used parts would even more popular
| |
- | due the the rating system. Still many believes this would be one
| |
- | futher towards a peer-reviewed quality control system for the parts.
| |
- | </li>
| |
- | <li><strong>61% of participants agreed that parts should be updated
| |
- | regularly by the designers, where most agreed at least when there
| |
- | is new information on the parts.</strong> It has also been suggested
| |
- | to give permission to all the users of that part for updating information.
| |
- | </li>
| |
- | <li><strong>73% of participants have been agree with us that excluding
| |
- | the low ranking parts or the parts with negative feedback from the
| |
- | future plates will increase efficiency of the system.</strong> The
| |
- | major concern about excluding any part is losing the variety of
| |
- | parts in the database. Few recommends excluding only the parts that
| |
- | are not working. </li>
| |
- | </ul>
| |
- | <p>“Efficiency shouldn't be top priority in a database. First and foremost,
| |
- | data is the top priority. Excluding those parts would make the system
| |
- | more efficient” </p>
| |
- | <p>“Some parts may be rare or new and have low efficiency, but can be
| |
- | very important! Getting rid of them would eliminate any chance of improvement
| |
- | to these parts, which not only a qualifier for an iGEM gold medal, but
| |
- | also one of the focuses of biobricks.” </p>
| |
- | <p><i>We suggest excluding the parts not-working, low rated or with
| |
- | negative feedbacks from the annual distribution plates but still archive
| |
- | them and make their data available through the parts registry. So the
| |
- | while the individuals labs are receiving plates with higher rated, fully
| |
- | working parts for their projects, anyone who wants to work on a more
| |
- | exotic part can search through the achieves and re-vitalize the parts
| |
- | stored there. The challenge of re-vitalization of parts can be encouraged
| |
- | as an collaborative effort.</i> </p>
| |
- | <h4>New Options for the Parts Registry Database </h4>
| |
- | <ul>
| |
- | <li><strong>96% of participants are like minded with us that it
| |
- | will be useful to have a link out to the gene/protein information
| |
- | of the parts and - %97 of participants have been agree that they
| |
- | would like to know if a part is also involved in known biological
| |
- | pathways.</strong> </li>
| |
- | </ul>
| |
- | <p><strong>For receiving pathway information more participants have
| |
- | voted for NCBI Cog (59%) than KEGG pathways (38%) when the responses
| |
- | for both has been distributed among the choices according to response
| |
- | rates.</strong> Adding the blast option to the parts registry has also
| |
- | been suggested to locate parts of interest. We are sure all of us would
| |
- | like to see gene-protein and pathway information if these information
| |
- | was integrated into the database and offered automatically for each
| |
- | entry in the database.</p>
| |
- | <p><i>We are planning to provide this information about the parts to
| |
- | all parts registry users as a build-in option in the next version of
| |
- | BioGuide in iGEM 2011. </i></p>
| |
- | <h4>NEW PARTS REGISTRY FORM SUGGESTED FOR THE NEW STANDARDS</h4>
| |
- | <p><a href="">Link out to the form</a></p>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 2nd row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project2" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Design</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="download2" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Code</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div id="miscellaneous2" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Human Practices</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 3rd row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project3" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Material</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="download3" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>User Guide</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div id="miscellaneous3" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Safety</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 4th row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project4" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Methods</h2>
| |
- | <h3>Part Extraction Standards</h3>
| |
- | <p>All information about the parts that are essential in experimental
| |
- | setup of iGEM projects has been utilized. The information for the parts
| |
- | available provided with all three 384 well plates in Spring 2010 distribution
| |
- | have been standardized. Our standardization criteria have been discussed
| |
- | in detail under Database Standardization. ER diagram has been generated
| |
- | which simply describes the organization of the data. Around 70% of the
| |
- | parts information has been fetched by the custom parsing code from XML
| |
- | and Excel files provided by iGEM. Rest of the data had to be collected
| |
- | and organized manually as the organization of these data cannot be standardized
| |
- | to generate an algorithm. This step was one of the most time consuming
| |
- | steps in our project. For each construct and Biobrick the information
| |
- | collected was; Activity, Inducer, Activator, Repressor and Inhibitor
| |
- | for promoters and Inducer, Activator, Repressor and Inhibitor information
| |
- | valid for synthesized molecules (mostly proteins and RNA fragments etc.)</p>
| |
- | <h3>Combination</h3>
| |
- | <p>Rules (Image Combinations) In order to build our input/output relations
| |
- | graphs first we run our algorithm on the real combination dataset which
| |
- | contains all few thousand different possible combinations of the biobricks.
| |
- | But after performing all combinations for the first few hundred biobricks
| |
- | application’s rate slowed downed tremendously, which also become very
| |
- | time consuming for displaying biobricks graphs. To overcome this bottleneck
| |
- | we have developed a new strategy, where we have only used the construct
| |
- | combinations of the biobricks distributed within the plates. Moreover,
| |
- | according to information gathered from the subparts of the constructs
| |
- | distrubuted, we also collected the subpart assembly order, such as 1st:
| |
- | promoter, 2nd:rbs, 3rd:coding seq, any internal parts and the Last:
| |
- | terminator. Each specific Biobrick type has been assigned a number as
| |
- | a unique image ID from 1 to 19. Gathering the information on subparts
| |
- | was not a direct forward process. ImageID assembly orders for each construct
| |
- | has been used to extract the type information for each subpart with
| |
- | that construct. This innovative approach helped us to reveal 400 possible
| |
- | brick combinations present within the 3x384 well plates distributed
| |
- | by iGEM in Spring 2010.</p>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="download4" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Supporting Tools</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div id="miscellaneous4" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Future Plan</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 5th row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project5" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Database Standardization</h2>
| |
- | <img src="https://static.igem.org/mediawiki/igem.org/d/d9/Metu_Software_ER.png" />
| |
- | <p>Two main focuses of our project was the organization of the available
| |
- | information about Biobricks on iGEM’s website and development of a software
| |
- | application to help synthetic biologists at the experimental set-up
| |
- | level by providing all available construct combinations for any given
| |
- | input and output relations ,which they can utilize for their own project.</p>
| |
- | <p>Normalization and re-organization of the part information at iGEM’s
| |
- | web site was needed in order to develop our application, which will
| |
- | automatically search the possible construct combinations. For the organization
| |
- | and analysis of the Biobricks, we used part info for Spring 2010 distribution.
| |
- | The information on all three 384 well plates distributed by iGEM scrutinized
| |
- | and checked individually to specify the standards available and needed.
| |
- | iGEM is providing so many parts within a hierarchical way, but there
| |
- | is no order in the information flow and no common standards. Furthermore,
| |
- | the information bulk is being used in an ineffective manner. Some of
| |
- | the parts distributed are known to be nonfunctional. Web pages for parts
| |
- | contain lots of information, but majority of them, are again not ordered.
| |
- | Moreover, some additional information had to be removed or replaced
| |
- | in such a way that the information for parts can be used effectively.
| |
- | And removal of the redundant bulk information related with parts at
| |
- | iGEM’s web site had been recommended for future. </p>
| |
- | <p>Although, the final standardization, which we have suggested is not
| |
- | for general public use and it was urgently needed in order to satisfy
| |
- | the needs of our algorithm. But, still it will be a valuable resource,
| |
- | since it summarizes the basic information about the parts.</p>
| |
- | <p>As the first step to build the proposed standardization template,
| |
- | the headings selected related to parts are listed on Table 1. Submission
| |
- | of part IDs for individual parts is an accepted and quite valuable way
| |
- | of tracking information. Although, every part has unique partID, for
| |
- | every part there is a need to assign unique part names as official iGEM
| |
- | names. Part names will have an important role as they will be providing
| |
- | the short description about the part, which synthetic biologists can
| |
- | immediately recognize and utilize during the construction of unique
| |
- | Biobricks. Additionally unique part names will be helpful to identify
| |
- | the devices with more than one Biobrick in their constructs. Assignment
| |
- | of unique and distinct names for parts describing their nature and content
| |
- | will be helpful to researchers for the recognition of and search for
| |
- | the parts.</p>
| |
- | <br>
| |
- | <h3>Headings Selected From Previous Entry Forms for Indication of Standardized
| |
- | Information</h3>
| |
- | <p>=========================================</p>
| |
- | <p>PartID:</p>
| |
- | <p>PartName:</p>
| |
- | <p>Bricks:</p>
| |
- | <p>BrickIDs:</p>
| |
- | <p>ImageIDs:</p>
| |
- | <p>RFC10:</p>
| |
- | <p>RFC21:</p>
| |
- | <p>RFC23:</p>
| |
- | <p>RFC25:</p>
| |
- | <p>=========================================</p>
| |
- | <p><span>Table 1: The table above basically describes and designates
| |
- | qualities of parts which identifies their compositions and demonstrates
| |
- | the status of previously assigned standards. PartID refers to the unique
| |
- | ID number for parts including atomic parts and assemblies. PartName
| |
- | refers to the given unique names to parts. Bricks, refers to the shortcut
| |
- | names which specifies atomic parts. ImageIDs, refers to individual or
| |
- | combination of numbers that are assigned by us. RFCs refers to the states
| |
- | of parts based on RFC standards.</span></p>
| |
- | <p>iGEM both provides individual, atomic parts and pre-combined constructs
| |
- | such as devices and systems. Availability of combined constructs is
| |
- | important to the researchers as combining individual bio-bricks one
| |
- | at a time will be very time consuming. These previously merged constructs,
| |
- | serve as the repository for puzzle and they can be used for different
| |
- | purposes. Up to date the largest and most trustworthy source, for synthetic
| |
- | biology and its components, is iGEM’s parts registry. In 2010, iGEM
| |
- | provided over 1000 parts that have initiated many projects. Having more
| |
- | atomic parts available in the iGEM’s repository, will lead to the design
| |
- | of more complex and robust constructs, and we would have a better chance
| |
- | to design different constructs for unique purposes. Also, for the parts
| |
- | that are already available, extra steps needs to be taken for the quality
| |
- | control and surveillance of these products. The quality control of the
| |
- | information for the parts is essential for the future of iGEM and synthetic
| |
- | biology. Even though we have found pre-determined RFC standards useful
| |
- | and included those to our standardized template, some individual parts
| |
- | still requires re-organization of the information as RFC standards alone
| |
- | for the functionality of parts, does not satisfy the needs for wet lab
| |
- | biologists.</p>
| |
- | <p>Without a question there is an urgent need to build a distinct and
| |
- | specific database well organized with its own standards for synthetic
| |
- | biology; however, development of such a database is not an easy task.</p>
| |
- | <br>
| |
- | <h3>Contact Information of Part Owners and Qualitative Group Comments
| |
- | about Parts</h3>
| |
- | <p>=========================================</p>
| |
- | <p>Designers: Mail:</p>
| |
- | <p>GroupFavorite:</p>
| |
- | <p>StarRating:</p>
| |
- | <p>Parameters:</p>
| |
- | <p>=========================================</p>
| |
- | <p><span>Table 2: The above table simply depicts information about possessors
| |
- | of parts and their contact information and the popularity of the parts
| |
- | for groups. Parameters heading, refers distinctive experimental details
| |
- | unique to the usage of parts which should be decided by groups.</span></p>
| |
- | <p>Second step for building the standardized template was to get the
| |
- | phylogenic information about the parts development process which includes
| |
- | the name of the group, designer and contact information, along with
| |
- | the comments from the group on the parts they have submitted. Contact
| |
- | information is especially important for iGEM as other groups who need
| |
- | extra information about the available part can reach to the required
| |
- | information. Even though contacting with the designers of the individual
| |
- | parts which are available is highly encouraged by iGEM, unavailability
| |
- | of contact information points at out the fact that iGEM’s parts registry
| |
- | needs strong re-organization in order to serve to the synthetic biology
| |
- | community properly.</p>
| |
- | <p>Additionally, the “group favorite” and “starRating” fields are also
| |
- | important for individual evaluation of the parts, which doesn’t get
| |
- | the deserved attention from the iGEM groups. “Group Favorite” defines
| |
- | the confidence on the part by the designer group. “StarRating” defines
| |
- | the related part in terms of popularity and usage efficiency among the
| |
- | groups. According to our observations, most groups are not aware of
| |
- | either of the fields or they are used incorrectly or ineffectively.
| |
- | For example for a part with a full reporter which is known to be functional
| |
- | and gives precise and expected results the StarRating should be at least
| |
- | 2 stars, but for most of the parts in 2010 distribution, it is very
| |
- | difficult to observe a part whose “StarRating” is above one. For quick
| |
- | determination of functionality of the parts these two evaluations are
| |
- | important so they have been included in the proposed standardization
| |
- | template. But, as they were not properly used up to now for the re-organization
| |
- | of the parts information during the development of our software application
| |
- | we had to include all parts to our queries regardless of their evaluations
| |
- | based on “Group Favorites” and “ StarRatings”</p>
| |
- | <p>Second step for building the standardized template was to get the
| |
- | phylogenic information about the parts development process which includes
| |
- | the name of the group, designer and contact information, along with
| |
- | the comments from the group on the parts they have submitted. Contact
| |
- | information is especially important for iGEM as other groups who need
| |
- | extra information about the available part can reach to the required
| |
- | information. Even though contacting with the designers of the individual
| |
- | parts which are available is highly encouraged by iGEM, unavailability
| |
- | of contact information points at out the fact that iGEM’s parts registry
| |
- | needs strong re-organization in order to serve to the synthetic biology
| |
- | community properly.</p>
| |
- | <p>Additionally, the “group favorite” and “starRating” fields are also
| |
- | important for individual evaluation of the parts, which doesn’t get
| |
- | the deserved attention from the iGEM groups. “Group Favorite” defines
| |
- | the confidence on the part by the designer group. “StarRating” defines
| |
- | the related part in terms of popularity and usage efficiency among the
| |
- | groups. According to our observations, most groups are not aware of
| |
- | either of the fields or they are used incorrectly or ineffectively.
| |
- | For example for a part with a full reporter which is known to be functional
| |
- | and gives precise and expected results the StarRating should be at least
| |
- | 2 stars, but for most of the parts in 2010 distribution, it is very
| |
- | difficult to observe a part whose “StarRating” is above one. For quick
| |
- | determination of functionality of the parts these two evaluations are
| |
- | important so they have been included in the proposed standardization
| |
- | template. But, as they were not properly used up to now for the re-organization
| |
- | of the parts information during the development of our software application
| |
- | we had to include all parts to our queries regardless of their evaluations
| |
- | based on “Group Favorites” and “ StarRatings”</p>
| |
- | <br>
| |
- | <h3>Input and Output Characteristics of Parts</h3>
| |
- | <p>=========================================</p>
| |
- | <p>Parameters:</p>
| |
- | <p>-Input:</p>
| |
- | <p>• Promoter:</p>
| |
- | <p>• Activity:</p>
| |
- | <p>• Inducer:</p>
| |
- | <p>• Activator:</p>
| |
- | <p>• Repressor:</p>
| |
- | <p>• Inhibitor:</p>
| |
- | <p>• Promoter2:</p>
| |
- | <p>• Activity:</p>
| |
- | <p>• Inducer:</p>
| |
- | <p>• Activator:</p>
| |
- | <p>• Repressor:</p>
| |
- | <p>• Inhibitor:</p>
| |
- | <p>-Output:</p>
| |
- | <p>• Reporter:</p>
| |
- | <p>• Reporter2:</p>
| |
- | <p>• Regulator:</p>
| |
- | <p>• Inducer:</p>
| |
- | <p>• Activator:</p>
| |
- | <p>• Repressor:</p>
| |
- | <p>• Inhibitor:</p>
| |
- | <p>• Regulator2:</p>
| |
- | <p>• Inducer:</p>
| |
- | <p>• Activator:</p>
| |
- | <p>• Repressor:</p>
| |
- | <p>• Inhibitor:</p>
| |
- | <p>-Working Condition:</p>
| |
- | <p>=========================================</p>
| |
- | <p><span>Table 3: The table above elaborately describes the input relations
| |
- | based on promoters and the output products based on the functional genes
| |
- | and RNAs which are included within the parts. Working condition simply
| |
- | describes any influencing factor or circumstance which is directly related
| |
- | with the functional properties of parts.</span></p>
| |
- | <p>Third part of our standardization template includes parameters of
| |
- | contingent input and output elements. These parameters are classified
| |
- | into two groups for simplicity as presented on Table 3. This final part
| |
- | of the standardization template includes the upmost important information
| |
- | about the Biobricks that are required for the BioGuide Software to run
| |
- | its searching algorithm.</p>
| |
- | <p>Briefly, BioGuide application is designed to catch the input and
| |
- | output relations of individual parts to examine possible Biobricks pathways
| |
- | for specific input and output queries. In other words, at pre-experimental
| |
- | stage, it helps wet lab biologists to design their unique constructs
| |
- | by revealing possible alternative options for pre-determined purposes,
| |
- | along with the primary paths. Our ultimate goal is to improve the algorithm
| |
- | designed for iGEM 2010 and present a new version of the BioGuide in
| |
- | iGEM 2011, which will provide optimum design of constructs for predetermined
| |
- | parameters.</p>
| |
- | <p>Most of the parts are composed of functional and nonfunctional constructs
| |
- | which are formed by atomic parts. And every part should carry the information
| |
- | for all of its atomic parts within itself. The “input” heading actually
| |
- | stands for promoters. Parts with one or more promoters can be found
| |
- | at iGEM’s Parts Registry. Along with the information on which and how
| |
- | many promoters a part might have, the activity level of promoters are
| |
- | also important to distinguish between a constitutively active promoter
| |
- | or a promoter activated by specific physiological processes or states
| |
- | etc. This information was crucial for us to dissect in order to run
| |
- | our algorithm as it directly affects which inputs can activate the devices
| |
- | or the systems.</p>
| |
- | <p>Throughout our investigations on the Parts Registry, we found out
| |
- | that much of the terminology was being used ambiguously. Although this
| |
- | might not be vital for synthetic biologists, it is still endeavoring
| |
- | to understand the function of certain regulatory elements which also
| |
- | becomes a time consuming task for the researcher. Thus, we recommend
| |
- | that the explanations of certain regulatory elements should be redefined
| |
- | and fixed especially for synthetic biology for easy communication, sharing
| |
- | and searching of information.</p>
| |
- | <p>Common misuses of the terminology can guide us to figure out how
| |
- | to construct a standard nomenclature for synthetic biology. We claim
| |
- | that a standard nomenclature is urgently needed for synthetic biology
| |
- | for the following reasons. First of all, synthetic biology is an emerging
| |
- | research discipline and an industrial application area which is highly
| |
- | promising. Secondly, redefinition of the terminology to build a standard
| |
- | nomenclature is needed as some of the terms are prone to be used instead
| |
- | of another causing problems related to misuse for the global communication
| |
- | about synthetic biology. Lastly, the nomenclature has major importance
| |
- | for the construction of a persistent and trustworthy database for synthetic
| |
- | biology which serves for the information exhibition and exchange globally.
| |
- | For instance, there are obvious misunderstandings about the words which
| |
- | are predominantly used for regulation process. We have noticed that,
| |
- | the terms “inhibitor” and “repressor” are being used as equivocally
| |
- | in the part information pages. Like the lactose inhibitor protein, a
| |
- | widely used DNA-binding transcriptional repressor, that have been labeled
| |
- | both as “inhibitor” and “repressor” at iGEM’s Parts Registry. Similar
| |
- | problems resulting from ambiguous use of terminology also observed with
| |
- | regulatory elements. To sum up, we investigated all input elements for
| |
- | promoters and classify these elements in terms of their function, affect
| |
- | and required input element for them. So, we suggest that terminology
| |
- | used for regulation of transcription should be defined clearly on iGEM’s
| |
- | website and correct use of terminology should be enforced.</p>
| |
- | <p>The second group of parameters was collected under the title “Output”,
| |
- | which refers to products of functional genes. In contradiction, the
| |
- | term “reporter” has also been described within the same list. Reporters
| |
- | are also genes whose products, can be used for screening as an output.
| |
- | According to our group, the usage of the term “reporter” for genes is
| |
- | unnecessary and cause extra complexity for information distribution
| |
- | and gives rise to discrepancies. Instead of using the term “reporter”,
| |
- | predefined “gene” description should be used for genes, which can function
| |
- | as reporters. The special information which is related with the characteristic
| |
- | of that gene should also be presented on part info web page.</p>
| |
- | <p>Furthermore, the same terminology “reporter” was used for both atomic
| |
- | parts and composite bio-bricks. Also the overall image descriptions
| |
- | for these were defined as “reporters”. We want to point out that using
| |
- | same nomenclature for both atomic genes and for whole functional constructs
| |
- | contributes to the complexity and makes specific explorations difficult
| |
- | through the Parts Registry. So, assigning “reporter” for both atomic
| |
- | parts and for whole constructs is not a good practice. Instead, we are
| |
- | suggesting the usage of other available terminology for the parts listed
| |
- | as reporters, which most of the constructs, now known as reporters,
| |
- | can be grouped into, such as “protein generators”, “composite parts”
| |
- | or “inverters”.</p>
| |
- | <p>Devices are whole constructs which are functional and have specific
| |
- | and distinct functions. But, as we have observed, unfortunately, the
| |
- | term “device” is also being used for parts which are not functional
| |
- | and do not have specific functional at all. Moreover, within the classification
| |
- | of devices, we argue that some terms are also being used unnecessarily
| |
- | and ambiguously. Devices are classified into five types which are protein
| |
- | generators, reporters, inverters, receivers and senders, measurement
| |
- | devices. For example iGEM defines protein generators as:</p>
| |
- | <p>Protein generator = promoter + rbs +gene + terminator</p>
| |
- | <p>Though we accept the definition for protein generators, we observed
| |
- | that there exist numerous parts which are defined as protein generators
| |
- | but actually most of them do not fit to the definition provided above.
| |
- | Although some parts are not functional and do not generate proteins
| |
- | at all, they are classified as protein generators, which makes searching
| |
- | for the parts difficult in the registry. Furthermore, there are also
| |
- | numerous parts which are defined as “composite parts” but actually they
| |
- | fit to the same definition with protein generators. In order to overcome
| |
- | the problem of misuse of device type we have extracted related image
| |
- | ID information for the composite parts. Image ID information helped
| |
- | us to correctly categorize composite parts depending on its individual
| |
- | atomic parts and identify the ones with more than one function, such
| |
- | as being both inhibitor and activator. In other words, we used image
| |
- | and part IDs in order to merge an input for its outputs.</p>
| |
- | <p>Subtitle working conditions, includes all the detailed information
| |
- | about the experimental properties of parts, and the details about the
| |
- | working process of individual parts and complete devices. Additionally,
| |
- | we marked the subtitle “Working Condition” in our standardization template
| |
- | as potentially the most important title that helps synthetic biologist
| |
- | to better understand the parts functions at iGEM’s part registry database.
| |
- | The main problem we have encounter with the subtitle “working condition”
| |
- | is within most of the parts the details about working process is not
| |
- | enough and not provided regularly. </p>
| |
- | <br>
| |
- | <h3>Examples of Misuse of Terminology:</h3>
| |
- | <h4>For Composite Parts:</h4>
| |
- | <p>PartID: BBa_S04055</p>
| |
- | <p>PartName: Synthetic lacYZ operon</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/a/ac/Metu-database1.png" />
| |
- | <p>This part is functional and responsible for the production of LacY
| |
- | and LacZ proteins. This part partially fits the definition for “composite
| |
- | part” but actually should be a protein generator as it fits fully to
| |
- | the definition of “protein generators”.</p>
| |
- | <h4>For Protein Generators:</h4>
| |
- | <p>PartID: BBa_J45299</p>
| |
- | <p>PartName: PchA & PchB enzyme generator</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/2/2c/Metu-database2.png" />
| |
- | <p>The part which is illustrated above actually fits the definition
| |
- | for “composite part” but in part registry it is classified as protein
| |
- | generator. This part can be functional but it needs a promoter. Even
| |
- | though this part is not functional and is not capable of producing protein,
| |
- | part registry assigns this product as protein generator. We suggest
| |
- | that all parts in the registry, which are composed of more than one
| |
- | atomic part and which are not functional on their own but can be functional,
| |
- | should be classified as “composite parts”.</p>
| |
- | <h4>For Reporters:</h4>
| |
- | <p>PartID: BBa_J04451</p>
| |
- | <p>PartName: RFP Coding Device with an LVA tag</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/0/0a/Metu-database3.png" />
| |
- | <p>This functional part is classified as “Reporter” in the parts registry
| |
- | database. It is very clear that this part fits the same description
| |
- | as Protein Generator in Biobrick part registry standards. Although,
| |
- | this part has specific and known functional role, characterizing this
| |
- | part as a reporter is unnecessary and contributes to the level of complexity
| |
- | of information provided. Instead, we suggest that this part should be
| |
- | classified as “protein generator” and related detailed information about
| |
- | the specific function of this part, should be provided in the part information
| |
- | page.</p>
| |
- | <p>In conclusion, as mentioned above we tried to reorganize and normalize
| |
- | the information about parts which is provided in part registry for 2010
| |
- | in order to develop our algorithm for the BioGuide application. During
| |
- | this process, we encountered some inconsistencies and misuses of the
| |
- | terminology being used and also inadequacies about the information provided
| |
- | about parts. First of all, we claim that a standard nomenclature should
| |
- | be constituted for future use in the field of synthetic biology. Based
| |
- | on the information gathered according to new nomenclature a professional
| |
- | database should be constructed to address the needs of synthetic biology.
| |
- | This will enable easy information exchange and exhibition globally.
| |
- | Secondly, although there are enough information about parts exists on
| |
- | parts registry database, the information which is provided for parts
| |
- | need to be ordered urgently. Furthermore, there should be new experimental
| |
- | standards which must be introduced to groups in the part submission
| |
- | process for the subtitle “working condition”. These experimental standards
| |
- | will be important because the experimental details about parts are not
| |
- | satisfying the needs of wet-lab biologists for the design and the construction
| |
- | of new Biobricks.</p>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="download5" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Contact</h2>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 6th row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project6" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Algorithm</h2>
| |
- | <p>In this section, the step by step functioning of our application,
| |
- | along with the encapsulation of the algorithmic concepts of ‘standardization’
| |
- | of functional iGEM devices are depicted in pictorial forms called flowcharts.
| |
- | Rectangular boxes represent the encapsulation of implementations of
| |
- | the computer programs to perform the particular tasks stated in that
| |
- | box on the flowcharts. These boxes are sometimes called subprograms,
| |
- | objects or packages in Object Oriented software Engineering context.
| |
- | The diamonds represent decision branching and they are found between
| |
- | two rectangular boxes. The arrows show the direction in which subprograms
| |
- | work and communicate. The subprogram at the head of the arrow starts
| |
- | executing after the termination of the subprogram at the tail of the
| |
- | arrow. Following flowcharts are the high level representations of our
| |
- | algorithms developed for the BioGuide software.</p>
| |
- | <br>
| |
- | <h3>1</h3>
| |
- | <img src="https://static.igem.org/mediawiki/2010/9/95/Metu-algorithm1.png" />
| |
- | <p><span>Diagram 1. Flowchart of collection, formatting and storage
| |
- | of devices data algorithm</span></p>
| |
- | <p>Information about the iGEM parts had to be collected in a standardized
| |
- | format for our application to function properly. Following data collection
| |
- | custom subprograms is needed to parse and forward the data the application’s
| |
- | database. In order to achieve this we have designed and implemented
| |
- | the algorithm shown in diagram 1. In this algorithm, the first stage
| |
- | was to find the list of part IDs of devices which were supplied by iGEM
| |
- | in Spring 2010 distribution. This information has been collected from
| |
- | two sources 1) plate files in excel format which was available online
| |
- | 2) device data provided in xml format, both provided by iGEM. The last
| |
- | step in the algorithm was to send the collected partID data to the application’s
| |
- | database.</p>
| |
- | <br>
| |
- | <h3>2.</h3>
| |
- | <img src="https://static.igem.org/mediawiki/2010/e/e6/Metu-algorithm2.png" />
| |
- | <p><span>Diagram 2. Flowchart for BioGuide execution before and during
| |
- | user interaction</span></p>
| |
- | <p>Diagram 2 presents the main algorithm, which shows how BioGuide application
| |
- | works. In BioGuide the major components are device and Biobrick graphs.
| |
- | While the device graph represents input-output (promoter-regulator)
| |
- | compatibility combination of iGEM devices, the Biobrick graph represents
| |
- | combinations of atomic parts assembled in a device or system. The flowchart
| |
- | shows how these graphs are created and embedded into the program, which
| |
- | displays both of the graphs to the user when launched. Application presents
| |
- | few interactive options to the user when started, which were shown on
| |
- | the flowchart under the horizontal, bolded line. As shown on the diagram
| |
- | 2, there are four interactive tasks BioGuide can do, where the device
| |
- | and Biobricks graphs are utilized. Upon clicking a node on a devices
| |
- | or Biobricks graph, that node changes in size and color and the various
| |
- | functions shown on the flowchart can be performed then after.</p>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 7th row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project7" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Modeling</h2>
| |
- | <h3>Graphical Modeling for Bio-Guide</h3>
| |
- | <h4>Introduction</h4>
| |
- | <p>Graphical Modeling Theory has been applied to construct four different
| |
- | graphs where relations of atomic parts, devices and systems and the
| |
- | functional combinations that can build new constructs are presented
| |
- | for the iGEMs parts registry database. Three graphs are composed of
| |
- | iGEM devices and one graph is based on Biobricks. Each graph comprises
| |
- | a set of vertices or nodes and a set of edges. In the set of nodes each
| |
- | node represents a device, while in the set of edges each edge represents
| |
- | the input-output combination of the nodes. These graphs are directed
| |
- | graphs as the edges are created according to input-output combination.
| |
- | All compatibilities between a regulator and a promoter of an edge is
| |
- | created, where the source of this edge is the device with the corresponding
| |
- | regulator and target of the edge is the device with the promoter in
| |
- | concern.</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/3/3f/Metu-node1.png" />
| |
- | <p><span>Fig. 1: A node representing a device</span></p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/1/14/Metu-node2.png" />
| |
- | <p><span>Fig. 2: Arrow representing an edge between two nodes</span></p>
| |
- | <p>The atomic structures used in our graphical model have been represented
| |
- | in Figures 1 and 2. A node is represented with a solid circle where
| |
- | the label, the part/device ID according to iGEM standards, of the device
| |
- | is marked on the foreground. The blue arrows between nodes connect the
| |
- | related devices, representing the input-output connectivity. End style
| |
- | of the arrow helps us to determine the direction of the node, like in
| |
- | Figure 2 where the node labeled BBa_S03520 is the source and BBa_JO9250
| |
- | is the target.</p>
| |
- | <br>
| |
- | <h3>Directivity</h3>
| |
- | <p>All the four constructed graphs build for BioGuide are directed graphs.
| |
- | So that, for every edge there must be a single source and a target.
| |
- | There is no single edge which is bidirectional. In mathematical form
| |
- | this can be represented as:</p>
| |
- | <p>If an edge e has node v as source and node w as target then the edge
| |
- | can be expressed as</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/6/6c/Metu-equation1.png" />
| |
- | <p>For a directed graph the combination (v, w) is totally different
| |
- | from (w, v). Therefore,</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/a/ac/Metu-equation2.png" />
| |
- | <p>The direction of the edges has been represented with the arrows,
| |
- | as explained in Figure 2.</p>
| |
- | <br>
| |
- | <h3>Connectivity</h3>
| |
- | <p>The nodes forming their own sub-graphs disconnected from the rest
| |
- | of the nodes have been recognized, which showed us the presence of incompatibility
| |
- | between few regulators and promoters of the devices. We have observed
| |
- | this disconnection in all four of our graphs. The basis of the disconnection
| |
- | has been shown in Figure 3, where the two sub-graphs without any edge
| |
- | that connects them to the main graph has been presented on the right
| |
- | hand side of the diagram. These features classify our graphs as disconnected
| |
- | graphs [1].</p>
| |
- | <img src="https://static.igem.org/mediawiki/2010/8/8b/Metu-node3.png" />
| |
- | <p><span>Fig. 3: A zoomed in screenshot showing two sub-graphs within
| |
- | the disconnected graph.</span></p>
| |
- | <br>
| |
- | <h3>"Semi-Simplicity"</h3>
| |
- | <p>A simple graph is a graph in which no more than one edge contains
| |
- | the same set of nodes. So, in a simple graph it is not possible to find
| |
- | more than one edge with the same source and the same target. Additionally,
| |
- | an edge with the same source and target, forming a loop is not allowed.
| |
- | But, in synthetic biology it is possible to construct a device consisting
| |
- | of devices or bio bricks of the same species or type. Accordingly, our
| |
- | graphs are simple graphs with an exception of possible self-containing
| |
- | loops, where the edge starts from and ends on the same node. Our graphs
| |
- | have an exception of having loops and due to this permitted flexibility
| |
- | our graphs are "semi-simple".</p>
| |
- | <p>For general information about graphs refer to:</p>
| |
- | <p><span><a href="http://en.wikipedia.org/wiki/Graph_(mathematics)">
| |
- | [1] http://en.wikipedia.org/wiki/Graph_(mathematics)</a></span></p>
| |
- | </div>
| |
- | </div>
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="clear">
| |
- | </div>
| |
- | <!-- 8th row -->
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div class="item">
| |
- | </div>
| |
- | <div id="project8" class="item">
| |
- | <div class="content2">
| |
- | <div class="text">
| |
- | <h2>Results</h2>
| |
| </div> | | </div> |
| </div> | | </div> |