- 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