First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] [team-cellml] Linux functionaltestbuildofPCEnv available


Chronological Thread 
  • From: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] [team-cellml] Linux functionaltestbuildofPCEnv available
  • Date: Wed, 04 Oct 2006 11:53:55 +0800
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
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg


Archive powered by MHonArc 2.6.18.

Top of page