Forums

Hello All,

I have some trouble with this proposal/vote. The term 'goes first' is
ambiguous. An event has 3 distinct phase:

1) Firing: Trigger changes from false to true.
If useValueFromTriggerTime is true calculate the assignment values

2) Optional delay

3) Execution:
If useValueFromTriggerTime is false calculate the assignment values
Assign calculated values to targets.

The priority can effect different phases. The final result will depend
on it. For a single priority object to resolve simultaneity I think we
need to place its effect on the execution phase as simultaneity may be
not a result of firing by itself but a combination of firing and delay.

Additionally, since the priority object is optional we need to specify
the behavior for 3 different situations:

1) All simultaneously executed events have the priority object
2) None of the simultaneously executed events has the priority object
3) Some simultaneously executed events have the priority object and
some not.

Another point, which is open, is what has to be done with cascading
events, i.e., an event with a higher priority triggers further events
without delay. Are these cascading events processed before the
remaining events or are they added to the priority queue.

Before these points are resolved and specified I think voting on this is
premature.

Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.edu
____________________________________________________________
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

Oops. Hit send prematurely.

It is the execution phase where it is evaluated. Also, newly created
events are the same as pending events. They must have a higher
priority than any other events pending to fire at this time point to
fire.

The last point you mention about what to do if no priority expression
is given is more subtle. At the hackathon, we agreed that
simultaneously enabled events should be fired in a random order. How
we achieve this when all events don't have priorities can safely be
arbitrary. Obviously if all have priorities we are also okay. The
problem is when there is a mixture. One solution would be to assign
some sort of default priortity like a uniform random variable.
Another solution is to fall back on the old spec which say their
firing order is undefined. This solution is the cleanest perhaps as
there is no need for a default and tools that don't support priority
expressions can fall back on the old spec. If you want to define
behavior for your simultaneous events, you must add priority
expressions to all your events.

One other approach is to say all events with no priority have equal
priority which is either expressly larger or smaller than those with
priority. By the way, this is not all that different than giving all
events the same constant priority as this should result in a random
choice.

Anyway, I think if we go with the timing of events without priorities
is arbitrary, i don't see why we cannot vote. The vote at this point
is whether this is a good thing to add.

Chris

Sent from my iPod

On Jun 24, 2010, at 5:10 PM, shoops <shoops@vbi.vt.edu> wrote:

> Hello All,
>
> I have some trouble with this proposal/vote. The term 'goes first' is
> ambiguous. An event has 3 distinct phase:
>
> 1) Firing: Trigger changes from false to true.
> If useValueFromTriggerTime is true calculate the assignment values
>
> 2) Optional delay
>
> 3) Execution:
> If useValueFromTriggerTime is false calculate the assignment values
> Assign calculated values to targets.
>
> The priority can effect different phases. The final result will depend
> on it. For a single priority object to resolve simultaneity I think we
> need to place its effect on the execution phase as simultaneity may be
> not a result of firing by itself but a combination of firing and
> delay.
>
> Additionally, since the priority object is optional we need to specify
> the behavior for 3 different situations:
>
> 1) All simultaneously executed events have the priority object
> 2) None of the simultaneously executed events has the priority object
> 3) Some simultaneously executed events have the priority object and
> some not.
>
> Another point, which is open, is what has to be done with cascading
> events, i.e., an event with a higher priority triggers further events
> without delay. Are these cascading events processed before the
> remaining events or are they added to the priority queue.
>
> Before these points are resolved and specified I think voting on
> this is
> premature.
>
> Thanks,
> Stefan
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax: (540) 231-2606
> Email: shoops@vbi.vt.edu
> ____________________________________________________________
> 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
____________________________________________________________
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

* shoops <shoops@vbi.vt.edu> [2010-06-25 03:03] writes:
> Hello Chris,
>
> On Thu, 24 Jun 2010 18:02:03 -0600
> "Chris J. Myers" <myers@ece.utah.edu> wrote:
>
> > It is the execution phase where it is evaluated. Also, newly
> > created events are the same as pending events. They must have a
> > higher priority than any other events pending to fire at this time
> > point to fire.
> >
>
> This is what I assumed but that must be stated clearly.

This is indeed the intention, and should it be voted in, the specification
will indeed need to say this.


