Re: [ISSUE-30] Suggestions for HTTP protocol updates

On Tuesday 02 June 2009 23:29:23 Chimezie Ogbuji wrote:
> +1 In addition this begs the question about 'compliance' levels.  I.e., is
> such a server considered a 'SPARQL protocol service'?

I'd say so...

> > So, the simplest protocol is one where the HTTP Request-URI is the graph
> > URI.
>
> Or perhaps a portion of the request URI is the graph URI?  Consider Dave
> Beckett's triplr service, which takes GET requests against the following
> URI:
>
> http://triplr.org/turtle/www.kanzaki.com/works/

Hmmm, this breaks webarch, as far as I can see: 
http://www.w3.org/TR/webarch/#uri-opacity


> I can imagine a perma-thread regarding how 'RESTful' such an approach is. 

Yeah, we should try to stay clear of those.

> For me, I think of following RESTful principles as simply meaning we should
> design web interfaces that behave in harmony with the HTTP specification
> such that any client (or developer of a client) can reasonably determine
> how to use the interface (mostly) with guidance from HTTP in addition to
> having other characteristics such as statelessness and cacheability.

Yes, I agree with the general sentiment, but OTOH, I wouldn't rush things in 
this area.


> Yes, this is another alternative.  For me, the difference between this
> approach (using request parameters appended to the request URI) and the one
> above is a wash and comes down to style preference.

I do not quite agree. A graph parameter is clearly a graph parameter, and will 
be parsed and made available as such. Microparsing the URI would require some 
special effort from the endpoint and indeed break Webarch.

> > However, I also note that this could be achieved by using the language,
> > and is as simple as INSERT DATA INTO <http://foo.com> { <triples> <go>
> > <here> . } So, whether it is worth it must be discussed. Also, it isn't
> > quite clear to me if this is entirely RESTful.
>
> You *might* find Mark Bakers opinions on this matter insightful:
>
> http://www.markbaker.ca/blog/2006/11/the-trouble-with-binding/

Yeah, it is interesting. I think this is also a good case for not updating a 
resource that we cannot identify plainly in this round. Simple PUT, POST and 
DELETE is uncontroversial, simple to implement and useful, so within the time 
allowed, that's where I think the main thrust should be.


Kind regards 

Kjetil Kjernsmo
-- 
Senior Knowledge Engineer / SPARQL F&R Editor
Mobile: +47 986 48 234
Email: kjetil.kjernsmo@computas.com   
Web: http://www.computas.com/

|  SHARE YOUR KNOWLEDGE  |

Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
1001

Received on Thursday, 4 June 2009 10:37:55 UTC