W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: More on MINUS vs. UNSAID

From: Gregory Williams <greg@evilfunhouse.com>
Date: Thu, 9 Jul 2009 13:27:34 -0400
Message-Id: <D88D817F-5253-4A6A-BA28-508D5251995A@evilfunhouse.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
On Jul 8, 2009, at 1:13 AM, Lee Feigenbaum wrote:

> Greg (& someone else?) explained UNSAID today as AntiOptional. I'm  
> wondering if "AntiOptional" is actually the same as MINUS-AntiJoin 
> +Restriction? Can anyone tell?

My (somewhat in jest) support for "AntiOptional" wasn't intended as a  
serious way to think about what UNSAID does. I liked it mostly because  
internally, my implementation of UNSAID differs from my implementation  
of OPTIONAL by only about 5 lines of code. The better way to think  
about it is, as Andy suggests, a filter.

I believe UNSAID is not the same as MINUS-AntiJoin+Restriction.  
Firstly, it seems that the Restriction is different, as UNSAID doesn't  
require intersection of the domains.

Second, I think another difference is going to appear in cases that  
don't make a lot of sense for "real" queries, such as using OPTIONAL  
within an UNSAID/MINUS block. Within an UNSAID block, this should have  
no affect, since OPTIONAL won't affect whether the pattern returns  
zero or some results. However, my (albeit sketch) understanding of  
MINUS-AntiJoin+Restriction is that an OPTIONAL within the MINUS could  
affect the compatibility of the RHS and LHS, if the OPTIONAL was unsafe.

In general, while it seems MINUS might be easier to formulate in  
algebraic terms (see Paul's email), I find that thinking about UNSAID/ 
NOT EXISTS as a filter is conceptually much simpler than the various  
formulations of MINUS we've discussed (though this is clearly a  
personal preference).

Received on Thursday, 9 July 2009 17:28:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC