Link to comment

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Nov/0006.html

Response

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