|
> 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.
I think I disagree. Currently a reaction can be defined without a
kineticLaw. Although the models are not simulatable, they are nevertheless
useful, if only to import and develop kinetics models. An sboTerm attached
would increase further the usefullness of those SBML files. A possible
solution would be to put an optional sboTerm on the reaction element. This
sboTerm would just be an indication, and the math attached to the term
would not be parsed with the help of terms attached to speciesReferences
and parameters.
In addition, we went in great length to define the structure of SBO so
that a soft can reconstruct the kineticLaw of a reaction based solely on
the sboTerms (which somehow is required by your point b) below).
> 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.
Verbatim, but for the symbols, that have to be those of the model, not the
CV.
> 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.
Well, it has to associate each bvar with the relevant SBML symbol first,
which is the hard part (but not too hard).
My battery is dying. I'll come back later
> 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
>
--
Nicolas LE NOVÈRE, Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223 494 521, Fax: +44(0)1223 494 468, Mob: +33(0)689218676
http://www.ebi.ac.uk/~lenov
|