Chronological Thread 

< Chronological >      < Thread >

---

David Nickerson wrote:
>>> The only issue with this is what happens when you upload models into
>>> the repository (the relative URIs would need to remain consistent with
>>> what is in the model, or alternatively, we would need to modify the
>>> URIs).
>>>
>
> I don't think anyone has yet come up with a solution for uploading
> CellML 1.1 models into the repository. If we follow the naming
> convention then all the submodels in a 1.1 model become parts of the top
> level model. And then I'm not sure how to handle different top level
> models for the same base model - i.e., all the different simulations
> performed to create/validate a given model are all going to be different
> top level models that import the mathematics from the base model and
> apply different boundary/initial conditions.
>
>
...
> I the past when this has come up, I think we have always thought that
> the model repository would be a flat structure and all the various
> components of a CellML 1.1 model would be renamed when you upload such
> models into the repository, basically using the _partXX suffix to give
> each component model a unique filename. This results in quite a mess of
> files and pretty much makes it impossible to manually work out what a
> given part of a model represents based solely on the URI for that model.
> Thus it then becomes critical to have a decent query interface to the
> repository so that when I want to import the fast sodium channel from
> the 2004 ten Tusscher human ventricular model into my current model I
> don't need to browse through all the different parts looking for the
> appropriate component (of course there are all sorts of other parameters
> for such queries like curation level, authors, etc.). I'm guessing that
> as both software and the model repository develop we're going to be
> wanting to use such query based imports - which will all be nicely
> hidden away and resolved into appropriate URI's for when the the model
> imports are instantiated.
>
I think a query interface would be useful for finding model components
when building models (and some sort of metadata describing the
super-structure of the model would be very useful, so that tools can
offer to update the model with newer versions of the same type of
component, or otherwise allow the user to change the exact components
used around, without affecting the model). However, I doubt that we want
to do this every time the user tries to run a model, as that would
result in 'moving target' models which are not guaranteed to produce
consistent results from run to run (as the repository changes may alter
the results of queries on base models).
>
>> Revision 706 will now use relative URIs when you call instantiate, since
>> this seems to correspond to what the CellML specification requires (it
>> even has an example with a relative URI in it). I don't strictly follow
>> the procedure from RFC3986 for resolving relative URLs, because we don't
>> currently have a URL parser in the CellML API. However, the procedure
>> used should produce identical results for URLs with no query or fragment
>> on the end (which doesn't make sense for CellML models anyway).
>>
>
> Hopefully the above shows that, at least in my mind, query based URL's
> do make sense when importing models from the model repository.
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
better than
findModel.xml?term1=human_ventricular_sodium_channel&term2=ventricular_sodium_channel&term3=sodium_channel

or something similar.

The way my relative URL resolution works now is that it will append the
relative URL to the absolute URL (it deals with relative URLs starting
with / correctly, this is just for URLs that don't start with /), after
removing the terminal component if it doesn't end in /, and then
resolves . and .. components out of the complete URL (including the
query string).

Resolve
findModel.xml?term1=human_ventricular_sodium_channel&term2=ventricular_sodium_channel&term3=sodium_channel

relative to http://www.cellml.org/models/test.xml will correctly give
http://www.cellml.org/models/findModel.xml?term1=human_ventricular_sodium_channel&term2=ventricular_sodium_channel&term3=sodium_channel

Likewise, resolving findModel.xml?term1=my_model relative to
http://www.cellml.org/models/findModel.xml?term1=human_ventricular_sodium_channel&term2=ventricular_sodium_channel&term3=sodium_channel

will give http://www.cellml.org/models/findModel.xml?term1=my_model.

You would only get problems if you have slashes in your query string,
e.g. resolving foo.xml relative to
http://www.cellml.org/models/findModel.xml?/a/../ will give
http://www.cellml.org/models/findModel.xml?/foo.xml, which differs from
what you would get under the RFC3986 rules
(http://www.cellml.org/models/foo.xml). That said, it is common practice
to urlencode slashes in query strings anyway, and this would avoid the
problem (although we technically should un-urlencode our paths before
making them relative, but we don't do this yet).
> To what
> extent they are hidden from the user/application developer remains to be
> seen. And not that such functionality is currently required (or
> expected) from the CellML API implementation.
>
>
> David.
>
>

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.