— the global portal for all things SBML


SBML Editors' meeting minutes

Editors present: Frank Bergmann, Mike Hucka, Stefan Hoops, Sarah Keating, Sven Sahle, Darren Wilkinson
Editors absent: (No one absent)
Visitors present: (No visitors)
Location: Electronic video conference
Scribe: Mike Hucka
Recording(s): none

This SBML Editors' meeting focused on resolving issues that arose during and after the 2009 SBML Forum earlier this month. Topics and resolutions are listed in sections below.


1. Removal of SpeciesType from the Core leaves a conceptual gap?

Issue description:
As evidenced by some recent discussions on sbml-discuss (here and here), the plan to remove SpeciesType from SBML Level 3 Core has been greeted by dismay by some people. The essential issue appears to boil down to the following: some people are using SpeciesType as a way to link together species that are the same type of entity, and they do no want to lose this capability while waiting for a replacement Level 3 package to provide an alternative to SpeciesType. Several counterarguments have been offered (notably, the use of annotations, and the use of a proposed Groups package in Level 3), but these do not seem to have been accepted by the proponents of keeping SpeciesType in Level 3 Core.
We will survey the SBML community and ask which one of several alternatives they prefer. We will present the following alternatives:
* Keep SpeciesType and CompartmentType in Level 3 Core after all
* Keep only SpeciesType in the Core, and get rid of CompartmentType
* Don't keep either; have people use the Level 3 Groups package instead
* Put Groups (or some equivalent functionality) into Level 3 Core
The survey will ask people to explain why, if they want SpeciesType to remain, they cannot (or do not want to) achieve the same effect with the Groups package.
Action items
Image:Todo.gif Sarah and Mike will compose the surveymonkey survey.

2. Does <notes> content have to declare XHTML namespace?

Issue description
A recent issue that arose from the BioModels team concerned the rules for XHTML content in <notes> elements as specified in the SBML Level 2 specification documents. The BioModels team discovered the hard way that a recent update to libSBML caused some of their models to be flagged as having errors; it turned out that the libSBML update fixed a bug in validating the content of <notes> elements, and previous libSBML versions passed some content that was not allowed according to the SBML specification. This in turn brought attention on the question of just exactly what does the SBML specification say in this regard, and why.
After some discussions both on the SBML mailing lists and internally on the SBML Editors' mailing list, we concluded that the Level 3 specification should not have the restrictions that the Level 2 specifications have. The Level 3 spec should say that (1) the content of notes should be XHTML and (2) no validation is performed on the XHTML content. A last remaining question is whether the <notes> elements must declare the use of the XHTML XML namespace, or whether it is assumed. The SBML Editors concluded that it has to be declared. An example of what we might tell people to do is thus:
<notes xmlns:xhtml="">
  <xhtml:p> Text </xhtml:p>
or, conceivably, by declaring the default namespace,
<sbml:notes xmlns:"">
assume the model declared the prefix sbml elsewhere, such as on <sbml> (something that might happen if people start using sbml:units attributes in MathML content).
Action items
Image:Todo.gif The Level 3 Core specification needs to be changed to reflect this view.

3. Do we explain how to use XInclude for file decomposition in the Core?

Issue description
There needs to be a mechanism for allowing models to be decomposed into files. This is orthogonal to using L3 Hierarchical Model Composition; it simply means a way to split up models into files. At one time, there were discussions about defining SBML-specific constructs; at other times, there were discussions of using XML XInclude.
This is an XML-level issue. Strictly speaking, since L3 Core does not prevent inclusion of elements from other namespaces, then we implicitly allow models to reference XInclude constructs (unless we were to explicitly disallow the use of XInclude). Using XInclude is a good idea anyway, because it's a standard approach. XInclude is only a file inclusion mechanism, and would have no semantic implication. The decomposition of a model into separate files would mean you would have such things as
<xi:include xmlns:xi="" xi:href="path/to/file" parse="xml"> 
anywhere in the SBML file. The granularity could be anything that the user desired. E.g.,
<sbml ...>
   <xi:include xmlns:xi="" xi:href="listOfCompartments.xml" parse="xml"> 
   <xi:include xmlns:xi="" xi:href="listOfSpecies.xml" parse="xml"> 
   <xi:include xmlns:xi="" xi:href="listOfReactions.xml" parse="xml"> 
But it comes down to being a tool issue, so leave it to tools to implement support or not. Tools can advertise whether they support XInclude.
Action items
Image:Todo.gif After Level 3 Core is issued, we should add an entry to the FAQ about this. No one has been tasked with doing this yet.

4. What to do about differences in the MathML subset between SBML and SBO?

Issue description
The SBO entries sometimes have definitionURL on <ci>. If someone naively imports them directly into SBML, they will get a validation error. Now, definitionURL is disallowed in SBML L2 because it allows changing the definition of the semantics of <ci>. Also, it is arguably the case that SBO should not use definitionURL for the purposes it is using it for, but instead, SBO should use the <semantic> element.
After some debate, we could not really identify very serious problems with allowing definitionURL on <ci> elements after all. It seems unlikely that anyone would redefine <ci> semantics in a radical way. Therefore, as a concessiont to easier interoperability, we decided to allow definitionURL on that element in L3 Core.
Action items
Image:Todo.gif The L3 Core spec needs to be modified in this way.

5. Should there be a common data type for Parameter and LocalParameter?

Issue description:
The fact that LocalParameter and Parameter are so similar means that people would want to implement them in a way that treats them with common code, but the lack of a common base type for a parameter makes this not immediately easy if one is doing a straight implementation of SBML from the specification. This may make backward compatibility of code more difficult. This leads to the idea of having a common parent data class for Parameter and LocalParameter.
This can't be made to work out in the desired way. Parameter is the class that has more attributes than LocalParameter; therefore, structurally, we would want to derive Parameter from LocalParameter. Unfortunately, this would go in the wrong direction in terms of compatibility with SBML Level 2.
Action items:
Image:Dropped.gif No action to be taken.

6. Did we settle the question of whether separate RDF bags are equivalent to one bag?

Issue description:
Stefan did careful reading of the RDF specification and believes he found conclusive evidence that the SBML interpretation of using RDF bags is inconsistent with the RDF definitions.
The rest of the SBML editors need to try to understand RDF bags and decide whether we reach the same conclusions.
Action items:
Image:Todo.gif The other Editors need to try to under the issues better.

7. The value type of Parameter & others is double, but can be set to a rational. Inconsistent?

Issue description:
The value attributes of entites such as Parameter, SpeciesReference, etc., are defined as having type double, yet they can be set to rational numbers using (e.g.) an InitialAssignment coupled with appropriate MathML. In a simple interpretation of the definition of objects such as Parameter, it appears they only have double values. This seems inconsistent because the data type double can't represent the rational numbers.
We noted that it is only the attribute that is declared as having type double, and this attribute is only used for direct initial value assignments for scalar values. The object in question (i.e., the Parameter, SpeciesReference stoichiometry, etc.) does not itself have to be of type double; the object should properly be considered as a real number. This reflects the idea that the initial value attributes on entities like Parameter are only there for some cases of initialization, and InitialAssigment (among other constructs) is there to support for a wider range of needs.
Action items:
Image:Todo.gif The specification should probably alert developers to this, perhaps in the best-practices discussions. None of the Editors has been tasked with this yet.

Retrieved from ""

This page was last modified 23:11, 13 May 2010.

Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 23:11, 13 May 2010.