W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

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

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 26 Oct 2010 13:51:05 -0400
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <2904A30D-4B10-474F-86DA-E046A6D2522A@evilfunhouse.com>
To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
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.

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.

.greg
Received on Tuesday, 26 October 2010 17:51:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT