- 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.
Changhai
From:
Michael Kifer <kifer@cs.sunysb.edu>
To:
"Adrian Paschke" <adrian.paschke@gmx.de>
Cc:
"'Sandro Hawke'" <sandro@w3.org>, Christian De Sainte
Marie/France/Contr/IBM@IBMFR, <public-rif-wg@w3.org>
Date:
28/04/2009 17:05
Subject:
Re: RIF Negation
Sent by:
public-rif-wg-request@w3.org
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
Courbevoie
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