- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Thu, 30 Dec 2004 10:31:46 -0500
- To: public-rdf-dawg@w3.org
On Sun, Dec 19, 2004 at 10:56:02PM +0000, Steve Harris wrote: > This leads me to something I meant to comment on re. implementing (bits > of) the return format and protocol. I think it would be useful if the return > format included some way to encode error messages insead of or in addition > to result bindings. > > When accessing SPARQL engines over HTTP you can use HTTP error values, but > you still have to provide some content to go with it to explain the error. > I'm doing it with HTML currently, but thats not a great idea for > mechanistic access eg. from non-interactive software. Also not all access > will be (direclty) via HTTP. [Catching up from holiday distractions...] Steve, I'd like us in this or in a next version (preferably ASAP) to work out an RDF scheme for communicating SPARQL query/protocol faults, warnings, and errors. Instances of such could be returned instead of result formats, whether in HTTP or other protocol. HTTP allows for this kind of extensibility by allowing most (all?) response types to contain an arbitrary representation of some resource in the body. One tricky bit, which came up in talking with Andy about the protocol doc, is how to signal to the requester that the returned graph is an error/fault/warning and not a query result. We might add a new response type to HTTP, 4xx, or overload an existing one. I'm pretty sanguine as to *how* we implement this in HTTP till we have an RDF vocabulary to communicate. Kendall Clark -- Sometimes it's appropriate, even patriotic, to be ashamed of your country. -- James Howard Kunstler
Received on Thursday, 30 December 2004 16:55:49 UTC