Re: From the comments list: CONSTRUCT *

On Mon, Nov 21, 2005 at 12:24:17PM +0000, Seaborne, Andy wrote:
> 
> There have been two recent comments on the lack of "CONSTRUCT *":
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Nov/0045.html
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Nov/0046.html
> 
> The case is made that it has utility based on the users' experiences. This
> message outlines some possibilities and ask people to state any preferences
> (+1/-1 etc).
> 
> 
> 1/ One possibility is to restrict "CONSTRUCT *" to the case where the query 
> is
> against a single graph: so it's limited to:
> 
> CONSTRUCT * WHERE { ... P ... }
> CONSTRUCT * WHERE { GRAPH <uri> { ... P ... } }
> 
> where P is a graph pattern not involving GRAPH.  It is the same as placing 
> all
> the basic pattens that occur in P in the pattern in the CONSTRUCT template.
> 
> This is accessing exactly one of the graphs in a dataset and returning that
> some part of the graph that will reconstruct the same variable bindings at 
> the
> client.  It is not exactly a subgraph in the presence of UNION because it 
> may
> include extra triples induced by one branch from matches only present in the
> other branch in the presence of UNION:
> 
> Data:
> <a> :q <c> .
> 
> CONSTRUCT *  # Repeating the patterns gives => { ?a :p ?c . ?a :q ?c }
> WHERE { { ?a :p ?c . } UNION { ?a :q ?c } }
> 
> Result:
> <a> :q <c> .
> <a> :p <c> .
> 
> CONSTRUCT * as repeating all the basic patterns will yield a graph that
> matches with the bindings: it just may not be minimal or even a subgraph.
> 
> 2/ A second possibilty is to create a single graph created from the parts 
> of all
> the graphs, named and default, used to match the query.  For example, a 
> query
> to pick information from a number of different graphs and create a new
> conveniently graph based on graph patterns used.  Reissuing the query 
> pattern
> does not lead to the same variable bindings.  Such queries can be written 
> out
> explicitly.
> 
> 
> 3/ A third possibility would require a multiple graph serialization syntax,
> where a dataset is synthesised based on the query with no limitations on use
> of GRAPH.

I like this from a closure perspective. Let's let RIF deal with this.

> 0/ The zeroth possibility is leave as-is - no "CONSTRUCT *".
> 
> 
> There is another principle for CONSTRUCT * instead of "it's a shorthand for
> the repeat of the basic patterns", which is "CONSTRUCT *" is the triples
> touched for all the solutions needed.  That can make interactions with
> optimization hard:
> 
> CONSTRUCT *  # Repeating the patterns gives => { ?a :p ?c . ?a :q ?c }
> WHERE { { ?a :p ?c . FILTER(false) } UNION { ?a :q ?c } }
> 
> an optimizer could notice that FILTER(false) rejects everything and never 
> use
> the left branch.  Woudl a subgraph need to include any :p triples?
> 
> 
> With the shorthand repeat template versions:
> 0/ +0.5
> 1/ +1
> 2/ +0.5
> 3/ -1

0/ +1
1/ -0.5
2/ 0
3/ +0.5

I believe that as soon as we include a graph, we're talking about
rules. I'm very hesitant to go into this area now.

> Of the these, the argument of utility justifies 1 to me.  2 is OK too.  3 
> can
> be done in multiple queries.  2 and 3 seem to me to make too many decisions
> about future use at this stage.
> 
> 
> 	Andy
> 
> PS SeRQL has CONSTRUCT * - Jeen informs me it's in the style of version 2.
> 
> 
> 
> 
> 

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.