- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 18 Nov 2005 11:03:38 -0600
- To: ext Richard Newman <r.newman@reading.ac.uk>
- Cc: Dan Connolly <connolly@w3.org>, public-rdf-dawg-comments@w3.org, Leo Sauermann <leo@gnowsis.com>
FWIW... I would prefer to see option 2. It seems to offer the best balance between solutions which use/support named graphs and those which do not. After all, the response to CONSTRUCT *is* a new graph, so it seems quite intuitive to me that one can use graph qualfications within the query insofar as the queried knowledge is organized by named graph, but that the triples returned of course constitute a distinct graph from any that the query matched. Cheers, Patrick On Nov 17, 2005, at 10:46, ext Richard Newman wrote: > > That is a challenge. I don't know what solutions the WG came up > with, but I can see three: > > 1. Allow this only with a result format that supports named graphs. > A request for RDF/XML with this query will return some invalid > request HTTP response. A SPARQL endpoint that can do content > negotiation, and can serialise in a smarter format, is free to > actually serialise the graph correctly. Obviously, using SPARQL > internally with a quad store (as is the case with Wilbur) can allow > for this to be done programmatically. > > 2. Synthesise the triples regardless, ignoring the graph binding. > One can consider the query below to be "build me a NEW graph using > the results of this query", in which case discarding the source > graph is quite reasonable. Note, of course, that the result > bindings can still be filtered on ?G, so supporting GRAPH within > the CONSTRUCT statement remains quite reasonable. > > This also makes sense if you define '*' in this context as "the > graph pattern you're querying on, with all the GRAPH stuff > removed". As long as it's defined in the docs, nobody can really > complain :) > > 3. Reject any such query -- let CONSTRUCT * only apply to queries > that ignore graph names. > > Any of these is something of a step up from not having the feature, > and the implementation is straightforward regardless. I'm > personally in favour of 2 or 3, with engines optionally supporting > 1 if the serialisation format supports it. > > Thoughts? > > -R > > On 16 Nov 2005, at 19:15, Dan Connolly wrote: > >> In a bit of haste... >> >> As I recall, the problem with CONSTRUCT * is interactions with GRAPH. >> For example: >> >> CONSTRUCT * WHERE { GRAPH ?G { ?work dc:title ?txt } }. >> >> I think the WG chose to punt on * rather than think too hard about >> that. >> >> If you have a suggestion that we didn't consider, we'll consider it. >> >> -- >> Dan Connolly, W3C http://www.w3.org/People/Connolly/ >> > >
Received on Friday, 18 November 2005 16:59:45 UTC