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

On 9/4/12 5:33 PM, Kjetil Kjernsmo wrote:
> 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
>
>
>

Welcome Kjetil !

Others:  Kjetil was also one of the supporters/promoters of the SWEO 
competition concept that paved the way for the LOD community during the 
very early days of Linked Data :-)

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen