- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 04 Dec 2006 14:19:44 +0000
- To: axel@polleres.net
- CC: public-rdf-dawg-comments@w3.org
Axel Polleres wrote: > Fred Zemke wrote: >> Axel Polleres wrote: >> >>> * I'd like to suggest to the working group some straightforward >>> extensions of SPARQL such as adding the set difference operator MINUS, >>> and allowing nesting of ASK queries in FILTER expressions which come >>> basically for free in the approach. >>> >>> * Finally, I discuss an extension towards recursion by allowing >>> bNode-free-CONSTRUCT queries as part of the query dataset, which may >>> be viewed as a light-weight, recursive rule language on top of of RDF. >> >> I think the ASK and CONSTRUCT ideas are very natural. I proposed them >> when I first took a look at SPARQL, >> though my starting point was experience within SQL. > > yes, I mention explicitly that these are "easy wins" in my opinion. FILTER ( ! ASK {pattern} ) would appear to be the same as UNSAID, assuming variables in the pattern are restricted by variables in the outer query and assuming the named variables bound to blank nodes are "told bnodes" for the subquery. Certainly neater than OPTIONAL/!BOUND but I wonder if this is a restricts form of more general subquery. http://www.w3.org/2001/sw/DataAccess/issues#unsaid Bijan Parsia wrote: > Background view: I think this is great stuff, but I suspect the group > is swamped enough without trying to take on this additional chunk of > work. It does suggest that a SPARQL/Next, or SPARQL/Extensions is > worth a continuance. > > I hate making this argument, because, esp. when a group has gone this > long, there is little energy or will to do the "next" bit. And "easy > wins" aren't necessarily so easy to get to spec, as I have to remind > myself over and over again. I agree with that. I'd add that what might appear an "easy win" can block or restrict more general approaches in SPARQL/Next. Andy
Received on Monday, 4 December 2006 14:20:03 UTC