Hi Andrew, I think I agree with what you are saying, and the sort of things I'm thinking about adding would all be optional and useful for people developing applications which generate static images. Not sure if it would all be relevant/useful for interactive environments such as PCEnv, so we can work out what can/should go in and what shouldn't once I get a better idea of what is needed.
I'm still working on exactly what is needed in addition to the existing specification, but the kind of things I'm thinking about are: - trace labels (for use in a legend/labelling traces) - axes labels - specifying an interval over which the graph is drawn (i.e., possibly not the complete range of a simulation) - a line type to control which lines in a line graph are drawn with the same/different line styles - a background colour for the graph I'll keep working on what I need to generate a figure suitable for use in a journal article and then send through some proposed modifications for the graphing specification. Another thing to consider, which probably is outside the scope of the graphing specification, is the addition of external data to a graph...but I think that is something we can think about later... David. Andrew Miller wrote: > David Nickerson wrote: >> Hi all, >> >> Currently the graphing metadata specification provides the basis for >> drawing two-dimensional line or scatter plots of data defined through >> simulations performed using CellML models. To distinguish multiple >> traces on a graph, each trace can be assigned a colour and for scatter >> plots a glyph. >> >> In terms of a graphical user interface the current specification >> probably provides enough information for useful plots to be drawn and >> other clues/hints can be given in the interface to aid the user in >> understanding the graph. >> >> In terms of model publication, I think the current specification lacks >> some information that is required for the complete specification of a >> graph suitable, for example, for use in a journal article describing the >> model. > What sort of information are you thinking of? Scaling information is one > obvious omission (the only thing is, if we specify it, we do constrain > the way that UIs based on the specification will work to some extent, > because there will be more than one way to express scaling information). > Information on axes might also be useful, although not all programs > would want to use this information (so we should make it clear what > parts are mandatory for processing software that claims to read in graph > metadata, and which parts are optional). >> Also for model curation purposes it might be useful to have some >> more information about the graph. >> > I think that does belong in a different specification, because it > doesn't describe how to render the graph, but rather, it interprets the > graph, which is quite a different thing. Of course, if you mean simply a > way to specify graph titles and labels on axes, it could be a different > issue. >> So with the view of using metadata to sufficiently describe a graph that >> could be used in a journal article, I am after opinions on whether the >> current graph metadata specification should be further developed to >> include more optional information or whether something like this belongs >> in a separate specification that builds on top of the current graphing >> metadata specification? The former would seem more preferable to me. >> > My answer: it depends. Since the graph metadata is still in the draft > stage, there is no reason we can't edit it further, and add in > additional things. That said, it is nice for application developers to > be able to claim compliance with a particular specification, which means > that we shouldn't put too much material into the specifications which is > not relevant to all people likely to implement it. > > Therefore, the criteria to consider are: > a) How well does the new metadata fit into the conceptual purpose of the > existing specification? > b) How much overlap is there between implementations which would want to > use the metadata in the existing specification, and implementations > which would want to use the new metadata? > c) How much of an additional burden does the new metadata impose on > implementors of the specification? > d) If the new metadata isn't put into the existing specification, would > this harm the conceptual elegance of the new specification? > > For scaling information, I would say: > a) very well, as it is rendering information. > b) probably a good overlap, I would certainly use it if the > representation was reasonable. > c) if it is optional, no burden. Supporting it wouldn't be too hard, > as graphing needs to deal with scaling internally anyway. > d) not really, because graph traces are RDF resources, and RDF is well > adapted for this. > > For metadata describing what a graph tells us about biology, or similar: > a) it doesn't really fit, aside from the common fact that both refer > to graphs. > b) maybe some overlap, but in different parts of the implementations > (it probably wouldn't be displayed alongside graphs). > c) if it is optional, none, otherwise a significant burden. > d) no > > Best regards, > Andrew > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
