Hierarchical Model Composition (Hoops 2007)
Proposal title
Hierarchical Model Composition
Proposal authors
Stefan Hoops
Virginia Bioinformatics Institute
Blacksburg, VA 24061, USA
Email: shoops at vbi.vt.edu
Nicolas Le Novère
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD, UK
Email: lenov at ebi.ac.uk
Ion Moraru
Center for Cell Analysis and Modeling
University of Connecticut Health Center
Farmington, CT 06030, USA
Email: moraru at panda.uchc.edu
Michael Hucka
Biological Network Modeling Center
Beckman Institute
California Institute of Technology
Pasadena, CA 91125, USA
Email: mhucka at caltech.edu
Andrew Finney
(Independent)
Email: andrew.finney at oxfordcc.co.uk
Martin Ginkel
Max Planck Institute for Dynamics of Complex Technical Systems
Magdeburg 39106, Germany
Email: ginkel at mpi-magdeburg.mpg.de
Wolfram Liebermeister
Max Planck Institute for Molecular Genetics
Berlin D-10115, Germany
Email: lieberme at molgen.mpg.de
Ranjit Randawa
Department of Computer Science
Virginia Tech
Blacksburg, VA 24061, USA
Email: rrandhawa at vt.edu
Proposal tracking number
Number 2404771 in the SBML issue tracking system.
Version information
Version number and date of public release
Version 2 released on 11 September 2007.
URL for this version of the proposal
URL for the previous version of this proposal
http://sbml.org/Events/Other_Events/SBML_Composition_Workshop_2007/Hierarchical_Modeling
Introduction and motivation
Model composition refers to the ability to include models as submodels inside other models. This requires defining the interfaces between the models and rules for connecting parts of models together. The motivation is to enable the creation of standard, vetted models and use them as library components when creating larger models, much as is done in software development, electronics design, and other engineering fields.
Ranjit Randhawa has a presentation summarizing his work on model fusion, aggregation and composition (Sept 2007) for his Ph.D. at Virginia Tech using models from the Tyson lab. Among other interesting features of this work, it helps frame the overall problem and distinguishes different ways in which we can think about "composing" models in SBML.
After the 2007 SBML Hackathon in Newcastle, Andrew Finney sent email around summarizing some of the technical issues discussed in Newcastle: Andrew 2007 Comments about Model Composition.
Nicolas Le Novère posted a message on sbml-discuss in July 2007 calling for the inclusion of modules in SBML Level 3 core, similar to CellML components. These modules, that could contain any number of any other SBML construct, would have their own namespaces, and would use consistent units. A variable in a component (compartment, species, parameter etc.) could be private or public. The use of modules would greatly facilitate the building and curation of models, would improve interoperability with CellML and would provide the ground for model composition. Andrew's 2003 proposal on model composition would only require a minor change: The pointers would identify either the main SBML model or a module.
For a focused workshop held in late 2007, Martin Ginkel put together a proposed list of goals and issues.
Background
Problems with current SBML approaches
SBML Level 2 has no direct support for allowing a model to include other models as submodels. Software tools either have to implement their own schemes outside of SBML, or (in principle) one could use annotations to augment a plain SBML Level 2 model with the necessary information to allow a software tool to compose a model out of submodels. There is a clear need for an official SBML language facility supporting hierarchical model composition.
Past work on this problem or similar topics
Complete proposals for SBML
- Andrew Finney's proposal of Oct. 2003. There is also a poster from ISMB 2004 that summarizes Andrew's composition proposal.
- Martin Ginkel's proposal of June 2002. Martin also gave a summary in a presentation at the 5th SBML Forum in 2002. Martin also has a web page for SBML composition containing this and an earlier presentation.
- CellML 1.1 includes a mechanism for composing models out of components. While not a proposal for SBML, there ares ideas there to keep in mind. At one point, we did state that a goal of SBML's composition facility was to allow interoperability with CellML via some sort of defined interfaces, though it is far from clear that the current proposals for SBML composition would make this possible.
Additional reference materials
- semanticSBML is a system for merging multiple SBML models into one (also see this poster). Any proposal for submodel composition will certainly affect semanticSBML, and likewise, its needs and capabilities may influence the SBML composition extension effort.
- Andrew Finney previously suggested that a proposal for sets could be another way to achieve model composition. Indeed, it remains an open question whether perhaps the model composition, sets and arrays could not somehow be combined into one overall framework using a single set of mechanisms.
- The Modelica 2.2 language provides for hierarchical object-oriented composition of components.
- JSim is a Java-based modeling framework that provides a way to do object-oriented composition.
Proposed syntax and semantics
HierarchicalModel Type
The HierachicalModel is the type of the model element, which is the top element of an SBML file containing a model which is composed from multiple submodels. The HierarchicalModel is derived from the Model type of the SBML core. The attributes of the model stay unchanged however the sequence of child elements is expanded. The added child elements are listOfSubmodels, listOfReplacements, and listOfPorts.
ListOfSubmodels Type
The ListOfSubmodels is the type of the listOfSubmodels element. This element contains a list of submodels. The model sources which are instantiated may be defined by a model element, or locally and remotely (in another XML documnet) through the SBMLInclude type. The two alternate attribute lists of the source element present restrictions of the SBMLInclude type (derived from xi:include) applicable for the local or remote model definitions. The scope of the SBML id of the hierarchical model does exclude the child of the submodel element. This means that an instantiated model has its own namespace. It is possible to instantiate several copies of a submodel from the same source.
The resulting section in an SBML document would look like:
<listOfSubModels>
<submodel id="Submodel_1">
<substanceConversionFactor
id="SCF_1"
name="Substant Conversion Factor 1"
value="1000"
units="submodelSubstsanceUnitPerParentModelSubstanceUnit"
constant="true" />
<volumeConversionFactor
id="VCF_1"
name="Volume Conversion Factor 1"
value="1000"
units="submodelVolumeUnitPerParentModelVolumeUnit"
constant="true" />
<areaConversionFactor
id="ACF_1"
name="Area Conversion Factor 1"
value="100"
units="submodelAreaUnitPerParentModelAreaUnit"
constant="true" />
<lengthConversionFactor
id="LCF_1"
name="Length Conversion Factor 1"
value="10"
units="submodelLengthUnitPerParentModelLengthUnit"
constant="true" />
<timeConversionFactor
id="TCF_1"
name="Time Conversion Factor 1"
value="60"
units="submodelTimeUnitPerParentModelTimeUnit"
constant="true" />
<model id = "HierarichicalModel_1">
...
</model>
</submodel>
...
<submodel id="Submodel_X">
<model xref="..." xpointer="..." />
</submodel >
</listOfSubmodels>
ListOfReplacements Type
ListOfPorts Type
ConversionFactor Type
Stefan: Do we need to specify whether something only is mutable initially.
The ConversionFactor type is used to specify the conversions required between the parent and sub models as well as the conversion required for replacements. The type is derived from the Parameter type of the SBML core with the restriction that the constant attribute is fixed to the value true.
The conversion is such that following two MathML fragments are equivalent in value and in units.
<ci> target </ci>
<apply>
<times/>
<ci> conversionFactor </ci>
<ci> source </ci>
</apply>
This means that when we flatten a hierarchical model to a SBML core model every occurrence of the first fragment will be replaced by the second. For this mechanism to work properly in the units space it is required that proper units for the conversion factors must be defined as part of the parent model.
ObjectReference Type
Package dependencies
The package as proposed here does not depend on any other SBML Level 3 packages.
Use-cases and examples
(Incomplete.)
Prototype implementations
(Incomplete.)
Translation to SBML Level 2
(Incomplete.)
Unresolved issues
(Incomplete.)
References
None at this time.