SBML.org — the global portal for all things SBML

Level 3 Package Proposal Voting Results: layout and rendering

The call for votes for the 'layout' and 'render' package proposals was issued on May 29 and closed on June 13, 2011. A total of 25 votes were cast. There were no duplicates or unregistered voters. The following subsections report the outcomes of the votes for the two packages.

Layout Package Proposal

The outcome of this vote is accept because more than 50% of the votes cast were cast for 'accept'. The following graph presents the results:

The following are the comments made by people who voted. The votes in particular are indicated in parentheses before the comments.

  • (Voted 'revise') Would this be something that should be merged with the annot package? At the least the developers of both packages should probably discuss how to specify their meta-information in a congruent way?
  • (Voted 'revise') I think it would be better to combine this with the related SBGN-ML (libSBGN) proposal.
  • (Voted 'revise') 1) layout information should be linked with information relevant for used graphic notation 2) there are no glyphs/layout info for mathematical elements (events, equations, functions).
  • (Voted 'reject') It seems to me that rendering should be the job of specific programs (like solving is the job of solvers) rather than that of the language itself. Otherwise it might loose focus. In that case why not encode the specifics of simulations (choice of integrator etc.), which might also be useful.
  • (Voted 'reject') Speaking as a (former) software engineer, I'm not keen on the idea of combining Views with Models (in an MVC sense). I've had discussions with my boss [...] regarding this, as I think that he incorporates this in [...]). In my world-view, the model should hold the data and the means of presenting this should be elsewhere. This, to me, is akin to adding HTML markup to the SBML to suggest that, when presenting the model in a textual format, we'd like to see enzyme names italicized.
  • (Voted 'reject') Visual representations of models are a kind of annotation. They do not affect the way we understand the model, and graphs can be generated from the model itself. Specifying the way graphs must be displayed is akin to specify the fonts to use for equations. Furthermore, this is covered by SBGNML. I completely understand that one may want to encode graphs that are not SBGN-compliant, but this should be kept as an annotation.
  • (Voted 'reject') First, this package appears to run counter to the general concept of a model interchange standard. It has often been strongly asserted that we want to encode the MODEL, not what some users and software packages may want to DO with the model. Second, such a package appears to undercut the efforts of SBGN to standardize the graphical presentation of biomodels.

Rendering Package Proposal

The outcome of this vote is accept because more than 50% of the votes cast were cast for 'accept'. The following graph presents the results:

The following are the comments made by people who voted. The votes in particular are indicated in parentheses before the comments.

  • (Voted 'accept') While I can see the utility for SBML my only concern here is whether rendering is not, in future, better suited to something from the SBGN family? But as an SBML extension no problem.
  • (Voted 'revise') Would this be something that should be merged with the annot package? At the least the developers of both packages should probably discuss how to specify their meta-information in a congruent way?
  • (Voted 'revise') This is a revision request for documentation. A critical question for a new user is why editors chose to provide a parallel vector definition in many ways similar to SVG. I am aware of the reasoning but this needs to be explained in the documentation probably at the very beginning.
  • (Voted 'revise') I think it would be better to combine this with the related SBGN-ML (libSBGN) proposal.
  • (Voted 'reject') (1) This approach allows only to render ready diagrams. There is no possibility to edit such diagram - the extension does not specifies how new specie or reaction should look like. (2) It looks very strange that 2 standards SBML and SBGN do not interact one with other. I think it is essential to adopt SBGN to display SBML diagrams. BioUML provides extension of SBGN to display SBML elements: http://ie.biouml.org/bioumlweb/#de=databases/Biomodels/Diagrams/BIOMD0000000005
  • (Voted 'reject') Same as for layout. [Editors' note: referencing the comment above beginning with "It seems to me ...".]
  • (Voted 'reject') See above. [Editors' note: referencing the comment above beginning with "Speaking as a ...".]
  • (Voted 'reject') Visual representations of models are a kind of annotation. They do not affect the way we understand the model, and graphs can be generated from the model itself. Specifying the way graphs must be displayed is akin to specify the fonts to use for equations. Furthermore, this is covered by SBGNML. I completely understand that one may want to encode graphs that are not SBGN-compliant, but this should be kept as an annotation.
  • (Voted 'reject') If SBGN is a prominent example of such rendering, why are we not simply adopting SBGN tools to render SBML files? It seems odd for a standards organization (SBML) to make the work of another, closely related and closely allied, standards organization (SBGN) optional. If the 'render' package working group feels there are deficiencies in SBGN, shouldn't they join with SBGN to improve it rather than constructing a render package that allows users to store "arbitrary diagrams?
  • (Voted 'revise') I am concerned that the approach is too low-level: the spec has drawn heavily from SVG and I get the feeling many elements should have stayed in SVG. While I will defer to the authors as they have clearly put in a huge amount of thought into setting this up, my own inclination would have been to embed SVG for the geometric primitives in much the same way we do MathML for reaction equations.


Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 16:40, 17 June 2011.