- From: Adrian Paschke <adrian.paschke@gmx.de>
- Date: Tue, 28 Apr 2009 14:39:40 +0200
- To: "'Paul Vincent'" <pvincent@tibco.com>, "'Sandro Hawke'" <sandro@w3.org>
- Cc: "'Christian De Sainte Marie'" <csma@fr.ibm.com>, <public-rif-wg@w3.org>
Yes, <Not> could be a polymorphic negation which is semantically overloaded depending on the RIF dialect. -Adrian -----Ursprüngliche Nachricht----- Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im Auftrag von Paul Vincent Gesendet: Dienstag, 28. April 2009 14:35 An: Sandro Hawke; Adrian Paschke Cc: Christian De Sainte Marie; public-rif-wg@w3.org Betreff: RE: RIF Negation Wichtigkeit: Niedrig Comment 1: The idea of using "not" is that, even though the semantics are overloaded for PRD, it has the same "basic" meaning, and there is some interchange of terms for cross-dialect use, and it is the default term for vendor implementations of PR languages. If the argument against "not" is that every dialect needs to be explicitly mutually exclusive from a "dialect semantics" perspective, doesn't that apply to (and condemn) RIF as a whole, as surely there are other more fundamental areas where we are "overloading" for dialect usage (e.g. consider PRD semantics for rules)? Comment 2: If RIFWG votes on separate terms for every semantic distinction (for "not" anyway), then using my bible of classical logic (er, Wikipedia) I see one should use ¬ for "logical not" and not for "PRD not" :) forall ?x if ¬( ex:p(?x)) then ex:q(?x) Paul Vincent TIBCO Software > -----Original Message----- > From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] > On Behalf Of Sandro Hawke > Sent: 28 April 2009 13:05 > To: Adrian Paschke > Cc: 'Christian De Sainte Marie'; public-rif-wg@w3.org > Subject: Re: RIF Negation > > > Right, probably it makes sense to have explicit constructs for > > > > Explicit/Strong/Classical negation Neg > > Default/Negation-as-failure/Weak/Inflationary Not > > If those are the only two we need, I think I'd call them > > Explicit/Strong/Classical negation not > Default/Negation-as-failure/Weak/Inflationary fail > > I could also see calling classical negation isFalse, but I'm not really > comfortable calling NAF "not", since um, it's not. :-) (In my > experience, most prolog educational material advises against calling it > "not" because it ends up misleading too many users. For instance, the > SWI-Prolog manual [1] for says: > > not(+Goal) True if Goal cannot be proven. Retained for > compatibility > only. New code should use \+/1. > > and, while XSB also has "not", it also has "\+" and "fail_if", and I > read the document for "not" to suggest it is mildly deprecated [2] > > -- Sandro > > [1] http://www.swi-prolog.org/pldoc/doc_for?object=not%2f1 > [2] http://xsb.sourceforge.net/manual1/node111.html#8424 > > > > -Adrian > > > > -----Urspr=FCngliche Nachricht----- > > Von: Sandro Hawke [mailto:sandro@w3.org]=20 > > 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*=20 > > > > > > > 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
Received on Tuesday, 28 April 2009 12:40:21 UTC