Re: Default serialisation for SPARQL Service Description

Hi Leigh,

Disclaimer: I'm writing this personally without having spoken with anyone
at all, so nothing I say should be considered to represent the working
group at all.


On Fri, Dec 7, 2012 at 11:12 AM, Leigh Dodds <leigh@ldodds.com> wrote:

> Hi,
>
> Section 2 of the SPARQL Service Description Document [1] says:
>
> "SPARQL services made available via the SPARQL Protocol should return
> a service description document at the service endpoint when
> dereferenced using the HTTP GET operation without any query parameter
> strings provided. This service description must be made available in
> an RDF serialization, may be embedded in (X)HTML by way of RDFa
> [RDFA], and should use content negotiation [CONNEG] if available in
> other RDF representations."
>
> However it doesn't recommend a *default* serialization for the
> description.


I can't recall if this was discussed, but in general if something isn't
explicitly specified then it is to provide maximum flexibility for
implementors.


> An RDF serialization MUST be provided and several may be
> provided via content negotiation, but if a service is only going to
> support a single format, the specification doesn't recommend one.
> Presumanbly the intention is that RDF/XML should be the default
> although with Turtle being standardised an implementor might
> reasonably choose that instead.
>

This is what prompted my response.

Yes, RDF/XML is the only formally ratified standard for the moment.
However, I believe that the majority prefer Turtle, and in many systems
RDF/XML is outright deprecated. (I'm actively ignoring it some some new
projects). So when you say that the intention is "presumably" RDF/XML I
would suggest that it isn't. Indeed the tension between formal standards
(RDF/XML) vs. something useful (Turtle) could well be the motivation for
underspecification.


> In practice I assume that most services will probably support multiple
> serializations, but I think having a recommended default would be
> useful.
>

I agree that most systems will probably support more than one. After all,
it's no big deal to use a Jena lib for the common representations, and
anyone wanting to implement less common formats (e.g. TriG) would probably
want to support a more common format as well.

The WG winds up soon, but there should be an opportunity to respond before
then.

Regards,
Paul Gearon