SBML.org — the global portal for all things SBML

Hierarchical Model Composition (Hoops 2007)

Contents

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

http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Hierarchical_Model_Composition_%28Hoops_2007%29

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

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.

Image:HierarchicalModel.jpg

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.

Image:ListOfSubmodels.jpg

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

Image:ListOfReplacements.jpg

ListOfPorts Type

Image:ListOfPorts.jpg

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.

Image:ConversionFactor.jpg

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

Image:ObjectReference.jpg


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.

Retrieved from "http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Hierarchical_Model_Composition_%28Hoops_2007%29"

This page was last modified 17:44, 4 October 2010.



Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 17:44, 4 October 2010.