Re: Indirect Graph Identification

Onsdag 05 september 2012 00:00, skrev Sandro Hawke:
> Still, in order to motivate a change, can you help explain to me why the
> greater flexibility of the template form would really matter to
> someone?  

Sorry to intrude, but this has some relevance to the paper I presented at 
the LAPIS workshop at ESWC2012:
http://folk.uio.no/kjekje/2012/hypermedia-rdf.pdf
with slides at
http://folk.uio.no/kjekje/2012/lapis2012.xhtml
(The slides are probably the most readable and fun :-) )

Part of the conversation here is actually about RESTfulness. In hypermedia, 
everything you need should be in-band, i.e. it should be in the message 
itself rather than in an out-of-band spec. In this context, the URIs for 
identifying graph should all be in the message, you should never have to 
look up in a spec to figure out what URIs should be used, and you should 
never have to look up a spec to figure out how to compose a URI. That's 
REST constraints. In the GSP context, RESTful interactions would require 
that you can use the Service Description to do all this, and if I 
understand James correctly, this is what he's advocating, and I sympathize.

So, then you can argue over the merits of REST, as Sandro says, it is pretty 
easy to just read the spec, add a ?graph parameter and off you go, but I 
think in general terms, RESTful interactions wins over non-RESTful 
interactions in the long term because in REST, devs do not need to take an 
extra round-trip to a bunch of specs to do their work, it is all there if 
you "View Source" :-) Note that I said "a bunch of specs", as this (only) 
becomes truly important when you implement a system that requires 
interaction with many data sources. Now, semweb should kinda be a one-stop 
solution for all that, but it isn't, we have to expect devs to interact 
with many different data sources using many different protocols for many 
years to come. Then, protocols that require spec lookups will loose to 
protocols that do not. I think.

This is actually what I thought what we would be doing when we (I was int he 
WG) resolved to do a RESTful update protocol. I realized at that time that 
I didn't grok REST, but I got really hung up in this indirect graph 
identification stuff. TimBL warned us very early on that it was a 
distraction, and that is exactly what it was, it is not an issue if the 
protocol had actually been RESTful, then the server could assign any URI to 
the graphs it hosts and that would be it. I suppose none of us actually 
understood TimBLs comments. That's life. The protocol should have been 
RESTful, and I think it would resolve James' very valid concerns.

BUT, IMHO, it is now too late to come up with an elaborate RESTful design. 
After the removal of any references to REST in the spec, I'm quite content 
with it. If, at some point, we get together and design something RESTful, I 
do not think the current spec will be a significant impediment to its 
adoption, as most likely, the REST spec will just wrap hypermedia RDF 
around the URI structure defined in the current spec and relax other 
constraints defined therein.

I believe that such a RESTful design could be done within the charter of 
Linked Data Platform Working Group.

So, I say, push to CR, and I'll try to shut up :-)

Cheers,

Kjetil

-- 
Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/

Received on Wednesday, 5 September 2012 09:51:16 UTC