Re: Content negotiation in SPARQL Protocol

On Wed, Nov 7, 2018 at 10:22 PM Gregory Williams <> wrote:
> > 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.

Well, OK. But it's prioritizing a non-standard format over a standard
one. The request does not specify such priority.

> 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.

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

> > - 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:

As I tried to explain, the client doesn't really care about SPARQL
protocol or formats. It accepts any XML and would be happy to send a
generic Accept: text/xml, application/xml. But that also has issues:

 curl -v -H "Accept: text/xml, application/xml"*+where+%7B%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
406 Not Acceptable

curl -v -H "Accept: text/xml, application/xml"*+where+%7B%3Fs+%3Fp+%3Fo+%7D+LIMIT+1
Content-Type: application/sparql-results+xml

Here Virtuoso's logic makes more sense to me actually (because I don't
think Accept values are compatible with
application/sparql-results+xml), but obviously 406 is not a
user-friendly result. So I had to add the SPARQL-specific XML formats
to Accept to override/avoid that.

Received on Wednesday, 7 November 2018 21:46:37 UTC