- 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