Forums

salis> It would be much easier to evaluate the rate laws
salis> of each reaction if they all had standard forms. A
salis> MathML expression is not unique. The same algebraic
salis> expression can be manipulated innumerable
salis> ways. Given two models with the same reactions, but
salis> different rate laws, it is still possible that
salis> those models are exactly equivalent. If each rate
salis> law had a standard form, not only would the
salis> expression and meaning of the rate law be clear and
salis> concise, but it would also make it unique. The
salis> unique identifier (it doesn't have to be an
salis> integer, it could be a string) could be stored
salis> alongside the MathML expression so long as the
salis> program which created the SBML file can match the
salis> expression with the standardized form of the rate
salis> law.

You are proposing that every rate law that can possibly be
placed in a model (SBML or otherwise) be assigned a unique
identifier, correct?

1. How will you construct the list of all possible rate laws?

2. Who will have authority to decide the correctness of a
particular rate law statement? (Errors are believed to
exist in long-established software packages as well as
printed publications, but who arbitrates?)

3. What happens when an existing definition of a rate law in
this master list is discovered to have errors? In
particular, what is the implication for all the software
tools that conformed to a specification of the list at
one time, but no longer do because definitions have been
updated?

4. What happens when you discover a rate law is missing from
the master list?

5. Obviously it is not enough to simply provide a list of
all the rate law names; the definitions of the rate law
formulas must be available too. How will software tools
obtain these definitions in a machine-readable form?

I'm not trying to be flip here. What you propose was in
essence tried with the collection of predefined rate laws in
SBML Level 1. The problems above are very difficult to
solve when a language specification includes an explicit
list of function definitions. These problems are part of
the reasons why the list disappeared in SBML Level 2.

By providing user-defined functions, SBML Level 2 obviates
some of the problems above, but (unexpectedly) introduces a
different one: people want to be able to have names
associated with the rate laws, but there is no defined way
of doing this in SBML Level 2. The simple solution of
providing a label attribute (like rateLawName="hill", etc.)
seems like it ought to work, except that as soon as people
attempt to share their models between software tools, they
run into the problem that different tools (or rather, the
tool authors and users) use different names, different
definitions, etc.

What's the alternative?

Instead of putting the definitions into the language,
several people have been working on a proposal to define a
scheme using extensible controlled vocabularies. The scheme
attempts to address each of the problems listed above.

Watch this space ... :-)

MH