> > Another solution is to fall back on the old spec which say
> > their firing order is undefined. This solution is the cleanest
> > perhaps as there is no need for a default and tools that don't
> > support priority expressions can fall back on the old spec. If you
> > want to define behavior for your simultaneous events, you must add
> > priority expressions to all your events.
>
> This is where I was headed :)

This is certainly what I was thinking, too. No priority = undefined, and
you can have it execute in whatever order you want--random, alphabetical,
order in the file, whatever. You could mix them in with events with
priorities, or not, as you saw fit.

> I actually think that we
> have done it more or less as it seems we can agree on the following:
>
> 1) All simultaneously executed events have the priority object
> As specified in the proposal/vote
>
> 2) None of the simultaneously executed events has the priority object
> Not defined as in L2V4 and L3 currently
>
> 3) Some simultaneously executed events have the priority object and
> some not.
> Not defined as in L2V4 and L3 currently

Yes, except that in #3, those events with priorities must execute in
priority order. It's only the events without priorities that may execute
in any order.

> It is entirely possible that even for the case of 'not defined'
> simulataneous execution will lead to a welldefined solution. This is
> the case if simulataneous events do not have conflicting assignments.
> In that case all assignments could be executed as one block. If we want
> this behavior we should add it to the specs.

This, however, I slightly disagree with, since even non-conflicting
assignments could in turn cause other events to fire that would not
trigger if they were all executed before any triggers were again checked.
I believe that the current spec should be interpreted as declaring that
simultaneous events execute sequentially in an undefined order, with
checks for event triggers between each event's execution, and not 'all at
once' in an undefined order, with only a single event trigger check at the
end of all executions.

This, however, is an interpretation of the current spec, and should not
affect this new proposal.

-Lucian
____________________________________________________________
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

* shoops <shoops@vbi.vt.edu> [2010-06-25 14:14] writes:
> Hello Lucian,
>
> On Fri, 25 Jun 2010 07:06:24 +0100
> Lucian Smith <lpsmith@spod-central.org> wrote:
>
> > > 3) Some simultaneously executed events have the priority object and
> > > some not.
> > > Not defined as in L2V4 and L3 currently
> >
> > Yes, except that in #3, those events with priorities must execute in
> > priority order. It's only the events without priorities that may
> > execute in any order.
>
> This is not possible. You have a set of elements of which some can be
> ordered and some not. This leads to the situation that the set cannot
> be ordered, i.e., the behavior is undefined. Every other
> interpretation would have to introduce some defaults which are
> strictly prohibited. Note that executing the events in a random order
> or partially random order as yu usggest is different than the order
> being undefined. People can easily avoid this situation by specifying
> the priority attribute for all events.

I think you're misunderstanding me. If you have six events, three with
priorities and three without:

10 7 2 X X X

The X's can be inserted anywhere, *but* the 10 must fire before the 7
which must fire before the 2.

X X X 10 7 2
X 10 X X 7 2
10 X 7 X 2 X
10 7 2 X X X

but not:

7 2 X 10 X X

There are no defaults, and the overall behavior is undefined... but the
priority-flagged events still fire in a defined order with respect to each
other.

-Lucian
____________________________________________________________
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

