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

Text archives Help


[cellml-discussion] Precise semantics of generateFlattenedModel()


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Precise semantics of generateFlattenedModel()
  • Date: Fri, 24 Feb 2006 11:30:12 +1300
Quoting David Nickerson <d.nickerson at auckland.ac.nz>:

> Am I correct in reading this as saying that metadata contained in
> imported components/variables/units... would not be present in the
> flattened model?
>
> If so, is it a bad thing to be discarding such metadata in the
> flattening process??

This does create some problems for assigning cmeta:id values(which have to be
unique in every given XML file, but not across imports). However, we could
scan
the base model and all elements added to it for cmeta:id values, and where we
find them, add them to a map. In addition, any elements added to the model
under construction could be scanned for cmeta:id elements, and where we find
them, they are checked for uniqueness, renamed if they are already in the map,
and we search for an rdf:Description in the imported file. If we find one, we
add the rdf:Description into any existing rdf:RDF in the model being
constructed, or into a new rdf:RDF if there are no existing ones.

However, this is technically not a good approach because there are several
ways
of expressing the same RDF, some of which delegate out parts of the RDF to
separate resources using rdf:resource rather than creating a single XML
hierarchy. I don't think many repository models actually do this, but it still
seems wrong to decide which data to include depending on the form of the RDF.

Given the apparent complexity of the semantics of getFlattenedModel(), I am
starting to think that it might be better provided as a supplementary service
rather than as part of the core CellML API, possibly with a more complex API
that gives the application more control of the process.

Best regards,
Andrew


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


Archive powered by MHonArc 2.6.18.

Top of page