Re: Graph Store Protocol HTTP status for empty graphs

The "service" in this case was actually a quad store (because quads
are being appended later on), but Dydra's behavior also changed
recently from 200 OK to 404 Not Found in response to an empty default
graph.
Looks like sending an OPTIONS request will work on both Fuseki and Dydra.

Good to know there's a definition of Graph Store, I hadn't noticed
that. But it does not touch the HTTP layer.

What I still haven't got a response to is: given the text "If the RDF
graph content identified in the request does not exist in the server,
and the operation requires that it does, a 404 Not Found response code
MUST be provided in the response." and an empty default graph, what
should the HTTP response status code be and why?
And what does "graph content" mean? Are triples the graph content?
Which would mean 0 triples do not exist as content? Or is it the graph
itself the graph content?...

On Sat, Sep 5, 2020 at 9:50 PM Andy Seaborne <andy@apache.org> wrote:
>
>
>
> On 05/09/2020 10:59, Martynas Jusevičius wrote:
> > Hi,
> >
> > yes the use case this time was discovering if the service is available.
>
> james:
>  >to determine whether a sparql endpoint is available
>
> I'm not clear what "the service" is here though it is possible to offer
> several protocols from the same URL.
>
> If it is testing for a SPARQL query service, there are also simple
> queries to use like "ASK{}".
>
> ----
>
> The GSP spec refers to SPARQL Update for the definition of "graph store"
> which does have a unnamed slot and "The unnamed slot holds an RDF graph"
> [1].
>
>      Andy
>
> [1] https://www.w3.org/TR/sparql11-update/#def_graphstore
>
>
> >
> > But we've implemented a GSP endpoint ourselves (a GSP proxy really),
> > and my understanding of the spec was always that even an empty default
> > graph should return 200 OK.
> >
> > But after re-reading the relevant text re. "graph content [...] does
> > not exist", I can see that it's not as clear cut as it should be, and
> > I get why Dydra would interpret it as 404 Not Found. Even though that
> > feels counter-intuitive to me.
> >
> > I've opened an issue for SPARQL 1.2: https://github.com/w3c/sparql-12/issues/115
> >
> > On Sat, Sep 5, 2020 at 11:52 AM james anderson <james@dydra.com> wrote:
> >>
> >> good morning;
> >>
> >>> On 2020-09-05, at 11:24:55, Andy Seaborne <andy@apache.org> wrote:
> >>>
> >>>
> >>>
> >>> 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.
> >>
> >> he did.
> >> he did not appreciate our interpretation.
> >> the initial objection being, because it is not what jena does.
> >>
> >> i suggested that, given his use case - to determine whether a sparql endpoint is available, it would be more portable to probe that endpoint for a service description.
> >> as that is a response which is well defined, that method should be preferred to probing a different service in the hope of eliciting some response which is not.
> >>
> >> best regards. from berlin,
> >> ---
> >> james anderson | james@dydra.com | http://dydra.com
> >>
> >>
> >>
> >>
> >>
> >>
> >
>

Received on Saturday, 5 September 2020 20:05:16 UTC