There have been two recent comments on the lack of "CONSTRUCT *":
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Nov/0045.htmlhttp://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.
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
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.