W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

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

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Thu, 4 Jun 2009 12:37:27 +0200
To: public-rdf-dawg@w3.org
Message-Id: <200906041237.27619.Kjetil.Kjernsmo@computas.com>
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: 

> 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/


Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
Received on Thursday, 4 June 2009 10:37:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:55 UTC