Default serialisation for SPARQL Service Description

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Default serialisation for SPARQL Service Description

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

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

Cheers,

L.

[1]. http://www.w3.org/TR/sparql11-service-description/#accessing

--
Leigh Dodds
Freelance Technologist
Open Data, Linked Data Geek
t: @ldodds
w: ldodds.com
e: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Default serialisation for SPARQL Service Description

Thouraya Bouabana Tebibel-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Default serialisation for SPARQL Service Description

Sandro Hawke
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 <[hidden email]> 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