#263 Trigger, Delay, and Priority: give them mathematical meaning?

Rejected-No_action
closed
nobody
5
2014-07-09
2014-05-16
No

Because the editors accepted the 'give everything an ID' issue by putting 'id' on SBase, we now have the situation where triggers, delays, and priorities have an ID, and have 'math' children. Should we give them mathematical meaning? Should we allow them to be set by assignments and rules?

You can effectively do this already for priorities and delays by making the 'math' a single 'ci' element that points to a parameter, and then using/setting that parameter as needed. But you can't do that for a Trigger, since a Trigger is a Boolean value, and Parameters can't be Booleans.

I think, on balance, I would vote against doing this (if I had a vote), but as I'm writing things up, it seems like an obvious gap, and I think we need to say why we're not doing it, if we don't.

Discussion

  • Nicolas Le Novère

    I agree with this solution and that it should be
    done

     
  • Michael Hucka

    Michael Hucka - 2014-06-04

    You're right that it's an inconsistency. However, (1) Trigger has 2 boolean fields, so it's not clear which one the 'id' would refer to, and (2) knowing the complaints we received over allowing SpeciesReference id's to be set, I can't imagine that tool developers will be happy if we add more things like that.

    So, I also vote not to add this capability.

     
  • Frank Bergmann

    Frank Bergmann - 2014-06-28

    I would prefer not to do it, for pretty much the same reasons that mike outlined above. Handling Events is already really complex in SBML, having those values now additionally set by other SBML elements would complicate the issue a lot. Even just returning the value is difficult, if there are multiple values to choose from.

    SO I would also vote not to do add this at this.

     
    • Chris Myers

      Chris Myers - 2014-06-28

      I agree with Frank. This are tricky because at least for delay and priority, they only have meaning at particular times, namely on trigger. Given this and no compelling use case, does not seem to be worth it.

      Chris

       
      Last edit: Lucian Smith 2014-07-07
  • Lucian Smith

    Lucian Smith - 2014-07-08

    Here is what I have in the current draft of the specification for InitialAssignment; the other elements with math children but no mathematical meaning have similar sections:

    "InitialAssignment inherits an optional 'id' attribute from SBase, of type SId. Despite having a math child, the 'id' of an InitialAssignment takes on no mathematical meaning, and the value of its math child may not be changed directly."

    We currently have two votes on the issue, so we need some more before closing it. Also, I wasn't sure whether Nicolas believed that we should or shouldn't give these things mathematical meaning or not, since I didn't phrase the original write-up unambiguously. So, when you vote, just make sure you say whether or not you think that the ID of all elements with a 'math' child should have mathematical meaning, or whether they should not have mathematical meaning. The latter is the current position of the the version in SVN.

     
  • Dagmar Waltemath

    I agree with the text that Lucian suggested, voting not to give these element a specific mathematical meaning.

     
  • Lucian Smith

    Lucian Smith - 2014-07-09
    • status: open --> closed
    • Group: Reported-Proposed --> Rejected-No_action
     
  • Lucian Smith

    Lucian Smith - 2014-07-09

    OK, with that vote, I'm going to say that the issue is closed/rejected, though new text in SVN does now explicitly state that many SBML constructs do not have mathematical meaning, despite having 'math' children. That language is in SVN, and will be incorporated into the upcoming L3v2 specification.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks