Re: Graph Store Protocol HTTP status for empty graphs

OK. Shouldn't there be tests for this? At least for #1?

On Fri, Sep 4, 2020 at 5:40 PM Gregory Williams <greg@evilfunhouse.com> wrote:
>
> On Sep 4, 2020, at 2:24 AM, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> >
> > Hi,
> >
> > I'd like to clarify what the HTTP status should be for these cases:
> > 1. GET default graph which is empty
> > 2. GET named graph which is empty
> >
> > I've looked at the GSP test suite, but I don't think they are covered:
> > https://www.w3.org/2009/sparql/docs/tests/data-sparql11/http-rdf-update/
> >
> > Jena Fuseki returns 200 OK for #1 which makes sense to me (as the
> > default graph always exists in an RDF dataset), but we use another
> > product which returns 404 Not Found.
> >
> > Re. #2, is it different from a non-existing named graph which returns
> > 404 Not Found? That one is covered:
> > https://www.w3.org/2009/sparql/docs/tests/data-sparql11/http-rdf-update/#head_on_a_nonexisting_graph
>
> I think Jena is doing the right thing with #1.
>
> For #2, my recollection is that whether this is different from a similar request on a non-existing graph depends on whether the underlying store supports empty graphs. At least in the Query spec, the wording was carefully designed to allow for both implementations that had the concept of an empty graph, and also those for which graphs were simply the result of which values appeared in the graph position of all quads. So I think either 200 or 404 would be acceptable responses.
>
> .greg
>

Received on Friday, 4 September 2020 15:47:03 UTC