GSP Test `DELETE - existing graph` has wrong expected result

[Qup42]

The SPARQL Graph Store Protocol Test DELETE - existing graph has an incorrect expected result. The standard states If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code. The graph being deleted - <http://$HOST/$GRAPHSTORE$/person/2.ttl> - does not exist so the correct response should be 404 Not Found like it is for DELETE - non-existent graph.

The intent is clear though: a graph that exists and is DELETEd should result in response code 200 or 204. The interesting questions seems to me how to best resolve this. <http://$HOST$/$GRAPHSTORE$/person/1.ttl> is still required later on. So I see two ways to resolve this:

• Create a graph for this test to drop it
• Drop the default graph which is only used before this test

[afs]

For some systems, based on quad storage and not having separate graph management, "empty graph" and "no graph" are not distinguished. I suspect that 200 happens in the wild.

This is general area discussed in 5.3. HTTP PUT.

I think the spec should be revised to SHOULD for 404, or say MUST return 404 or 200.

cc @kasei

[Qup42]

For some systems, based on quad storage and not having separate graph management, "empty graph" and "no graph" are not distinguished. I suspect that 200 happens in the wild.

• DELETE - non-existent graph (following DELETE - existing graph with a GET in between) does the exact same operation but now expects a 404 Not Found. This heavily indicates to me that the graph should exist for the first test case.
  Edit: In an old list of all Conformance Tests I found PUT - empty graph which creates the graph being deleted. This seems to be caused by the removal of the unapproved test cases which are required for the setup of this case.
• As far as I can tell Jena returns 404 for DELETE - existing graph (I used indirect graph identification though) when I manually execute the tests in the manifest in order.

This is general area discussed in 5.3. HTTP PUT.

I think the spec should be revised to SHOULD for 404, or say MUST return 404 or 200.

I agree that allowing 404/200 to accommodate both types of graph management seems sensible. The general status code remarks contain the clause and the operation requires that it does which for me leaves enough freedom for both implicit and explicit graph existence. 5.4 HTTP DELETE on the other hand only has If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code. without this clause. How can I return anything else than 404 here without deviating the standard?

[afs]

Jena isn't a good example. The "dataset" abstraction has several implementations. Some handle empty graphs differently to no-such-graph, some don't. It is a reflection of the implementation approach.

The GSP operations have special code to make this look the same in the most frequent cases. But it is a thin layer and it is possible to see through the abstraction.

. 5.4 HTTP DELETE on the other hand only has If there is no such RDF graph content in the Graph Store, the server MUST respond with a 404 Not Found response code.

How can I return anything else than 404 here without deviating the standard?

That's something that can be treated as an errata since there is a working group at the moment. The issue list is at https://github.com/w3c/sparql-graph-store-protocol/issues

What we need to know is what the deployed de facto behaviours.

There's scope for a "practice and experience" note somewhere to discuss empty graphs.