Forums

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.

Poul Nielsen wrote:

> The issues that you raise are critical for model reusability. CellML
> may offer some ideas worth considering.

I know. Hence the last sentence of my post ... ;-)

> I am not sure why you
> suggest that so many restrictions be placed on modules (no separate
> namespaces,

The "modules" I described are not encapsulation devices like CellML
components. There are no ports or terminals. Hence a kineticLaw in a module
directly reuse a symbol defined in another module.

People discussing model composition have another notion, closer to
encapsulation, called submodel.

only one definition,

You misread. I wrote "could contain only one definition". What I mean is
that a module could contain only a listOfSpecies, with one species. But it
could also contain many species, compartments, reactions etc.

no implicit unit conversion)

Because there are no ports. If a module A defines a species X in item, and
a reaction is defined in a module B where the unit of species is mole, the
symbol X used in the reaction still represent items. If the modeller meant
to use this symbol as mole, a division by Na is necessary. This is actually
the current state of affairs in SBML.

I really meant modules as in programming languages, where you split a
source-code into modules for ease of use. The encapsulation devices would
be more like class definitions (very much like CellML components).

Maybe those modules are useless. Maybe we should go all the way, and make
encapsulation and model composition part of the core (and use RDF for the
whole of SBML not the annotations ...). This is a discussion I would very
much see unfolding here. But even if we do not, I still think we need to be
able to split a model into manageable bits and pieces.

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

Nicolas Le Novere wrote:
> Maybe those modules are useless. Maybe we should go all the way, and make
> encapsulation and model composition part of the core (and use RDF for the
> whole of SBML not the annotations ...). This is a discussion I would very
> much see unfolding here. But even if we do not, I still think we need to be
> able to split a model into manageable bits and pieces
I personally don't particularly like using RDF for all of SBML instead
of annotations. In my opinion, it is simple enough to create model
composition software that will read the RDF and harmonize the IDs
between models. Requiring the ID to be the same in different sub-models
would make it easier to code simulation software. While the model
composition software would be simple enough it would require a remapping
of IDs prior to simulation, adding additional complexity for people
writing new codes.

I understand that a wealth of software that uses SBML out there is very
full-featured, but I would guess that there are more one-off codes out
there that do just one small thing that the user wants. Allowing
simplification of the one-off codes seems as though it would help SBML
in the long run.

Bill

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

On Tuesday 17 July 2007 14:27, Bill Denney wrote:
> Allowing simplification of the one-off codes seems as though it
> would help SBML in the long run.

I completely agree with this. For example this would be
important in a scenario where elementary operations
on SBML files are provided by web services which can
then be put together into workflows with something like
Taverna.

--
Pedro Mendes
Chair in Computational Systems Biology
University of Manchester

School of Computer Science \ Manchester Centre for Integrative Sys.Biol.
Kilburn Building, Oxford Road, | Manchester Interdisciplinary Biocentre
Manchester, M13 9PL, UK \ 131 Princess St., Manchester, M1 7DN, UK
____________________________________________________________
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.

Stefan Hoops wrote:

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

Well ... I am not sure I am talking about model (de)composition here in
fact. I am not even sure I am dealing with the modeling side at all. This
is purely an encoding problem. But, yes, you are right, a proper
(de)composition framework would address my concerns as a side-effect. BUT,
in the current roadmap, such a framework would be an extension of SBML, not
part of the core. What I propose is to include modules and import in the core.

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

Yes, but when it comes to editing the model, with SBMLeditor or
CellDesigner, you could only load one of the files. This is very different,
both in terms of loading time and ease of use. Same than with a book
written in TeX, where each chapter is stored in a different TeX file,
imported with input or include commands. You can only generate the
bibliography and the index on the total document. This is not a set of
independent articles that you bundles up. This is not model composition.
This is one indivisible model that you store in different bits and pieces.

>> 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?

Because some people define a unit per parameter and per species.

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

No, no, no. My mistake. I should never have mentioned time. You are right
of course. There are no timeUnits anymore. But we can still have a
listOfSpecies with species in mole, millimole, micromole, gram and item.

> How can this be resolved without implicit unit conversion in
> the absent of explicit conversion definitions?

The same it is done right now. If a model contains a kineticLaw using
species in mole and item, it is up to the modeller to properly write the
math. I am not proposing anything new here. This is the current situation.



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