Re: Content negotiation in SPARQL Protocol

On Nov 7, 2018, at 1:02 PM, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> Executing both a CONSTRUCT and SELECT on DBpedia:
> 
>    curl -v -H "Accept: application/rdf+xml,
> application/sparql-results+xml"
> http://dbpedia.org/sparql?query=construct+%7B+%3Fs+%3Fp+%3Fo+%7D+where+%7B%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
>    curl -v -H "Accept: application/rdf+xml,
> application/sparql-results+xml"
> http://dbpedia.org/sparql?query=select+*+where+%7B%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
> 
> Both responses came back with Content-Type: application/rdf+xml, which
> is incorrect in the case of SELECT.
...
> So here comes the questions:
> - is DBPedia/Virtuoso or Wikidata/BlazeGraph doing the right thing here?

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.

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.

> - does the Protocol spec define this somewhere?

I think this is just HTTP, and doesn’t have to do with the Protocol.

> - what should be the generic Accept header, if not Accept:
> application/rdf+xml, application/sparql-results+xml?

That will depend on what formats your client can accept. It sounds to me that in your case you should be doing something like this:

Accept: application/sparql-results+xml;q=1.0, application/rdf+xml;q=0.9

thanks,
.greg

Received on Wednesday, 7 November 2018 21:23:05 UTC