1

Benjamin N. Grosof

MIT Sloan School of Management

50 Memorial Drive

Cambridge, MA 02142, USA

+01 617 253 8694

bgrosof@mit.edu

http://www.mit.edu/~bgrosof


Terrence C. Poon*

Oracle Corporation

500 Oracle Parkway

Redwood Shores, CA 94065, USA

+01 650 506 7000

tpoon@alum.mit.edu

* work done while at MIT


Copyright is held by the author/owner(s).
WWW2003, May 20-24, 2003, Budapest, Hungary.
ACM 1-58113-680-3/03/0005.

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 authors 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 winners 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. Michigans 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 W3Cs 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 Handbooks 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 (KRs) 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.alss 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 Bs 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: