Forums

Dear Nicolas

The issues that you raise are critical for model reusability. CellML
may offer some ideas worth considering. CellML 1.1 was driven by the
need to support reusability, but to do so by adding a single new
concept - the <import> element (see http://www.cellml.org/
specifications/cellml_1.1/#sec_import_model). I am not sure why you
suggest that so many restrictions be placed on modules (no separate
namespaces, only one definition, no implicit unit conversion). Surely
you want to minimise the number of special cases when extending SBML?

Best wishes
Poul

On 2007 Jul 17, at 20:24, Nicolas Le Novere 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. In addition 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.
>
> 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.
>
> 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.
>
> 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 ...]
>
> --
> Nicolas LE NOVERE, Computational Neurobiology,
> EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10
> 1SD, UK
> Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074
> Skype:n.lenovere
> http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN:
> nlenovere@hotmail.com
> ____________________________________________________________
> 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.

____________________________________________________________
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.