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

Comments on SPARQL 1.1 WD 20091022

From: Leigh Dodds <leigh.dodds@talis.com>
Date: Sat, 24 Oct 2009 14:09:18 +0100
Message-ID: <f323a4470910240609p1d8e034fjb7d60b73f1cc79fd@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
Hi,

Here are some personal comments/questions on the 22/10/2009 WD of SPARQL 1.1.

* Example in Section 2. I don't think the project expression conforms
with grammar shown latter in the doc; missing brackets? I know this is
still up for discussion, but thought I'd point it out

* Section 2, Syntax. re: the note about using FILTER instead of
HAVING. Assuming I'm reading the comment correctly, I think for
readability purposes its better to have a separate keyword (HAVING)
rather than re-use the FILTER keyword. I think its clearer that there
are different constraints (i.e. aggregates allowed or not) on the
expression, and retains similarity with SQL.

* Section 3. Text above example query is wrong, I think it should
ready "from all the people that Alice knows", not "that know Alice".

* Section 4. What is the rationale for including both a FILTER and a
graph pattern operator for EXISTS/NOT EXISTS? If there are benefits in
terms of expressivity or ease of implementation it would be good to be
able to call these out in the specification.

* Section 4. The NOT EXISTS and EXISTS graph pattern operators are
described as "applying only to variables defined earlier in the
pattern". What does "earlier" mean if a SPARQL processor can re-order
the statements for optimization purposes? Does use of those operators
have some impact on an implementations ability to do that?

Cheers,

L.

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@talis.com
http://www.talis.com
Received on Saturday, 24 October 2009 13:17:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 24 October 2009 13:17:50 GMT