W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: Open issues in HTTP/Update protocol (for discussion)

From: Paul Gearon <gearon@ieee.org>
Date: Tue, 14 Dec 2010 13:26:43 -0500
Message-ID: <AANLkTinqUsoFxhUdDh4uYo0RPzFx+Q60i85AKMx3Xer6@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On Tue, Dec 14, 2010 at 12:59 PM, Andy Seaborne
<andy.seaborne@epimorphics.com> wrote:
> On 30/11/10 18:23, Chimezie Ogbuji wrote:
>>
>> Subject: Open HTTP Update issues for discussion

<snip/>

>> * ISSUE-56 (PATCH HTTP/Update and SPARQL Update payload) [1]

<snip/>

>> In particular, SPARQL Update ...
>
> I confess I don't quite understand this.  The 400 and 404 text above seem to
> both talk about a graph other than the PATCH target.
>
> Could you give examples of the two cases?
> Isn't the request URI the target of the PATCH request?
>
> I don't think a SPARQL Update request ever addresses a graph - it's the
> graph store, right?  GET returns meta data about teh graph store, (303?)

It occurs to me that I wasn't clear about my interest in using PATCH.

In the case where a request is issued against a store, then I am
against the use of PATCH. (Unless we want to allow users to enable
features on a store by PATCHing the capabilities document)  :-)

There are some stores (including Mulgara) which allow graphs to be
referenced with a URI. In some cases that URI is *the* name of the
graph, in others it acts as an alias (e.g.
http://endpoint/sparql?graph=original_graph_uri). I was only
interested in PATCH applying to graphs that can be referenced in this
way - a capability that I am familiar with, but which is outside of
the SPARQL spec.

The majority opinion in last week's call was that we not use PATCH,
and I can live with that.

Regards,
Paul Gearon
Received on Tuesday, 14 December 2010 18:27:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT