Re: Proposal: simple mechanism for referencing rate laws
17 Jun '05 19:15
My first impression after quickly skimming the proposal:
(1) The <csymbol> approach is much simpler but leaves the SBML
without having the rate law explicitly encode but It has the
"advantage" of the parameters being name-independent but positional.
(2) The <semantics> approach has the advantage of encoding the rate
law but if there are 1000 reactions with the same rate law in the
file the rate law is repeated 1000 times.
These points are both made in the summaries of the appropriate sections.
Is there some way a function reference to a function in the
<listOfFunctionDefintions> can be added to either of these methods
to make the model both self-contained and non-duplicitous? The
positional arguments of the <csymbol> approach fit in with this
On Jun 17, 2005, at 6:28 PM, Michael Hucka wrote:
> Dear SBML community,
> You may recall a long-running discussion thread not long ago
> in which one of the issues raised was the need for a way of
> labeling rate law expressions in SBML Level 2 models. That
> particular thread was not the first time the issue was raised.
> One solution is to use the general URI/RDF-based annotation
> scheme proposed by Finney and Le Novere:
> Their approach is applicable not just to rate laws, but for
> any annotation on a model. It provides a means of relating
> rate laws and other parts of models to definitions in
> community-organized controlled vocabularies.
> Some people have expressed reservations about the complexity
> of the content that is inserted into SBML to make the
> RDF-based solution work.
> I've developed two proposals for light-weight alternatives
> specificially limited to rate laws, using existing MathML
> facilities as much as possible. These alternatives assume
> essentially the scheme proposed by Le Novere and Finney for
> managing the controlled vocabularies, but offer a different
> SBML syntax for referring to CV terms.
> I seek feedback and discussion on these two proposals. I've
> described them both in a single white paper because they are
> closely related. The white paper is here:
> Both alternatives seem workable to me, but they have
> different tradeoffs, and I'd like to leave it to the rest of
> you to discuss and perhaps decide on one (or none) of the
> two. If there is sufficient interest, the winning version
> could be considered as a candidate for inclusion in SBML
> Level 2 Version 2.
> I hope this proposal will stimulate discussion and a
> resolution of this problem in SBML.