RE: SPARQL Query - third last call

> This section is linked to in the grammar note.
>
>       Andy

Ok, didn't remember the note under the table...
works for me.

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:23 PM
> To: Polleres, Axel
> Cc: public-rdf-dawg@w3.org
> Subject: 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.h
> >> t
> >>> 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.h
> >> t
> >>> 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:38:59 UTC