Re: Default serialisation for SPARQL Service Description

On 12/10/2012 04:25 PM, Paul Gearon wrote:
> 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.
>

Same here.

>
> On Fri, Dec 7, 2012 at 11:12 AM, Leigh Dodds <leigh@ldodds.com 
> <mailto: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.

I concur.

I note that the Linked Data Platform Working Group recently resolved to 
use Turtle this way:

    *RESOLVED:* Servers MUST support Turtle; servers MAY deliver other
    formats using standard HTTP content negotiation; If the client
    doesn't indicate a preference, Turtle MUST be returned

                    --
                    http://www.w3.org/2012/ldp/meeting/2012-11-01#resolution_3

It's an unfortunate bit of timing that prevents SPARQL from doing that.  
SPARQL is expected to go to REC before Turtle, while LDP will arrive a 
bit later.   So SPARQL isn't allowed to depend on Turtle, while LDP is.

I expect the community best practice will be for SPARQL to use Turtle 
this way, soon, and perhaps a future version of SPARQL will require it.

     -- Sandro

>     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