Re: Fwd: Some comments on the SPARQL 1.1 draft documents

Axel, I made a few changes, and I think the response accurately reflects 
the WG consensus.

Lee

Axel Polleres wrote:
> 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 
>> <mailto:public-rdf-dawg-comments@w3.org>
>> *From: *"Ben Lavender" <blavender@gmail.com <mailto:blavender@gmail.com>>
>> *Date: *5 November 2009 13:00:56 PST
>> *To: *<public-rdf-dawg-comments@w3.org 
>> <mailto: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 Saturday, 7 November 2009 04:43:28 UTC