There may also be requirements for some of the metadata you describe in terms of model curation.
Andre. Andrew Miller wrote: > 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 -- 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
