Forums

The topic of this vote is:
Disabling events

The URL for the voting page is:
http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Surveys/Event_semantics:_disabling_triggers

This is the third of three related surveys. It concerns the
following problem: there is no way to stop a delayed event
from executing once it has triggered. In the current SBML
L3 specification, once an event's trigger is fired its
associated assignments are always executed even if, during a
delay, the trigger condition transitions back from true to
false. The experiences of developers of software tools and
models is that the lack of a way to indicate a trigger
should be retested is an error of omission in the SBML event
semantics, and is problematic in at least two ways. First,
other modeling formalisms tend to support the ability to
selectively disable events; the lack of this functionality
makes SBML unable to support translation from common other
formalisms such as Petri nets, which is somewhat
embarrassing for a format that bills itself as a systems
biology markup language. Second, certain modeling scenarios
involve multiple events whose trigger conditions may all
evaluate to true at the same time, in which case, the models
would ideally select only one of the events to fire. This
in effect requires a way for an event to disable other
events, which is impossible to accomplish with the current
event semantics.

Proposed solution: add a boolean flag (tentatively named
"persistent") on the Trigger object. The semantics would be
as follows. If the value is true, the behavior of the Event
would be as in the current SBML L3 specification. If the
value is false, it means a delayed event should be prevented
from being executed after it is fired if the trigger
condition transitions from true to false before the delay
elapses. (This in turn requires that a software simulator
must test for the condition; however, software developers
who have already experimented with this feature report it is
an easy implementation change to make.) The name
"persistent" is meant to evoke the idea that the Trigger
persists in its on-state and does not have to be re-checked
after it fires if persistent="true".

Please help us by visiting the following page and filling
out the very brief form to state your opinion:

http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Surveys/Event_semantics:_disabling_triggers

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
counted.

Thanks!
The SBML Editors

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu