W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2009

Some comments on the SPARQL 1.1 draft documents

From: Ben Lavender <blavender@gmail.com>
Date: Thu, 5 Nov 2009 22:00:56 +0100
Message-ID: <ee8ed2da0911051300i1df3d97cjcd63a69a7073095d@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
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

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:


Ben Lavender
Received on Thursday, 5 November 2009 21:06:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:10 UTC