Event survey #1 of 3: adding priorities to events
24 Jun '10 14:26
The topic of this vote is:
Adding priorities to SBML Events
The URL for the voting page is:
This is the first of three related surveys.
A long-standing problem in SBML Level 2, perpetuated in
Level 3, has concerned the semantics of SBML Events. The
slow pace of support for SBML Events in software
implementations has meant that the interoperability issues
only became apparent fairly recently. A consensus is
emerging among software developers that the current SBML
Level 3 Version 1 Core specification of the semantics of
events does not provide sufficient information for
developers to implement support for events in a consistent
and unambiguous way.
Chris Myers has lead an effort to identify how to improve
the definition of SBML Events to correct the definitions in
the current scheme and provide a sound foundation for SBML
Level 3. He presented the problems and proposed changes at
the 2010 SBML-BioModels.net Hackathon; a link to the
presentation slides is available in the May 3 agenda table
on the meeting page (http://shrinkster.com/1eau).
The SBML Level 3 Version 1 Core specification is currently
in final candidate state, while we await two software
implementations to demonstrate support for it. Discussions
at the last Hackathon lead to the decision to issue the
survey you are reading now. The purpose of this survey is
to establish, by community majority voting, whether the
stated problems are errors that should be corrected in the
SBML Level 3 Version 1 Core before it is ultimately
finalized. There are three separate surveys, each dealing
with a separate small change being proposed in SBML Events.
This is the first of the three surveys. It concerns the
following problem: the SBML specification fails to define
what should happen when two events are scheduled to fire
simultaneously. The current specification simply does not
provide a tie-breaking rule. The lack of this leads to the
possibility that different simulators will produce different
results for the same simulation.
The proposed solution has two parts. First, add an optional
sub-object for specifying a priority in the SBML Event
object. Second, redefine the semantics of events such that
(1) if two or more events would fire simultaneously, the one
with the highest priority goes first, or (2) if more than
one event has the same (i.e., numerically identical) highest
priority, choose one randomly from among them. The priority
would take the form of a new optional sub-object "Priority"
that would resemble the current Delay sub-object in Event,
and contain a single MathML expression. This expression
would only be evaluated when an event fires simultaneously
with another event.
Please help us by visiting the following page and filling
out the very brief form to state your opinion:
Your opinion is valuable even if you don't currently use
SBML Events, because it will help reach a consensus that has
implications for the Level 3 Core specification.
The deadline for submission of answers is midnight July 9.
IMPORTANT: the SBML Development Process mandates that only
the votes of subscribers to the sbml-discuss mailing list
are counted (http://shrinkster.com/1eat). If you do not
have a subscription to the actual list (e.g., if you read it
using the web interface) but you want to vote, please
register for the actual mailing list. During the vote
counting, only votes from registered list members will be
The SBML Editors
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,
Powered by FUDforum. (Copyright Advanced Internet Designs Inc.)