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

Re: [ACTION-18] use case on !ASK in FILTERS to emulate negation

From: Simon Schenk <sschenk@uni-koblenz.de>
Date: Wed, 27 May 2009 07:59:00 +0200
To: Paul Gearon <gearon@ieee.org>
Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, Ivan Mikhailov <imikhailov@openlinksw.com>, Axel Polleres <axel.polleres@deri.org>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-Id: <1243403940.8001.5.camel@tweety>
Am Dienstag, den 26.05.2009, 12:41 -0500 schrieb Paul Gearon:
> On Mon, May 25, 2009 at 12:48 PM, Seaborne, Andy <andy.seaborne@hp.com> wrote:
> <snip/>
> > Simon/Eric - you gave do you have examples where either MINUS or EXISTS can not easily be used where EXISTS or MINUS can?
> >
> > The distinguishing example is helpful - seem to me that MINUS needs a slightly artificial form to introduce ?name to be set-compatible with the preceding pattern.  But is this an artefact of the example and is there a counter example of EXISTs having to be slightly artificial?
> >
> > http://www.w3.org/2009/sparql/wiki/index.php?title=Design:Negation#Distinguish_MINUS_from_UNSAID
> I don't see why you think {?x foaf:name ?name} is needed on the
> right-hand-side of the MINUS to make it compatible. This term
> restricts the set down to only those things that are named, but since
> the query only takes it away from named things anyway, then the result
> can't be any different. Including this term does make the MINUS
> operate on less data, but at the expense of performing an extra join.
> Or is the definition of MINUS here different to the one I'm used to
> (the one implemented in Mulgara)?

I think there are two MINUS' out there: The Mulgara one basically is
UNSAID, if I understand correctly. The SeRQL (and also RQL, I think) one
has a set based semantics. Hence, you really need the same binding set,
including the name, which makes it a bit complicated to use. 

Simon Schenk | ISWeb | Uni Koblenz

Received on Wednesday, 27 May 2009 08:49:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:54 UTC