Talk:Registry of Standard Biological Models: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
No edit summary
Line 26: Line 26:
This is just an idea that has germinating very very slowly with me for a while.  Its really just the next logical extension to the parts registry rather than a different idea.  Any feedback welcome.--[[User:Bcanton|BC]] 22:28, 22 Sep 2005 (EDT)
This is just an idea that has germinating very very slowly with me for a while.  Its really just the next logical extension to the parts registry rather than a different idea.  Any feedback welcome.--[[User:Bcanton|BC]] 22:28, 22 Sep 2005 (EDT)


== Follow up on registry of biobricks models ==
=== Follow up on registry of biobricks models ===





Revision as of 07:29, 26 September 2007

Early Discussions

Original idea

I'd like to see a centralized and standardized source of models for biological parts and devices. A good framework for this would be the registry of standard biological parts. Each part and device should have a simple ODE model of its behavior accompanying it. In fact, this registry of models would operate identically and confer all the same advantages as a registry of parts. Namely, it would produce simple standard models of components that could be reliably and rapidly combined to form models of more complex components. If everybody building models was drawing from the same pool of component models, we could be more sure that those models were an accurate reflection of the physical component. Again, just as with the registry of physical parts, everytime I wanted to build a model, I wouldn't have to start from scratch, I could start from well-tested components.

For example a constitutive promoter has a model with no inputs (ignoring polymerase and σ factor levels) and one output, PoPS. In Matlab, this would be a simple function with no inputs that returns a scalar output which is the PoPS output of the device -

PoPS_out = R0040;

A protein generator would have a model with a PoPS input and a protein production rate as output. For example -

dP = E0240(PoPS_in);

Note that E0240 might actually be a collection of part models for an RBS, coding region, and terminator -

function dp = E0240(PoPS_in)
RiPS = B0032(PoPS_in);
translation_rate = E0040(RiPS);
dp = B0015(translation_rate);


The part models for R0040 and E0240 could be put together in an obvious way to form a model of a reporter device.

We already have models for many of our simple parts that could be combined easily if only steady state conditions were considered. Some more organization would be required to allow each model to represent the time varying behavior of a device as combining devices would require the assembly of ODE's from different files. It should still be very possible though.


This is just an idea that has germinating very very slowly with me for a while. Its really just the next logical extension to the parts registry rather than a different idea. Any feedback welcome.--BC 22:28, 22 Sep 2005 (EDT)

Follow up on registry of biobricks models

I fully support the idea of building such a repository of biobrick models. As you mention, it is complementary to the physical DNA repository. Storing, sharing and improving models would be key to be able to move to a Synthetic Biology CAD approach (it seems to be the sense of history in any other engineering field: finite element modelling, electronic systems, control systems..).

However, you describe models having already in mind a way to solve them (Continuous approach with ODEs), it could be important for the registry to simply describe the system to be considered without any constrains on the way to extract their properties. No definitive modelling approach has proven to be more relevant than the others, it should always be possible to explore a given model with different strategies and maybe different purposes. Sometimes, you could only be interested in exploring topological features of the models (patterns, motifs, interlocks) . When it comes to dynamic modelling, you may want to use a stochastic, continuous or hybrid method. The description of the model should be open enough.

As you mention also, an other key feature of the registry would be to provide modular parts. So that you can build a more complex model in a drag and drop fashion. it should also allow the ability to build multiscale models. I would be interested to explore existing standards such as SBML or CellML in order to see if they could be used as a description language for Standard Biological Models. SBML has a strong community behing it and many compatible software to design or integrate models. CellML has developed a nice modular approach. -- User:Vincent - 13th june 2006 -

  • BC 15:55, 29 August 2006 (EDT): Hey Vincent, I think you are right, it would be good to make available a generic description of the model (species, reactions, rates) without enforcing a solution method. SBML/cellML might well be good candidates to specify device models in a general way that would still allow users to build models in a hierarchical fashion.

There would need to be standards set such that it is easy to compose models of multiple devices possibly contributed by different individuals. Of course this is the exact same issue that the physical registry is trying to solve:) This was what I was trying to fix by picking a popular solution method (ODEs) but mabye some of the markup languages would be useful to retain solution method flexibility while still permitting a modular approach to model composition.

BioModels.net

From a seminar announcement by Mike Hucka:

"Systems biology by its nature requires collaborations between scientists with expertise in biology, chemistry, computer sciences, engineering, mathematics, and physics. Successful integration of these disciplines depends on bringing to bear both social and technological tools: namely, consortia that help forge collaborations and common understanding, software tools that permit analysis of vast and complex data, and agreed-upon standards that enable researchers to communicate and reuse each other's results in practical and unambiguous ways. In this presentation, I will discuss several international projects (SBML, SBGN, and BioModels.net) aimed at addressing the last issue.

An important prerequisite for effective sharing of computational models is reaching agreement on how to communicate them, both between software and between humans. The Systems Biology Markup Language (SBML) project is an effort to create a machine-readable format for representing computational models at the biochemical reaction level. By supporting SBML as an input and output format, different software tools can operate on the same representation of a model, removing chance for errors in translation and assuring a common starting point for analyses and simulations. SBML has become the most successful effort in this direction so far, with over 100 software tools supporting it today.

A recently-created sister project is the Systems Biology Graphical Notation (SBGN) project. It addresses the issue of consistent human communication, by attempting to add more rigor and consistency to the graphical network diagrams that often accompany published research on models of biological reaction systems. The real payoff will come when more people and software adopt such a common visual notation and it becomes as familiar to them as circuit schematics are to electronics engineers.

Finally, when developing and publishing computational models, it is only natural to want to put them into a database. The BioModels.net project is an effort to (1) provide a free, centralized, publicly-accessible database of human-curated computational models in SBML and other structured formats; (2) define agreed-upon standards for model curation; and (2) define agreed-upon vocabularies for annotating models with connections to biological data resources."