[ISSUE-30] Suggestions for HTTP protocol updates

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.

So, the simplest protocol is one where the HTTP Request-URI is the graph URI. 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.

Whether the server stores these triples as files in a file system, or puts them in a graph in a quad store should be left open, and that implementations should not force the graph URIs to have any relation to the endpoint 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. 

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.

Then, we could try to take it even further to emulate the WHERE clause, and so on. Supposedly, we could look to the DeltaV protocol used in Subversion for inspiration. 

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.


Cheers,

Kjetil