- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Sat, 5 Sep 2020 11:59:36 +0200
- To: james anderson <james@dydra.com>
- Cc: public-sparql-dev@w3.org
Hi, yes the use case this time was discovering if the service is available. 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 10:00:00 UTC