Forums

Hello Nicolas,

Please let me assure that I am not arguing against model
(de)composition. This is clearly a feature we need to try to support in
the next level of SBML. My arguments below are against splitting a
model into several files without having a proper (de)composition
framework.


On Tue, 17 Jul 2007 09:24:07 +0100
Nicolas Le Novere <lenov@ebi.ac.uk> wrote:

> At the moment, a model written in SBML is monolithic. A model is
> entirely described in an element "model",
> located in a given file. This has several unpleasant consequences.
> Firstly, while initialy the size of the models was on the human
> scale, this is no longer the case. The largest models of the curated
> branch of BioModels Database reach several hundreds reactions, and in
> the uncurated branch we reach thousands (FBA models). This results in
> very large files, that are slow to load and to process.

The size of all module files together would still be the size of the
initial file wouldn't it?
Processing several files is not faster than processing one. The problem
is still the size of the resulting model which needs to be analyzed.
This is a problem of the tools and not SBML.

> the structure of a model is not easely retrieved. We need to analyse
> all the reactions to understand what is going on. Finally, the unit
> problem is getting worse with the size.

Why?

>
> Maybe we should create modules. A module is an SBML construct that
> looks like an SBML Level2 model, but with the constraint that the
> units are consistent. All the species in a module would have the same
> unit. All the compartments as well. And all the time related
> constructs as well.

This is actually a very nasty problem you are creating. We just got rid
of different units for the kinetic law. However, since the modules use
different units (especially time) it is now possible to have some
reactions in one unit system whereas others from another module have
another. How can this be resolved without implicit unit conversion in
the absent of explicit conversion definitions?

>
> Modules could be stored in different files and an SBML file could
> contain several modules. An "import" element must be created.
>
> Modules do not contain their own namespaces.
>
> A module could contain only one definition (such as a species), or a
> whole mini-model.
>
> A module could not contain other modules. We are not talking about
> model composition here.
>
> There is not unit conversion implied. If a symbol is defined in a
> module with a given unit, it is always u
> sed with this unit, even in another module. It is up to the modeller
> to take care of the proper conversion
> within e.g. the kineticLaw's math.

Please see my comment above.

>
> Modules are not equivalent to CellML's components. Again we are not
> talking about model composition.
>
> All that is a bit naive and fuzzy at the moment. But providing
> something along these lines in the core would maybe make the model
> composition extension easier.
>
> [Alternatively, let's all have a good look at CellML and reuse their
> good ideas ...]
>

I hope my comments are not to harsh.


Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility I
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu.