Re: SPARQL Query - third last call

On 10/07/12 14:14, Polleres, Axel wrote:
> All fine, just one last thing:
>
> [[
> Variables introduced by <code>AS</code> in a <code>SELECT</code> clause must not already be <a href="#variableScope">in-scope</a>.
> ]]
>
> I would prefer to make this more explicit, because "already be in-scope" isn't clear in terms to what  "aleady" refers to. Would the following work for you?
>
> [[
> Variables introduced by <code>AS</code> in a <code>SELECT</code> clause must not already be <a href="#variableScope">in-scope</a>, i.e., within SELECT clauses of the form
>    '<code>SELECT ... (Expr AS v ) ...  { P }</code>'
> the variable <code>v</code> must neither be in-scope within the SELECT clause before  '<code>(Expr AS v )</code>' nor within <code>P</code>.
> ]]
>

These are grammar notes and there is is also the scope section which is 
definitional.

[[
The scoping for (expr AS v) applies immediately.  In
SELECT expressions, the variable may be used in an expression
later in the same SELECT clause and may not be
assigned again in the same SELECT clause.
]]

This section is linked to in the grammar note.

	Andy

>
> Thanks again for all your work!
> Axel
>
> --
> Dr. Axel Polleres
> Siemens AG Österreich
> Corporate Technology Central Eastern Europe Research & Technologies
> CT T CEE
>
> Tel.: +43 (0) 51707-36983
> Mobile: +43 (0) 664 88550859
> Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com
>
>
>> -----Original Message-----
>> From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
>> Sent: Tuesday, 10 July 2012 3:06 PM
>> To: public-rdf-dawg@w3.org
>> Subject: 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.ht
>>> ml 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.ht
>>> ml 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:23:47 UTC