— the global portal for all things SBML

Martin Goals

  1. General Goals
    • (UseCase? 1): Composing tool takes multiple traditional SBML models and creates composed model with minimal changes to the original models.
    • (UseCase? 2): Modular modeling tool creates models from predefined library of modules. Modules are designed to be composed in the sense of software engineering.
    • (UseCase? 3): Analysis tools read and analyze (simulate, compute) composed model with minimal implementational effort
    • Important: Balance between complexity of storage format and complexity of the composing tool
    • General question: Is it useful/necessary to make composition part of the SBML Core? (Big pro: References can be solved in general)
  2. Goals for Composition Extension
    • Express multiple submodels or modules
    • Express instantiation
    • Create directed links
      • Between parts of instances (horizontal)
      • Between normal main model parts and instances (vertical)
    • What should be replacable with links:
      • Compartments
      • Species
      • Parameters
      • Rules?
      • Reactions?
      • Events?


      • Not all the elements can be addressed, because there are no IDs
    • Scheme for references
      • Between normal model parts and parts of instances (e.g. using a species inside an instance within a rule)
      • From math to instances directly? Changing the core of SBML, replacing Sid-references with something more complex. (e.g. instance.path.notation)
      • Other approach: List of references inside the main model, referring to objects inside instances and assigning an unique id on the top level
      • Hierarchical naming scheme necessary
    • One consistent unit table vs. several local tables with automatic conversion in the reading tool
      • Suggestion: Have one table and let the composing tool construct this table from composed models
    • Annotation for helping with model checks
    • Allow expression of interfaces, although not mandantory
    • Parametrization of instances (at least setting numerical values different from the defaults in the module definition)
  3. Goals for Composition Tools
    • Support creation of models with submodels
    • Creation of interfaces and linking
    • Scheme for deleting objects in an instance (e.g. Linked species from source model to the target, delete assignmentrules in the target model)
      • Default: If a variable is linked from a source instance, take only the rules from this instance and delete all rules in target instances, which determine this variable (avoid overdetermined models)
      • Necessary: ID for everything? XQuery
    • Creation of parametrized instances
    • Creation of one consistent unit table
    • Checking of math and consistency
    • Gathering annotations for helping with model merging
    • Support for refactoring of modularized models
    • Support for checking of consistency and units in composed models
    • Support for flattening of composed models
  4. Things to postpone
    • Subnet replacement (Just too complicated to implement, can be part of the tool)
    • External submodels referenced by URL: Gather experience with models that contain all submodels
  5. Models to start trying
    • Signalling models (similar timescale, less problems with compartments)
    • Metabolic models, perhaps starting with structural models

Retrieved from ""

This page was last modified 02:33, 27 December 2007.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 02:33, 27 December 2007.