Andrew 2007 Comments about Model Composition
The following issues were raised which were not covered by the existing model composition proposal on the SBML wiki (despite the tone of the language I'm actually writing this for comments! - that includes the original proposal!) Forgive me if you have already thought these issues though ages ago
a) Explicit 'MustBeOverloaded' flag on ports
Currently ports (elements that are explictly part of a model's interface) by default can be optionally linked to (overloaded) when the containing model is instantiated. Ports must have an additional flag 'MustBeOverloaded', that defaults to false, that when true indicates that the port must be linked to. It is recommended that simulators issue a warning if a model containing, at the top level, ports with 'MustBeOverloaded' true values is simulated.
b) N to N links
(on links a 'from' reference overloads a 'to' reference) The syntax for links should be revised to allow zero or more 'from' and one or more 'to' object references. A link with zero 'from' references deletes the 'to' object(s). A link cannot contain more than one species or compartment 'from' references (otherwise you could split a species or compartment) (Note that a link to nothing is not allowed)
c) Reaction overloading
Reaction links should be allowed. Reaction overloading differs from species overloads in the following ways with respect to the reaction network bipartite graph the flattened model containing a link from one species to another in separate models combines the edges from both models incident to both species e.g. model1: s1 -> s2, model2: s3 -> s4, link from s3 to s4 flattens to s1 -> s2,s3 -> s4 whereas a reaction overload only retains the edges belonging to the 'from' (overloading) reaction e.g. model1: r1: s1 -> s2: k2*s1, model2: r2: s3 -> s4: k2*s3 link from r2 to r1 flattens to (r2,r1): s1 -> s2: k2*s3 (this is not meant to be something a modeller would do but that shows the semantics) a more realistic example: model1:
r1 s1->s2; k1*s1 r2 s2->s3; k2*s2 r3 s3->s4; k3*s3 model2: r4 s5->s6; k4*s5
link from s5 to s1 link from s6 to s3 link from r4 to r1,r2 flattens to
(r4,r1,r2) (s5,s1)->(s6,s3); k4 * (s5,s1) r3 (s6,s3) -> s4 : k3*(s6,s3);
d) Garbage collection
The above raises the issue that species (orphan's?) can be left disconnected in the fattened model. These species should be removed (garbage collected) from the flattened model. The species can only be removed if in the flattened model the species doesn't occur in any math expression, rule variable attribute, speciesReference or modifierSpeciesReference. an example is s2 in the above model
e) Relationship to Multi-component species - File Inclusion etc
couple of issues:
1) We need to be careful that we don't over complicate the process of including submodels that contain a system of species types and related generic reactions. I need to think about the issues around this. Really it's the complex species stuff that adds the complexity....
2) Observables, that is a set of multicomponent species states can referenced by a 'from' of a link (this effectively makes reactions involving the 'to' species template reactions). The big question is whether referring them in a 'to' of a link is possible however I think this is a real can of worms that is best left untouched for now.
f) Parameter Sets
It was argued that the mechanism for modifying parameter values is going to be extremely verbose and that syntactic sugar would be nice for this
g) SBML short hand
For the purposes of model composition specification development it might be nice to have a short hand notation for it (and perhaps a tool to support it..) I'll talk nicely to Darren...