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: matt.halstead at auckland.ac.nz (Matt Halstead)
  • Subject: [cellml-discussion] Precise semantics of generateFlattenedModel()
  • Date: Fri, 24 Feb 2006 12:24:57 +1300
I think that while it is complex to flatten metadata also, it is
probably a good idea if there is a use case to persist this flattened
model outside of the in-memory representation. The cmeta:id will
always pose a problem with name clashes; however the resulting
rdf:about that is used to reference is does not (when fully
qualified). The relationship between the cmeta:id and the referring
rdf:about is a made up thing for CellML that so far as I know, we are
the only ones that care about.

The relationship holds true for documents that are not flattened, but
when we flatten them, then the true cmeta:id of the imported elements
no longer abide by our simple rule. They really need to be fully
qualified. Basically we need a similar mechanism to rdf:ID where this
is the short within-document-form of the rdf:about="fully qualified
uri" (see http://www.w3.org/TR/rdf-primer/#newresources). Since the
cellml is not actually RDF, then it does not make sense to subclass
cmeta:id from rdf:ID, but it might be nice to make CellML RDF
compliant sometime (as Carey is finding out). So what we need is a
concept like cmeta:about that follows the same rules of rdf:about.
Then when we do imports and flatten, the cmeta:id of any imported
elements would have cmeta:ids stripped and replaced by fully
qualified cmeta:abouts so that the reference was still valid, unique,
and not replicating metadata into a new uri space.

that's a proposal :-)

cheers
Matt



On 24/02/2006, at 11:30 AM, Andrew Miller wrote:

> 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.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion



Archive powered by MHonArc 2.6.18.

Top of page