Re: From the comments list: CONSTRUCT *

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.

Nice idea but IMHO too much work to consider at this point.

> 0/ The zeroth possibility is leave as-is - no "CONSTRUCT *".

I can live with it but it seems there are such obvious ways to implement 
this which make life a lot easier, that it's sort of a shame to leave it 
out.

> 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/ -0.5
1/ +1
2/ +0.5
3/ -1

> 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.

I can see how 3 may affect future use, but not 2, really.

> PS SeRQL has CONSTRUCT * - Jeen informs me it's in the style of version 2.

That choice is not based on any particular use case, we just happened to 
like it that way :) Besides, the version of SeRQL that deals with 
context (named graphs) is still only in alpha stage.

Jeen
-- 
Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31 33 46599877

Received on Tuesday, 20 December 2005 14:35:19 UTC