SWSO is a core service ontology and is domain-independent. However, it is often necessary to represent domain-specific ontologies. Such ontologies might be represented in SWSL-Rules or in SWSL-FOL. An important and frequently-used flavor of domain-specific service ontologies uses the object-oriented framework of the kind found in object-oriented programming languages and in AI frame-based systems. In such frameworks, the values of a property P of a superclass are inherited by each of its subclasses. These subclasses are known as the specializations of the parent superclass. For example, the property P might be a data attribute or a method definition. This inheritance has default flavor: explicitly specified information about the property for the subclass overrides -- or cancels -- the inheritance. Such default inheritance (and, by extension, such an ontology) is logically nonmonotonic and cannot be represented in SWSL-FOL. However, it can be represented in SWSL-Rules, which is object-oriented and includes inheritance as a basic feature.
To illustrate this point, we give an example of a service, Sell Product, which relies on such a domain-specific service ontology. The ontology describes a Sell Product business process and a some of its specializations. The form and domain of this ontology are similar to those found 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 knowledge -- for a number of SWS tasks, including:
In [Bernstein2003]
we introduced an example about Sell Product. The example below is
adapted from that. There we give an
approach to representing default inheritance about process ontologies
in terms of Courteous LP. Another approach to representing default
inheritance in a similar spirit is shown in [Yang02]
who use LP
with NAF but
without Courteous, instead defining special constructs
that extend the LP KR.
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.
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:
SellProduct[
identifyCustomers *-> genericFindCust,
informCustomers *-> genericInformCust,
obtainOrder *-> genericGetOrder,
deliverProduct *-> genericDeliver,
receivePay *-> genericGetPay
].
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. For instance,
?Product[genericInformCust] :-
?Product[genericFindCust -> ?Cust] and
generateFlyer(?Cust) and
informMailRoom.
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.
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 6.1.
Figure 6.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:
SellByMailOrder::SellProduct[
identifyCustomers *-> obtainMailLists,
informCustomers *-> junkmailAds,
obtainOrder *-> getOrderByMail
].
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:
?Product[junkmailAds] :-
?Product[obtainMailLists -> ?List] and
?List[address -> ?Addr] and
affixLabelToAd(?Addr) and
informMailRoom.
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:
SellInRetail::SellProduct[
identifyCustomers *-> attractToBrickAndMortar,
obtainOrder *-> getOrderAtRegister,
receivePay *-> getPayAtRegister
].
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 SellInRetail
undefined
and thus the inheritance of that attribute is "canceled."
Next, suppose that we need to extend the repertoire of selling services with a third process, "Sell electronically," which can be executed electronically.
Figure 6.2: The "Sell Product" service with three subclasses; the third subclass has an exception handler.
Figure 6.2 shows that the new process has an exception attached to the second subtask "Inform potential customers by email" in order to addresses the issue of unwanted email solicitations. The exception permits people to remove themselves from the mailing list by putting their addresses on the opt-out list.
Inheritance and overriding of the attributes from the parent class is modeled as before:
SellElectronically::SellProduct[
identifyCustomers *-> obtainByDataMining,
informCustomers *-> informByEmail,
obtainOrder *-> getOrderByEMail
].
The method informByEmail
could be defined as follows:
?Product[informByEmail] :-
?Product[obtainByDataMining -> ?Email] and
sendEmail(?Email).
One way to incorporate the
opt-out exception to the general policy is by adding the premise naf
optOutList(?Email) to the
body of the above rule. However, this approach is not modular, since it
requires modification of the existing rules (the method informByEmail
may have already been defined). Even if it were acceptable to make this
change now, further changes to the opt-out policy might require
additional changes to the existing rules. A more scalable approach is
to express the above opt-out exception using constraints, and this is
where the mutex
primitive of the Courteous
layer of SWSL-Rules comes in:
!- sendEmail(?Email) and optOut(?Email).
This constraint says that sendEmail(?Email)
and optOut(?Email)
cannot be true together for the same individual. For people who put
their names on the opt-out list, optOut(?Email)
will be true and, therefore, sendEmail(?Email)
will be false. On the other hand, for an email address, e,
that is not found on the opt-out list, the corresponding predicate
predicate optOut(e)
will not be provable and, by negation-as-failure, optOut(e)
will be assumed false. Therefore, sending email to that address will
not be blocked.