Forums

shoops> Hello Mike, I still do not get why we need a
shoops> kinetic law without a math element. If I do not
shoops> know the mechanism I do not have a kinetic law. If
shoops> I know the mechanism (not only ODE) I have a
shoops> kinetic law and a mathematical expression. Our
shoops> problem is not the math element our problem is
shoops> that the math element only describes the right
shoops> side of an ODE in the current specification. In my
shoops> opinion this is the problem we need to attack. As
shoops> I have suggested earlier subclassing of the
shoops> kinetic law could be a solution. In addition we
shoops> can allow multiple kinetic laws for a reaction
shoops> each being from a different subclass.

Hi Stefan,

I only meant to propose the empty-math-interpretation as a
potential middle ground in the arguments on both sides. The
approach would have the advantage of answering the requests
made by some people for being able to have syntactically
valid SBML models that are incomplete. (But, these would
obviously not be considered fully characterized models.)

For example, the JigCell group (whose tool reads and writes
SBML as its "native" storage format) have noted that users
sometimes want to save a model even though it's not complete
and thus not fully characterized. If the tool is rigorously
checking syntax, writing out incomplete kinetic law elements
(for example) would be a no-no, leading to annoyance for the
user. Of course, there are other ways of coping with this,
but this is an example of the motivation for the idea above.

Other people recently noted that models are not developed
overnight, and pieces may be added over time. See, e.g.,
http://www.sbml.org/forums/index.php?t=tree&goto=2972&rid=0

Let's turn to the idea of subclassing for a moment. The
difficulty with subclasses that I see is they have to be
defined in the specification as permissible syntactic data
structures, and we don't (and probably can't) have a settled
list of these types. So how would we write the SBML
specification for these subclasses? Maybe I'm missing
something obvious. (Wouldn't be the first time.)

But along the lines of your suggestion, I'd like to throw
out the following idea. What if Reaction were defined to
have not one KineticLaw, but a list of KineticLaws? A model
would then look like this:

<reaction id="J1">
<listOfReactants>
...
</listOfReactants>
<listOfProducts>
...
</listOfProducts>
<listOfKineticLaws>
<kineticLaw sboTerm="..."> <!-- 1st one -->
<math xmlns="...">
...
</math>
<listOfParameters>
...
</listOfParameters>
</kineticLaw>
<kineticLaw sboTerm="..."> <!-- another one -->
<math xmlns="...">
...
</math>
<listOfParameters>
...
</listOfParameters>
</kineticLaw>
</listOfKineticLaws>
</reaction>

The specification would state that if a tool cannot deal
with alternative formulations, it can take the first law in
the list. Most models would have only one kinetic law
anyway.

Some tools would be more advanced and allow a user to
explicitly define alternative kinetic laws for different
simulation frameworks. For example, one might be for ODEs,
while another (or maybe even more than one) kinetic law in
the list might be for discrete stochastic simulation, and so
on.

The main difficulty I've been having with this idea is
coming up with a scheme for establishing correspondence
between the kinetic laws defined in different reactions.
Basically, the problem is, if you have two reactions R1 and
R2, and each has multiple kinetic laws, how do you know
which kinetic laws to use if you're doing a simulation?

In the example above, I show the use of sboTerm attributes
on the kineticLaws, the idea being that the attribute would
point to controlled vocabulary terms standing for
"continuous deterministic simulation framework", "petri net
framework", etc. But that's not the only way it could go.
Here are the alternatives that come to my mind:

a) Use sboTerm tags as above.

b) Do it by position. All the first laws in every reaction
woudl implicitly be grouped together, all the second laws
would be grouped together, etc. Problems with this idea
include: what if two reactions don't have the same number
of kinetic laws? What if one reaction is supposed to
translate to multiple kinetic laws in a certain
framework? Basically, this approach seems fragile.

c) Use a new attribute giving a sequence number for each
kineticLaw -- something that says essentially law=1,
law=2, etc., and the specification would stipulate that
all laws labeled #1 would belong together, all laws
labeled #2 would belong together, etc. This seems more
robust than alternative (b), but still doesn't address
the possibility of a reaction requiring multiple rate
laws in some given framework.

d) Have some sort of type attribute on the kineticLaw
elements, like type="something". I feel this is no
different than using sboTerms, and is actually worse,
because it would require us to agree and prescribe a
separate list of terms. There are obvious problems with
maintenance, evolution, and error correction.

Anyway, this is just an idea. I'm curious to hear what
people thing. It might be stupid, but I'm prepared to take
the flames ;-).

MH