Re: IBM Graph Update Protocol document

Kjetil, thanks for the review, as I had to do some changes in layout and 
formatting I think a few cut and paste errors such as the {graph-store} 
crept in; you are correct in GET, PUT, PATCH, DELETE the {graph-uri} 
should be used and not {graph-store}.

On the first issue:

Our general feeling was that the URI generated by the server is an 
identify for the storage form of the graph, and will often be related to, 
but not the same as the URI for the graph itself. So, we would expect that 
the server base URI would often be different from the base URI of the 
graphs being posted. Thus, the Graph: header is expected to be a URI that 
corresponds to original, and the server can then create URIs of the form:

http://graphs.example.com/graph/http://example.org/data/graph1.rdf
or
http://graphs.example.com/graph?uri=http://example.org/data/graph1.rdf

where the values are suitable URL encoded.

On the second:
The PATCH verb was include in the original 1.0 HTTP specification and 
removed from the 1.1 update with the wording:

   "The PATCH, LINK, UNLINK methods were defined but not commonly
    implemented in previous versions of this specification"

There is plenty of lively debate on PATCH in various communities, I am 
happy to remove this (it is optional), but it would give us no 
reasonable/easy way to specify the update rather than wholesale 
replacement of a graph.

As for the proposed Graph header, it doesn't seem unreasonable for an 
"application-level protocol" (the term used in RFC5023, the Atom 
Publishing Protocol) to add new headers and in fact APP adds the Slug: 
header, which effectively our Graph: header replaces. The alternative is 
to only allow POST to generate identifiers itself and not allow the client 
any control over the generated URI which I think is problematic. 

Thanks,

Simon K. Johnston (skjohn@us.ibm.com) - STSM, Jazz Foundation Services
Mobile: +1 (919) 200-9973
Office: +1 (919) 595-0786 (tie-line: 268-6838)
Blog: http://www.ibm.com/developerworks/blogs/page/johnston 




From:
"Kjetil Kjernsmo" <Kjetil.Kjernsmo@computas.com>
To:
Simon K Johnston/Redmond/IBM@IBMUS, <public-rdf-dawg@w3.org>
Date:
07/14/2009 08:09 AM
Subject:
Re: IBM Graph Update Protocol document


Hi Simon, All,

I think this is a very interesting proposal. I have a few comments.

First, in both replace graph and delete graph, the text says that the 
request should be made against the {graph-store} URI. Is this correct? 
Shouldn't it be the {graph-uri}? It seems to be the latter in the list 
earlier in the document and the following examples, and it seems to be the 
right thing.

I see two main issues with respect to the proposals that have been 
circulating around here.

The largest issue is whether it should be possible to manipulate graphs 
that has a graph-URI which is not dereferenceable on the host of the 
SPARQL endpoint, i.e. if the endpoint is http://example.org/sparql should 
it be possible to manipulate a graph with the URI 
http://graphs.example.com/graph/dahut ?
As far as I can see from your proposal, it would be possible to insert 
such a graph by using the Graph header, but no further manipulation would 
be possible. Is that correct?

This issue seems to be where Simon Schenk and I went in diametrically 
different directions; I feel that manipulating those graphs should be 
time-permitting only, whereas Simon felt we should do only that and that 
the case where the graph-uri can be manipulated directly is not very 
interesting. I suppose he is on vacation and cannot correct me if I 
misrepresent his opinions, if I do it is unintentional.

The other issue you bring to the table, which is new I believe, is the 
PATCH HTTP verb. This never made it into HTTP, did it? I think the ideas 
that have circulated around here is that PUT will insert a graph if it 
doesn't exist and replace if it does. POST will insert if the graph 
doesn't exist, and update if it does.

I think the ideas expressed in your document is well aligned with what the 
group has been discussing previously, except for this, so I'd like to 
bring that to the surface: Do people want to standardise a Graph header 
and a PATCH verb as extensions to HTTP?

I hope that we can reach a consensus very soon on whether we should only 
manipulate graph URIs that can be dereferenced. The other details can be 
dealt with later, but I think it is an interesting topic.

Best,

Kjetil