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

Hi,

Sorry for responding so late, but my family needed my attention during
the last days.

>>> Ivan Herman wrote:
>>> 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.

I agree with you Ivan that a 3-tier stack of APIs is a good mental model
for describing our RDF/RDFa APIs.

And I now see my remarks on the RDF-API (SPARQL, persistent graphs) as
well as the examples and use cases I wrote for the RDF API to match best
to the intention of this second layer API.

>>
>>> 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

I would say we can do a mixture of #1 and #2 by collecting the good and
the bad from existing RDF libs (Jena, Sesame, RDFlib, Redland).

>> 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.

What I am still missing a bit is an open discussion about use cases of
these three APIs. Initially I thought, I created some use cases for the
lowest API.

I had our old linked data API in mind. Now I assume the use cases match
better with the RDFWA PI.  Shall I remove the three application use
cases from the spec of the RDF API?

Nathan, could you give me some problems and examples for which I as a
web developer should use the RDF API?

Best regards,

Ben


> 
> 
> ----
> 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
> 
> 
> 
> 
> 
> 
> 


-- 
__________________________________________
Benjamin Adrian
Email : benjamin.adrian@dfki.de
WWW : http://www.dfki.uni-kl.de/~adrian/
Tel.: +49631 20575 1450
Twitter: http://twitter.com/BenBanBun
Skype: benbanbun
__________________________________________
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschäftsführung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
__________________________________________

Received on Wednesday, 27 April 2011 15:42:27 UTC