Re: Graph Store Protocol HTTP status for empty graphs

On 04/09/2020 16:46, Martynas Jusevičius wrote:
> OK. Shouldn't there be tests for this? At least for #1?

Would you like to contribute some tests?

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

Better to discuss that with "the other product" to see what they say first.

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

Yes.

Related discussion:

https://www.w3.org/TR/sparql11-update/#graphUpdate

(quads stores vs graph stores)

     Andy

Received on Saturday, 5 September 2020 09:25:12 UTC