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 > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
