W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

RE: SPARQL Query - third last call

From: Polleres, Axel <axel.polleres@siemens.com>
Date: Tue, 10 Jul 2012 13:48:16 +0200
To: "andy.seaborne@epimorphics.com" <andy.seaborne@epimorphics.com>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <9DA51FFE5E84464082D7A089342DEEE8013E03D858F0@ATVIES9917WMSX.ww300.siemens.net>
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:
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:
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 }


Sorry again for the late feedback.


Dr. Axel Polleres
Siemens AG Österreich
Corporate Technology Central Eastern Europe Research & Technologies

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:07 UTC