Re: Some comments on the SPARQL 1.1 draft documents

Wrt his first comment and your reply, you may point him to the recent  
thread launched by Sandro if he has concerns on the topic.

Alex.

On 6 Nov 2009, at 11:51, Steve Harris wrote:

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

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Friday, 6 November 2009 11:56:08 UTC