- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 27 Apr 2011 18:37:28 +0200
- To: benjamin.adrian@dfki.de
- Cc: nathan@webr3.org, public-rdfa-wg@w3.org, Manu Sporny <msporny@digitalbazaar.com>
On Apr 27, 2011, at 17:41 , Benjamin Adrian wrote: <snip/> > >>> >>>> 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). Since this mail was written, I have looked at the RDFa API again. In fact, the current RDFa API is so modular already (kudos!) that it seems to be fairly simple to take: - Projection inteface - DocumentData interface, without a reference to the rdfa interface, but with, somehow, a reference to a parser - RDFAEnvironment (essentially a query) to be renamed That is it. What you get is the same, easy-to-use Javascript environment to use RDF data out there in a read only fashion, and use the fact that repeated parse would provide data merge. That is the essence of RDF, after all. In other words, this interface can be used to make mashups of RDF data out there. And that is, actually, a huge plus. (Of course, some of the URI-s used to parse will be ugly because they involve SPARQL queries turned into URI-s, but that might be the object of another interface that the community could come up with, where community might meant a certain Benjamin Adrian:-), but that should be kept separate) This level should be implementable/definable on top of the RDF API. And I believe we are there (my only issue is how to get to a parser, something that I raised in my comments on the RDF API, too...) Cheers Ivan > >>> 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 > __________________________________________ > ---- 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 Wednesday, 27 April 2011 16:36:32 UTC