RE: SPARQL Query - third last call

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

--------------------------------------------------------------------

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.

----------------------------------
>
> 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".
>
> ----------------------------------

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), 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.

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:

"
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.

--------------------------------------------------------------------


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?

Sorry again for the late feedback.

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 10:18 AM
> To: SPARQL Working Group
> Subject: SPARQL Query - third last call
>
> The query spec editors feel that rq25 is as ready for
> publication as a last call.
>
> Given the intended timescale of the WG and current
> availability of WG members to review, we feel it is now time
> to publish.  Some editorial matters remain [1] but we believe
> these are not barriers to a third last call publication.
>
>       Andy
>
> [1] http://www.w3.org/2009/sparql/wiki/To_PR#Query_.28LC.29
>
>

Received on Tuesday, 10 July 2012 11:48:57 UTC