W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

RE: update= vs query=

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sun, 27 Sep 2009 16:35:17 +0000
To: Steve Harris <steve.harris@garlik.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693E18881A@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Steve Harris
> Sent: 26 September 2009 09:54
> To: public-rdf-dawg@w3.org Group
> Subject: Re: update= vs query=
> On 25 Sep 2009, at 12:33, Seaborne, Andy wrote:
> [snip]
> > I prefer query= and update= to keep them apart.  I use the servlet
> > API and the query string has been parsed to separate out the named
> > arguments so this is convenient in telling them apart before needing
> > to look at the body and invoke the right entry point in the parser.
> >
> > It will also help with ensuring updates are issued only over POST.
> > I can see some value in a common name for a simple client to pass on
> > strings without interpretation so if there were a "either=" (not
> > that name!) as well but it lets in update requests being sent over
> > GET.  Binding "update=" to POST only makes it clear.  And isn't it a
> > regex to tell 99% of the cases apart so that isn't a burden for the
> > client to do it.
> I have a concern with what happens when you receive a POST request
> using "either", e.g.
> SELECT { ?x ?y ?z }
> INTO <http://foo.example/somegraph>
> WHERE { GRAPH <http://bar.example/somegraph> { ?x ?y ?z } }
> If would be very hard for the endpoint to make a sensible guess as to
> whether it should try an interpret this as SPARQL/Query or SPARQL/
> Update, and would have trouble returning a sensible error message in
> either case.

Steve - I don't understand the example.  SELECT is always a query - INSERT would be the operation in SPARQL/Update. The verbs of query and update are distinct so the example does not parse either way.

> Additionally, I like the separation that query= and update= gives,
> potentially avoiding some of the problems that SQL has from (often)
> sharing a common API for pure query operations and update operations,
> if the SPARQL client has to be explicit.

I agree - the "either=" suggestion is for completeness.  I think we need a sufficiently motivating reason for looking at it and, so far, I don't see one.

> If there's some application where the client really want to have a
> single method then it can do the regex client side to make the guess.

Agreed.  The verbs in query and update are distinct.

> At least then it can inform the application which it attempted to
> treat the query as, which would help with debugging.
> - Steve


Received on Sunday, 27 September 2009 16:36:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC