- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 21 Nov 2005 12:24:17 +0000
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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