Team:Edinburgh/Modelling/Future

From 2010.igem.org

(Difference between revisions)
Line 104: Line 104:
   <ul>
   <ul>
   <li><a href="https://2010.igem.org/Team:Edinburgh/Notebook/Collaboration">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 109: Line 110:
   <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>

Revision as of 15:44, 18 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 definite 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.