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

Hi,

I thought a bit about the design space for the RESTful protocol. I guess
we have to distinguish the following cases:

a) A graph is accessible at the URI, which also happens to be it's name.
Some standard Webserver might be sufficient here. For SPARQL/Update this
is just a corner case. 

b) A SPARQL endpoint holds a set of named graphs and a default graph.

b1) We talk about a dataset in the SPARQL/Query sense. There can be many
such datasets available at the endpoint. We need to identify the dataset
as well as the graphs in the dataset.

b2) We talk about a graph store, consisting of a default graph and a set
of named graphs.

I propose to ignore a), as it is a corner case. 
I propose to ignore b1), as it becomes complicated, once we start
talking about datasets as first class objects.

My thoughts about b2):

To be precise, we talk about the copy of a named graph, which the store
holds. This can be different from what the owner of the name of the
graph intends. A common example would be an outdated web crawl. Hence,
we not only are allowed to, but we should scope the graph name to the
store.

I propose to have a graph store endpoint, say <http://my/graph/store>.
It's default graph is accessible at exactly this URI. Named graphs in
the store are accessed using URI parameters, e.g.
<http://my/graph/store?graph=http://example.org/myfoaf>. The name could
also be a URI encoded part of the overall URI, but this way one could
easily write it by hand for use with w.g. curl.

The allowed operation then would be as expected
GET returns the whole graph
POST adds triples to the graph, creating it first, if necessary
PUT replaces a graph. PUT of an empty document is creation only.
DELETE deletes a graph.

Caveat: If the graph store's URL addresses the default graph, where to
send changes using the update language via http? A possible solution
would be adding some default postfix to the store's URI to address the
default graph.

WHERE would not be addressed. If the graph store corresponds to a SPARQL
endpoint it could be simulated using CONSTRUCT + the above interface, of
cause loosing atomicity.

Cheers,
Simon


Am Dienstag, den 02.06.2009, 22:34 +0200 schrieb Kjetil Kjernsmo:
> 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
> 
-- 
Simon Schenk | ISWeb | Uni Koblenz
http://isweb.uni-koblenz.de
http://www.uni-koblenz.de/~sschenk