In the SWS vision (see http://www.swsi.org),
semantic service
descriptions, i.e., process knowledge represented using Semantic Web
(SW) KR, will enable various kinds of reasoning in support of several
key tasks including advertising/discovery, matchmaking,
negotiation/contracting, composition, execution monitoring, etc., of
Web Services. Some early, relatively simple SWS prototypes
have already been developed. To realize the whole vision,
however, SWS developers will need large amounts of process knowledge
that is represented declaratively, i.e., in semantically clean fashion
cf. SW KR. A key
part of process knowledge is ontological: definitional
knowledge in the form of class hierarchies (where some (sub)classes are
specializations of superclasses) and property information associated
with those classes. A central kind of reasoning in ontologies
is inheritance, in which each subclass (specialization) inherits the
values of the properties associated with its superclasses
(generalizations). In monotonic inheritance, a subclass can add new
properties and/or property values. Inheritance is useful
since it enables reuse: to specify a new subclass’s
set of associated property info – one can just specify the
differences from its superclass(es)’s property info.
Experience in the Process Handbook (PH) project, which has been under
development at the MIT Center for Coordination Science (CCS)
for over
ten years, including the contributions of a diverse and highly
distributed group of over 40 scientists, students and industrial
sponsors [Process Handbook]
[Malone99]
has shown that in practice
users of inheritance often – perhaps,
usually –
desire non-monotonic
inheritance,
which is more
general. In
non-monotonic inheritance, unlike monotonic inheritance, one can change
what’s inherited: either to replace/override (i.e.,
modify) or to
cancel (i.e., delete) an inherited property value.
Non-monotonic
inheritance is a.k.a. default inheritance or inheritance with
exceptions. Permitting inheritance to be non-monotonic
enables more
reuse/modularity. When inheritance is restricted to be
monotonic, if
one needs to change (both override or cancel) some inherited property
info,
then one has to manually/explicitly repeat the specification of much or
all of the property info that one wants to reuse from
previously-defined classes, without benefit of
inheritance.
Non-monotonic inheritance thus enables easier specification:
not only
initially but also especially during updating and merging (e.g., in
maintenance). Non-monotonic inheritance is found ubiquitously
in object-oriented
programming languages and design tools, including Java, C++, and the
PH.
Consequently, the experience
within the PH project has reconfirmed findings [MacLean90]
that allowing cancellation aids ease of understanding/specification.
OWL [VanHarmelen03]
can represent expressively
complex
kinds of monotonic inheritance but
is fundamentally incapable of
representing any kind of non-monotonic reasoning, including
non-monotonic inheritance.
The same is true for most classical first-order reasoning mechanisms in
use within all the semantic web services initiatives we are aware of.
Our position, which is supported by the findings of the Process
Handbook project as well as two decades of experience with
object-oriented programming, is therefore, that it
is imperative that semantic web services description languages have to
support non-monotonic inheritance to preserve the ease of use while
maintaining an bounded acceptable reasoning complexity.
As such we point out the drawbacks of current semantic web-service
description languages, which are based on OWL, while proposing a
remedy,
which we implemented in SWSL-Rules [ Grosof2005, http://www.daml.org/services/swsl/report/].
To further support our position the remainder of this paper provides an
example of a simple use of non-monotonic inheritance in an application
scenario, which can be used for service discovery, service execution,
service composition, contract formation and negotiation, as well as
contract or process monitoring and exception handling.

The SWSL Ontology is a core
service ontology. However, it is also often useful to represent other,
e.g., domain-specific,
ontologies as well.
Such ontologies might be represented in SWSL-Rules or in SWSL-FOL. An
important and frequently-found flavor of domain-specific service
ontologies is object-oriented framework knowledge of the kind found in
software class hierarchies specified in object-oriented programming
languages or in AI frame-based systems.
In such object-oriented framework knowledge the values of a property P
of a (super)class (say, C1) are inherited by each of its subclasses
(say, C2). These subclasses are known as the specializations
of the parent
(super)class. For example, the property P might be a data attribute or
a method definition. This inheritance is default
in nature/flavor:
explicitly specified information about the property for the subclass
may
override -- or cancel -- the inheritance. Such default inheritance, and
thus such an ontology, is logically non-monotonic. They thus cannot be
represented in SWSL-FOL. However, they can be represented
in SWSL-Rules, e.g., using the Courteous
Inheritance approach of [Bernstein2003]
[Grosof2004d]
(see also [Yang02]
for an analogous approach).
In that approach, such ontology is represented using the Courteous
Logic Programs knowledge representation,
i.e., the Courteous feature of SWSL-Rules, along with a set of
approximately 20 generic background rules (in that KR) that axiomatize
the generic behavior of default inheritance.
In this section, we next give
an example, called the Sell
Product example, of such a
domain-specific
service ontology, using that Courteous Inheritance approach. The
ontology is about the Sell Product business process
and a few of its specializations. The form and domain of this
ontology are similar to those in the Process
Handbook [Process Handbook]
[Malone99].
This kind of ontology is
useful for business process modeling and
design,
and thus is useful -- along with other rules knowledge -- for a number
of SWS tasks, including:

The example is a reformatted variant of the example in [Bernstein2003],
where we give an
approach to representing default inheritance about process ontologies
in terms of Courteous Logic Programs. Another approach to
representing default
inheritance in a similar spirit is shown in [Yang02]
who use Logic Programs with NAF(negation as failure) but
without Courteous, instead defining special constructs
that extend the LP KR (logic programs knowledge representation).
Below, we give an approach similar in spirit to both of the above, that
is relatively simple -- simple enough for a self contained brief
presentation here -- although lacking some of the advantages and
subtleties of the above two approaches.

Modeling the parent service
"Sell Product"

Suppose we need to design
a sales process that is used in an organization in two
ways. One version is used in a mail-order business and the other
in a retail store. First, we need to model a generic sales
process for which one can find a template in a process repository
(e.g., the Process Handbook). The "Sell product"
service consists of five subtasks: "Identify potential customers,"
"Inform potential customers," "Obtain Order," "Deliver product ," and
"Receive payment." In this example, we do not model any sequencing
dependencies between the subtasks.

One way to represent this
situation is to treat the main service as a class and its subtasks as
attributes (note that the semantics of the notation used here is
defined via a transformation to non-monotonic logic programs [Bernstein2003, Yang02]):

Here the attribute names
represent the names of the subtasks and the values of these attributes
are the names of the actual procedures to be used to perform these
tasks. These procedures can be written in a procedural programming
language, such as Java, or even in SWSL-Rules [Grosof2005].
For
instance,

Some of the formulas in the
body of the above rule could be purely declarative and be defined by
other rules in the knowledge base (e.g., genericFindCust)
while others could have side effects in the physical world (such as generateFlyer
and informMailRoom).
Such side-effectful statements are not currently part of SWSL-Rules,
but they are planned for future extensions.

Note that the method genericFindCust
returns a set
of customers (based on some marketing criteria), and the method genericFindCust
is executed for each
such customer.

Overriding and Canceling
Inherited Features

Continuing the example, we
specify the "Sell by mail order" and "Sell
in retail
store" services as subclasses of the "Sell Product" process, as shown
in Figure 1.

Figure 1: The "Sell Product"
service with
two subclasses. The grayed out subtasks are overwritten
with more specific alternatives; the subtask with the red cross is
deleted ("canceled").

This subclassing approach
has several advantages. First, it provides a simple way
of reusing the elements already defined in an object-oriented manner.
Second,
taxonomic organization of processes has been found
useful for human browsing [Malone99].

For "Sell by mail order,"
inheritance of three of the subtasks
of the parent service "Sell product" is
overwritten by other subtasks, and two subtasks are inherited.
For "Sell in retail store", one subtask is inherited, inheritance of
three
others is overwritten, and one subtask is "canceled" (i.e., is no
longer
defined for the subsprocess).

Since nonmonotonic
inheritance
is one of the basic concepts of SWSL-Rules, modeling of the service
"Sell by mail order" is straightforward. First, we need to specify it
as a subclass of SellProduct.
Then we need to explicitly define the three overwritten subtasks and
provide new values (new procedures) for them. We do not need to mention
the two tasks that are inherited:

Because of the overriding in
the SellByMailOrder
subclass, the subtask informCustomers
is no longer performed using the previously defined method genericInformCust.
Instead, the method junkmailAds
is used; it could be defined in SWSL-Rules as follows:

To model the "Sell in retain
store" we first specify a new subclass of
the
"Sell Product" service. According to the figure, this subclass inherits
the deliverProduct
attribute, while three other attributes, identifyCustomers,
obtainOrder,
and receivePay,
are overwritten.
This is modeled similarly to the SellByMailOrder
subclass:

The more interesting case is
the cancellation of the informCustomers
attribute. One way to achieve this is to introduce a special null
subtask and use it to override inheritance of the genericInformCust
procedure. A more interesting way it to take advantage of the semantics
of multiple inheritance
in SWSL-Rules according to which conflicting multiple inheritance for
the same attribute makes the value undefined. To achieve this, we can
introduce a family of classes parameterized by the features that need
to be canceled:

FeatureTerminator(?Feature)[?Feature *-> null].

For each concrete attribute,
the above statement says that the value of that attribute in the
corresponding class is null.
As a special case (when ?Feature
= informCustomers), the value
of the attribute informCustomers
in class FeatureTerminator(informCustomers)
is null. To cancel the inheritance of informCustomers
we now need to add the following fact:

SellInRetail::FeatureTerminator(informCustomers).

With this statement, SellInRetail
becomes a subclass of two classes, SellProduct
and FeatureTerminator(informCustomers).
Each of these classes has an explicit definition of the attribute informCustomers,
but those definitions are in conflict. According to the semantics of
inheritance in SWSL-Rules, this makes the value of informCustomers
in class SellInRetailundefined
and thus the inheritance of that attribute is "canceled."

As the example shows the use of non-monotonic and canceling
inheritance provides the means to elegantly model the "Sell product"
example. Modeling the
example in a monotonic setting would have
required either required a refactoring of the ontology resulting in the
removal of information (i.e., assertions) from the ontology, which
would result in a poorer basis for reasoning about the problem domain,
or the use of other modeling approaches, which would reduce the
understandability of the ontology to users.
Consequently, it
is imperative that semantic web services description languages have to
support non-monotonic inheritance to preserve the ease of use while
maintaining tractability
(the latter is shown in [Grosof2004a]).
We believe that to attain the expressability desired one needs to use
non-monotonic LP (logic programs) to that end, as we did in the SWSL-Rules
language.