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

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.

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 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
  - we should not constrain out productivity ahead of time or close down 
our options.
  - #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.

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.

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

Received on Friday, 22 April 2011 13:35:44 UTC