Re: Review of SPARQL Query Doc

(Steve - there aggregate comments in Matt's review which I've not addressed)

Hi Matt,

Thank you very much for the comments.

I've made sure none of these comments get lost so I've added editor's 
"To Do" marks (@@) to the doc as described below.

For sections that not changed by SPARQL 1.0 and you suggest editorial 
chnages, could you suggest some text?  I'm a little wary of making too 
many changes in SPARQL 1.0 sections if they are not corrections - 
clarifying certain points can be an unbounded task as different readers 
are looking for different things but suggested text would help me a lot.

> The document looks good overall. I think it just needs a few sections
> completed before it is ready for publication: some text related to
> HAVING in Section 10, and some text to accompany the example in Section
> 8.3 for MINUS.

I've added a @@ to make sure this happens sometime.

We can either delay publication or publish a snapshot of what we have. 
The document will not have all sections completed in time for 
publication this month.

I leave the decision of which way to go to the chairs.

> Detailed Comments:
>
> -- Section 4.1.3 states that query variables have global scope. My
> understanding is that this is still true in the presence of subqueries,
> but it may be helpful to readers to make an explicit statement here
> about how subqueries affect variable scope.

Thanks for catching this.  The nesting of project does change this.

> -- From my understanding, {?a :p1 ?b OPTIONAL {?a :p2 ?c} ?a :p3 ?c} is
> not equivalent to {?a :p1 ?b . ?a :p3 ?c OPTIONAL {?a :p2 ?c}}. It think
> there should be a statement on the effect of OPTIONAL placement inside a
> group graph pattern in Section 6.

Yes, it's different - order matters.

There is no change here for SPARQL 1.1.
Could you suggest some text for this?

> -- I think it would be helpful to readers if the example in Section 7
> was modified to show that SPARQL UNION does not eliminate duplicates
> (i.e. it is more like SQL UNION ALL instead of SQL UNION).

(It does need to reflect the updated syntax form)

> -- Would it make sense in Section 8 to mention FILTER + !BOUND() as a
> form of negation?

Personal opinion: rather than making the doc refer back to the 1.0, 
idiom, I'd rather we just state the new feature(s) and make the 1.1 
document "standalone" and we are trying to add features that make this 
unnecessary.

OPTIONAL/!bound is in the F&R document which is more about the diffs 
from 1.0 to 1.1.

> -- Typo in Section 8.2: existance --> existence

Done.

> -- The results in the example in Section 8.3 look wrong. I don't think
> <http://example/bob> should be in the result set.

Fixed.

> -- Typo in Section 8.4: thinkign --> thinking

Done.


** Aggregates - I'll leave these to Steve.

> -- I'm not familiar with the IF operator (Section 15.4.15).

Conditional expression.

IF(expr1, expr2, expr3)

evaluate the expr1, if true the result if expr2, else it's expr3.

There was a discussion a while back and no concerns about it then.

> -- Section 16.2.3 Step 3: Aggregates, typo: soltuion --> solution

Done.

> -- In Section 16.4 Definition: Extend, should "extend(mu, var, expr) =
> mu if var not in dom(mu) *OR* eval(expr) is an error" be "extend(mu,
> var, expr) = mu if var not in dom(mu) *AND* eval(expr) is an error"?

"and" makes more sense at present although both are right - for the "or" 
case, it strays into the case of "var in dom(mu)" which is defined but I 
do plan to propose a definition.

The WG went for silent error (hence this defn), and any query processor 
can log it as a warning, for SELECT expressions which don't evaluate 
correctly so the natural way to complete the definition is to ignore the 
expression value.  As we work through the full details and test cases, 
we should be clearer position about errors in SELECT expressions.

	Andy

Received on Saturday, 8 May 2010 19:22:02 UTC