>> 2. The RDF-based annotation scheme requires parsing RDF.
lenov> No. Since the RDF is expressed as XML, you can use
lenov> XPath to get right to the URI. You don't need to
lenov> take care of the fine structure of the XML tree.
Hmmm.... okay, but then you need an XPath/XSLT engine, no?
I'm not sure this is a significant enough savings over
having an RDF processor, but I may not have enough direct
experience with this and you may know better.
But anyway, I concede there may be easier ways to get to the
elements and that you don't need to parse the full RDF per
se. You could just get the XML and look for specific bits.
>> 3. The RDF-based approach requires around a dozen lines
>> 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
lenov> Human being are NOT supposed to read and EVEN LESS
lenov> supposed to write SBML files! A very large share of
lenov> the invalid SBML files floating around are due to
Do you really need to tell *me* that? :-) :-) Or are you
only reminding the rest of the mailing list?
Of course I agree with what you say. My point in bringing
up the readability issue is only this: even apart from
situations of occasionally having to debug the SBML, which
does happen at the level of the XML, software developers
continue to look at the XML and argue about the elegance,
conciseness, etc., of the format. When arguing for SBML as
a solution to someone's needs, developers are swayed by
simplicity and perspicuity. So although it shouldn't
matter, in practice, when talking to developers and trying
to explain "here's how you do X in SBML", it does.
lenov> In the qualified version, a <dc:relation> element
lenov> means "is" If there are several <dc:relation>
lenov> refering to terms of biomodels.net/CVs/, all the
lenov> terms should be fine. An example is the Henri,
lenov> Michaelis-Menten, Van Slyke, Briggs-Haldane
lenov> ratelaws. They have all the same formula although
lenov> based on very different assumptions.
lenov> As a rule, a software should be able to use any of
lenov> the alternative ratelaws refered to by the
Maybe I'm wrong in this, but it seems to me we want a way to
distinguish the intention behind the annotation. I'm
obviously having a hard time expressing it, but it seems to
me there is a sense in which the following are different:
"this reaction rate expression is taken from the
definition of term XYZ123 in rate law dictionary ABCDEF"
"for your information, this reaction rate expression is
the same as XYZ123 in rate law dictionary ABCDEF"
The first one is somehow a stronger statement, strong enough
that the reading application can know "ah, yes, this is not
merely an informational annotation made perhaps by someone
other than the model author; this model was actually created
with the assertion that the definition of the reaction rate
formula is identical in meaning and intention to the
definition of XYZ123 in ABCDEF."
But I suspect this could be done in the RDF approach too.