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
>> [email protected]
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
> _______________________________________________
> cellml-discussion mailing list
> [email protected]
> http://www.cellml.org/mailman/listinfo/cellml-discussion
--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
_______________________________________________
cellml-discussion mailing list
[email protected]
http://www.cellml.org/mailman/listinfo/cellml-discussion
