|Editors present:||Frank Bergmann, Mike Hucka, Sven Sahle, Jim Schaff, Lucian Smith, Darren Wilkinson|
|Editors absent:||(No one absent)|
|Visitors present:||Herbert Sauro|
|Location:||University of Washington|
This SBML Editors' meeting focused on SBML Level 3 issues and development of Level 3 packages.
Question: can Level 3 packages extend the MathML subset? How?
We started out by looking at an example, using the 2005 Gillespie & Wilkinson proposal for distributions and ranges (direct link to PDF is http://sbml.org/images/5/5e/Distributions-2005.pdf — see also the SBML.org wiki for Level 3, in the entry for distribution and ranges). Considerable discussion and exploration followed about what could be done to support such things.
Stepping back, we should first answer, what are the requirements for what we're trying to accomplish?
- Allow packages to extend the MathML subset that models are allowed to use.
- Allow packages to introduce new functions and constants that don't exist in MathML.
- Accomplish #1 and #2 in a way that permits the validation of models. This means that a software tool should be clearly able to evaluate whether some given content comes from a package (as opposed to being an error in the model).
- Allow those constructs to be used in user-defined functions, because people are certainly going to want to do that.
- Require packages to specify where the extensions (functions and constants) are permitted to be used in a model. (For example, currently L3 Core allows the use of
csymbolfor delay, but does not allow that to be used in the definition of a user-defined function.)
We looked at the following options:
- Allow new
definitionURLattributes can have patterns that clearly indicate they come from Level 3 packages. (This is the approach taken in the Gillespie et al. proposal mentioned above.)
- Introduce a new
csymboldefinition that is essentially a special type of
applyelement, whose first argument is the identifier of a function defined externally.
- Extend FunctionDefinition to allow not only the
<math>element, but also a construct that provides a way of referencing an external definition.
- Provide a different parallel construct to FunctionDefinition with different capabilities & restrictions.
We worked on direction #4; results are shown in the subsection below.
Proposal for a new construct to extend the math allowed in a model
This approach answers the question of how a package can introduce new identifiers with mathematical meaning. The ideas is to use a separate construct that defines the meaning of the identifiers, and stipulates that those identifiers can be used as id's used as the first
<ci> element inside an
<sbml xmlns="http://www.sbml.org/sbml/level3/version1/core" level="3" version="1" xmlns:distrib="http://www.sbml.org/sbml/level3/version1/distrib/version1" distrib:required="true" /> <model ...> ... <listOfDistribFunctions xmlns="http://www.sbml.org/sbml/level3/version1/distrib/version" xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core"> <functionBinding sbml:id="normalRandom" function="distribNormalFunction"> </listOfDistribFunctions> ... <listOfRules> <assignmentRule variable="S1"> <math xmlns="http://www.w3.org/1998/Math/MathML" xmlns:sbml="http://www.sbml.org/sbml/level3/version1/core"> <apply> <ci> normalRandom </ci> <ci> mu </ci> <ci> sigma </ci> </apply> </math> </assignmentRule> </listOfRules> ... </model> </sbml>
What happens if a tool doesn't understand the package ("distrib" in this case), and comes across the reference to the identifier
normalRandom in the assignment rule? The fact that the package is required means that the tool shouldn't have the hope of understanding the math anyway.
FunctionDefinition restricts what can be used in the
<math>— how is this affected now?
The L3 Core FunctionDefinition definition states that identifiers in
<ci> elements can only be either identifiers passed in through
<bvar>'s or else identifiers of other FunctionDefinition objects. But this is not a problem, because we already said that packages can extend the Core. This is a case where a package would extend the Core by extending what can appear inside FunctionDefinition objects.
But this approach doesn't answer how to extend the MathML subset, does it?
There is a problem that SBML defines a particular subset of MathML to be used inside
<math> elements, and if we allow packages to use different MathML subsets, a difficult and ugly validation problem arises. Thus, it's true that the current solution only solves how to introduce new identifiers that have a (potentially) mathematical meaning, and not the problem of how to introduce new MathML constructs.
We decided to punt on the original problem and simply see how far we can get with the proposed approach. It may be that this is enough for people's needs.
Is there a problem with non-required packages and identifiers?
Suppose a package is not required for fully understanding the math of a model. Then what was said so far was that the package's constructs could be ignored when reading a model, and in principle, the model should be simulatable. However, if the constructs in the package define identifiers (of type SId), then there is a risk of creating invalid SBML: the tool may not know which identifiers were defined in the constructs of the package, and might accidentally create more entities with the same identifier. Then a tool that does understand the package would find duplicate id's being used.
- Require that all identifiers in a model are created using an attributed called
idand is in the SBML namespace.
- Make identifiers created within those package constructs be in their own namespace.
- Require that all identifiers created within those packages, if they are meant to be used elsewhere in the model, are defined using a namespace-qualified attribute
Provisionally, we feel #3 is a workable solution. It has an additional advantage that a software tool could look for all
sbml:id definitions in a model even if doesn't understand the rest of the package.
An additional realization we had is that the same treatment should be done for metaid's (meaning, they should be done as
Moving to working on a proposal: let's look at Groups
Decision: despite the various weaknesses, we decided it's still worth pursuing. Here are some characteristics decided upon:
- Groups can have identifiers (using the
- Cannot reference the id in MathML
- No explicit semantics/typing/relationship attributes to indicate the relationships (see below)