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

On Apr 22, 2011, at 15:34 , Nathan wrote:

<snip/>

> Ivan Herman wrote:
>> (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.
> 
> Yes, fully agree, the RDF API and then the RDFWA PI-s (or RDF API Extensions as I like to call them :p), some of which are defined by the community, some of which are defined by us.
> 

The reason I do not like the term extension is because I would think that, for a number of lambda user, one of these will be _the_ interface they would use and extension somehow conveys the feeling that they should go to the basis...

> Still unsure whether the RDFa API would be an example of one of the RDF API Extensions or a whether it's an extension to the DOM interfaces though. Perhaps it's a mix of both,

I it a mix of both. There is the generic, 'RDF' part and the DOM related part. That is not a critique, just the nature of the beast.

> I dare say that detail doesn't matter though, it is what it is.

:-)


> 
>> 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
> 
> Personally, I'm very undecided, I can say that:
> - we definitely need to do #1 first

Agreed

> - we should not constrain out productivity ahead of time or close down our options.

Agreed, but we have to plan in view of our manpower...

> - #2 is almost clear enough to define, perhaps just not quite yet.
> 
> With regards #2, I too feel that it is low hanging fruit, but at the minute it's unclear to me whether the methods we have are:
> - complementary functions which would polish say the Graph interface,
> - or, a generic extension interface which can be added to say Graph (in the RDF API), DocumentData (in the RDFa API) and some DataStore (in some API Extension)
> - or, the beginning of another level of API focussed at the general developer.


I am not sure I clearly make the distinction among these. Actually... I do not even mind too much if the RDFa API stays as it is and we create a separate document that simply repeats the generic interfaces for general RDF usage. (After all, for a full RDF package, there would be an RDFa parser I presume, ie, the generic RDF user, if not interested in the DOM part of RDFa, may just ignore the RDFa side altogether apart from parsing in).


> 
> Naturally, until that's clear I'm wary of where to put them, and would prefer to wait a little while until it is clear. Because, if they /are/ the beginning of another second level API, and we add the to the RDF API, then the natural place to keep adding things is the single document, lines become blurred, and we could easily end up with a big mess (or requiring people to implement more than they should).
> 
> Put another way, the RDF API is currently more of an RDF Interface without a key API which ties it all together, rather it allows modular implementation and has a single RDFEnvironment interface which provides the bare minimum required for other modules to "do things", basically it just covers handling terms, prefixes, and the basic rdf concepts. A dependency you can inject, rather than a traditional API which ties everything together and has methods like .parse, .persist, .sugar-this, .convenience-that.
> 
> For now I'd really like to keep the current document like that, nice and modular and loosely coupled, then, if we find that there's a clear way to provide a developer friendly coupling of the various interfaces together with convenience methods, we can do it as a 2nd level API, probably as a different Rec, I don't even mind if that one were to be called the RDF API and the current one RDF Core Interfaces or something, but certainly want to keep that separation clear, for both implementers and as a design aid for ourselves.
> 


That was my idea all along. What I have in mind is a separate document, exactly for all these reasons. The RDF API document is the one you edit, and we should not add these extra functionalities into that one. By putting this version of RDFWA PI into a document we clearly convey the image of that representing a separate layer. And #3, if we decide to do that, would be a separate document, too.


> Simply, make sure what we have is clean and easy to implement without bugs, build on it with some libs and see if:
> - any more useful interfaces common to all libraries pop out and can be standardized and added
> - any additional methods on specific interfaces emerge, and if so add them (like Graph.match for example, which has already emerged)
> - a standard way of tying some things together emerges and can be agree'd / standardized.
> 
> Ultimately then, I personally can't say yes or no to 1,2,3 at the time, but I'm more than happy to just keep working away and address each one as we feel it's clear what that thing would be and how to do it.
> 
> Best,
> 
> Nathan


----
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 15:36:43 UTC