Re: Content negotiation in SPARQL Protocol

On Nov 7, 2018, at 1:46 PM, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> On Wed, Nov 7, 2018 at 10:22 PM Gregory Williams <greg@evilfunhouse.com> wrote:
>> 
>> It looks to me like DBPedia is doing a perfectly fine thing sending you back rdf/xml for the select query, because it’s using an rdf/xml serialization of a result set. I don’t think this format was ever standardized, but it’s used within the SPARQL test suite.
> 
> Well, OK. But it's prioritizing a non-standard format over a standard
> one. The request does not specify such priority.

The server almost certainly doesn’t know which formats are “non-standard.” Your request has told the server that either of the media types are equally acceptable, so it chose one. The solution to this is to tell the server which media types you prefer.

>> If you prefer the standardized "SPARQL Query Results XML Format” (or JSON, CSV, or TSV), then you should use an appropriate q-value in your Accept header to indicate that.
>> 
>>> - should an endpoint use different conneg for different query types?
>> 
>> The query type isn’t the important part here. It’s the serialization format of the result of that query type.
> 
> Really though? If, unlike Virtuoso, my SPARQL endpoint implementation
> does not have an RDF/XML serializer for SPARQL results, then it has to
> send 406 Not Acceptable when RDF/XML is requested for SELECT/ASK.

I’m not sure what the *endpoint* using “different conneg” means in this context. If the client requests a media type that isn’t available, the server can response with 406. But that isn’t a requirement. RFC7231 has this to say:

"""
If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
"""

> In other words, my implementation has to maintain 2 different sets of
> variants for those 2 query types.

I’m not sure on why you think this is true. Will the example I gave with different q-values not handle your use-case? It should be able to gracefully handle the two different XML formats we’ve been discussing.

thanks,
.greg

Received on Wednesday, 7 November 2018 22:03:54 UTC