SBML.org — the global portal for all things SBML

Level 3 Package Proposal Voting Results: groups

The call for votes for the 'groups' package was issued on June 28 and closed on July 13, 2012. A total of 19 votes were cast.

The outcome of this vote is accept.

This outcome is based on the final question of the survey, which had four mutually-exclusive choices: Accept (proposal addresses a need that SBML should cover, and the approach clearly follows the stated principles), Reject (proposal does not address a need that SBML should cover), Revise (approach either does not follow the stated principles, or there is insufficient information to tell if it does), or Abstain, (I cannot fully assess the proposal as given, or do not wish to state an opinion). The following graph presents the results for this question:


The voting for this package proposal used an updated format that requested additional information from voters. The responses for each of these additional questions are reported separately below. The comments written by respondents for the overall assessment question are provided at the end of this page.

Question about UTILITY

The question was posed as follows: Utility: the package addresses a problem whose solution SBML users are likely to find useful. It had four possible answer choices: (a) Agree, (b) Disagree, (c) Insufficient info, and (d) Abstain.

The following graph shows the overall total responses:


The following are the individual comments written by respondents. The votes in particular are indicated in parentheses before the comments.

  • (Voted 'Disagree') I'm not sure exactly what purpose Groups would serve. Previously, I have used speciesType to "group" together species in different compartments (such as the example here with ATP) in order to reduce duplication of annotations. (i.e. the speciesType would be annotated, not individual species). I subsequently dropped this practice, as it seemed that software packages don't necessarily support speciesTypes. Given that the benefits of using speciesTypes appeared minimal, this wasn't a great loss. Similarly, I wonder how much would be gained by introducing Groups, and if their introduction is justified given the trade-off against increased complexity.
  • (Voted 'Agree') I can already think of some cool things to group together!
  • (Voted 'Agree') I'd actually prefer if it would be possible to use the groups identifiers in math as well, for example one could use it as a mass assignment to all members of a group in initial assignments or event assignments.

Question about BIOLOGICAL ORIENTATION

The question was posed as follows: Biological orientation: the package's overall aim is to support the description of biological processes and phenomena. It had four possible answer choices: (a) Agree, (b) Disagree, (c) Insufficient info, and (d) Abstain.

The following graph shows the overall total responses:


The following are the individual comments written by respondents. The votes in particular are indicated in parentheses before the comments.

  • (Voted 'Insufficient info') Groups could be used for any kind of information. Whether the overall aim is to only describe the description of biological processes and phenomena is not apparent in the proposal. In fact I hope it is not, as Groups could be universally useful.
  • (Voted 'Agree') In a way, it does. However, the relation between elements in a group remains unclear.
  • (Voted 'Agree') If any of these principles was unclear in the proposed specification, it would be this one. It talks about compartmenttype and speciestype, but assumes the reader already knows why those things are desired. Today, the issues are clear, but as new people come to SBML, they may be confused.

Question about COHERENCE

The question was posed as follows: Coherence: the package extends SBML in a way that follows naturally from Level 3 Core and other packages. It had four possible answer choices: (a) Agree, (b) Disagree, (c) Insufficient info, and (d) Abstain.

The following graph shows the overall total responses:


There were no comments left with this question.

Question about ORTHOGONALITY

The question was posed as follows: Orthogonality: within reason, the package does not duplicate the purpose or data captured by other packages. It had four possible answer choices: (a) Agree, (b) Disagree, (c) Insufficient info, and (d) Abstain.

The following graph shows the overall total responses:


There were no comments left with this question.

Question about overall assessment

In addition to asking for an overall assessment (the response to which is the first result on this page), the survey also provided space for respondents to include comments with their overall assessment. The following are the explanations that people provided, together with the way they voted on the overall assessment question.

  • (Voted 'Revise') I hope 2 more features can be captured by the extension. First, logic relationship among the members, such as "and"/"or". For example, in a simple spatial model, 2 molecules may bind to each other and they are located in membranes of 2 different cells of same type (trans-binding). The two cells or membranes can be grouped with "and" logic as the compartment of the association reaction. In contract, use "or" to indicate "cis" binding and the binding may happen in either cell. Secondly, an optional attribute to indicate the "class" of the members may help group entities in more detailed manner, for example, all members are reactions, or compartments, etc.
  • (Voted 'Revise') Similar to my comments under "Utility", I would prefer to see more concrete use cases that illustrate the benefits of Groups (that cannot be provided by Core) before accepting this package.


Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 00:26, 16 July 2012.