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