- From: Leigh Dodds <leigh.dodds@talis.com>
- Date: Wed, 27 Jan 2010 13:09:03 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Hi Andy, Thanks for the response, it addresses my comments and questions. Cheers, L. 2009/11/19 Andy Seaborne <andy.seaborne@talis.com>: > > On 24/10/2009 14:09, Leigh Dodds wrote: > 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 > -- Leigh Dodds Programme Manager, Talis Platform Talis leigh.dodds@talis.com http://www.talis.com
Received on Wednesday, 27 January 2010 13:09:32 UTC