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
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: firstname.lastname@example.org
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,