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 mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
