Re: SPARQL Query - third last call

On 10/07/12 12:48, Polleres, Axel wrote:
> Hi Andy, all
>
> (this is in completion of ACTION-641)
>
> I'm finally - sorry sorry for the delay again - looking into the discussion we had around BIND-Scope, and have the following comments/questions:
>
> --------------------------------------------------------------------
>
> 1) This one is minor/editorial:
>   http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0160.html
> doesn't seem to have a reply yet. (I had a minor final editorial comment to the table in 18.2.1
> There suggesting to leave out the "Group" keyword (as it's really not a keyword), or, if you want to leave "Group" at least shorten the describing text in accordance with the other rows
>

I think the {} needs explaining.

I have made the word group not in code font.

Elsewhere the text says "in-scope in P" so I think the current wording 
is best.

> --------------------------------------------------------------------
>
> 2) This one is a question for clarification only:
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012AprJun/0159.html
> You seemed to agree on Option 2 here, but your text now reads slightly different
> than my suggested text.

BIND applies to the TriplesBlock, not the whole of the preceding group
I did not find anything else that made sense.

More below.

>
> ----------------------------------
>>
>> Option 2: ---------
>>
>> Disallow variable being in-scope in the semegroup, but only before
>> the BIND clause appears: That could be addressed by changing item 12
>> as follows:
>>
>> *   The variable assigned in a BIND clause must not be already<a
>> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
>>
>>
> within the pattern in the same group before the BIND clause. That is, if
> BIND (Exp as V) appears in a pattern
>> {  P1 BIND (Exp as V) P2 }, then v must not be<a
>> href="http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a<http://www.w3.org/TR/sparql11-query/#variableScope">in-scope</a>
>>>   P1.
>>
>>
>> --------------------------------------------------------------------
>>
>> +1 to this option.  This is the intention because of the use case above
>> and the wording about "ends a BGP".

but, on detailed work, it didn't work out.

1/ It's unnecessarily restrictive
2/ It's at odds with scoped bottom up evaluation (see next)
3/ join is not (syntactically) commutative
...

>>
>> ----------------------------------
>
> You now write:
> "
> The variable assigned in a BIND clause must not be already
> in-use within the immediately preceeding TriplesBlock within a
> GroupGraphPattern. "
>
> I suppose the small difference between my wording suggestion and yours is the sema reason
> as the one why you disagreed with test-cases bind-scope 7 and 8... If that is the reason (pls confirm),

.. the tests involve subpattern (sub-group) nesting.

The design makes scoping proper otherwise nested and flat queries behave 
differently (one is illegal) for no good reason whatsoever.

 > then I also better understand why you disagreed with those test cases 
--> fine by me!

>
> --------------------------------------------------------------------
>
> 3) This one is IMO important: I have one last question about the current item 12
>
> "
> Expressions used in SELECT clauses must only use
> in-scope variables. This only applies to expressions used on the left-hand side of AS.
> "
>
> I am both unsure whether this is clearly defined, nnor whether we actually need to limit this? Wouldn't variables not in-scope within expressions just be unbound? E.g., what speaks against:
>
>     SELECT (bound(?X) AS ?B)
>     WHERE {}
>
> Particularly, since it seems we could equally write
>
>     SELECT ?X (bound(?X) AS ?B)
>     WHERE {}
>
> Where, according to the in-scope definition, ?X is in-scope.

The text is merely pointing out that it SELECT expressions (not FILTER 
or BIND ones).

Actually, it's unnecesary - removed and replaced by ...

>
> So, I have an alternative suggestion:
>   Didn't we rather want to limit the variables on the *right-hand-side* of 'AS' to be *not* already in-scope? That is, wouldn't we rather want to limit the usage of variables in SELECT clauses as follows:
>

Separate issue - worth pointing out though.  Change made.


> "
> Within SELECT clauses of the form
>      SELECT ... (Expr AS v ) ...  { P }
> the variable v must neither be in-scope within the SELECT clause before  '(Expr AS v )'
> nor within P
> "
>
> ? If you agree, I suggest to change item 12 accordingly.
>

[[
Variables introduced by <code>AS</code> in a <code>SELECT</code> clause
must not already be <a href="#variableScope">in-scope</a>.
]]

> --------------------------------------------------------------------
>
>
> That is, in summary, I understood
> we want to prohibit
>
>     SELECT ?X (Expr AS ?X) { ?P }
>
> or, respectively,
>
>      SELECT ?Y (Expr AS ?X) { ?Y :p ?X }
>
> but we don't want to prohibit
>
>      SELECT (Expr AS ?X) (?X AS ?Y) { P }
>
> Yes?

Yes.

Have you tried the validator?

	Andy

>
> Sorry again for the late feedback.
>
> Axel

Received on Tuesday, 10 July 2012 13:06:44 UTC