* Stefan Hoops <shoops@vbi.vt.edu> [2010-06-25 17:24] writes:
> Hello Lucian,
>
> On Fri, 25 Jun 2010 16:36:39 +0100
> Lucian Smith <lpsmith@spod-central.org> wrote:
>
> > * shoops <shoops@vbi.vt.edu> [2010-06-25 14:14] writes:
> > > Hello Lucian,
> > >
> > > On Fri, 25 Jun 2010 07:06:24 +0100
> > > Lucian Smith <lpsmith@spod-central.org> wrote:
> > >
> > > > > 3) Some simultaneously executed events have the priority object
> > > > > and some not.
> > > > > Not defined as in L2V4 and L3 currently
> > > >
> > > > Yes, except that in #3, those events with priorities must execute
> > > > in priority order. It's only the events without priorities that
> > > > may execute in any order.
> > >
> > > This is not possible. You have a set of elements of which some can
> > > be ordered and some not. This leads to the situation that the set
> > > cannot be ordered, i.e., the behavior is undefined. Every other
> > > interpretation would have to introduce some defaults which are
> > > strictly prohibited. Note that executing the events in a random
> > > order or partially random order as yu usggest is different than the
> > > order being undefined. People can easily avoid this situation by
> > > specifying the priority attribute for all events.
> >
> > I think you're misunderstanding me. If you have six events, three
> > with priorities and three without:
> >
> > 10 7 2 X X X
> >
> > The X's can be inserted anywhere, *but* the 10 must fire before the 7
> > which must fire before the 2.
> >
> > X X X 10 7 2
> > X 10 X X 7 2
> > 10 X 7 X 2 X
> > 10 7 2 X X X
> >
> > but not:
> >
> > 7 2 X 10 X X
> >
> > There are no defaults, and the overall behavior is undefined... but
> > the priority-flagged events still fire in a defined order with
> > respect to each other.
>
> No you are misunderstanding me! I was afraid that the above was your
> intend. What you propose is that we change the undefined behavior to
> random insertions into a sorted set. I fact you are saying that the
> default for the optional object priority is a random number if and only
> if it happens simultaneously with events that have a priority object.
> You however do not specify from which distribution the random number
> shall be drawn. We should avoid all this mess and simply leave this as
> undefined. If people want the above they need to define the proper
> priorities for all events. This proper definition could include a
> distribution package as suggested by Darren if you want a random order.
>
> Please avoid shortcuts and overloaded semantics at all costs. We made
> such an effort to become very clear and specific in L3. We should not
> haste the introduction of new features. This does not mean that I am
> against the priority object in fact I am very much in favor of it.
> However I can not stress enough that we should make its semantics as
> simple as possible.

