W3C home > Mailing lists > Public > www-ws@w3.org > July 2003

[SWSL] thoughts on nonmonotonic inheritance wrt SWSI (inline'd and attached too)

From: Benjamin Grosof <bgrosof@MIT.EDU>
Date: Wed, 02 Jul 2003 22:40:41 -0400
Message-Id: <5.1.0.14.2.20030702223325.00b168c0@po12.mit.edu>
To: www-ws@w3.org, swsl-committee@daml.org (Semantic Web Services Language Committee)
Cc: Avi Bernstein <bernstein@ifi.unizh.ch>, John Quimby <quimby@MIT.EDU>, George Herman <gherman@MIT.EDU>, Harold.Boley@nrc.ca, Said Tabet <stabet@attbi.com>, Mike Dean <mdean@bbn.com>, Gerd Wagner <G.R.Wagner@tm.tue.nl>, Andreas.Eberhart@i-u.de, Tom Malone <malone@MIT.EDU>, Grigoris Antoniou <ga@informatik.uni-bremen.de>
% 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.


________________________________________________________________________________________________
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


Received on Wednesday, 2 July 2003 22:41:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:43 GMT