Re: Graph Store Protocol HTTP status for empty graphs

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 19:49:26 UTC