Re: Suggested modification for CONSTRUCT

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