Chronological Thread 

< Chronological >      < Thread >

---

Alan Garny's reply to my question about imports has promoted me to
write down a couple of ongoing concerns with import structures.

The relevant section in the specification is
http://www.cellml.org/public/specification/20030930/
cellml_specification.html#sec_import_model

A simple example for the declaration of an import follows :

<model
name="our_model.xml"
xmlns="http://www.cellml.org/cellml/1.1#";
xmlns:xlink="http://www.w3.org/1999/xlink";>
<import xlink:href="http://www.example.com/myocyte_model.xml";>
<units name="millivolts" units_ref="millivolts" />
<component name="Na_channel" component_ref="sodium_channel" />
</import>
.....
</model>


From the specification we have "The xlink:href attribute has a value
equal to the Uniform Resource Identifier that identifies the location
of the imported CellML model."

Two situations that come to mind concern importing models from curated
repositories. These are

1) where a model changes but maintains the same URI

2) where a model changes and its URI is modified

The first case is a concern for systems that will necessarily cache
imported models locally. In various situations, it is too much of a
bottleneck to have to retrieve all imported models from remote
locations, especially if the CellML community is working from a
collaborative repository. In this situation we have at least
something in common with web based content. For URLs that are http
based, we can rely on HTTP caching methods. Additionally we are free
to add versioning information into the metadata of the model that could
be queried remotely through various methods.

The second case asks questions about the best practices for updating
the URI of a modified model. I can't see an easy way to determine when
there has been a significant enough change to require a new URI. One
premise could be that if the change breaks models that import it then a
new model and hence URI should be defined. Since we cannot hope to
test all models that use import a particular model, then we could set
some rules based around any change that adds a new structure - e.g.
component, variable, connection, group, or modifies an interface. But
then such a change may have been made to correct a model that was
initially incorrect. Any model that imported the old one would not get
the new structure, and in this case, a correction of an obvious error.
Forcing the breakage of a model that imports the previously incorrect
model is actually a good practice - much like unit tests breaking in
code.

I don't think these concerns are show stoppers, but need to be thought
about sooner rather than later. The metadata specification for CellML
seems like the appropriate place to begin defining information about
changes that help a machine importing a model make decisions about
using it. For instance, if there is a new model that has a different
URI to the one being imported, then it is useful to link to this from
the currently imported model along with a semantic description of what
this link means - such as - "structural_correction". The user
importing the model can then make a decision on whether to update its
local import declaration.

I have put some notes together on possible linking mechanisms which I
will post next week. These notes will also cover a naming issue that
seems apparent now. The role of the name attribute seems almost
redundant now that we have URI based imports. By the fact that we
define a URI for a model that describes a unique instance of it at some
unique location, then we are providing a unique name by which to
identify that model. People are free to copy a model and place it in
other locations to be imported by other models, but this necessarily
creates a new instance - there is nothing that ensures two separate
copies will remain the same. We can identify the independence of two
models by their URI, and not by the name. To me, the name of the model
is more in line with a type - e.g. we may have a number of instances of
the ""our_model.xml" model that may differ in aspects such as
corrections to structure, or initial conditions, but still relate to
the same model concept. This is the domain of CellML typing and
ontologies.

cheers
Matt

---

• [cellml-discussion] some general concerns with import, Matt Halstead, 08/06/2004

---

Archive powered by MHonArc 2.6.18.