Chronological Thread 

< Chronological >      < Thread >

---

I agree that we need to only ever have a single URL for a given model
and you have pretty much convinced me that we don't want to start
including query type URL's in a import's href. However, I think that it
is always going to be too hard to define "nice" URL's based on any
ontology that I can think of.

Depending on how model authors write their components, submodels, etc.
you can easily end up with reusable components that could belong to any
of two or more categories of the ontology and thus someone would have to
decide where such a model belongs (pretty random) - or end up with the
model in more than one location (a bad thing).

I think the current model naming convention will work for 1.1 models,
you just won't end up with useful URL's and will generally require a
more intelligent query based interface to a model repository to find the
particular component that you want to use. The advantage of the current
model naming convention is that you can use standard file system tools
to locate all the models related to a particular publication and all the
parts that go with a particular version and/or variant of that model.

So I think that while the ontology based view of the model repository
you describe would be a useful view of the model repository, it would be
more a generated view rather than the static URL's that get used in
model imports. Then model authoring tools would provide such views of
the model repository to allow authors to select the desired components
for import into the current model, but the actual import would always
use the static URL as the href attribute value in the import element.

Does that make sense?


Andre.


> 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
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg

---

• [cellml-discussion] [team-cellml] Linux functional test build of PCEnv available, Andrew Miller, 10/02/2006
  • [cellml-discussion] [team-cellml] Linux functional test buildof PCEnv available, David Nickerson, 10/02/2006
    • [cellml-discussion] [team-cellml] Linux functional test buildof PCEnv available, Andrew Miller, 10/02/2006
      • [cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available, David Nickerson, 10/02/2006
        • [cellml-discussion] [team-cellml] Linux functional test buildofPCEnv available, Andrew Miller, 10/02/2006
          • [cellml-discussion] [team-cellml] Linux functional testbuildofPCEnv available, David Nickerson, 10/04/2006
            • [cellml-discussion] [team-cellml] Linux functional testbuildofPCEnv available, Andrew Miller, 10/04/2006
              • [cellml-discussion] [team-cellml] Linux functionaltestbuildofPCEnv available, David Nickerson, 10/04/2006

---

Archive powered by MHonArc 2.6.18.