- From: Steve Harris <steve.harris@garlik.com>
- Date: Sun, 27 Sep 2009 20:35:06 +0100
- To: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 27 Sep 2009, at 17:35, Seaborne, Andy wrote: [snip] >> >> 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. That was the point, I was thinking of a scenario where a user types an update expression but uses SELECT instead of INSERT by mistake (maybe CONSTRUCT would have been a more obvious example). The syntax error message returned will be at best unhelpful and probably confusing. >> 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. - Steve -- Steve Harris Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK +44(0)20 8973 2465 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Sunday, 27 September 2009 19:35:43 UTC