SBML Level 3 Package Proposal: Stochastic Differential Equations (SDE)

[Lucian Smith]

Hey, everyone!  We've been talking about this at COMBINE and HARMONY meetings, but finally, following the Level 3 Package Development process, T.J. Sego, Rahuman Sheriff, and I would like to formally propose that the SBML community accept the idea:  "We should develop a L3 package for stochastic differential equations."

Here is the full proposal:

https://docs.google.com/document/d/1od1ZWv6apH4XPqcXbBR_Al_uwiOA1jmCuq2uIzJ29jk/edit?tab=t.0#heading=h.i11tldx2xa35

Note that this is a *proposal*, not a *draft specification*.  While we would love to have everyone's comments on the draft spec, what we need to start the official process is a vote by the community that just says, "Yes, we should have a package that covers this."

So!  This begins a formal 2-week 'call for feedback' time.  Feel free to comment here or on the document itself with any comments, complaints, or suggestions you might have.

In two weeks, we'll vote, and if the result is 'accept', we'll formally invite people to a package working group and work on the specification itself will continue.

Full details of the package development process can be found:

https://sbml.org/documents/process/level-3-process/

Thank you all!

-Lucian Smith

[Lucian Smith]

Thanks to everyone who's been commenting on the proposal and draft specification for SDE.  Most of the comments thus far have been about the specification itself, instead of on the 'proposal' side of things.  We welcome more contributions to the discussion, at:

https://docs.google.com/document/d/1g_lVAZGEW4VQg_h1yOOHJvMR_Hphp77Ss3_O7HaomF8/

My own interpretation of the current points of contention are that they concern the scope and implementation details of the proposed package, not whether the package as a whole should be worked on.  As such, I would like to go ahead and call for votes on the *proposal* on Monday.  But if people disagree, let me know!  

-Lucian Smith

[Hoops, Stefan (sh9cq)]

Hello Lucian,

It might seem that this is a minor point but I would suggest that we
remove the implementation SDE of the simulation from the proposal
title. I prefer to use some thing: 
Intrinsic Noise Specification. 

Thus the scope will be broader as it is not limited to SDEs though
those will probalby the main use case. Additionally the new title names
the additional model component described.

Thanks,
Stefan

--
Stefan Hoops, Ph.D.
Research Associate Professor
Biocomplexity Institute & Initiative
University of Virginia
995 Research Park Boulevard
Charlottesville, VA 22911

Phone: +1 540 570 1301
Email: sho...@virginia.edu

[Lucian Smith]

I am certainly not opposed to expanding the scope of the package, but I would want to know exactly how it was going to be expanded, and what kind of modeling would additionally be covered.  Currently, the only concrete proposed change to the draft specification I've seen has been to *limit* the scope of the package from 'SDEs using a variety of integrals' to 'SDEs using the Ito integral alone'.

What other forms of 'intrinsic noise' are being proposed?  What kind of modeling would they allow that the current proposal/spec does not?

If it's currently unclear what the answers to those questions are, I think it would be OK to defer that to the package working group to work on in the coming months.  But if people have a clear idea now, that'd be great.

-Lucian

--
For questions or feedback about the sbml-discuss list,
contact sbml...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "sbml-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbml-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sbml-discuss/f95786ec6dd923b9ae99589289863a4332e238c4.camel%40virginia.edu.

[Hoops, Stefan (sh9cq)]

Hello Lucian,

I am not an expert either but limiting the use of intrinsic noise only
to SDEs seems wrong. The core did not limit the scope to ODEs. In the
contrary the fact that it is not limited to ODEs is the strength. It is
in actually possible to use Ito variant SDEs to simulate a core model
if it is interpreted in the Langevin sense.

Limiting the interpretation to only one mathematical approach should
not be what we are striving for. I just like to focus on why we
invented SBML. We wanted to describe model and facilitate exchange of
models and therefore validation of analysis results.

Thanks,
Stefan

[Rahuman Sheriff]

Hi Stefan,
I like your idea to keep things board for future.
But, I am not sure whether "Intrinsic Noise Specification” is the right direction here. distrib package can help define distributions, and these can be used to specify various intrinsic noise in the system.
SDE proposal specifically about the SDEs, I got the same question as Lucian, what else this package could expand to support in future, so we wisely choose the name to reflect it.
Best regards
Sheriff

> To view this discussion visit https://groups.google.com/d/msgid/sbml-discuss/02a51ba33be3ba8f844c74ace42117497244eef7.camel%40virginia.edu.

[Hoops, Stefan (sh9cq)]

Hello Sheriff,

Intrinsic Noise Specification is just an initial suggestion. My reason
for starting this discussion about the naming is more based on the for
me very unsatisfying restriction of the extension to SDEs. SBML is
about modeling and exchange of concepts. The concept we are addressing
with this extension is not to specify SDEs it is to specify intrinsic
noise.

