. 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.
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  , 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 , 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
In this paper, we newly extend the SweetDeal approach by also incorporating process knowledge descriptions whose ontologies are represented in DAML+OIL . OWL , 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) . 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  with Web Services techniques  to create Semantic Web Services , a topic which the DAML-Services effort  and the Web Service Modelling Framework (WSMF) effort  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 , 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.
paper is drawn from a larger effort on SweetDeal whose most recent portion
(second authors masters thesis) define
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.
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 ; Smodels, a forward logic-program rule engine ; the IBM CommonRules rule engine, a forward SCLP system ; and Common Logic (formerly known as Knowledge Interchange Format (KIF)), an emerging ISO industry standard for knowledge interchange in classical logic . The latest component of SweetRules is SweetJess  which aims to enable bi-directional translation to Jess, a popular open-source forward production-rule system in Java . 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  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  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) ; (3) the Joint US/EU ad hoc Agent Markup Language Committee  which designed DAML+OIL; and (4) the Oasis e-business standards body .
3. OVERVIEW OF THE REST OF THE PAPER
section 4, we review the MIT Process Handbook (PH)  , and Klein et als extension of it to treat exception
conditions in contracts . 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
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.
PROCESS HANDBOOK (PH)
section, we review the MIT Process Handbook (PH)  , and Klein et al
extension of it to treat exception conditions in contracts .
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, 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.
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.
upon the Process Handbook, Klein et a
 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
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).
are four classes of exception handlers in . For an exce p tion
that has not occurred yet, one can use: