Link to comment

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Oct/0000.html

Status

Approved.

http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0477.html

Response

Leigh,

Thank you for your comments.

This first published working draft contains the new areas for query that the working group is progressing. The material will be integrated with the the previous version of the query language to produce a single, new document for SPARQL 1.1 Query.

Things may be a little rough in this first draft ...

Leigh Dodds wrote:

> 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

Yes - it's not consistent. The WG had not reached a conclusion on the exact syntax at the time of publication.

> * 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".

Agreed.

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

If the working group decides to allow EXISTS/NOT EXISTS in FILTERs, then there will be a example to illustrate the point.

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

It's loose wording to discuss the scoping of variables. "earlier" means the pattern to the left or above of the NOT EXISTS.

> 
> Cheers,
> 
> L.

Andy
on behalf of the SPARQL Working Group