RE: comments please: Approaches to Negation in RuleML

From: Wagner, G.R. ([email protected])
Date: 04/26/03

  • Next message: Mike Dean: "Joint Committee telecon today 29 April"
    some quick comments to your
    > Approaches to Negation in RuleML
    > V1  draft   4/25/2003
    You say that
    > NAF is the most commonly used form of negation in 
    > commercially important rule systems, i.e in Prolog, SQL, 
    > OPS5 production rules, ECA rules.
    Notice that in SQL, and also in UML/OCL, the "official"
    negation is neither NAF nor Boolean (2-valued), but rather 
    Kleene's 3-valued (also called "strong") negation. In 
    addition to this strong negation, there is also NAF, e.g. 
    in the from of the EXCEPT operation. I have a preliminary 
    report on this at
    > The large majority of the knowledgeable LP R&D community,  
    > prefers/recommends the well-founded semantics (WFS) 
    How do you know there is such a majority, was there any vote?
    I'd like to remark that the well-founded semantics is not a
    logical semantics in the classical model-theoretic sense, but
    rather a proof procedure/theory based on certain intuitive
    principles of constructing inferences, which do, however, not
    apply to the more general case of disjunctive logic programs,
    as there is no unique generalization of WFS to disjunctive
    rules. This shows that well-founded inference is a sound but
    incomplete proof calculus with respect to the stable model
    semantics (which applies both to normal and disjunctive
    > It uses a third truth value -- "u" for "undefined" -- for 
    > the nastily oscillatory cases of cyclic dependence
    This is an unfortunate use of a third truth value for
    something where, in fact, no third truth value is needed:
    these "oscillatory cases of cyclic dependence" correspond
    to undecidability in the sense that neither the atom nor
    its negation is provable - but that's not a case where you
    need a third truth value; using a third truth value for
    this purpose is like using a sledge hammer to crack a nut.
    Notice that you do need a third truth value, however, as 
    soon as you introduce a second negation, like in "extended 
    logic programs" (simply because two truth value allow only
    for one negation). 
    > Let us call the strong-negation operator "cneg" or "not", 
    > and the NAF operator "fneg" or "fail".  
    In previous RuleML discussions we used to calle these two
    negations "neg" and "naf", which seems to be more user-
    > The first, and most basic, aspect of the semantic treatment 
    > of strong negation is to view "cneg p", where p is any 
    > predicate, as equivalently standing for another "not_p", 
    > where "not_p" is a newly introduced predicate. Intuitively, 
    > what is going on is that one reasons *separately* about 
    > both "sides" (positive and strong-negative) of each 
    > predicate "p".   
    This is not quite true, because even if one does not enforce
    the law of the excluded middle for "cneg", one does want to
    enforce the law of the excluded contradiction, so one would
    have to make sure that "not_p" excludes "p" (as it is done
    in the semantics of extended logic programs). The most
    general logical treatment of rules with two kinds of negation,
    as far as I know, is
    published in D.M. Gabbay and H. Wansing (Eds.), What is Negation?, 
    Kluwer Academic Publishers, 1999.
    I agree that, ultimately, some form of inconsistency tolerance 
    is needed in an expressive Web rule language, and your proposal
    of "Courteous LP" seems to be an interesting candidate for
    this, but "politically/psychologically" it is more advisable 
    to postpone this issue until the more basic issues have been 
    settled (many people, especially in the "logicist AI" tradition, 
    are scared by the issue of inconsistency tolerance). 
    Best,  G e r d
    Gerd Wagner
    Dep. Information & Technology 
    Eindhoven University of Technology  
    Email: [email protected] 
    Phone: (+31 40) 247 26 17  
    Fax: (+31 40) 247 26 12

    This archive was generated by hypermail 2.1.4 : 04/26/03 EST