Re: More minimalisic proposal than potentially bound (http://www.w3.org/2009/sparql/track/actions/329)

On 26 October 2010 18:51, Gregory Williams <greg@evilfunhouse.com> wrote:
> On Oct 26, 2010, at 12:55 PM, Birte Glimm wrote:
>
>> Thus, here's my attempt of defining scope, so that I can use the
>> definition for SELCT * as above:
>>
>> Let Q be a query with group graph pattern G. The variables in scope
>> for Q, written scope(Q) are the variables in scope of G, written
>> scope(G). The variables in scope of a group graph pattern are
>> recursively defined as follows:
>> A group graph pattern G can either be a sub-select query (SubSelect
>> from the grammar) or a sub-group graph pattern (GroupGraphPatternSub
>> from the grammar). If G is a sub-group graph pattern, then G can
>> contain blocks of triples in addition to a non-triple graph pattern
>> (GraphPatternNotTriples in the grammar). Variables occurring in the
>> blocks of triples are in scope of G. If G contains a non-triple graph
>> pattern composed of one or more group graph patterns G1 to Gn, e.g.,
>> OPTIONAL G1 or G1 UNION G2, then variables in scope(Gi) for each 1 <=
>> i <= n are in scope for G. If G is a sub-select query with group graph
>> pattern G', then scope(G) = scope(G').
>
> This leaves out several ways that variables can be bound (and in scope) besides triple patterns including GRAPH ?v {}, and BIND(expr AS ?v). Also, I'm a bit unclear on the wording here, as group graph patterns can't "be" sub-select queries or "sub-group" graph patterns. GGPs can contain subqueries, or other GGPs, but they can also contain BGPs and all the other graph patterns.

Well, he wording mainly follows the SPARQL grammar, which
distinguished between GGP as a single sub-select query and the other
forms of GGP. Other forms can be composed of other GGPs, e.g., in the
case of UNION.

I agree that variables for some cases are still missing, as ?v in your
GRAPH ?v {} example.
>
> I find the "potentially bound" definition much easier to understand and that definition maps nicely onto my mental model of the different graph patterns and operators in an AST. I personally think there's value in allowing SELECT * to be used in (non-trivial) grouped aggregate queries, and find it clear how the concept of "potentially bound" would encompass both the subselect and aggregate grouping cases we've discussed that affect the list of projectable, in-scope variables.

My main objection to potentially bound is that I think that it is the
same as variables that are in scope. The term in scope is used in
several places already, just the definition of what that means is
still missing and I wouldn't want to introduce another term in
parallel to in scope, which essentially denotes exactly the same.
Either there is a difference between in scope and potentially bound
(which I don't see yet) or we should decide for one term to use
throughout. I prefer in scope and that's used already in several other
places.
Once we have a definition for that, which could then also be closer to
the one proposed for potentially bound, we can just say that the * in
SELECT * is an abbreviation for a list of all variables that are in
scope.

Birte

> .greg
>
>
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Wednesday, 27 October 2010 13:10:54 UTC