[Mulgara-dev] Queries against non-existent graphs

[Paul Gearon]

Hi Gregg,

On Fri, Dec 31, 2010 at 1:52 AM, Gregg Reynolds <dev at mobileink.com> wrote:
> 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?

Perhaps, though there is a reason for having different exceptions.

In the case of the URI <urn:test:unicode> the system looks internally,
and can't find it. So it goes through the remaining resolvers, and
nothing claims that it knows how to handle that type of URI, so it
gives up.

For the <http://foobar.org/baz> URI, the system looks internally, and
can't find it. So it goes through the remaining resolver, and the HTTP
resolver says that it knows how to deal with that kind of URI. So
that's the resolver that gets used. However, it gets back a 404 on the
URL, and has to report that it couldn't get the graph.

So it's a different process. It therefore makes sense that you'd get a
different error. But then you have to ask if the user cares. Probably
not. So maybe they'd get logged differently, but reported the same way
to the user.

> Should they be caught before the
> query is executed?

No, since the only definitive way to know the availability of the
graph is to execute the query.

>  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.

No, I think that a query against a non-existent graph should be
considered a query against an empty graph. This is supported by SPARQL
now. Even if it weren't, it's consistent with an open world
assumption. In the open world, not having a graph means that you don't
know about it, not that it doesn't exist. So it should act as if it
were successful, but with an empty data set.

The problem is that if you have a typo or something, then you'll just
get an empty answer. In that case, an error might have been more
useful. But since it's now consistent with other parts of SPARQL, I
think we really just need to act as if it's an empty graph. I think we
can do that by having unknown graphs fall back to the null resolver.
I'll check.


> 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.

I agree with you there. It's in line with what I was saying above.
Currently it's not set up for that, but I think we need to make it
happen that way.

To give an example of SPARQL Update, we're keeping the ability to
create an empty graph, but that's allowed to be a no-op. If an update
operation tries to insert data into a non-existent graph, then the
store is required to create that graph silently.

Paul