From the comments list: CONSTRUCT *

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.


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.

Received on Monday, 21 November 2005 12:25:05 UTC