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: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-discussion] Time for a decent RDF library in the CellML API?
  • Date: Wed, 06 Sep 2006 16:53:24 +1200
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).

Also note that the design of the CellML API means that methods for
accessing RDF are identified by URIs, 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. 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.

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.

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).

> 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).
> 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.

Best regards,
Andrew



Archive powered by MHonArc 2.6.18.

Top of page