SBML.org — the global portal for all things SBML

2009-11-09

SBML Editors' meeting minutes

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


This SBML Editors' meeting focused on remaining issues before SBML Level 3 Core can be released. The following issues are not in any specific order and may not be in the order they were discussed.

Contents


1. Should info about tracker item 2017553 (delays within delays) be added?

Issue description:
There was a past tracker item (#2017553—Can csymbol delay reference another delay?) that at the time of L2v4 was pushed back to L3, and which we were supposed to revisit. The item concerns what happens if the mathematical expression in a delay csymbol contains another delay csymbol. Should the L3 Core specification say something about that?
Conclusions:
We judged that the specification actually already explains enough about how delays are to be interpreted. In the tracker item comments, Sven pointed out that circular references such as b = delay(b, 5) are not allowed by virtue of the fact that (in section 4.11.5) SBML rules are not permitted to be circular. Stefan added that referencing time (which delays do implicitly) should not be considered to break the dependency loop. Sarah provided a detailed interpretation of the time delays implied by nesting delay expressions, the outcome of which is that the "current time" always ends up being the same current time and the only effect is to add or subtract to the amount of delay. We decided that instead of adding something to the specification (which appears not to be strictly necessary) or even the recommended practices of the specification (which would be inappropriate because this does not really concern recommended practices), we would add an FAQ item about this topic. The FAQ item can use some of the details that Sarah provided in the tracker comments.
Action items:
Image:Todo.gif Add FAQ item regarding this topic. No one was assigned the task.

2. The MathML subset lacks basic things like rem (remainder) and others. Add them?

Issue description:
We discovered while looking at other parts of the MathML spec that certain relatively straightforward operators such as <rem> (for remainder) and several others were not in the SBML subset of MathML. It was not clear why they are omitted, since they are not problematic in the way that (say) integrals and differentials would be. Mike vaguely remembers that years ago, when L2v1 was first developed, the MathML subset was chosen to be as small as possible, and some operators that could be constructed using other operators were purposefully not included. Sarah suggests also that perhaps the subset was chosen to be as similar as possible to L1's math operators. Regardless, the question now came up of whether to add missing operators to the SBML MathML subset, on the occasion of issuing L3 Core.
Conclusions:
We had trouble coming up with a principled reason for choosing some operators and not others. Looking at the table in section 4.2.3 of the MathML 2.0 spec, we could not easily say which ones should be added and which ones not, without being arbitrary. (Example of arbitrary decision: if we're going to go add <rem>, why not then include the statistical operators? how about <gcd>, <lcm>? how about <grad>?) Considering how late in the development of L3 Core this is coming, we decided not to change the MathML subset in L3 Core beyond what is in the specification now. We anticipate that L3 packages may expand the subset of MathML operators on an as-needed basis.
Action items:
Image:Todo.gif We should add an FAQ item explaining how to define some of the missing operators in terms of the operators provided in SBML. Frank volunteered to do this.
Image:Done.gif added this entry Why can't I use the <rem> operator

3. Where are MIRIAM history elements permitted on SBML elements?

Issue description:
We have not yet edited the specification for the issue of expanding where history elements may be placed. (By "history elements", we mean the element described in section 6.6.) The question arose of what should the specification say? We know we want to allow history information on any SBML element, not just <model>, but what else do we change?
Conclusions:
The consensus is that expanding the places where history elements may be placed does not true functionality, because the history elements as they currently are defined in SBML are quite limited. For example, the history element provides a way to indicate who created something, but there is no predefined way of providing information about who modified something—there is only a way to add one or more modification time stamps, not modifiers' identities. Consequently, it does not appear to be important to belabor the new capabilities added by expanding the places where history elements may be put in an SBML model. We should simply remove the restrictions on putting them only on <model>.
Action items:
Image:Todo.gif Mike will edit section 6 in the spec to not restrict the placement of histories.

4. We cannot produce a fully valid XML Schema. What to do?

Issue description:
We have not yet produced an XML Schema for L3 Core, and the draft spec contains an empty section for that. Due to the removal of ordering restrictions on the contents of lists in SBML, the XML Schema cannot capture the full SBML L3 syntax. This means that if one goes only by the schema, one might reject L3 models that are actually syntactically valid. This could potentially cause problems. Moreover, we already know that we want to move away from XML Schema because it is generally weaker than RELAX NG and Schematron. So we have several options : (1) produce an XML schema and put it in the spec, like was done for past SBML specs, but include warnings about the schema's limitations; (2) produce a RELAX NG schema and include that in the spec instead, dropping XML Schema; (3) don't put any schemas in the spec, instead breaking out the schema(s) as a (or multiple) separate document(s).
Conclusions:
We do not believe we will have time to produce and debug a RELAX NG schema (at least not one we have confidence in) in time for a L3 Core release. We decided option (3), to remove the schema from the spec and provide it as a separate document, is the least problematic and most flexible solution in the long run. By doing so, we will be able to provide multiple schemas over time without having to issue new specs.
Action items:
Image:Todo.gif Mike needs to edit the relevant sections in the spec to remove the inclusion of the schemas, and to adjust the introduction section to reflect the fact that there is no schema in the spec document.

5. The validation rules need to be updated. How should we go about it?

Issue description:
Sarah made a huge first pass in identifying new rules and unresolved questions. Are there any other validation rules that need to be changed or updated?
Conclusions:
All of the SBML Editors need to go through the rules and the spec, and identify any remaining items.
Action items:
Image:Todo.gif Everyone will look at the rules and communicate over email about any issues they find.

6. Should kilogram and gram be recommended as possible substance & extent units?

Issue description:
Table 7 in the spec says that substance units may have units of gram and kilogram, but it does not state the same about extent units. The substance and extent units should be allowed to be the same. Then in addition, validation rules 20205 and 20210 should similarly be consistent, shouldn't they? And in addition, shouldn't other units be allowed? What if one wanted to use units of charge (coulomb) as a unit of substance? Shouldn't that be allowed?
Conclusions:
We don't want to recommend grams and kilograms as units of substance or extent. They're permitted, but it's not a recommended practice. Consequently, Table 7 should not list gram and kilogram as "recommended" valid units for substance or extent. However, the consistency-check rules can list these, since those rules are for testing consistency and one could in principle construct a consistent model using these units. (We merely don't want to recommend them, not disallow them altogether.)
Action items:
Image:Todo.gif Table 7 needs to be updated.
Image:Todo.gif We still need to settle the question of whether other units are permitted. We did not seem to reach a firm conclusion during the call.

7. Validation rule 20105 is unenforceable, isn't it?

Issue description:
Rule 20105 stated the following: The sbml container element must declare whether understanding any SBML L3 package used within the document is required for complete mathematical interpretation of a model. This is done using the required attribute for each SBML L3 package declared. Over email on the sbml-editors list, Frank noted that he thinks this is impossible to enforce.
Conclusions:
Frank is right. In order to verify whether the required flag is correctly included in a particular model, a software tool needs to know whether the namespace it's attached to is in fact an agreed-upon SBML L3 package namespace. If a namespace is referenced and the namespace is not a true L3 package, then the business about required is irrelevant for it. Even if the namespace URI starts with the SBML L3 package namespace URI prefix, then until the package is accepted by the SBML community, it is at best a provisional or experimental package, and again, the requirement about providing a required flag does not hold. Only by knowing which specific namespaces correspond to finalized L3 packages can a software tool apply this particular validation rule. Now, since we cannot even list the valid packages now, and since packages may be introduced in the future, we cannot actually list all the valid namespaces in the L3 Core specification, which means that we cannot properly define the validation procedure for this rule.
Action items:
Image:Done.gif Sarah will remove this from the specification's list of validation rules.

8. Are 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.
Conclusions:
The rest of the SBML editors need to try to understand RDF bags and decide whether we reach the same conclusions. Sven agrees that Stefan's argument is self-consistent, but also finds that the RDF specification's language is confusing. We need further research to reach a consensus that we have 100% rock-solid evidence for any conclusions about SBML's descriptions of RDF usage.
Action items:
Image:Todo.gif The Editors will investigate RDF bags and mail their conclusions by mid-day (PDT timezone) Nov. 10.
Image:Updated.gif 2009-11-10: The conclusion is that in fact the SBML specification is not in error.

9. The list of BioModels qualifiers needs to be updated

Issue description:
The list of biomodels qualifiers has changed since the current copy of the spec has been issued.
Conclusions:
We need to update the list of BioModels qualifiers in section 6 of the spec.
Action items:
Image:Todo.gif Someone needs to do the update. No one was assigned the task.
Image:Updated.gif (2009-11-10) Frank volunteered to take this up.
Image:Done.gif (2009-11-16) added the three new identifiers

Retrieved from "http://sbml.org/Events/SBML_Editors%27_Meetings/Minutes/2009-11-09"

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.