Re: CONSTRUCT: allow *? [OK?]

The working group has considered this comment but in the end it decided to 
leave "CONSTRUCT *" out of this version of SPARQL.

--------
PROPOSED: to leave out CONSTRUCT *, as the cost of delaying the SPARQL spec to 
work out the design details, and the risk of conflict with rules designs, 
outweighs the convenience of adding it
ACCEPTED
--------

There is some discussion from
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005OctDec/0266.html

Addressing some restricted, simple cases, and not others, didn't motivate the 
working group members, given that a quick, restricted design may block later 
designs as well as have potential interactions with rules.

Please let us know whether this reply addresses your comment.

If you could additionally send a message with [closed] in the
subject line, it would save us a little bit of bookkeeping.

	Andy


Seaborne, Andy wrote:
> 
> 
> 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 Wednesday, 21 December 2005 11:39:33 UTC