ABSTRACT
. SweetDeal is a rule-based
approach to representation of business contracts that enables software agents
to create, evaluate, negotiate, and execute contracts with substantial
automation and modularity. It builds
upon the situated courteous logic programs knowledge representation in RuleML,
the emerging standard for Semantic Web XML rules. Here, we newly extend the SweetDeal approach by also
incorporating process knowledge descriptions whose ontologies are represented
in DAML+OIL (emerging standard for Semantic Web ontologies) thereby enabling
more complex contracts with behavioral provisions, especially for handling
exception conditions (e.g., late delivery or non-payment) that might arise
during the execution of the contract.
This provides a foundation for representing and automating deals about
services – in particular, about Web Services, so as to help search, select, and
compose them. Our system is also the
first to combine emerging Semantic Web standards for knowledge representation
of rules (RuleML) with ontologies
(DAML+OIL) for a practical e-business application domain, and further to do so
with process knowledge. This also newly
fleshes out the evolving concept of Semantic Web Services. A prototype (soon public) is running.
Categories and
Subject Descriptors
I.2.4 [Knowledge Representation Formalisms and Methods]:
Representation languages, Representations (procedural and rule-based); H.4.m [Information
Systems Applications]: Miscellaneous.
General Terms
Design, Theory, Languages, Management,
Standardization, Economics, Human Factors, Algorithms, Documentation.
Keywords
Electronic contracts, electronic commerce, XML,
Semantic Web, Web Services, Semantic Web Services, knowledge representation,
intelligent software agents, rules, logic programs, ontologies, business
process automation, process descriptions, process knowledge, RDF, Description
Logic, DAML+OIL, OWL, knowledge-based, declarative.
_____________________________________________
Copyright is held
by the author/owner(s).
WWW
2003, May 20-24, 2003,
Budapest, Hungary.
ACM1-58113-680-3/03/0005.
_____________________________________________
1. INTRODUCTIONIntroduction
A key
challenge in e-commerce is to specify the terms of the deal between buyers and
sellers, e.g., pricing and description of goods/services. In previous work [1] [2], we have developed
an approach that automates (parts or all of) such business contracts by
representing and communicating them as modular sets of declarative
logic-program rules. This approach
enables software agents to create, evaluate, negotiate, and execute contracts with substantial automation
and modularity. It enables a high
degree of reuse of the contract description for multiple purposes in the
overall process of contracting:
discovery, negotiation, evaluation, execution, and monitoring. That approach, now called SweetDeal, builds
upon our situated courteous logic programs (SCLP) knowledge representation in
RuleML [3], the emerging standard for Semantic Web XML rules that we (first author)
co-lead. SweetDeal also builds upon our
SweetRules prototype system for rules inferencing and inter-operability in SCLP
RuleML [4].[1]
In this paper, we newly extend the SweetDeal approach by also incorporating process knowledge descriptions whose ontologies are represented in DAML+OIL [5]. OWL [30], the emerging Semantic Web standard for ontologies from the World Wide Web Consortium (W3C), is based very closely on DAML+OIL; their fundamental knowledge representation is Description Logic (DL), an expressive fragment of first-order logic, and both encode this syntactically in Resource Description Framework (RDF) [33]. RDF is a somewhat cleaner, simpler, and more expressive language for labeled directed graphs than basic XML, and is itself in turn easily encoded in XML. We chose DAML+OIL because it was more stable during the period we performed this work; indeed, when we began this work, OWL did not yet exist.
Our extension of the SweetDeal approach to incorporate such process descriptions enables more complex contracts with behavioral provisions, especially for handling exception conditions that might arise during the execution of the contract. For example, a contract can first identify possible exceptions like late delivery or non-payment. Next, it can specify handlers to find or fix these exceptions, such as contingency payments, escrow services, prerequisite-violation detectors, and notifications. Our rule-based representation enables software agents in an electronic marketplace to create, evaluate, negotiate, and execute such complex contracts with substantial automation, and to reuse the same (declarative) knowledge for multiple purposes. In particular, our approach provides a foundation for representing and automating deals about services – including about electronic services, e.g., Web Services – so as to help search, select, and compose them. It thereby points the way to how and why to combine Semantic Web techniques [6] with Web Services techniques [7] to create Semantic Web Services [29], a topic which the DAML-Services effort [8] and the Web Service Modelling Framework (WSMF) effort [28] have also been addressing (although not yet much in terms of describing contractual deal aspects).
Our SweetDeal system is also the first to combine emerging Semantic Web standards for knowledge representation of rules (RuleML) with ontologies (DAML+OIL) knowledge for a practical e-business application domain, and further to do so with process knowledge. The process knowledge ontology (e.g., about exceptions and handlers) is drawn from the MIT Process Handbook [9], a previously-existing repository unique in its large content and frequent use by industry business process designers. This is the first time that the MIT Process Handbook has been automated using XML or powerful logical knowledge representation.
This
paper is drawn from a larger effort on SweetDeal whose most recent portion
(second author’s masters thesis) defineds and
implementeds
a software market agent that creates contract proposals in a
semi-automated manner (i.e., in support of a human user) by combining reusable
modular contract provisions, called contract fragments, from a queryable
contract repository with process knowledge from a queryable process
repository. This addresses the negotiation
process in an overall interaction architecture for an agent marketplace with
such rule-based contracts. A prototype of the SweetDeal system is running. We intend to make the prototype publicly
available in the near future.
2. SWEETRULES, RULEML,
SWEETDEAL: MORE BACKGROUND
SweetDeal is part of our larger effort SWEET, acronym for “Semantic WEb Enabling Technology”, and is prototyped on top of SweetRules. Our earlier SweetRules prototype was the first to implement SCLP RuleML inferencing and also was the first to implement translation of (SCLP) RuleML to and from multiple heterogeneous rule systems. SweetRules enables bi-directional translation from SCLP RuleML to: XSB, a Prolog rule system [10]; Smodels, a forward logic-program rule engine [11]; the IBM CommonRules rule engine, a forward SCLP system [12]; and Common Logic (formerly known as Knowledge Interchange Format (KIF)), an emerging ISO industry standard for knowledge interchange in classical logic [13].[2] The latest component of SweetRules is SweetJess [14] which aims to enable bi-directional translation to Jess, a popular open-source forward production-rule system in Java [15]. The SweetJess prototype is publicly available free for Web download.
The SCLP case of RuleML is expressively powerful. The courteous extension of logic programs enables prioritized conflict handling and thereby facilitates modularity in specification, modification, merging, and updating. The situated extension of logic programs enables procedural attachments for “sensing” (testing rule antecedents) and “effecting” (performing actions triggered by conclusions). Merging and modification is important specifically for automated (“agent”) contracts, because contracts are often assembled from reusable provisions, from multiple organizational sources, and then tweaked. Updating is important because a contract is often treated as a template to be filled in. For example, before an on-line auction is held a contract template is provided for the good/service being auctioned. Then when the auction closes, the template is filled in with the winning price and the winner’s name, address, and payment method. Indeed, in [2] we show how to use SCLP to represent contracts in this dynamically updated manner, for a real auction server – U. Michigan’s AuctionBot – and the semi-realistic domain of a Trading Agent Competition about travel packages. More generally, the design of SCLP as a knowledge representation (KR) grew out of a detailed requirements analysis [1] for rules in automated contracts and business policies. The RuleML standards effort is being pursued in informal cooperation with: (1) the W3C’s Semantic Web Activity, which has now included rules in its charter along with ontologies; (2) the DARPA Agent Markup Language Program (DAML) [16]; (3) the Joint US/EU ad hoc Agent Markup Language Committee [31] which designed DAML+OIL; and (4) the Oasis e-business standards body [32].
3. OVERVIEW OF THE REST OF THE PAPER
In
section 4, we review the MIT Process Handbook (PH) [9] [17], and Klein et al.’s extension of it to treat exception
conditions in contracts [18]. In section
5, we newly show how to represent the Process Handbook’s process ontology
(including about exceptions) in DAML+OIL, giving some examples. In section 6, we describe our development
of an additional ontology specifically about contracts, again giving examples
in DAML+OIL. This contract ontology
extends and complements the PH process ontology. In section 7, we newly give an approach to using DAML+OIL ontology
as the predicates predicates, etc., of RuleML
rules. In section 8, we newly show how
to use the DAML+OIL process ontology, including about contracts and exceptions,
as the predicates etc. of RuleML rules, where a ruleset represents part or all
of a (draft or final) contract with exceptions and exception handlers. We illustrate by giving a long-ish example
of such a contract ruleset whose rule-based contingency provisions include
detecting and penalizing late delivery exceptions, thus providing means to
deter or adjudicate a late delivery. In
section 9, we give conclusions. In section 10,
we discuss directions for future work.
\
4. MIT
PROCESS HANDBOOK (PH)
In this
section, we review the MIT Process Handbook (PH) [9] [17], and Klein et al.’’s
extension of it to treat exception conditions in contracts [18].
The MIT
Process Handbook (PH) is a previously-existing knowledge repository of business
process knowledge. It is primarily
textual and oriented to human-readability although with some useful automation
for knowledge management using taxonomic structure. Among automated repositories of business process knowledge, it is
unique (to our knowledge) in having a large amount of content and having been
frequently used practically by industry business process designers from many
different companies. Previous to our
work in SweetDeal, however, its content had never been automated in XML, nor
had that content ever been represented in any kind of powerful logical
knowledge representation – the closest was its use of a fairly conventional
Object-Oriented (OO) style of taxonomic hierarchy, as a tool to organize its
content for retrieval and browsing.
The
Handbook describes and classifies major business processes using the
organizational concepts of decomposition,
dependencies, and specialization. The Handbook models each
process as a collection of activities that can be decomposed into
sub-activities, which may themselves be processes. In turn, coordination is modeled
as the management of dependencies that represent flows of control, data, or
material between activities. Each dependency is managed by a coordination
mechanism, which is the process that controls its resource flow.
Finally, processes are arranged into a generalization-specialization taxonomy, with generic processes at the top and increasingly specialized processes underneath. Each specialization automatically inherits the properties of its parents, except where it explicitly adds or changes a property. This is similar to taxonomic class hierarchies having default inheritance[3], such as in many Object-Oriented (OO) programming languages, knowledge representations (KR’s) and information modeling systems. Note that the taxonomy is not a tree, as an entity may have multiple parents. In general, there thus is multiple inheritance. For example, BuyAsALargeBusiness is a subclass of both Buy and ManageEntity. The figure below shows a part of the taxonomy with some of the specializations for the “Sell” process. Note the first generation of children of “Sell” are questions; these are classes used as intermediate categories, analogous to virtual classes (or pure interfaces) in OO programming languages. Since there is multiple inheritance, it is easy to provide several such “cross-cutting” dimensions of categories along which to organize the hierarchy.
Figure 1: Some specializations of “Sell” in the MIT Process Handbook.
Exception Conditions
The terms of any contract establish a set of commitments between the parties involved for the execution of that contract. When a contract is executed, these commitments are sometimes violated. Often contracts, or the laws or automation upon which they rely, specify how such violation situations should be handled.
Building
upon the Process Handbook, Klein et al.l
[18] consider these violations to be coordination failures – called “exceptions”
– and introduces the concept of exception handlers, which are processes
that manage particular exceptions. We
in turn build upon Klein et al.’al’ss
approach. When an exception occurs
during contract execution, an exception handler associated with that exception
may be invoked.
Figure
2: Some exceptions in the MIT Process Handbook.
For
example, in a given contract (agreement), company A agrees to pay $50 per unit
for 100 units of company B’s product, and B agrees to deliver within 15 days
(commitments). However, due to unforeseen circumstances, when the contract is
actually performed, B only manages to deliver in 20 days (exception). As a
result, B pays $1000 to A as compensation for the delay (exception handler).
Figure
2: Some exceptions in the MIT Process Handbook.
There are four classes of exception handlers in
[18]. For an exception that has not occurred yet, one can use:
·
Exception anticipation processes, which
identify situations where the exception is likely to occur.
·
Exception avoidance processes, which
decrease or eliminate the likelihood of the exception.
For
an exception that has already occurred, one can use:
·
Exception detection processes, which detect
when the exception has actually occurred.
·
Exception resolution processes, which
resolve the exception once it has occurred.
[18]
extends the MIT Process Handbook with an exception taxonomy. Every process may
be associated via hasException links
to its potential exceptions (zero or more), which are the characteristic ways
in which its commitments may be violated. hasException
should be understood as “has potential exception”. Similar to the process taxonomy, exceptions are arranged in a
specialization hierarchy, with generic exceptions on top and more specialized exceptions
underneath. In turn, each exception is associated (via an isHandledBy link) to the processes (exception handlers) that can be used to deal with that exception.
Since handlers are processes, they may have their own characteristic
exceptions.
Figure
3: Some exception handlers in the MIT Process Handbook.[4]
There
are four classes of exception handlers in [18]. For an exception
that has not occurred yet, one can use: