Re: CONSTRUCT: allow *?

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

Given this implementation experience, I'll prepare a proposal for the working 
group based on a restricted form of CONSTRUCT *.  Something like:

CONSTRUCT * WHERE { .. no GRAPH .. }
CONSTRUCT * WHERE { GRAPH <g> { .. no GRAPH .. } }

In the above suggestions: my personal views are:

1/ I would like to see a standard, deployed multigraph serialization syntax, 
first.  Until there is a standrad, I'd leave this to extensions to a SPARQL 
server (presumably just one providing HTTP for the content negotiation).

2/ Could be made to work but I'm not sure having one fixed merging mechanism 
is justified.  One of the main reasons for keeping RDF in separate graphs is 
so that it can be treated independently.

3/ seems like a balence bewteen need and generality.  With a series of 
queries, you could do the other cases.

	Andy

> 
> 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 10:28:07 UTC