From: Benjamin Grosof (bgrosof@mit.edu)
Date: 10/28/04
% notes on negation from RuleML telecon 10/28/04 % by Benjamin Grosof The choice of element name for negation was discussed for about 10 minutes on today's 10/28/04 RuleML Steering Committee telecon. participants today: Harold Boley (chairing) Said Tabet Gerd Wagner Michael Kifer Benjamin Grosof %%%% Agenda for that portion of the telecon: [by Harold Boley] Naming Issue: neg or not ------------------------ Peter's partial notes Re: neg or not in SWRL FOL RuleML: "1/ Pat mentioned that neg is not very standard wrt FOL. There was some discussion on whether to change back, Pat and Peter are among the not group. The consensus was to mull this over for a week." In RuleML we decided ca. 2 years ago to have this taxonomy: not (neutral, NL-oriented) neg (strong, technical) naf (nonmon, technical) This was also reflected in: http://www.daml.org/listarchive/joint-committee/1077.html In the SC we decided mid-Sep to go with neg (for classical-strong), as mentioned in my editing suggestions to Peter (which he implemented). Yesterday, Pat stirred up this discussion. %%%% Consensus was reached. The group requested Benjamin to write up his formulation of that consensus and send to both the Joint Committee and RuleML-SC mailing lists. Here it is: In markup tags: neg stands for classical negation in FOL, strong negation in LP naf stands for negation-as-failure, a.k.a. weak negation and default negation Often in a given tool-specific rule/KB editors' presentation syntax/view, however, one could without ambiguity use "not" for negation, because only one form of negation would be available. E.g., in a a normal-LP editor or a FOL-formula editor. People felt pretty strongly that this was the right way to go. Rationale: RuleML supports both LP and FOL KR's and their communities of users. Each community uses "not" to mean negation in both presentation syntax (e.g., Prolog's, KIF) and in natural language. There is thus a need to disambiguate syntactically, by using distinct markup element tagnames other than "not", for several reasons: 1. It reduces chances of confusion by implementers/developers and users. Remember, users will tend not to see actual markup, but it's helpful to force implementers/developers to think about which form/semantics of negation is at hand. 2. It is essential in extensions of LP, such as Courteous LP, that employ both negation-as-failure and classical negation. 3. It's generally the clean way to do things. We want to avoid having two semantically similar but different expressive constructs being named the same thing within the RuleML family of sublanguages. 4. It clarifies the semantics of merging KB's. Using technical names in the markup, rather than the familiar natural language term "not", forces implementers/developers -- who are the main people dealing directly with markup rather than users -- to think about which form/semantics of negation is at hand. ________________________________________________________________________________________________ Prof. Benjamin Grosof Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules, XML, Agents, Semantic Web Services MIT Sloan School of Management, Information Technology group http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof
This archive was generated by hypermail 2.1.4 : 10/28/04 EST