Re: Some comments on the SPARQL 1.1 draft documents

Seems reasonable, but one comment: I'm not familiar with "upwards  
compatible" as a term. Is it equivalent to backwards compatible, or  
forwards compatible, or some other?

- Steve

On 6 Nov 2009, at 02:18, 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
>> 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
>>
>>
>>
>

-- 
Steve Harris, CTO, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD