[Mulgara-dev] Queries against non-existent graphs

Gregg Reynolds dev at mobileink.com
Fri Dec 31 06:52:11 UTC 2010


Currently a query against a non-existant graph <urn:foo:bar> throws
"HTTP/1.1 500 Query failed: Graph not in local storage, and not able to be
found with the "urn" scheme: <urn:test:unicode>."  This is thrown fairly
deep in the code.

A query against a non-existant graph <http://foobar.org/baz> throws
"HTTP/1.1 500 Query failed: foobar.org"

Should these throw the same exception?  Should they be caught before the
query is executed?  That's the way I've done it in ProtocolServlet, but it
dawned on me that with open-world semantics that might not be correct, since
we might want to delegate the query to another server.

More generally:  should a query against a non-existant graph be considered
an exception?  I think so, since it amounts to asking null for info.  But
what about queries involving multiple graphs, named or un-named?  If one
graph is non-existent, should the query throw the exception?  I'm inclined
to think so, since a user request to merge graphs g and h indicates an
expectation that the graphs exist.

Related issue:  should a plain (non-SPARQL) POST to a non-existant graph
throw an exception?  I'm inclined to think maybe it should, since it implies
an expectation that the resource already exists.  On the other hand,
URI/resource semantics seem to be open-worldy by nature: a URI identifies a
resource even if the server contains no representation of the resource.  The
problem is that if this is good enough for POST, it should be good enough
for GET; it would effectively mean that there are no non-existent graphs (or
resources); rather there are only servers that are incapable of delivering
serializations of the resource.  On this view a query against a
"non-existent" graph should return some representation of "zero contents"
rather than an exception.

Sorry if this is all covered somewhere.

Thanks,

Gregg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20101231/dc9803dc/attachment.html>


More information about the Mulgara-dev mailing list