Re: CONSTRUCT: allow *?

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 Thursday, 17 November 2005 16:46:23 UTC