Martin Goals
- 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)
- 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?
Problem
- 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)
- 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
- 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
- Models to start trying
- Signalling models (similar timescale, less problems with compartments)
- Metabolic models, perhaps starting with structural models