W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

Re: RIF Negation

From: Changhai Ke <changhai.ke@fr.ibm.com>
Date: Tue, 28 Apr 2009 17:47:50 +0200
To: kifer@cs.sunysb.edu
Cc: "Adrian Paschke" <adrian.paschke@gmx.de>, Christian De Sainte Marie <csma@fr.ibm.com>, public-rif-wg@w3.org, public-rif-wg-request@w3.org, "'Sandro Hawke'" <sandro@w3.org>
Message-ID: <OF25C7DB59.1AB846B6-ONC12575A6.0055056F-C12575A6.0056C6BD@fr.ibm.com>
Hello all,

In short, I'm in favor of using "not" as an XML tag in PRD.

But the result of applying "not" ought to be specified. In PRD 1.0, let's 
use the "binary logic", which means that "applying not to false yields 
true", and "applying not to true yields false". Most of the production 
engines support this.

In the future, it makes sense to have "ternary logic". Basically, this 
means for production rule engines to have the notion of "unknown". For 
example the "age" of the customer, or the "category" of a membership can 
be "unknown".

If you write a test: (customer.age > 50), and customer's age is unknown, 
the test result will be unknown. Similarily, the test (not (customer.age > 
50)) still produces "unknown" value, as well as the test (customer.age <= 
50) which is also unknown. Then a production rule engine could adopt a 
behavior, which will be whenever the condition part yields unknown, do not 
apply the rule (which simply means that we consider the condition part as 
false). This is fairly straight.

In PRD 1.0, let's go for the binary logic "not", which is the most basic 
form. In the future, with the introduction of "unknown", we could switch 
to ternary logic, without changing the "not" tag in the XML.


Michael Kifer <kifer@cs.sunysb.edu>
"Adrian Paschke" <adrian.paschke@gmx.de>
"'Sandro Hawke'" <sandro@w3.org>, Christian De Sainte 
Marie/France/Contr/IBM@IBMFR, <public-rif-wg@w3.org>
28/04/2009 17:05
Re: RIF Negation
Sent by:

FLD uses Naf for default negation.

On Tue, 28 Apr 2009 13:52:56 +0200
"Adrian Paschke" <adrian.paschke@gmx.de> wrote:

> Right, probably it makes sense to have explicit constructs for
> Explicit/Strong/Classical negation                Neg
> Default/Negation-as-failure/Weak/Inflationary     Not
> -Adrian
> -----Ursprüngliche Nachricht-----
> Von: Sandro Hawke [mailto:sandro@w3.org] 
> Gesendet: Dienstag, 28. April 2009 13:34
> An: Adrian Paschke
> Cc: 'Christian De Sainte Marie'; public-rif-wg@w3.org
> Betreff: Re: AW: [Admin] Agenda for RIF telecon 28 April *ADDENDUM* 
> > We discussed it in the last PRD telecon. The semantics of a generic
> > "not" in case of PRD is clear since it used in a production rule set,
> > i.e. it is inflationary not.
> But is it also classical negation and NAF?  In particular, if I have
> this ruleset:
>    forall ?x
>       if not ex:p(?x) then ex:q(?x)
> this proposal defines that as a PRD ruleset.  To my eye, it could just
> as easily be FOL or LPD.  As long as the semantics in all cases would be
> the same, they could all use the same "not", but otherwise, it seems
> like they need to use different operators.
> > Alternative we could introduce many different constructs for
> > negations, but this might be counterproductive to the interchange
> > purpose of RIF. I would propose that the intended semantics of a rule
> > set such as stratified, well-founded, stable models, is denoted by a
> > special label (e.g. an attribute or additional construct) for the rule
> > set and not by different constructs for negations. Otherwise a simple
> > (business) rule set cannot be interchanged between a WFS rule engine
> > and a Stable rule engine without a translation.
> How would that work?  If a ruleset was labeled
> "use-well-founded-semantics" and I was a "stable-semantics" engine, what
> would I do with it?
>      -- Sandro

    -- michael

Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 €
SIREN/SIRET : 552 118 465 02430

Received on Tuesday, 28 April 2009 15:49:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:55 UTC