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

On 6/2/09 4:34 PM, "Kjetil Kjernsmo" <Kjetil.Kjernsmo@computas.com> wrote:
> All,
> For those who didn't make it to todays telecon, we opened a new issue today:
> http://www.w3.org/2009/sparql/track/issues/30
> about using HTTP for graph updates.
> 
> I'll try to clarify some ideas I've had around using the HTTP protocol and
> REST principles, and hopefully also summarize the options that we have, but
> not authoritatively.
> 
> I think having a protocol is important because it allows clients to know
> nothing more than HTTP. It is also important because it is really simple to
> configure a server to support just GET, PUT, POST and DELETE operations, and I
> think a server that does just that is as important as a server that runs a
> SPARQL endpoint in the background.

+1 In addition this begs the question about 'compliance' levels.  I.e., is
such a server considered a 'SPARQL protocol service'?
 
> 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/

And interprets it as a request to extract RDF from
http://www.kanzaki.com/works/

At least, this gets around the challenge of not having the necessary
'control' over web space to ensure that all the graph names in the dataset
resolve to endpoint locations (the *same* endpoint location?) that know how
to interpret PUT application/rdf+xml, etc. requests in this way.
 
I can imagine a perma-thread regarding how 'RESTful' such an approach is.  I
think, generally, we should be careful about what we mean when we say REST
principles because there are some REST 'principles' that have more to do
with style than anything else (PUT vs. POST comes to mind as the favorite
topic for perpetual redux threads).

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.

> If a client PUTs triples to a graph URI, a subsequent GET will return the same
> triples. A POST will add the triples in the message to the graph at the graph
> URI and DELETE will remove the triples from the graph at the graph URI.
> 
> Now, this has the obvious shortcoming that it cannot be used in a case where
> you don't control the graph URI, so you can't make it identical to the
> Request-URI. That's where the proposal to create use URIs like
> http://endpoint/rest/?graph=http://foo.com comes in, as this can serve this
> important case.

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

[[[
It does respect Web architecture, but only because itıs read-only. As soon
as you need to add mutation support, or indeed any other operation on the
same resource, the process fails and what results is not Web-friendly. This
is because ³operation on the same resource² doesnıt work if the operation is
part of the resource name; if the operation changes, the name changes, and
therefore the resource-identified changes.
]]]

It might be useful to tease out this criticism a bit.  However, I have a
hard time understanding the explicit *cost* (besides the blanket statement
of saying it is not 'RESTful') with doing things this way.  He mentions that
this mostly has to do with resource identification, which (in our case) is
inherently problematic since there is already some built-in disconnect in
the fact that RDF dataset Graph URIs are really just names (and thus don't
seem to have de-referenceability in mind).  Perhaps this is what Andy (or
was it SteveH?) was hinting at when he suggested we may need a more robust
definition of what an RDF dataset is at least with respect to web
architecture.  How can named RDF graphs in a dataset be referenced outside
of a SPARQL query?

> Personally, I think this is taking it too far, and my proposal is:
> 1) we look upon GET, PUT, POST and DELETE on the Request-URI where it is
> identical to the graph URI as a required feature.
> 2) The http://endpoint/rest/?graph=http://foo.com must be subject to further
> discussion, but may enter as a time-permitting feature.
> 3) Trying to do WHERE in the protocol is out of scope.

-- 
----------------------
Chimezie (chee-meh) Thomas-Ogbuji (oh-bu-gee)
Heart and Vascular Institute (Clinical Investigations)
Cleveland Clinic (ogbujic@ccf.org)
Ph.D. Student Case Western Reserve University
(chimezie.thomas-ogbuji@case.edu)


===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2008).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Tuesday, 2 June 2009 21:30:09 UTC