Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

Just one note, when you redirect emails from a bunch of us to the
mailing list it is probably useful if you either preface your reply with
a summary of the conversation so far or include the original emails so
that people can get some context as to what is being discussed and who
initiated the discussion.

>> The graphing metadata simply states how to present combinations of
>> simulation results in some meaningful way, possibly annotated in some
>> way (experimental data, labels, etc.). The graphing metadata that I am
>> currently using includes things like line format (colour, dashes,
>> etc.) background colours, etc.
> Is this specification published anywhere? Would it be possible to get
> the draft at http://www.cellml.org/specifications/metadata/graphs
> updated to take into account the work that you have been doing. I have
> been wanting to do this for some time, but I have been waiting for your
> work, so that I am not creating another incompatible metadata specification.

I'm still working on this when I can and will try to update the
specification when I get a chance. A lot that I have done is simply
working out the bits I need to be able to make graphs suitable for
inclusion in a journal article. I think it will still need a bit of work
to turn it into a reasonable metadata specification...

>> Applications are free to process the graphing metadata and display the
>> empty graphs while awaiting simulation results. Any application
>> specific layout information for presenting multiple graphs would then
>> be external to the graphing metadata.
> I'm not sure what you mean by 'external'. Software which doesn't
> understand the PCEnv specific parts of the RDF directed graph (DG, to
> avoid conflict of terminology) will simply not see those arcs (because
> they don't query it). There is no problem with this data being in the
> DG, and we could easily have more than one type of application-specific
> metadata in the DG. The only time this will become a problem is if the
> same data can be described in two incompatible ways, because the
> application-specific metadata is not truly application specific.
> Application specific metadata will refer to standardised metadata where
> it can, and this standardised metadata will be common to all applications.

I was addressing Poul's original concern that application specific
metadata does not get intertwined with general, standardised CellML
Metadata. It also seems appropriate to me that if the kind of data you
want is splitter locations and currently selected graphs that this
should not be defined in the CellML Graphing Metadata specification -
hence it would need to be in a different namespace. I have no problem
with such information being in the same DG, I just don't want to see it
when I ask for all CellML graphing metadata.

>> Having said that, such layout information may be fairly simple extra
>> information that could be easily included in the graphing RDF in some
>> other namespace.
> I don't envisage there being a strong separation between 'graphing RDF'
> and other RDF, as they all can be aggregated to form one big DG. Do you
> mean a separate file, or a separate rdf:RDF top-level element? I would
> certainly find it more convenient to lump everything into one graph. We
> do require some logic, when writing out data, to decide which arcs
> belong in the 'session' RDF/XML output, and which belong in the model
> XML output, within an embedded rdf:RDF element.

Nope - I'm happy for one big DG containing everything. And as a starting
point, I'd suggest that all the arcs defined in the CellML metadata
specification go into the model XML output while everything else goes
into this "session" RDF/XML. I don't really like the idea of calling it
session data though unless you want to further separate out the actual
individual session metadata from other simulation/graphing/etc metadata.

>> Or equally easily we could just have some other RDF describing the
>> layout which references the graphs. With either of these approaches
>> you could say things like "draw this graph next to that graph" or
>> "draw this graph below that one", etc... I think this sort of approach
>> would be more generally useful than starting to use something like XUL
>> to specify the layout.
> I don't think anyone has suggested that we should be using XUL on a
> model-by-model basis. The problem with specifying the proximity of
> graphs is that any approach will likely start to assume something about
> the model used in the software, while different software packages will
> have a different model. It also doesn't completely address the question
> of how screen layout is set up, so I don't know if this metadata would
> even be particularly useful.

Again, this was in response to Peter's original email which did in fact
suggest using XUL on a model-by-model basis. Given your reply, however,
I am no longer sure what the issue is that we are trying to address.

> Poul's suggestion to treat the list of graphs as being ordered is
> probably a better way to approach this. Graphs can then be assigned to
> regions on the screen in-order, so that the most important graph will
> always be shown in all software packages, but with less significant
> graphs only being show in packages which can show more than one graph at
> a time.

But with this approach how do you say that you want this graph drawn
with that one? which is the question that I thought we were
addressing...namely that you want these graphs in one pane, these in
another and that one on its own...

>> PCEnv can then process this extra metadata and determine the
>> appropriate XUL to layout the graphs in the requested format. Other
>> applications that are not based on XUL would also be able to use the
>> layout information.
> I don't like the idea of changing the XUL based on RDF metadata, as it
> implies that you cannot create the metadata easily from within PCEnv. I
> think it is better just to record attributes such as splitter positions
> and graphs currently chosen for each pane.

I think that if it is this sort of information that you want to store,
then it is not going to be useful for any other application and you
should just stick it into some PCEnv specific session data for that
particular set-up. This information is what I would term session data.

What I was envisioning was more generally useful, application
independent, layout information. But from the sounds of it, this is no
longer what we are discussing.

>> For graphing metadata that only uses simulations for one model, I
>> think it makes little difference if the graphing (and graph layout)
>> metadata is contained within the CellML model file or not.
> That is not necessarily true, because the user can load more than one
> model, and switch between models, and this could make a significant
> difference as to how this case is handled.

in terms of PCEnv specific session data, not in terms of the graphing
metadata. And again, this was addressing Poul's original concern that
the model XML not be polluted with application specific data. I have no
preference where you store the PCEnv session data, as long as its not in
a namespace I'm processing then I won't see it while querying the DG.

One point to bear in mind, however, is that you probably can't rely on
all applications being kind enough to retain unknown metadata when
editing models....


Andre.

---

• [cellml-discussion] Session specs for PCEnv, Andrew Miller, 03/12/2007
  • [cellml-discussion] Session specs for PCEnv, David Nickerson, 03/12/2007

---

Archive powered by MHonArc 2.6.18.