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
