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

Text archives Help


[cellml-discussion] Time for a decent RDF library in the CellML API?


Chronological Thread 
  • From: matt.halstead at auckland.ac.nz (Matt)
  • Subject: [cellml-discussion] Time for a decent RDF library in the CellML API?
  • Date: Wed, 6 Sep 2006 20:00:19 +1200

On 6/09/2006, at 4:53 PM, Andrew Miller wrote:

> Matt wrote:
>> The fact there is no standardized API does not mean we invent our
>> own. There are plenty of RDF implementations around and a huge amount
>> of overlap between them. I suggest we find that subset that shows
>> reasonable intersection over the most popular rdf libraries and use
>> that.
> I think you will find that my proposal meets these criteria, because I
> have specified all the very basic RDF operations (as well as some
> necessarily CellML specific ones).
>

Yep, I agree that it is a reasonable set. I'd be surprised if any
useful RDF library does not implement them. I don't see why we need to.


> Also note that the design of the CellML API means that methods for
> accessing RDF are identified by URIs,

What do you mean by this?

> so you can have more than one
> (although we wouldn't want to burden this on implementors, so they
> would
> have to be optional. We could have a core, required API, and allow
> make
> better RDF specifications, e.g. providing query language access,
> documented but not required).
>> But in saying that, I'm not sure you need to be exposing the
>> RDF through an RDF centric API. The developers of the metadata editor
>> found it more useful to offer an API that was centered around the
>> kinds of metadata that needed to be supplied - for instance to add a
>> series of authors, it was much nicer to be able to populate an
>> authors data structure, especially since in the cellml metadata
>> specification there is a strict interpretation of the underlying RDF
>> data structures - such as bags, lists etc.
>>
> It is certainly worthwhile to offer convenience interfaces specific to
> certain specifications, such as cmeta, the simulation and graph
> specifications.

I see these as been the current use cases, and the most important
level at which to address any specific API (not the RDF level).


> However, the problem with this is that there is such a
> large (and continuously growing) set of RDF-based metadata that people
> might want to use, and so they need to be able to access this without
> updating the CellML API to support every specification ever invented.

RDF can always be processed by RDF libraries so long as the RDF/XML
fragments are available to load. The lesson learnt with the cellml
metadata editor was that the higher level API that addressed the
necessary and optional but useful metadata requirements were the most
relevant interfaces. Our metadata specification is quite strict about
the relationship of various RDF schemas for particular annotation
purposes, e.g. the combination of bqs:Person and vcard structures.

I think for the annotation structures that we say are necessary or
useful, that a predefined specification and interface is very useful,
especially for people trying to populate specific data structures out
of them. If for example we said feel free to use anything inside
bqs:reference, or actually any arbitrary reference schema, then we
run into an increasing number of permutations that one would need to
accommodate in RDF queries or RDF subgraph graph accessors to get at
the same information.

RDF does not itself imply anything goes; I feel energy is better
spent specifying a strict RDF schema and an API that satisfies
interacting with data that conforms to this (and not at the triple
level).


>
> Providing an RDF API at the CellML API side is very useful, especially
> when there are multiple consumers of the implementation, because
> you are
> working with the real document, rather than a copy which was
> created at
> some earlier point.
>

I think you are assuming too much about the underlying framework
here. Perhaps I am wrong, but are referring to the shared model
through the corba interface?


> As I have pointed out, if you try to get serialised RDF/XML out of an
> RDF/XML unaware implementation, you run into all sorts of problems
> with
> getting all the data.
>
> For example, I just had to write code like this in PCEnv:
> function getModelMetadata(model)
> {
> var el = model.getRDFRepresentation("http://www.cellml.org/RDFXML/
> DOM").
> QueryInterface(Components.interfaces.
> cellml_api_IRDFXMLDOMRepresentation).data;
> var od = el.ownerDocument;
> var rnl =
> od.getElementsByTagNameNS("http://www.w3.org/1999/02/22-rdf-syntax-
> ns#",
> "RDF");
> var l = rnl.length;
> var i;
> var td = od.implementation.createDocument(
> "http://www.w3.org/1999/02/22-rdf-syntax-ns#";, "rdf:RDF",
> od.doctype);
> var de = td.documentElement;
> for (i = 0; i < l; i++)
> {
> de.appendChild(td.importNode(rnl.item(i), true));
> }
> var rrs = window.context.cellmlBootstrap.serialiseNode(td);
>
> // Put it into the Mozilla RDF implementation...
> var p = Components.classes["@mozilla.org/rdf/xml-parser;1"].
> createInstance(Components.interfaces.nsIRDFXMLParser);
> var mds =
> Components.classes["@mozilla.org/rdf/datasource;1?name=in-memory-
> datasource"].
> createInstance(Components.interfaces.nsIRDFDataSource);
> var modelURI = model.base_uri.asText;
> var uri = Components.classes["@mozilla.org/network/standard-url;1"].
> createInstance(Components.interfaces.nsIURI);
> uri.spec = modelURI;
> p.parseString(mds, uri, rrs);
> return mds;
> }
>
> This is bad for several reasons:
> 1) I have to do a lot of work just to support a relatively common
> operation (getting the metadata) properly.
> 2) It requires a lot of communication between the CellML API and
> the user.
> 3) It uses the DOM core to traverse through nodes defined in
> CellML, in
> order to find all the RDF. The CellML API was designed to prevent
> this,
> so this is a violation of the design principles underlying the
> CellML API.
> 4) It makes a copy of the RDF from the model at the Mozilla side,
> which
> could potentially get out of sync.
> 5) Trying to change the model requires even more special logic (e.g.
> would have to write code to explicitly strip out all the rdf:RDF
> elements, serialise the RDF into a document at the Mozilla-side,
> send it
> across to the API side as a string and parse into a document, then
> import the new document element into the model document, and append to
> the model document element).
>

I tend to use an XPATH query and copy the fragments into a new
document. I don't find this particularly hard, and for any given
implementation of the CellML API, it's just a single call away for
the user of that API.


>> There is nothing stopping anyone adding arbitrary RDF using whatever
>> RDF tool they want.
>>
> Except that RDF/XML is not a nice way to work with RDF, and as I
> showed
> above, serialise/parse creates problems (I could use your same
> argument
> to say that we should work on CellML documents from directly from the
> DOM core API, but that doesn't mean that it would be productive).

I wasn't saying that we use RDF/XML to work with RDF. I am saying
anyone adding arbitrary RDF to a CellML model is free to use whatever
RDF library implementation they want to access it. They may even have
their own schema aware libraries - well, I'd hope so.

>> Specifying and implementing our own RDF API does not make sense to me
>> at all.
>>
> It makes a lot of sense to me, because it is consistent with the main
> goal of the CellML API, which (according to me, at least) is to
> provide
> easier programmatic access to the contents of CellML documents.

Yes, but I am suggesting this is at a higher level than the RDF
level. You might want to check out what they ended up with in the
metadata editor code.

cheers
Matt


>
> Best regards,
> Andrew
>
> _______________________________________________
> 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