Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
> Just to kick off the comments with a bug: when I click on the open in
> PCEnv link all I get is a download dialog box to download the CellML
> file. I'm assuming that if I had PCEnv installed this would
> automatically open in PCEnv. However, for my case I don't already have
> PCEnv installed and I expected the standard behaviour of being
> prompted to install PCEnv...
Hi Andre,

Please see the meeting minutes about this. There are so many possible
combinations of browsers, platforms, and CellML programs we can't
possibly hope to support this. However, the consensus on how to deal
with this was that the repository should always open a window telling
the user how to get the model to open in the software they have selected
(including links to installation instructions).

> 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.

> 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.
>
> 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.

> 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.

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.
> 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.
>
> 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.

Best regards,
Andrew Miller

---

• [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.