Re: The necessity of hypermedia RDF and an approach to achieve it

Hi all!

Thanks Melvin for posting the abstract of my LAPIS2012 at ESWC paper! I had 
planned to join this list for a long time, now I've finally done it!

In addition to the paper, 
http://folk.uio.no/kjekje/2012/hypermedia-rdf.pdf
I'd also like to point to the slides:
http://folk.uio.no/kjekje/2012/lapis2012.xhtml
It was partly intended to provoke discussion, and it was successful, I 
guess, because it caused so much discussion I never had the time to get 
through the slides. :-) Anyway, I think the slides are easier to understand 
and more humorous than the paper. 

Basically, my plan was to write the code, get my University to join the W3C 
and then submit a Member Submission with this stuff. I wrote the read-only 
bit of the paper, which is now available in the Perl module 
RDF::LinkedData, 
https://metacpan.org/module/RDF::LinkedData
and will also be available in the next stable releases of Debian and Ubuntu 
in the package librdf-linkeddata-perl.
A typical deployment of that module will now also include a quite 
comprehensive VoID description, a SPARQL 1.1 endpoint and CORS support, see 
e.g. http://data.lenka.no/

Since time hasn't allowed me to complete the read-write support of my 
module, I haven't pushed my agenda any further (as I feel it should be 
supported by running code). Now that the die is cast ;-), this is it: Based 
on my admittedly superficial reading of the Linked Data Basic Profile work, 
and my more thorough reading of the SPARQL HTTP Graph Store work, I think 
they should be the different sides of the same coin, united by hypermedia 
RDF. The main difference between data operated on in a Linked Data scenario 
and a Graph Store/document scenario is that in the former case the server 
MAY or even SHOULD restrict the triples it is willing to admit or emit to 
triples that is in a close relationship to where the Request-URI is an 
subject or object URI. Whoa, that was a mouthful. 

Consequently, beyond standardizing the hypermedia vocabulary, which I have 
suggested a design for, most of the attention should be devoted to defining 
how a Linked Data server should behave when facing data that are very far 
from the Request-URI, and show how the graph store should be done fully 
RESTfully.

I've been working on the read-write parts of the module, but I should be 
refactoring a bit and I am currently writing tests:
https://github.com/kjetilk/RDF-LinkedData/tree/feature-rw
but then, I really ran out of time, as this is tangential to my research, I 
shouldn't spend much time on it. It basically uses Toby Inkster's RDF::ACL 
module, which again can take a WebID-authenticated user URI (also tobyink-
code) or some other authentication mechanism that sets a URI. It can 
already include the hypermedia URIs from the paper, but you still can't 
write, so I have not made a new release. It is really very simple though.


The last part of my talk, from slide #36 and onwards was something I had 
only intended to talk about if time allowed, as it is mainly a critisism of 
the SPARQL HTTP Graph Store, which have no removed any references to REST. 
It is less fun and less constructive to just critisize other people's work, 
so I toned it down. While a member of the SPARQL WG, I helped concieve it, 
but it took a entirely different path that I had envisioned and I think it 
should be done RESTfully, as originally intended.

Cheers,

Kjetil

Received on Tuesday, 4 September 2012 21:34:29 UTC