I am accepting this issue as valid.
We might want to consider putting an ID on rate rules and letting people use them in MathML. The concept of using a derivative inside an equation is fairly standard, and would expand the range of models that translate to and from SBML.
EDIT: discussion of the above idea agreed that the goal was good, but needed a different way to go about it. After considering several possibilities, we finally settled on 'provide a csymbol that means 'the rate of change of X'.
I am accepting this issue as valid.
I'm interested in hearing different opinions on this--how easy would it be for simulators we know about to incorporate the concept? How useful would it be for modeling?
I am accepting this issue as valid.
I'm accepting this as a valid issue for L3V2.
I have to say, I did not encounter many models potentially covered by SBML with such a feature. That would become different when we start covering physiology, developmental biology etc. (that often use multiphysics). I would say this is at minimum a package issue, but most probably an SBML+ issue. Definitively not an L3V2 core issue.
I am accepting this issue as valid.
This was considered and proposed as part of the changes to L3v2, along with the general addition of SIds on lots of things.
Diff:
--- old +++ new @@ -1 +1 @@ -We might want to consider putting an ID on rate rules and letting people use them in MathML. The concept of using a derivative inside an equation is fairly standard, and would expand the range of models that translate too and from SBML. +We might want to consider putting an ID on rate rules and letting people use them in MathML. The concept of using a derivative inside an equation is fairly standard, and would expand the range of models that translate to and from SBML.
Update: the current thinking on the SBML editor's list is to introduce a new csymbol which would, I think, be used in an 'apply' context, and would mean 'the derivative of this symbol with respect to time':
<math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <csymbol encoding="text" definitionURL="http://www.sbml.org/sbml/symbols/derivativeof"> derivativeof </csymbol> <ci> S1 </ci> </apply> </math>
I don't know if we want to allow other things to go in the 'S1' slot, above, or not?:
<math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <csymbol encoding="text" definitionURL="http://www.sbml.org/sbml/symbols/derivativeof"> derivativeof </csymbol> <apply> <plus/> <ci> S1 </ci> <ci> S2 </ci> </apply> </apply> </math>
which would be d(S1+S2)/dt.
-Lucian
(I should also add that there is existing MathML out there that could encode this as well. However, it was felt that if we introduced the general MathML form for creating derivatives, we would allow the encoding of models that the majority of interpreters could not actually parse--things like d(S1)/d(S2) or the like. If we actually only want to allow d(X)/dt, it's much safer to just have that.
Another option is to add something to a 'ci' element:
<ci> S1 </ci>
would mean 'S1', while
<ci sbml:isderivative="true"> S1 </ci>
or perhaps
<ci> S1 <sbml:derivative /> </ci>
would mean 'the derivative of S1 with respect to time'.
People are currently leaning towards the 'csymbol' version, however.
I was wondering the same thing. You could use "diff"
http://www.w3.org/TR/MathML2/chapter4.html#contm.diff
Like you said, this would mean that it would be possible to describe derivatives which are not with respect to time which would make analysis substantially more complicated. However, I think you are even now allowing for some things which would be problematic. Your example allows for something like:
d(S1 * S2) / dt
which if my calculus is remembered correctly (big if there), is not equal to:
dS1/dt * dS2/d2
and it is typically only those rates which are readily available. I think we need to go further and restrict it to be a single identifier and not an expression.
That being said, I'm a bit more partial to just using diff and adding restriction to this form:
<apply> <diff/> <ci> S1 </ci> </apply>
which is interpreted I believe as the time derivative of S1.
Chris
Discussions over the sbml-editors list led to the following votes so far:
Frank: csymbol
Sarah: csymbol
Mike: csymbol
Argh, I didn't notice the second page of discussions.
So, I think there is merit to Chris' suggestion of using <diff>. I think the question boils down to which is better: reusing the existing MathML <diff> but putting lots of restrictions on its use (which makes it non-MathML-y), or using csymbol, by which we would be duplicating capabilities that do already exist in MathML, but have the freedom to define it whatever way we choose (=> simpler, and actually more MathML-y).
(Note: edited my and Chris's posts so that the XML showed up in the comments on the web site. The trick turns out to be that you need four spaces of indenting, and then it knows to treat it as raw XML instead of formatted XML.)
I would strongly object to the introduction of the mathml general differentiation. In SBML we do integrate over time, and I hope this is not about to be changed soon. Using the mathml diff
operation, we would allow expressions like:
<apply> <diff/> <bvar><ci>x</ci></bvar> <apply><sin/><ci>x</ci></apply> </apply>
Something I would not want to invite. And while we could certainly restrict the diff
opertator imported into the SBML-mathml, it seems wrong to restrict it to restrict it to diff
s without bvar
s and only certain ci
s. Similarly with the csymbol
, for the time being, i would only allow direct SIds
to be referenced.
I still think we should do think properly, or not doing it. Inventing a symbol to re-implement part of the wheel (subset of diff) seems very clunky to me. If we only want to refer to the time derivative of a variable, we should use rateRule id, with the proper safeguards like we use reaction's id (that are also time derivatives). But I think the crux of the issue is Frank's statement: "In SBML we do integrate over time, and I hope this is not about to be changed soon". Should it not be "In systems biology modelling, we do X, Y, Z" rather than in SBML? So why don't we find actual examples, in publications, of what is needed here? Personnaly I saw way more dx/dy than dz/dt on the right hand side.
Here is a proposal that could perhaps bridge both sides: We use MathML diff, but in the spec, we say that valid L3V2 core must used the csymbol time as the second argument. So in the future, if we decide to introduce other derivatives, we just relax the rule, without changing the syntax.
Well, what was meant by the statement "this is not about to be changed soon" is that it would be a much bigger change, that I feel cannot be done in a minor version change. I don't think that fixing time will be as easy either, as then we would have to make sure that the bvar
element of the diff
would have to be the csymbol
we use for time. That is why i suggested that if we really have to use it we require no bvars and only ci elements representing SIds.
This is exactly what I was proposing. We allow diff with no bvars and only a single ci element representing an Sid. We would need to make a similar restriction with csymbol, so it does not appear to me to be any cleaner to use csymbol.
Chris
So, looking at the MathML spec, it seems to me that what we want to say is not actually what 'diff' implies:
http://www.w3.org/TR/MathML2/appendixc.html#cedef.diff
and
http://www.w3.org/TR/MathML2/chapter4.html#contm.diff
In both of these descriptions, the first argument of 'diff' is a function, not a variable, and the second (optional) argument of 'diff' is a variable that occurs in that function. Hence, you can write "diff(x^2, x)" or "diff(sin(x), x)", but you cannot write (as we want to) "diff(S1, time)", because S1 is not a function that takes 'time' as an argument.
Maybe there's a different MathML construct that does what we want? But if not, I think we're back to the 'csymbol' or 'ci' element options.
I had the confusion initially. However, when we say plot S1 in a simulation. What we are really saying is plot S1(t). Namely, all are variables are actually functions of time already. Therefore, I think diff(S1,t) is exactly what we want.
Chris
Actually, this is exactly what we are doing. A timecourse in systems biology is describing the evolution of variables that are function of other variables, including time. The variable is just implicit. But it is only because it is introduced in the numerical resolution by the solver. We had an interesting double deaf discussion during the first distrib meeting. PKPD modellers explicitly include time as a dependent variable, which allow them to use variability not just in the ordinates (what we call the variable) but also in the abscissa (the time). So they would say X=F(X,P,t) where X would be the vector of concentrations, P the vector of independent variables and t is time. We can then compute dX/dt, or dX/dWhateverWeWant.
So, hmm. You're saying that when it talks about functions:
"The derivative of a function f (often displayed as f') can be written as:
<apply> <diff/> <ci> f </ci> </apply>"
We can use 'S1' instead of 'f', because S1 is, in some way, a function with respect to time in SBML? I guess I could buy that. It avoids the bvar issue that Frank was worried about, and uses the standard that Nicolas wants us to use...
My only worry about this is that while time is indeed the only 'domain' in core SBML, spatial adds space to that, meaning that 'the gradient of S1' might mean 'the gradient of S1 in time' or it might mean 'the gradient of S1 along the X axis' or the like. I guess that package would be allowed to relax our core restriction here, should they wish to?
Log in to post a comment.