CellML Discussion List

Text archives Help


[cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available
  • Date: Mon, 02 Oct 2006 17:30:58 +1300

David Nickerson wrote:
>> I'm not sure we would name them so the URL needed a query portion,
>> because that would mean that browsers would save the model wrong. A
>> hierarchy (perhaps a subset of an existing ontology restricted so it
>> becomes a tree) could be used to locate the model from the path rather
>> than query, e.g.
>> /models/channels/sodium/ventricular/human/tenTusscher.xml might be
>>
>
> so you are suggesting that we move away from a flat directory structure
> or is your example above addressing an ontology which would actually
> resolve to a URL like
> http://www.cellml.org/models/2004_ten_tusscher_noble_noble_panfilov_version02_part07.xml?
>

I think that having only one URL for each model is a good idea, because
that makes it much easier to define metadata about a model outside of
the model (otherwise, there are two equivalent URLs, but software
doesn't know they are equivalent unless it does some extra work to do
this), so if our URLs are not informative enough, perhaps URLs with
ontological information in them should be used for library components.

The current naming system works well for flat models (all models are
currently flat, because we don't support CellML 1.1 in the repository),
and so I think that it should be preserved for top-level, non-reusable
models (these would presumably correspond to your experiment CellML
files). Keeping top-level models with the current naming system also
ensures that we don't rename any existing models.

Library models have never really been addressed by the naming
specification, and I think that some sort of hierarchical naming system
like my example above (but probably with year information as well as the
author on the final component of the path) would be a good approach. The
only difficulty is deciding which ontological terms to include in the
names, as this likely varies depending on the highest level terms.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page