W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2006

Re: Prototype SPARQL engine based on Datalog and relation of SPARQL to the Rules Layer

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 04 Dec 2006 14:19:44 +0000
Message-ID: <45742E80.3080606@hp.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:51 GMT