Re: Why does rdf-sparql-protocol say to return 500 when refusing a query?

On 4/28/11 7:37 AM, Richard Cyganiak wrote:
> On 28 Apr 2011, at 11:26, Leigh Dodds wrote:
>> However it may be useful to define a standard response format and
>> potentially error messages to help client apps/users distinguish
>> between more fine-grained error states. I suggested this during
>> discussion of the original protocol specification but the WG decided
>> it wasn't warranted initially [1]. Based on this discussion I'm not
>> sure implementation experience has moved on enough, or converged
>> enough to feed this back as part of SPARQL 1.1.
> I raised this issue again with the SPARQL WG last year:
>
> Original message:
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Sep/0002.html
>
> Replies start here:
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/index.html
>
> The thread pretty much covers the entire design space and elicited lots of good (and bad) arguments.
>
> My takeaway, after surveying 141 public SPARQL endpoints, is that the most interoperable option is to serve SPARQL error messages as a text/plain one-liner.
>
> Also, none of the editors of the SPARQL 1.1 Protocol document felt it necessary to contribute to the thread, despite it running for a week and concrete text changes to the specs being proposed. I take this to indicate that making the Protocol more interoperable is unfortunately rather low on their list of priorities :-(
>
> Best,
> Richard
>
Richard / Leigh,

You know what? Let's just do it!

Innovation by committee doesn't work, and it won't start working today. 
Standardization should follow implementations out in the wild. The 
existence of LOD and the LOD cloud is a contemporary reminder.

This list (from prior posts) looks fine to me as a starting point:

* Syntax error (400)
* Accept range mismatch (406)
* Query rejected off-hand as too resource-intensive (403?)
* Store unreachable (504?)
* Server overloaded (503?)
* Query timed out (504?, 403?).

The one-liner can be a fallback so as not to impose on others while still making it possible for developers to write smarter SPARQL clients and servers via more granular response codes.

I can assure you, we'll implement these codes once there is some agreement over here.



-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Thursday, 28 April 2011 12:15:18 UTC