Forums

Here is a PROPOSAL for refining and clarifying how to use
sboTerms to address the issues that have been raised. If
this is really bogus for any reason, feel free to flame away
:-).

Background assumptions:

A1) sboTerm attributes are optional.
A2) the math recorded in a model is authoritative
A3) the restrictions below only concern sboTerm on kinetic
laws; sboTerms may be present on other SBML elements
without restriction

Now stipulate the following (where the key change is item b):

a) If an sboTerm attribute is present on a KineticLaw
object, the 'math' field must also contain a formula. A
model containing an sboTerm on a KineticLaw lacking a
math field would be deemed invalid.

(The converse is *not* true: if a math field is present,
an sboTerm does not have to be present.)

b) If an sboTerm attribute is present on a KineticLaw
object, the formula stored in the 'math' field must be
verbatim the formula recorded with the definition of the
CV term referenced by that sboTerm.

This sounds hard to implement for an SBML writer, but
isn't: if a tool understands sboTerm, then it must have
access to the CV. If it has access to the CV, then
(presumably) it can simply read out the formula stored in
the CV entry and do a literal string substitution into
the model. (Indeed, this is one of the design principles
of the whole approach.) I believe Howard Salis made this
point too.

c) Tools reading SBML should behave as follows:

1) If a tool does not understand sboTerms, it can ignore
them: it should treat the model as it would today,
looking at the math only.

2) If a tool understands only sboTerms and not the math
formulas, it is like other tools today that do not
understand SBML maths. Users should be made aware of
how the tool is interpreting the SBML, and it might be
perfectly acceptable to the tool's users. As with
other tools that do not interpret the math, the tool
would not pass all parts of the SBML validation suite
and would not be considered fully SBML compliant.

3) If a tool understands both sboTerm and math, then this
implies it must have access to the SBO CV. (Otherwise
it wouldn't be able to understand sboTerms in the
first place.) If that's the case, then by condition
(b) above, the tool should be able to perform
consistency checking between the formulas and the
sboTerms *without* having to perform a test of
mathematical equivalence: the formulas should be
identical, modulo differences in whitespace and
formatting. Therefore, as a best-practice guideline,
those applications that can, should check that the
sboTerm definitions and the math formulas are
literally the same. (However, because this is
probably something that not everyone will implement,
we probably cannot make this a requirement, only a
best-practice guideline.)

d) Tools editing and subsequently writing out SBML should
behave as follows:

1) If a tool does not understand sboTerms, then for any
SBML element that it modifies, if the element contains
sboTerms it should remove the sboTerms on that
element. (This is not ideal, but reduces the chances
that what is written out has become inconsistent
because of changes made to elements.)

2) If a tool understands only sboTerm and not math, then
presumably it must have access to sboTerm definitions.
Then, for kinetic laws that it writes out, it should
be able to read out the definition of the law from the
CV, and perform direct literal substitution into the
'math' element of the kinetic law.

3) If a tool understands both sboTerm and math, then
presumably it already will be designed to produce
consistent output and no special guideline is
required.

Somehow I feel I'm missing some essential problems, but
anyway, how does this sound to people?

MH