SBML.org — the global portal for all things SBML

2013-05-19 During HARMONY

SBML Editors' meeting minutes

Editors present:
Editors absent:
Visitors present:
Location: University of Connecticut Health Center, CT, USA
Scribe:
Recording(s):


Links to previous meeting's notes

Topic group: issues in the current Core specification

Clarification of the meaning of 'supported' in relation to an SBML spec

It has recently come up that Chris interpreted the statements regarding support in a slightly different way than the way intended. We need to clarify the text, if nothing else.

Conclusion: the text of item 1c concerns making sure that a specification is implementable, to avoid features that are unproven or wishful thinking. With that in mind, the we want to elaborate the text to read as follows:

Every feature in the specification must be able to be created by at least one tool and interpreted by at least one tool. The tool may or may not be the same in the two cases.

Clarification of the meaning of the 'required' attribute

We recently argued about whether there is a contradiction in the specification regarding the use of the required attribute. Have we resolved this ?

Possible interpretations of the existing L3v1 spec:

  • A model that uses package elements to *change* the mathematical interpretation of one or more SBML core elements must be set 'true', and it must be set 'false' otherwise.
  • A model that uses package elements to change the mathematical interpretation of one or more non-package elements *or* to add a new mathematical interpretation to the model must be set 'true', and it must be set 'false' otherwise.

I believe consensus on the list was to go with the latter.

However, there has also been discussion whether this is actually what we want 'required' to mean, and if we should change it for L3v2. Here are some possibilities:

The above two:

  • A model that uses package elements to *change* the mathematical interpretation of one or more SBML core elements must be set 'true', and it must be set 'false' otherwise.
  • A model that uses package elements to change the mathematical interpretation of one or more non-package elements *or* to add a new mathematical interpretation to the model must be set 'true', and it must be set 'false' otherwise.

Others:

  • Package elements *can be used* to change or add mathematical meaning in a model if 'true', and *cannot be used* in this way if set 'false'. Whether it actually does so or not for *this* model is irrelevant, and left ambiguous.
  • Package elements can be used to change or add mathematical meaning in a model, and the modeler is pretty sure that this happened if 'true', and otherwise, 'false'.
  • Package elements might be used to change or add mathematical meaning in a model, but the modeler is pretty sure you could get away with ignoring them if 'false', otherwise, if elements *can* be used to change or add mathematical meaning, 'true', otherwise, 'false'.

Options I don't think should be on the table:

  • The modeler thought that the package information was 'really important'.
  • The modeler wants anyone who receives the model to implement support for the package.

Topic group: general issues with Level 3 packages

Are validation rules part of the spec ?

We recently debated this on the SBML Editors list but came to no clear conclusion. Possibilities include:

  • They are not.
  • They are, but conflicts are resolved in favor of the main text with only the Release needing to be updated, not the Version.
  • They are, and conflicts are resolved in favor of the validation rule, with only the Release needing to be updated, not the Version.
  • They are, and conflicts must be resolved by updating the Version.

It also come up in a meeting I (Sarah) attended that it was unclear whether the two implementation requirement included the implementation of the validation rules. Lucian--*effectively* the answer to this is 'no', since comp was accepted before either tool did any validation at all. Whether this is a good precedent to set is probably debatable.

Restricted use of third party standards

(Sarah:) My recent attempt to get the community to consider this provoked much discussion; although it was all MathML related. I had hoped to encompass the introduction of UncertML by distrib into the discussion. Some issues arose, not least of which was the fact that we are not connecting with people doing hands-on modelling (at least not via sbml-discuss). We need to decide what we do regarding this (the third party standards) issue and indeed the connecting to more people issue.

Topic group: specific Level 3 packages

Lucian's updates: http://sbml.org/Forums/index.php?t=tree&goto=8113&rid=0

Unmentioned packages: comp, fbc, annotations, dynamic structures, render, spatial.

The 'Required Elements' package

(from Lucian): If the Required Elements package is going to be useful to anyone (and the jury is still out on this, frankly), it will be to people who write software who have an SBML document with 'required' packages in it they don't understand, who want to do something with it anyway, but want to be able to warn the user about particular variables that will be affected. This will actually be useful to people if there are validation rules that describe the interaction of RE and the various required packages. What's the best place to store those validation rules? Should any package say that the RE package is required, or should they just describe what to do *if* the RE package is present?

The 'Distributions' package

The 'Groups' package

Topic group: new versions of L2 and L3

SBaseRef

Should SBaseRef move to core ?

Discussion on the groups PWG list considered that fact that it would be useful for the groups package to have access to this element. However, it is not sensible to require the whole comp package (where SBaseRef is currently defined) to facilitate this.

Another alternative would be to make 'metaid' a required attribute--anything that needed to reference anything could then be guaranteed of having something to reference.

https://sourceforge.net/p/sbml/sbml-specifications/248/

Define MathElement

If we want to allow packages to define their own mathematical SIds, we could require that some SIdRefs (such as those that appear in MathML) point to 'any element with mathematical meaning', or we could create a new 'MathElement' class that Parameter, Species, etc. inherit from, that packages could also define new elements that inherit from.

http://sourceforge.net/p/sbml/sbml-specifications/247/

L2V5

Next steps ?

A summary of where we got with this last year is here.

L3V2

Next steps ?

A summary of where we got to with this last year is here.

Conveying decisions/questions to the community

Last year, we had some proposals for L3v2 and others, but what with one thing and another, never ended up actually proposing these ideas to the community at large. What timeframe is reasonable to expect for this to happen, and how can we all help without simply adding it to Mike's massive to-do list?

Scientific Advisory Board

Updates? Actions needed?

Retrieved from "http://sbml.org/Events/SBML_Editors%27_Meetings/Minutes/2013-05-19_During_HARMONY"

This page was last modified 17:08, 6 September 2013.



Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 17:08, 6 September 2013.