I am aware of the distribution package and its concept the description
of a distribution of values in the core the description of PDFs.
Intrinsic noise at least as I see it is not described through PDFs and
thus would add a totally new concept to the distribution package. I
therefore prefer a separate packages where the distribution package
describes the extrinsic noise. The concepts of the packages are
complementary and there support through tools is independent which
makes adaption easier.

I object to the name SDE as it is not a modeling concept it is a family
of approaches to address intrinsic noise. Distinguishing between those
approaches is better dealt with in SED-ML.

Thanks,
Stefan

[T.J. Sego]

Hi Stefan,

Like Sheriff, I also like your idea of keeping things broad for the future. And like Sheriff, I am also not sure that a specification about intrinsic noise is the right direction.

The goal of the specification is not restricted to describing intrinsic noise. SDEs do not exclusively describe intrinsic noise (e.g., environmental noise). It also does not naturally follow (at least to me) that applying SDEs in biological modeling domains would be exclusively concerned with intrinsic noise. 

What’s unclear to me is the presumed disconnect between conceptual and mathematical specification. If we are concerned with describing the nature of noise in a model, what would we say about the noise that’s conceptual and not also mathematical? To me, there doesn’t seem to be much that would be sufficiently orthogonal, or that would not require mathematical descriptions as part of the specification, whether implicit or explicit.

For example, I agree that it’s possible to interpret SBML core in a Langevin sense and arrive at a SDE. Such an interpretation adds additional statements about the system (through the SED-ML in your example) that impose additional characteristics (e.g., about the nature of the system dynamics). I argue that, from a model specification standpoint, this is model specification by extension and thus inappropriate for SED-ML. I’m not claiming that you’re arguing for such a solution but instead using this example to elucidate some of what I find so difficult about the idea of a purely conceptual specification of noise. Assuming one could make such a specification, it’s difficult to envision how completing the specification through SED-ML to produce an executable simulation wouldn’t be an activity that, fundamentally, would be like your Langevin interpretation example that imposes additional conceptual statements about the model.

The rest on SDEs per se I’m happy to dive into more. But concerning the scope of the package, it’s unclear to me what it means to talk about noise and exclude math approaches from consideration. I appreciate the push to maintain generality, but I can’t help but think that we’re mimicking the approach of SBML core. SBML core imposes mathematical characteristics and features on a modeled system, as do other extensions. The same would be true of this extension.

Lastly, a quick clarifier. SDEs are not a family of approaches to address intrinsic noise. They have no formal concept of "intrinsic" or "extrinsic". Strictly speaking, they are differential equations with stochastic process terms with solutions that are also stochastic processes. Indeed, they can be used to describe intrinsic noise, but the distinction is an important one. 

T.J.

[Matthias König]

The motivation behind SBML packages is that many researchers use mathematical constructs to describe their models that go beyond pure ODEs (as represented in SBML Core). Examples include constraint-based models or Boolean models. Additional packages (such as fbc or qual) define how to represent this extra information—often mathematical in nature—so that these alternative modeling paradigms can be expressed, frequently in combination with SBML Core or other packages.

In my view, the motivation for creating a new package should always stem from a concrete use case or a specific class of models or formalisms. In this case, stochastic differential equations (SDEs) represent both the use case and the mathematical framework we aim to capture.

Keeping the package focused on SDEs ensures a clear and manageable scope, which helps promote consistent implementation and community support. When a package becomes too broad or generic, it becomes difficult to maintain focus and make meaningful progress—especially in our community, where everyone already balances standardization efforts with their regular research and work commitments.

For these reasons, I strongly recommend keeping the scope of the package limited to SDEs.

Best Matthias

[Hoops, Stefan (sh9cq)]

Hello T.J and Matthias,

I do not agree that the SBML was designed to faciltate the encoding of
mathematical constructs. The core definitely was not. From the
beginning we allowed for at least two different mathematical
interpretations.

Also fbc and qual do not prescribe to just one mathematical
interpretation. By calling this extension SDE we basically force it to
only describe SDE. I can imagine users being interested in steady-state
distribution of systems with intrinsic noise. The caclculation of this
steady-state calculation may or may not involve SDEs.

Furthermore the adaptation of the packages as currently proposed will
be very hard as applications in order to support this package will have
to implement Ito, Stratonivich, and all other through the appropriate
KISAO term identified SDE interpretations.

From the modelers standpoint what else but intrinsic noise (diffusion)
and kinetic law (drift) is there to specify. If we leave the kinetic
law as is and add the capability to specify the intrinsic noise we are
limited to specifying only Ito SDEs. 

I do not see this as a problem as Ido SDEs can be converted to
Stratonovichs SDE by modifying the drift term. The conversion works in
both ways, i.e., models currently using the Stratonovich interpretation
can be converted and represented with a far simpler package addressing
intrinsic noise.

Furthermore, Ito integration methods are far easier to come by. Even in
physics where the Stratonovich interpretation is common these SDEs are
converted to Ito to simplify the simulation.

I am convinced that a simpler approach will lead to higher adaption and
the simpler extension should not be called SDEs.

Thanks,
Stefan






On Wed, 2025-11-12 at 03:06 -0800, 'Matthias König' via sbml-discuss
wrote:

> > > > > On 11 Nov 2025, at 13:43, 'Hoops, Stefan (sh9cq)' via sbml-

[T.J. Sego]

Hi Stefan,

I think it’s important to note that SDEs according to our proposal would accommodate a wide variety of interpretations because the stochastic integral would be part of the model specification. Indeed, we are proposing to force the package to only describe SDEs, but I feel that this is an appropriate balance of abstraction and specificity. Additionally, to my knowledge, nothing about the specification would exclude analyses like steady-state analysis.

Concerning difficulty of supporting multiple stochastic integrals, I’m not particularly concerned about this issue at this point because 1) the same would be true if the intent were to specify such details in SED-ML; 2) we have not yet decided how support for different integrals would be handled (TBD after this stage); and 3) at least from a simulation software standpoint, many SDE simulators provide pre-packaged support for a variety of integrals and extensions to additional integrals and solver methods.

Concerning what else to specify beyond the kinetic law, a unique specification for a SDE requires 1) a drift term; 2) a diffusion term; and 3) a stochastic integral. The ability to convert SDE terms to accommodate different integrals makes these three details necessary to uniquely specify a SDE model according to our proposal. Importantly, specifying the stochastic integral is not a simulation detail that is appropriate for SED-ML. Rather, specifying the stochastic integral is a statement about the nature of the modeled system and hence part of the model specification. Additionally, to our knowledge, there is no universal conversion between any two given stochastic integrals. But on this topic, I’ll re-raise a point from my previous post that it is unclear to me what it would mean to develop a conceptual specification of noise (generally because, again, SDEs per se do not care about “intrinsic” vs. “extrinsic”).

T.J.

[Lucian Smith]

So, there are a few different proposals on the table, and it's probably useful to separate them:

1) Change the name.

This is by far the simplest change to accomplish, and the one that affects the least amount of things.  I'm swayed by Stefan's argument that people could calculate the steady state of these models that 'SDE' might not be the best, and I'm swayed by TJ's point that because not all of these models only describe intrinsic noise that 'intrinsic noise' also might not be the best.  I don't have a better idea, though.  'Continuous noise'?

Proposal:  accept this change, but defer to the package working group to determine the actual name after some more brainstorming.

2) Limit the allowed integration schemes to Ito alone, instead of Ito + Stratonovich.

This only makes sense to do *if* it can be shown that all integrals in one form can be converted to the other form (both ways!).  If there is a counterexample, I would say that it no longer makes sense to limit SBML to only encoding one.

If they can indeed be converted freely back and forth, then the question is: who do we put this burden on?  The modelers or the tool developers?  If we limit the package to only describing Ito, we burden the modelers with the task of converting their Stratonovich models to Ito models.  If instead we allow both Ito and Stratonovich in the package, we burden tool developers with the task of either converting Stratonovich models to Ito, or to implementing both forms natively, or refusing to simulate models of the other form.

Because the burden to tool developers is a one-time cost, while the burden to modelers is ongoing and unbounded, I think it makes the most sense to burden the developers instead of the modelers, and allow both forms in the spec.  However, we also should be able to lower the burden (for either way we decide) by providing routines in libsbml to convert one to the other.

Proposal:  allow both forms in the current spec, and work on implementing translators in libsbml.

3) Add more 'noise' information to the spec.

Right now, this is more of a general feeling that 'we could do this sort of thing' than it is a specific 'we should add X to the Y class' proposal.  However, it would be entirely appropriate for the package working group to think about and investigate this moving forward, so:

Proposal: investigate this in the package working group.

4) Planning for change: KiSAO vs. IntegralType

As written, the current draft implies that we start with defining 'Ito' and 'Stragonovich' in KiSAO, and later, if someone wants to support a new integral form, to just add that new form to KiSAO.  The benefit of this is that updating a spec takes forever, so this would be a way to do it quickly.  The counter to this is that tool developers will never know whether they support existing models until they encounter a KiSAO term they don't know.  Similarly, modelers must rely on word-of-mouth to know whether there would be any tool that supports the integral they want to use.  Traditionally (i.e. a vote to this effect in 2005) SBML has decided that everything needs to be in the spec, and that external ontologies shouldn't influence the mathematics of a model.  This seems reasonable to me; if people want to expand to use new integrals in the future, we should bite the bullet and come out with a new spec.

Proposal: change the 'integral' attribute from 'A KiSAO ID' to a defined-in-the-spec 'IntegralType', which starts off allowed to take two values, "ito" or "stratonovich"

However!  *All* of these proposals, I would argue, would be appropriate discussions for a post-approval package working group.  So I'm going to go ahead and call for votes.  If anyone disagrees with me and thinks these issues should be resolved pre-approval, vote 'insufficient information'!

-Lucian

To view this discussion visit https://groups.google.com/d/msgid/sbml-discuss/242a15c2deba0954e49bbd1176f2390bf0298730.camel%40virginia.edu.