Representing Agent Contracts with Exceptions using XML Rules, Ontologies, and Process Descriptions

and Introduction 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 [cite EC-99, CI-02], we have developed an approach that automates such business contracts by representing and communicating them as modular logic-program rules. That approach, now called SweetDeal, builds upon our situated courteous logic programs (SCLP) knowledge representation in RuleML [cite RuleML], the emerging standard for Semantic Web XML rules that we co-lead. SweetDeal also builds upon our SweetRules prototype system for rules inferencing and inter-operability in SCLP RuleML [cite WITS-01]. Here, we newly extend the SweetDeal approach by also incorporating process knowledge descriptions whose ontologies are represented in DAML+OIL [cite D+O], thereby enabling 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 nonpayment. 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 allows software agents in a peer-to-peer electronic marketplace to create, evaluate, negotiate, and execute such complex contracts with substantial automation. Our approach thus provides a foundation for representing and automating deals about services – in particular, about Web Services, so as to help search, select, and compose them. It thereby points the way to combining Semantic Web techniques [cite SW] with Web Services techniques [cite WS]. Our SweetDeal system is also the first to combine emerging Semantic Web standards for knowledge representation of rules (RuleML) and ontologies (DAML+OIL) with process knowledge for a pragmatic e-business application area. The process knowledge ontology (e.g., about exceptions and handlers) is drawn from the MIT Process Handbook [cite PH], a previouslyexisting 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. Further prototyping of our system is in progress. 1. 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 bidirectional translation from SCLP RuleML to: XSB, a Prolog rule system [cite XSB]; Smodels, a forward logic-program rule engine; the IBM CommonRules rule engine, a forward SCLP system [cite CR]; and Knowledge Interchange Format (KIF, a.k.a. “CommonLogic”), an emerging industry standard for knowledge interchange in classical logic [cite KIF]. The latest component of SweetRules is SweetJess [cite SJ-02], currently being prototyped, which aims to enable bidirectional translation to Jess, a popular open-source forward production-rule system in Java [cite JESS]. 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 [cite CI-02] 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 [cite EC-99] for rules in automated contracts and business policies. The RuleML standards effort is being pursued in informal cooperation with the World Wide Web Consortium’s Semantic Web Activity, which has now included rules in its charter along with ontologies, and with the DARPA Agent Markup Language Program (DAML). 2. Overview of the rest of the paper In section 3, we review the MIT Process Handbook (PH) [cite PH, MS-99], and Klein et al’s extension of it to treat exception conditions in contracts [cite AA-02]. In section 4, we newly show how to represent the Process Handbook’s process ontology (including about exceptions) in DAML+OIL, giving some examples. In section 5, we discuss the inability of DAML+OIL, however, to represent default (i.e., non-monotonic) inheritance -which the PH ontology employs in the general case, just as does C++ and many other object-oriented (OO) systems. (Elsewhere, we will detail how the courteous extension to logic programs provides an alternative knowledge representation tool for properly treating such default inheritance.) In section 6, we describe our development of new additional process ontology specifically about contracts, again giving examples in DAML+OIL. This contract process ontology extends and complements the PH 1 SweetRules is built in Java. It uses XSLT and components of the IBM CommonRules library. process ontology. In section 7, we newly give an approach to using DAML+OIL ontology as the 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 wind up with some discussion including of future work. 3. MIT Process Handbook (PH) In this section, we review the MIT Process Handbook (PH) [cite PH, MS-99], and Klein et al’s extension of it to treat exception conditions in contracts [cite AA-02]. The MIT Process Handbook (PH) [cite PH, MS-99] 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, such as in many Object-Oriented (OO) programming languages, knowledge representations (KR’s) and information modelling 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. 2 a.k.a. “inheritance with exceptions”, a.k.a. “non-monotonic inheritance” Figure: 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 [cite AA-02] 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’s approach. When an exception occurs during contract execution, an exception handler associated with that exception may be invoked. Figure: 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). There are four classes of exception handlers in [cite AA-02]. 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. Figure: Some exception handlers in the MIT Process Handbook. [cite AA-02] 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: Entity relationship diagram for the augmented MIT Process Handbook taxonomy. Process CoordinationMechanism ExceptionHandler Exception hasException