Fwd: Some comments on the SPARQL 1.1 draft documents

I have drafted a reply at:

http://www.w3.org/2009/sparql/wiki/CommentResponse:BL

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

Axel


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
>
>
>