I think we're saying the same thing? The firing of the X's in indeed
undefined. Because they are undefined (but *some* order must be chosen)
any of my four examples are possibilities. In fact, there are 20
possibilities, and all of them are legal (120, if you include the possible
permutations of the X's). The simulator may choose any method it wants to
choose between them--the specification leaves it undefined.

My point was that just because you insert an undefined-priority event into
the list, you can't decide to fire the 7 before the 10. The 10 must always
fire before the 7. That's all I was saying.

-Lucian
____________________________________________________________
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

* Stefan Hoops <shoops@vbi.vt.edu> [2010-06-25 18:20] writes:
> Hello Lucian,
>
> On Fri, 25 Jun 2010 17:50:34 +0100
> Lucian Smith <lpsmith@spod-central.org> wrote:
>
> > I think we're saying the same thing? The firing of the X's in indeed
> > undefined. Because they are undefined (but *some* order must be
> > chosen) any of my four examples are possibilities. In fact, there
> > are 20 possibilities, and all of them are legal (120, if you include
> > the possible permutations of the X's). The simulator may choose any
> > method it wants to choose between them--the specification leaves it
> > undefined.
>
> No we are not saying the same thing. It is not possible to mix
> undefined and ordered.

OK, I guess I disagree then. But I don't know what you are saying, in
that case. I think it is perfectly possible to mix undefined and ordered,
as long as the ordered end up in order.

> Undefined behavior as in L2V4 and L3 is not the
> same as a random order.

True.

> It may be the same order every time you simulate

True.

> or it may change from simulation to simulation,

True.

> it may even lead to stopping the simulation.

I don't think this is an acceptable reading of the specification, so this
bit I disagree with. I think that the *order* is undefined, not the fact
that the events are supposed to fire. The spec says:

"It is assumed that, although the precise time at which these events are
executed is not resolved beyond the given point in simulated time,
the order in which the events occur is resolved."

It does *not* say 'or you can stop the simulation'. All the events must
fire, in an order that is up to you.


> Again, we should avoid defining a resolution of a situation which
> should be avoided to begin with.

I actually completely disagree with this philosophy. We should either
define what happens (even if only to say 'it is up to you, and a modeller
cannot rely on any one thing happening', as we do now with simultaneous
events), or we should declare that it is actually illegal.

*Are* you suggesting that we make it illegal? That would, I argue, be a
significant change from the current specification. If you are not
suggesting that, but you are claiming that a particular simulator *may
not* decide to mix in undefined-priority events with defined-priority
events, I don't see on what basis you are making this claim. If you are
not making either claim, then I think you actually are agreeing with what
I am trying to say, though I'll grant that you may be disagreeing with
what I unintentionally communicated.

> If someone decides that the order of
> simultaneous events is important for the correct simulation of a model
> than they need to define the priority of all events which may occur
> simultaneously. If that is not done the outcome is undefined.

Yes, with the caveat that I believe it is only the order of the events
firing that is undefined, and not that the behavior of the simulator is
left completely undefined. In other words, if there is a simulation with
N simultaneously-firing events in it, I believe that there are N! possible
execution pathways available to the simulator, some or all of which may
'collapse' into equivalent final states. But options like not executing
any of the events, or stopping the simulator, or executing all event
assignments twice, are all illegal.

Here, I'll work through a possible execution pathway of a simulator.
Let's say that this simulator normally executes simultaneous events in the
order it finds them in the file. This is perfectly legal behavior. There
are six such events that it has on its list:

A, B, C, D, E, F.

Now, it looks at the priorities. It discovers that because A, D, and F
interact with each other, the modeler has given them explicit priorities.
Events B, C, and E all do not interact at all with each other or with any
other event in the model, so the priorities were left off of those.

Now, it turns out that the priority order of A, D, and F is that D has the
highest priority, then A, then F. The simulator must now permute its
chosen order such that D executes before A, which executes before F.
There are two possible legal event orders it could do without changing the
overall order of events very much:

B, C, D, A, E, F
or
B, C, D, E, A, F

Now, this order is 'mixing in' undefined-priority events with
defined-priority events, but its only decisions were made in order to put
D-A-F in that order. The rest was a side-effect of the 'undefined order'
aspect of the spec.

A different possibility would be that the algorithm it uses first pulls
out all events with priorities and only executes them after everything
else has fired. In this case, it ends up firing them:

B, C, E, D, A, F

Or maybe it pulls them out and executes them first:

D, A, F, B, C, E.


I would argue that these are all perfectly legal. I would also argue that
it fulfils your requirements that there are no defaults, and that it
doesn't rely on random behavior vs. undefined behavior, and that it could
execute these events in the same order every time it encountered them
(should it so choose).

I would also argue that becuse B, C, and E all do not interact with the
rest of the model in terms of events firing, there is no need to make this
model illegal, or to stop the simulation. (However, I am not arguing that
the simulator or SBML interpreter actually check to make sure they don't
interact that way--they should just trust the modeler.)


Once again, I've probably written too much, but I do agree that it's an
important distinction to make.

-Lucian
____________________________________________________________
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

I am okay with stefan's modifications to the proposal. It is simple
to warn the user when events are firing simultaneously without
priorities. If one wants truely random without a nondeterminism
package just give all an equal priority.

Chris

Sent from my iPod

On Jun 25, 2010, at 10:12 AM, Stefan Hoops <shoops@vbi.vt.edu> wrote:

> Hello Lucian,
>
> On Fri, 25 Jun 2010 16:36:39 +0100
> Lucian Smith <lpsmith@spod-central.org> wrote:
>
>> * shoops <shoops@vbi.vt.edu> [2010-06-25 14:14] writes:
>>> Hello Lucian,
>>>
>>> On Fri, 25 Jun 2010 07:06:24 +0100
>>> Lucian Smith <lpsmith@spod-central.org> wrote:
>>>
>>>>> 3) Some simultaneously executed events have the priority object
>>>>> and some not.
>>>>> Not defined as in L2V4 and L3 currently
>>>>
>>>> Yes, except that in #3, those events with priorities must execute
>>>> in priority order. It's only the events without priorities that
>>>> may execute in any order.
>>>
>>> This is not possible. You have a set of elements of which some can
>>> be ordered and some not. This leads to the situation that the set
>>> cannot be ordered, i.e., the behavior is undefined. Every other
>>> interpretation would have to introduce some defaults which are
>>> strictly prohibited. Note that executing the events in a random
>>> order or partially random order as yu usggest is different than the
>>> order being undefined. People can easily avoid this situation by
>>> specifying the priority attribute for all events.
>>
>> I think you're misunderstanding me. If you have six events, three
>> with priorities and three without:
>>
>> 10 7 2 X X X
>>
>> The X's can be inserted anywhere, *but* the 10 must fire before the 7
>> which must fire before the 2.
>>
>> X X X 10 7 2
>> X 10 X X 7 2
>> 10 X 7 X 2 X
>> 10 7 2 X X X
>>
>> but not:
>>
>> 7 2 X 10 X X
>>
>> There are no defaults, and the overall behavior is undefined... but
>> the priority-flagged events still fire in a defined order with
>> respect to each other.
>
> No you are misunderstanding me! I was afraid that the above was your
> intend. What you propose is that we change the undefined behavior to
> random insertions into a sorted set. I fact you are saying that the
> default for the optional object priority is a random number if and
> only
> if it happens simultaneously with events that have a priority object.
> You however do not specify from which distribution the random number
> shall be drawn. We should avoid all this mess and simply leave this as
> undefined. If people want the above they need to define the proper
> priorities for all events. This proper definition could include a
> distribution package as suggested by Darren if you want a random
> order.
>
> Please avoid shortcuts and overloaded semantics at all costs. We made
> such an effort to become very clear and specific in L3. We should not
> haste the introduction of new features. This does not mean that I am
> against the priority object in fact I am very much in favor of it.
> However I can not stress enough that we should make its semantics as
> simple as possible.
>
> Thanks,
> Stefan
>
>
>>
>> -Lucian
>> ____________________________________________________________
>> 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
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax: (540) 231-2606
> Email: shoops@vbi.vt.edu
> ____________________________________________________________
> 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
____________________________________________________________
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

On 25/06/10 18:09, Stefan Hoops wrote:

> No we are not saying the same thing. It is not possible to mix
> undefined and ordered.

I agree with Stefan. The situation is very similar to the unit one. If
priorities are used, they must be used on all events. If a single event
misses a priority, then all the other priorities are ignored. The
priorities do no matter at all. People are free to do whatever they want
with the events.

I do not see any advantage at all in mixed situations. And actually, I
cannot imagine how such a model would be generated since SBML is supposed
to be written by a software. Either this software generates priorities, for
all events, or not.

--
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere


____________________________________________________________
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

On 25/06/10 22:56, Lucian Smith wrote:
> * Nicolas Le novère<lenov@ebi.ac.uk> [2010-06-25 22:27] writes:
>> On 25/06/10 18:09, Stefan Hoops wrote:

>> I agree with Stefan. The situation is very similar to the unit one. If
>> priorities are used, they must be used on all events. If a single event
>> misses a priority, then all the other priorities are ignored. The
>> priorities do no matter at all. People are free to do whatever they want
>> with the events.
>
> I don't think this is quite what Stefan was saying (though maybe it was!)
> but I disagree. You put priorities on the events that might clash. You
> leave the rest alone. I don't understand why this is even controversial.

Yes, this is what Stefan was saying. And the discussion clearly show that
this is controversial.

>> I do not see any advantage at all in mixed situations. And actually, I
>> cannot imagine how such a model would be generated since SBML is supposed
>> to be written by a software. Either this software generates priorities, for
>> all events, or not.
>
> Priorities are added, as I see it, by hand. I cannot envision any
> algorithm that generates priorities automatically for all events, unless
> it is to give them all the same priority in order to ensure randomness.

I am not talking about algorithm. I am talking about tools. You add the
priority by hand IN YOUR TOOL. Then your tool writes the SBML.

> But whenever two priorities differ and were not randomly generated, the
> reason it was so is due to a specific decision on the part of the modeler.
> A decision that need not be made for all events, just the ones whose
> EventAssignments might clash in some fashion.

But all eventAssignment can potentially clash, except the one that are
triggered and fired at explicit times. Actually finding events that cannot
clash in a complex model would be an interesting research project.

--
Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust
Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521
Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT email)
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere


____________________________________________________________
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

The topic of this vote was:
Adding priorities to SBML Events

Thank you all for your participation in the SBML electronic
vote on this issue. The voting on this topic is closed.
For reference, the call for votes can be found at this URL:

http://sbml.org/Forums/index.php?t=tree&goto=6249&rid=2

The total number of votes cast was 12; all votes were
unique. There was one question: "Should the definition of
the Event object in SBML Level 3 Version 1 Core be modified
to add a sub-object for a priority, as described above?"
The results are as follows:

Number of votes for "yes": 10
Number of votes for "no": 1
No opinion: 1

The results show that a majority of voters prefer to change
the definition of Event to add a sub-object for a priority.

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

[Updated on: 12 Jul '10 12:01] by Moderator