Re: primary use case of the RDF API (ISSUE-91)

(I labelled it as ISSUE-91, because I believe it is very much in line with that issue, too)

On Apr 21, 2011, at 23:18 , Nathan wrote:
<snip/>
> 
> Now the interesting bit, do all developers only use jQuery? No, many use other libraries like Dojo, MooTools, Prototype, YUI, ExtJS etc, as a matter of preference, or simply picking the right tool for the job. Do all those libraries use the DOM API though? Yes they do.
> 
> We need the equivalent of the DOM API first. And we cannot possibly define a secondary level API which everybody will be happy with, that's the job of the library implementers IMHO.
> 
> Disagree?

No:-)

On the contrary, with all controversies around the DOM, I think this is a good analogy. I increasingly see our work as having 3 tiers (and I guess I have already talked about this in my earlier mails)

- RDF API (the RDF DOM, so to say): defining a standard low level API to map fundamental RDF constructs into Javascript
- RDFWA PI-s (absolutely awful name, something for RDF Web Application Programming Interface): higher level interfaces for lambda Javascript developers
- RDFa API: well, you know what that is

Actually, RDFWA PI is actually a collection of API-s, some of them defined by us, some of them defined by the community. In this sense, I could even consider the RDFa API as being an example for _an_ RDFWA PI.

So the big question for us: which RDFWA PI would this group define? We have to deliver on is the RDF API and the RDFa API, that is for sure. There are several answers here that came up in past discussions:

1. None. Let the community figure out
2. A slight generalization of the RDFa API: essentially, move all non-RDFa dependent features of the RDFa API into this layer and define it in a way that it could be used with any datastore (giving access to a parse method). The RDFa API would then become an extension of this level by adding the DOM specific methods, and embedding (somehow) the general interfaces into the Document object
3. An interface to SPARQL endpoints (NOT requiring a local SPARQL implementation). What this layer would do is, essentially, to take a SPARQL CONSTRUCT or DESCRIBE query, turn the query into a proper (and awful:-) GET URI, and parse the returned RDF/XML into the triple store.

My (personal) belief is that we ought to do #2. It is a very low hanging fruit (if you guys agree, I might make a first stab at it just by cutting out the unnecessary parts from the RDFa API document) and it would provide a proper consistency with the way we handle RDFa. At present, there is some sort of a discrepancy because RDFa is handled _very_ differently.

As for #3: I think it is more valuable to do a slightly more general interface to SPARQL endpoints rather than to concentrate on CONSTRUCT only. It should also handle the Query form, interpreting the result set in JSON rather than triples. It is not very complicated, but it is a bit of work. I have done something like that myself in Python at some point; it is now a separate sourceforge project[1] managed by two great guys from Spain. And that package was inspired by Lee's package[2]. I believe such a layer would be very useful; I am not sure we are at the point of standardizing it. Why don't we consider having a separate Note on #3, essentially taking [1] and [2] as a starting point but defining it on top of the RDF API?

I think, to move forward, we should

- decide on whether we agree with the 3 tier view
- decide if we do #1, ie, nothing more :-)
- decide if we do #2 as a Rec
- decide if we do #3 and, if so, as a Rec or as a Note

Ivan



[1] http://sourceforge.net/projects/sparql-wrapper/
[2] http://thefigtrees.net/lee/blog/2006/04/sparql_calendar_demo_a_sparql.html





----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Friday, 22 April 2011 09:05:08 UTC