W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

GRAPH { ... } & subqueries Re: [ISSUE-8] subqueries and datasets

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Fri, 08 May 2009 14:26:42 -0400
Message-ID: <4A047962.60106@thefigtrees.net>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
CC: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Seaborne, Andy wrote:
> 
> 
> Note the case of:
> 
> GRAPH <foo> {
>  ....
>  { SELECT * .... }
> }
> 
> This is a compositionality argument that the default graph of the subSELCT should be the same graph as is named <foo> in the dataset.  But then the default graph is not accessible except by name if it has one).

Andy, thanks for bringing this up; this is (to me) an interesting issue 
regarding subselects.

In current SPARQL/Query, everything outside a GRAPH { ... } clause 
matches the default graph. GRAPH <foo> sets the 'active graph' for 
matching inside of the GRAPH clause. (And GRAPH ?g lets the active graph 
range over all of the named graphs, binding ?g appropriately as it matches.)

How do existing implementations handle the construct Andy has above?

Does execution of the subquery start with <foo> as its active graph?

(I assume that GRAPH clauses within the subquery then work the same way 
that nested GRAPH queries already do today - they override the active 
graph for whatever's inside them, but can still bind any ?g-type GRAPH 
variables outside.)

Lee
Received on Friday, 8 May 2009 18:27:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:54 UTC