% this version's date: 7/2/03 Thoughts on nonmonotonic inheritance wrt SWSI by Benjamin Grosof This in response to my action item from 6/26/03 SWSL telecon. Outline: 1. draft of bullet item about it for requirements 2. example of nonmonotonic inheritance about process modeling 1. Draft of bullet item about nonmonotonic inheritance for SWSL requirements o Enable representation of *default* inheritance of properties, roughly in the manner commonly employed in object-oriented approaches to process modeling and data modeling, e.g., in frame-based systems, C++, and Java. "Default" here means that a property's value inherited from a superclass may be overridden with a new value, or simply cancelled (i.e., not inherited). Default inheritance cannot be represented in Description Logic, notably OWL, since that is logically nonmonotonic. However, it can be represented in LP rules (with negation-as-failure and/or priorities), notably RuleML. 2. Example of nonmonotonic inheritance about process modeling This example drawn from a preliminary draft of my work (joint with Avi Bernstein) on representing the inheritance mechanism of the MIT Process Handbook. Our approach is to use Semantic Web (SW) rules / ontologies KR, i.e., RuleML and OWL. (NB: the PH actually spawned PIF and thus PSL) The MIT Process Handbook (PH) is a large repository of business process design knowledge built up over the last 8 years or so; it contains thousands of business processes and concepts and has been used by a number of actual industrial business process designers as well as for research projects. In previous work [1], we have given an approach and an application for representing and employing its knowledge for e-contracting purposes, using RuleML and OWL. An effort is currently underway to make much of the Process Handbook available under an open source license. Its content, when translated using SW techniques such as what we are currently developing, thus offers the potential to become an important open repository of ontological knowledge about realistic, practical business processes, and thus SW service descriptions. The following example is adapted and simplified from the content of the current PH but captures the essence of its mechanism/representation of inheritance. A typical kind of process represented in the PH is Sell, i.e., the process of selling a product. Formally, Sell is said to be an class that is a subclass of Activity. Every activity can have subtasks. In particular, Sell has three subtasks: Identify-prospects, Make-deal, and Fulfill-deal. Formally, each of these subtasks has an associated slot id. Each of the subtasks is an Activity. (Realistically, these subtasks must be composed/performed with sequential dependency, but again for simplicity's sake we omit that aspect here.) class(Sell); subclassof(Sell,Activity); subtask(Sell, slot-1, Identify-prospects); /* find sales prospects */ subtask(Sell, slot-2, Make-deal); subtask(Sell, slot-3, Fulfill-deal); subclassof(Identify-prospects,Activity); subclassof(Make-deal,Activity); subclassof(Fulfill-deal,Activity); E-Sell, i.e., the process of selling electronically (on-line), is a subclass of Sell. subclassof(E-Sell,Sell); E-Sell should inherit these three subtasks from Sell. I.e., the following entailments are desired: |= subtask(E-Sell, slot-1, Identify-prospects); |= subtask(E-Sell, slot-2, Make-deal); |= subtask(E-Sell, slot-3, Fulfill-deal); UI-Sell, i.e., the process of selling electronically to customers once they are already interacting within a particular user interface, is a subclass of E-Sell. subclassof(UI-Sell,E-Sell); For UI-Sell, (suppose) one wishes to specify that there is NO subtask of Identify-prospects, since within the given UI, there is exactly one relevant prospect, namely the user. (This is typically a rather opportunistic kind of selling.) One thus wishes to CANCEL the inheritance of Identify-prospects as slot-1's value. The PH currently calls this "removing" the inheritance of that subtask slot. remove-inheritance-of(UI-Sell,slot-1); The following NON-entailment is thus desired: |=/= subtask(E-Sell, slot-1, Identify-prospects); Brick-Sell, i.e., the process of selling in a physical ("bricks and mortar") store to visitors -- i.e., candidate customers -- who are already physically in the store, is also a subclass of Sell. subclassof(Brick-Sell, Sell); For Brick-Sell, (suppose) one wishes to specify that its first subtask is Engage-visitors -- i.e., chat up visitors to engage them in dialogue -- rather than Identify-prospects. One thus wishes to OVERRIDE the inheritance of Identify-prospects as slot-1's value, and REPLACE that value instead with Engage-visitors. replace-inheritance-of(Brick-Sell,slot-1,Engage-visitors); subclassof(Engage-visitors,Activity); The following entailment is thus desired: |= subtask(Brick-Sell, slot-1, Engage-visitors); And the following corresponding NON-entailment is desired as well: |=/= subtask(Brick-Sell, slot-1, Identify-prospects); This new value should itself be inheritable by further subclasses. E.g., Brick-Sell-Bicycle, i.e., brick-selling a bicycle, is a subclass of Brick-Sell. subclassof(Brick-Sell-Bicycle,Brick-Sell); The following entailment is desired: |= subtask(Brick-Sell-Bicycle, slot-1, Engage-visitors); By providing various background rules and using the KR of Courteous LP RuleML, in our approach we are able to represent the above knowledge, including the desired entailments / non-entailments. References: [1] Grosof, B.N. and Poon, T.C., "SweetDeal: Representing Agent Contracts with Exceptions using XML Rules, Ontologies, and Process Descriptions", Proc. WWW-2003.