W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Fwd: Some comments on the SPARQL 1.1 draft documents

From: Axel Polleres <axel.polleres@deri.org>
Date: Thu, 5 Nov 2009 18:18:46 -0800
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <2148DD30-2C8B-496D-BC38-492502B37B4D@deri.org>
I have drafted a reply at:


Please feel free to add or suggest changes to the reply, if needed.


Begin forwarded message:

> Resent-From: public-rdf-dawg-comments@w3.org
> From: "Ben Lavender" <blavender@gmail.com>
> Date: 5 November 2009 13:00:56 PST
> To: <public-rdf-dawg-comments@w3.org>
> Subject: Some comments on the SPARQL 1.1 draft documents
> archived-at: <http://www.w3.org/mid/ee8ed2da0911051300i1df3d97cjcd63a69a7073095d@mail.gmail.com 
> >
> 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 Friday, 6 November 2009 02:19:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC