Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
> 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?
>
I think it does.

However, I don't think that we want the transformation from the
functional view to the name of the model to be irreversible (i.e. it
should be easy for tools to figure out what a component does, so that
someone viewing a model authored by someone else can quickly find out
what the model does). There are several ways to define metadata to avoid
this issue:
1) Importing model has metadata describing the super-structure (that is,
in addition to describing the specific models that it imports, it also
provides information which is more general about the components making
up the model, so they can be identified without the software having to
know anything specific about the imported components).
2) Imported model has information about all the components, describing
what they do in a machine readable form, with levels of information
getting progressively more specific to the actual implementation (this
could be based on an ontological classification, but may include
additional fields as well where appropriate).
3) The information is not included in either the imported or importing
model, but can be queried and retrieved in a machine readable format
from the repository.

The information gained from any one of these approaches could be
displayed to the user to help them identify components without making
the user guess from the import URL. It could also help visual display
(Sarala's work already fits, to some extent, into option 3, but even
more general UIs could benefit from displaying basic icons for
components based on the information).

I think that we probably want to do anyway, since it is the next logical
step from documenting the structure in docbook, and would allow a wide
variety of tools to leverage this information for domain specific purposes.

Matt's work already provides 3 to some extent as well.

I think 1 would be a useful thing to have to allow for "template models"
to be created, but it is probably further off, and so not the best
approach for now.

Opinions?

Best regards,
Andrew

---

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