Forums

Here are some additional late comments in response to
Andrew's comments about the proposed "simpler" scheme for
reaction rate expressions in SBML. I've changed the order
of the quoted text.

afinney> As I have said before several times on this
afinney> mailing list we really need a general mechanism
afinney> for CV annotation. The RDF approach is one
afinney> standards based approach to do this.

I don't have an objection to using RDF for general
annotations of the sort proposed for database linkages. My
reasons for making the alternative proposal I sent are
specifically related to dealing with reaction rate
equations.

1. People requested a way of unambiguously labeling each
reaction rate equation as being a particular
known/well-defined formula. My proposal does this with
simple, direct syntax, and importantly, when it's used
it's clear that such an assertion is being made.

My understanding of the 11 May 2005 URI/RDF-based
annotation proposal is that it does not offer an obvious
way of being so specific. The URI/RDF approach provides
a mechanism for attaching multiple statements of the form
"X has a relationship to Y" for a kineticLaw element.
Without a specific relationship type for this case, there
is some ambiguity about whether any of those annotations
is an assertion about the definition of the reaction rate
formula. A software tool would therefore have trouble
determining when it could substitute another, equivalent
definition for that formula. It's not enough to look for
a relationship having a root URI of (say)
http://biomodels.net/CVs/... because the definition may
be specific to a group of users and not contained in a
biomodels.net CV, and thus wouldn't be detected by
looking for a reference to a particular URI.

That said, I think the URI/RDF-based approach could
probably be made to work in this way, by (1) introducing
appropriate relationship terms beyond the Dublin Core
ones (again, if I'm reading it correctly -- perhaps this
already is there and I'm misunderstanding the available
relationship terms) and (2) establishing some guideline
that indicates which relationship takes precedence in the
case when a kineticLaw has multiple annotations.

2. The RDF-based annotation scheme requires parsing RDF.
While this may not matter to people using a library such
as libSBML, which would hide such things from the calling
app, it does matter to people who can't use libSBML and
would have to implement RDF handling on their own.
Contrast this to the syntax in my proposal, which
requires parsing and handling only one or two more MathML
construct, and these MathML constructs are *already*
defined in SBML -- apps should already be prepared to
handle them. The proposal is thus quite minimal in its
imposition of new syntax and needs.

3. The RDF-based approach requires around a dozen lines of
not-terribly-obvious XML to make a statement that is
captured in roughly 2 lines in my (IMHO) simpler
proposal. The simpler proposal is clearly more
parsimonious. IMHO it is shorter and easier for humans
to read the resultant SBML, and I hypothesize, it will
take less time to process by software tools.


afinney> a) IMHO we need to have a general purpose CV
afinney> reference mechanism outside MathML. I'm not sure
afinney> having a duplicate system in MathML reduces the
afinney> complexity.

For the 3 reasons given above, I think my simpler
alternative proposal not only is noticeably less complex to
implement, but also (because of reason #1) does not entirely
duplicate existing functionality in the URI/RDF approach.


afinney> I think its time for the people who don't like
afinney> the RDF approach to really come out and argue
afinney> their case.

We have not seen a lot of responses either way to follow up
on this question. The few responses that were made were
essentially along the lines of "whatever, just provide an
API in a library like libsbml". But I have a feeling this
is not really representative of the majority view. Perhaps
we need to formulate a survey to really bring out some
responses to this question, because I think it's important
to get answered.


afinney> If RDF is soooo hard to parse we could just use
afinney> an SBML specific mechanism which can used in all
afinney> cases.

Maybe this is in fact needed. This question should perhaps
be rolled into the question above, in a survey?


afinney> b) The 'csymbol' approach you outline is probably
afinney> more true to the intended
afinney> use of 'csymbol' than is the 'semantics' approach
afinney> is to the intended use of 'semantics'.
afinney> http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter4.html#contm.semantics
afinney> seems to indicate that semantics allows you
afinney> attach annotations to MathML elements. Its not
afinney> clear: a semantics element without an annotation
afinney> element might be invalid.

Available evidence says it's valid. Here are 2 sources of
evidence:

1. Section 4.2.1.4 has an example of <semantics> without
<annotation> or <annotation-xml>. See
http://www.w3.org/TR/MathML2/chapter4.html#contm.deffun

2. The Content Validation Markup Grammar defined in Appendix
B of the MathML 2.0 specification clearly makes
<annotation> and <annotation-xml> on <semantics> optional.


afinney> c) Despite (b) I actually think the semantics
afinney> approach is correct way to
afinney> structure the information. The link to the rate
afinney> law CV should be in addition to the rate law
afinney> MathML not a replacement for it. That way the CV
afinney> information can be ignored and the model can be
afinney> simulated.

Yes, I myself prefer this option too.

Thanks for your feedback!

MH