Team:Edinburgh/Modelling/Future
From 2010.igem.org
(14 intermediate revisions not shown) | |||
Line 8: | Line 8: | ||
<style type="text/css"> | <style type="text/css"> | ||
+ | |||
+ | #body{ | ||
+ | background-image:url("https://static.igem.org/mediawiki/2010/9/9e/Ed10-LargePaperRipped.jpg"); | ||
+ | background-repeat:repeat-y; | ||
+ | } | ||
</style> | </style> | ||
Line 43: | Line 48: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/BioBricks#Genomic">submitted parts</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/BioBricks#Genomic">submitted parts</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Results#Genomic">results</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Results#Genomic">results</a></li> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Project/Future">future | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Project/Future">the future</a></li> |
<li><a href="https://2010.igem.org/Team:Edinburgh/Project/References">references</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Project/References">references</a></li> | ||
</ul> | </ul> | ||
Line 50: | Line 55: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial" class="dir">bacterial BRIDGEs</a> | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial" class="dir">bacterial BRIDGEs</a> | ||
<ul> | <ul> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Core_repressilator">the | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Core_repressilator">the project</a></li> |
<li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Red_light_producer">red light</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Red_light_producer">red light</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Red_light_sensor">red sensor</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Red_light_sensor">red sensor</a></li> | ||
Line 59: | Line 64: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/BioBricks#Bacterial">submitted parts</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/BioBricks#Bacterial">submitted parts</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Results#Bacterial">results</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Results#Bacterial">results</a></li> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Future">future | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/Future">the future</a></li> |
<li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/References">references</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Bacterial/References">references</a></li> | ||
</ul> | </ul> | ||
Line 70: | Line 75: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Bacterial">the bacterial model</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Bacterial">the bacterial model</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Signalling">the signalling model</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Signalling">the signalling model</a></li> | ||
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Tools">tools</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Results#Modelling">results</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Results#Modelling">results</a></li> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Future">future | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/Future">the future</a></li> |
<li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/References">references</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Modelling/References">references</a></li> | ||
</ul> | </ul> | ||
Line 78: | Line 84: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Human" class="dir">human BRIDGEs</a> | <li><a href="https://2010.igem.org/Team:Edinburgh/Human" class="dir">human BRIDGEs</a> | ||
<ul> | <ul> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/ | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/Communication">communication of science</a></li> |
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/Branding">iGEM survey</a></li> | ||
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/Conversations">conversations</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Human/Epic">the epic</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/Epic">the epic</a></li> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/ | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/FutureApps">future applications</a></li> |
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Human | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Results#Human">further thoughts</a></li> |
<li><a href="https://2010.igem.org/Team:Edinburgh/Human/References">references</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Human/References">references</a></li> | ||
</ul> | </ul> | ||
Line 88: | Line 96: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook" class="dir">lab notes </a> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook" class="dir">lab notes </a> | ||
<ul> | <ul> | ||
- | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook">collaboration</a></li> | + | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Collaboration">collaboration</a></li> |
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Attribution">attribution</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/BRIDGE">BRIDGE</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/BRIDGE">BRIDGE</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Red_light_producer">red light</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Red_light_producer">red light</a></li> | ||
Line 94: | Line 103: | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Blue_light_producer">blue light</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Blue_light_producer">blue light</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Blue_light_sensor">blue sensor</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Blue_light_sensor">blue sensor</a></li> | ||
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Green_light_producer">green light</a></li> | ||
+ | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Green_light_sensor">green sensor</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Modelling">modelling</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Modelling">modelling</a></li> | ||
<li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Safety">safety</a></li> | <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Safety">safety</a></li> | ||
Line 109: | Line 120: | ||
<br> | <br> | ||
- | <div id="body" style="padding: 0px | + | <div id="body" style="padding: 0px 60px 10px 60px; height: 998px"> |
<br> | <br> | ||
Line 115: | Line 126: | ||
<br> | <br> | ||
- | < | + | <a name="Future1" id="Future1"></a><h2>Future Work: Refining the models</h2> |
+ | <br> | ||
- | < | + | <p>The immediate <b>future</b> for the modelling <b>component</b> of our project lies in further <b>refining</b> the model with any characterisation data obtained; for example, <b>fitting</b> the response curves of the individual pathways to <b>observed</b> results, or <b>adjusting</b> the light output relevant to the amount of luciferase produced. Doing so would increase the <b>viability</b> of our model as an <b>accurate representation</b> of the biology that it represents, and would thus improve the <b>predictive capabilities</b> and the <b>reliability</b> of the data that can be <b>inferred</b> from the system. It would also allow us to perform further <b>study</b> and <b>analysis</b> upon the models to try to <b>answer</b> relevant biological questions.</p> |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
+ | <p>Alternatively, we could attempt to <b>extend</b> the <b>scope</b> of the modelling in new <b>directions</b>. A number of different <b>possibilities</b> exist, including three-dimensional structural modelling of proteins such as the light receptors or their signal transduction pathways, or energy-based modelling involving thermodynamics and kinetic states. Again, the <b>aim</b> of this modelling would be to increase the accuracy of the biological <b>interactions depicted</b> within the model and to reduce the effect of the <b>assumptions</b> we have to make in order to achieve a certain level of <b>granularity</b>.</p> | ||
+ | |||
+ | <p>We would like to view models not only as <b>design</b> and <b>prototyping</b> tools, but also as <b>fundamental</b> components of an <b>iterative</b> process in which they help <b>predict</b> and <b>influence</b> biological decisions, and are in turn <b>updated</b> and <b>improve understanding</b> via the characterisation data obtained. From a software engineering <b>point of view</b>, modelling in iGEM is very similar to extreme programming, in which models are only made as needed to <b>explain</b> or <b>describe</b> concepts, and are <b>discarded</b> almost as quickly. A possible alternative to this methodology is model-driven development, in which models form the <b>core</b> of the development process and are <b>integrated</b> far more closely into the project <b>lifecycle</b>. Although neither <b>way of thinking</b> is necessary better than its counterpart - both have <b>advantages</b> according to the situation, such as the former being more useful for short-term, high-intensity projects - it would be good to <b>promote</b> them both as possible <b>options</b> within synthetic biology.</p> | ||
<br> | <br> | ||
<br> | <br> | ||
+ | |||
+ | <a name="Future2" id="Future2"></a><h2>Future Work: The "Virtual Registry"</h2> | ||
<br> | <br> | ||
+ | |||
+ | <p><b>Thinking</b> in broader terms, one of the main future <b>applications</b> we can see stemming from the modelling component of our project is in <b>formalising</b> Ty Thomson's unofficial framework for modelling BioBricks in Kappa, possibly by <b>submitting</b> it as a RFC to the <a href="http://partsregistry.org/Main_Page">Registry</a> as a means of characterising BioBricks. This would provide a <b>definitive</b> and <b>standardised</b> method to quantify the actions of parts entered into the Registry; for example, all ribosome binding sites would be associated with a definitive kinetic rate that quantifies the rate at which ribosomes bind to the transcribed mRNA. With just a little <b>effort</b> and <b>support</b>, an attempt could be made to <b>standardise</b> the rather <b>disparate</b> nature of modelling within synthetic biology at this point in time, as well as helping to <b>promote</b> useful modelling <b>techniques</b> and good modelling <b>practices</b> within the <b>community</b>.</p> | ||
+ | |||
+ | <p>In turn, such an <b>advance</b> would allow for the development of an associated <b>"Virtual Registry"</b> of characterised parts, devices, and models. Although <b>margins of error</b> would still be present, one can still <b>foresee</b> the time when a synthetic biologist would be able to fully <b>create</b> and <b>test</b> a potential system in a relatively <b>realistic</b> virtual environment before even having to order a single piece of DNA. Although such an <b>endeavour</b> would rely greatly upon the accuracy of the data input into the "Virtual Registry", the <b>success</b> of the <a href="http://partsregistry.org/Main_Page">BioBrick Registry</a> in helping to <b>popularise</b> and <b>support</b> the usage of standardised biological parts is a valuable <b>precedent</b> in determining the <b>feasibility</b> of such a project.</p> | ||
+ | |||
+ | <p>We see our modelling work this year as an important <b>first step</b> in this direction, and hope to encourage the <b>adoption</b> of this framework as well as the <b>development</b> of software tools adhering to it.</p> | ||
+ | <br> | ||
+ | <br> | ||
+ | |||
+ | <br> | ||
+ | <br> | ||
+ | <br> | ||
+ | |||
+ | <center><a href="#top" class="dir"><img width="100" src="https://static.igem.org/mediawiki/2010/9/9f/Ed10-RTT.png"></a></center> | ||
+ | |||
+ | </div> | ||
+ | |||
+ | <div id="windowbox" style="border: .2em solid #660000; padding: 5px; position:fixed; top:50%; right:30px; width:8%;"> | ||
+ | <span style="color:ivory;">Throughout this wiki there are words in <b>bold</b> that indicate a relevance to <b>human aspects</b>. It will become obvious that <b>human aspects</b> are a part of almost everything in <b>iGEM</b>.</span> | ||
</div> | </div> |
Latest revision as of 02:22, 28 October 2010
Future Work: Refining the models
The immediate future for the modelling component of our project lies in further refining the model with any characterisation data obtained; for example, fitting the response curves of the individual pathways to observed results, or adjusting the light output relevant to the amount of luciferase produced. Doing so would increase the viability of our model as an accurate representation of the biology that it represents, and would thus improve the predictive capabilities and the reliability of the data that can be inferred from the system. It would also allow us to perform further study and analysis upon the models to try to answer relevant biological questions.
Alternatively, we could attempt to extend the scope of the modelling in new directions. A number of different possibilities exist, including three-dimensional structural modelling of proteins such as the light receptors or their signal transduction pathways, or energy-based modelling involving thermodynamics and kinetic states. Again, the aim of this modelling would be to increase the accuracy of the biological interactions depicted within the model and to reduce the effect of the assumptions we have to make in order to achieve a certain level of granularity.
We would like to view models not only as design and prototyping tools, but also as fundamental components of an iterative process in which they help predict and influence biological decisions, and are in turn updated and improve understanding via the characterisation data obtained. From a software engineering point of view, modelling in iGEM is very similar to extreme programming, in which models are only made as needed to explain or describe concepts, and are discarded almost as quickly. A possible alternative to this methodology is model-driven development, in which models form the core of the development process and are integrated far more closely into the project lifecycle. Although neither way of thinking is necessary better than its counterpart - both have advantages according to the situation, such as the former being more useful for short-term, high-intensity projects - it would be good to promote them both as possible options within synthetic biology.
Future Work: The "Virtual Registry"
Thinking in broader terms, one of the main future applications we can see stemming from the modelling component of our project is in formalising Ty Thomson's unofficial framework for modelling BioBricks in Kappa, possibly by submitting it as a RFC to the Registry as a means of characterising BioBricks. This would provide a definitive and standardised method to quantify the actions of parts entered into the Registry; for example, all ribosome binding sites would be associated with a definitive kinetic rate that quantifies the rate at which ribosomes bind to the transcribed mRNA. With just a little effort and support, an attempt could be made to standardise the rather disparate nature of modelling within synthetic biology at this point in time, as well as helping to promote useful modelling techniques and good modelling practices within the community.
In turn, such an advance would allow for the development of an associated "Virtual Registry" of characterised parts, devices, and models. Although margins of error would still be present, one can still foresee the time when a synthetic biologist would be able to fully create and test a potential system in a relatively realistic virtual environment before even having to order a single piece of DNA. Although such an endeavour would rely greatly upon the accuracy of the data input into the "Virtual Registry", the success of the BioBrick Registry in helping to popularise and support the usage of standardised biological parts is a valuable precedent in determining the feasibility of such a project.
We see our modelling work this year as an important first step in this direction, and hope to encourage the adoption of this framework as well as the development of software tools adhering to it.