- From: david.nickerson at nus.edu.sg (David Nickerson)
- Subject: [cellml-discussion] Time for a decent RDF library in the CellMLAPI?
- Date: Fri, 08 Sep 2006 11:25:25 +0800
If I understand the discussion so far, I agree with Matt and we should
be looking at a higher level API than providing methods to manipulate
the RDF directly.
I also think that while such an API will be very useful we need to
ensure that this discussion doesn't hold up the initial release of PCEnv.
Andre.
Matt wrote:
>
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
>
>
_______________________________________________
>
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.