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

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?



Leigh Dodds
Programme Manager, Talis Platform
Received on Saturday, 24 October 2009 13:17:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:10 UTC