Re: Some comments on the SPARQL 1.1 draft documents

Hi Ben,

First, thanks for your comments.

> The first, smaller point was a disappointment with the choice 
> of RDF/XML as the one standard required to be supported by the 
> new RDF graph HTTP management API. [...] Other easy to parse 
> protocols have existed for years. Why the continued support 
> of RDF/XML as the canonical standard?

The working group is operating in the W3C realm, and RDF/XML is the only normative format to exchange RDF at this point. While other formats are being used and supported, the standardisation of these formats is not in the scope of the SPARQL WG.

> The larger point was that the sizable syntax extensions make a
> protocol with limited adoption even more difficult to implement.
> Implementations do not exist for several popular web development
> languages, and enlarging the syntax only increases the range of
> features that are 'required' to be supported.

In case this is referring to the Update part of the protocol, let us emphasize that we do not require nor intend that a SPARQL endpoint has to support both SPARQL/Query and SPARQL/Update. In this sense, and in the sense that SPARQL1.1 shall be fully upwards compatible, any SPARQL endpoint implementing only query shall be fully conformant.

There are a large number of implementations of SPARQL 1.0 in a wide variety of language environments spanning both scripting languages and compiled languages. You can see a community-maintained list of implementations here: http://esw.w3.org/topic/SparqlImplementations

The Working Group selected the current set of deliverables based upon three months of deliberations that included feedback from both SPARQL implementors and users as to what features & extensions are most widely needed for improved utility and interoperability of SPARQL.

> I suggested that a better route would be to establish a more
> machine-friendly format as the standard, and define SPARQL in terms of
> how it compiles into that.  That algebra, already published alongside
> the syntax, is readably expressible as S-expressions, and those should
> be the protocol, with the human-readable form as an addendum.  The end
> result is that *every* language feature can easily be subject to
> extension, service discovery, and the incremental implementation that
> small-scale open source projects need, instead of only those features
> expressible by extension functions.

I am not sure what exactly you are referring to here, but the goal of the group is to develop widely requested and implemented extensions  of SPARQL in an upwards compatible fashion. This does not foresee to change the format of the language radically, nor have concrete proposals for such new format been suggested when the group was chartered.


> The service discovery feature was an excellent step in the right
> direction, and some of us would love to see it apply to everything
> SPARQL can do, not just part of it.

Thank you for this comment. Indeed the service description feature is intended to be minimal and extensible by external vocabularies to describe e.g. datasets, additional endpoint features, etc. The group will very much welcome such proposals which might, if widely used, be adopted in further versions of the standard.

with best regards, 
Axel Polleres, on behalf of the SPARQL WG


On 5 Nov 2009, at 21:00, Ben Lavender wrote:

> I posted some comments about the 1.1 draft on my blog, which Axel
> Polleres asked that I post here.  I will not paste the entire
> contents, as I suffer from a clinical lack of conciseness.  Instead, I
> will say my two main points and link.
> 
> The first, smaller point was a disappointment with the choice of
> RDF/XML as the one standard required to be supported by the new RDF
> graph HTTP management API.  The protocol has issues marked as
> 'postponed' for years.  Other easy to parse protocols have existed for
> years.  Why the continued support of RDF/XML as the canonical
> standard?
> 
> The larger point was that the sizable syntax extensions make a
> protocol with limited adoption even more difficult to implement.
> Implementations do not exist for several popular web development
> languages, and enlarging the syntax only increases the range of
> features that are 'required' to be supported.
> 
> I suggested that a better route would be to establish a more
> machine-friendly format as the standard, and define SPARQL in terms of
> how it compiles into that.  That algebra, already published alongside
> the syntax, is readably expressible as S-expressions, and those should
> be the protocol, with the human-readable form as an addendum.  The end
> result is that *every* language feature can easily be subject to
> extension, service discovery, and the incremental implementation that
> small-scale open source projects need, instead of only those features
> expressible by extension functions.
> 
> Further, it's worth noting that SQL has spent the last 20 years being
> abstracted away by necessarily complicated libraries, and having the
> structure of a query language be well-defined in a machine-readable
> format seems to be more forward-looking than the incidental details of
> a human-readable version.
> 
> The service discovery feature was an excellent step in the right
> direction, and some of us would love to see it apply to everything
> SPARQL can do, not just part of it.
> 
> The long-winded version is at:
> 
> http://bhuga.net/2009/11/w3c-going-wrong-direction-sparql-11
> 
> Ben Lavender
> 
> 
>

Received on Monday, 7 December 2009 21:26:57 UTC