% 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.