#247 Create MathId and MathChild intermediate classes.

Rejected-No_action
closed
nobody
5
2014-06-25
2013-04-04
No

The concept of 'an SBML element with mathematical meaning' has always existed, but in core, it usually is covered by explicitly listing the five elements this describes: Compartment, Parameter, Reaction, Species, and SpeciesReference. However, as packages are developed, this list is being expanded, and references to this list are also being created. For example, there are three elements of the 'qual' package with mathematical meaning: QualitativeSpecies, Input, and Output. On the 'reference' side of things, 'comp' allows an element 'with mathematical meaning' to replace a 'Parameter', as an exception to the 'like must replace like' rule (see p24 of the comp spec). 'Distrib' is in talks right now to extend these five core elements with descriptions of their error--it would be nice if it could simultaneously extend elements from other packages with mathematical meaning to describe their error, as well.

Along those lines, it has been proposed that some SIdRef element restrictions be loosened for packages, in some cases. The target of an InitialAssignment element, for example, could easily be 'an element with mathematical meaning' instead of the current list of five core elements. (If a package is not understood, it is no trouble to simply disregard an InitialAssignment that points to an element from that package--if you already don't understand the element, it is no worse to not set its initial assignment).

Ultimately, this ties into Nicolas's vision of SBML+, where there is a more unified core 'element with mathematical meaning' class and perhaps even list. But I think that a step in this direction could be taken even for L3v2, which would make life a lot more straightforward for packages that deal with mathematics.

At the most basic level, I would propose that we create a new class (called something like 'MathElement'), which inherits from SBase, and from which our five classes inherit. It doesn't even need to do anything; everything could be exactly the same as it was. However, the rest of the spec could then begin to refer to the MathElement class instead of listing the five other classes each time. This would allow packages to define classes that refer to MathElement and SIdRefs that must refer to MathElement objects, in a package-agnostic way.

We could then make MathElement slightly more useful by moving attributes to it: 'id' and 'name' are obvious candidates to start with. Slightly more controversial would be to include the 'constant' attribute and the 'units' attribute: not all of those five elements (nor the new ones in qual) currently have it. You could also standardize the interface for these elements by giving it a 'value' attribute. This would be a more significant change--it would replace the 'size' attribute on Compartment, the 'initialAmount'/'initialConcentration' attributes on Species, and would be a new thing for Reaction, for example.

Another option would be to create a ValuedMathElement that inherits from MathElement and adds 'constant', 'units', and 'value'. It would kind of depend on what exactly people wanted.

Overall, I think a MathElement class, with 'id' and 'name' could be quite useful, and probably non-controversial. The other changes could be argued for or against. And it would make writing the core spec simpler in reference to packages, and would make writing package specs simpler in reference to core and other packages as well.

Discussion

  • Lucian Smith

    Lucian Smith - 2013-04-04
    • labels: --> Level 3 Version 2
     
  • Sarah Keating

    Sarah Keating - 2013-09-04

    Just going on record with this one that the name 'MathElement' could be very confusing. At HARMONY this was being discussed and it became apparent that at least one of the participants in the discussion thought that 'MathElement' referred to elements that has a 'math' child.

    I agree that it is actually a very good thing to have and we should actually possibly go the whole way and have two new intermediate classes - one for elements that have a mathematical value and one for elements that contain a math child element.

    But I think we need to be very careful how we name these :-)

     
  • Chris Myers

    Chris Myers - 2013-09-14

    I agree that this should be done. Not sure the best name for it.

     
  • Frank Bergmann

    Frank Bergmann - 2013-09-14

    I'm accepting this issue as valid. I hate the name though ... it could ne that i was the unnamed one that sarah talked about.

    However there is no need, for this to change the whole SBML structure. We could just tag these elements in the specification with whatever name we come up with. In software implementations this could then take the form of interfaces that the individual classes implement.

     
  • Nicolas Le Novère

    I'm accepting this issue as valid.

     
  • Lucian Smith

    Lucian Smith - 2013-09-15

    Another option for the name: MathID (and, if we do another for something with a child 'math' element, MathChild).

     
  • Chris Myers

    Chris Myers - 2013-09-15

    I like MathId and MathChild.

     
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • labels: Level 3 Version 2 --> Level 3 Version 1 Core
     
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • summary: Create a MathElement intermediate class. --> Create a MathId and MathChild intermediate classes.
     
  • Lucian Smith

    Lucian Smith - 2013-09-16
    • summary: Create a MathId and MathChild intermediate classes. --> Create MathId and MathChild intermediate classes.
     
  • Nicolas Le Novère

    I agree with this solution and that it should be
    done

     
    • Chris Myers

      Chris Myers - 2014-05-29

      I vaguely remember that we ran into issues with this one, and we decided to drop it. But, I may be confusing this one with something else.

      Chris

       
      Last edit: Lucian Smith 2014-06-05
  • Michael Hucka

    Michael Hucka - 2014-06-04

    My recollection is that we decided (either over the editors' list or in person) against this.

     
    • Chris Myers

      Chris Myers - 2014-06-05

      My recollection was this was what we decided in Paris.

      Chris

       
      Last edit: Lucian Smith 2014-06-05
      • Michael Hucka

        Michael Hucka - 2014-06-05

        Um, when you say "this", what is "this"? A decision to do it, or a decision not to do it?

         
        • Chris Myers

          Chris Myers - 2014-06-05

          A decision not to do it.

          Chris

           
          Last edit: Lucian Smith 2014-06-05
  • Lucian Smith

    Lucian Smith - 2014-06-25

    Given that people remember not needing to do this, and given that I've just finished incorporating a bunch of other changes into the spec that address the issues this change was supposed to fix, I am going to mark this as 'closed'/'Rejected'. If anyone feels we should resurrect the idea, feel free to comment, or simply to change this back to 'open'.

     
  • Lucian Smith

    Lucian Smith - 2014-06-25
    • status: open --> closed
    • Group: Reported-Proposed --> Rejected-No_action
     

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

Sign up for the SourceForge newsletter:





No, thanks