A declarative approach to business rules in contracts : courteous logic programs in XML

x\|^

HD28

.M41A

i^

Business

uL

MIT

MIT

Sloan

School

of

Management

Sloan

Working

Paper

4187-01

eBusiness@MIT

Working

Paper

113

October

2001

A

DECLARATIVE

APPROACH

TO

BUSINESS

RULES

IN

CONTRACTS:

COURTEOUS

LOGIC

PROGRAMS

IN

XML

Benjamin

Grosof,

Yannis

Labrou,

Hoi

Y.

Chan

This

paper

is

available

through

the

Center

for

eBusiness@MIT web

site at

the

following

URL:

http://ebusiness.mit.edu/research/papers.html

This

paper

also

can be

downloaded

without

charge

from

the

Social

Science

Research

Network

Electronic

Paper

Collection:

A

Declarative

Approach

to

Business

Rules

in

Contracts:

Courteous

Logic

Programs

in

XML

*

Benjamin

N.

Grosof

IBM

T.J.

Watson

Research

Center,

P.O.

Box

704,

Yorktown

Heights,

NY

10598,

USA

grosof@us

.

ibm.

com

(alt.:

grosof

@cs .Stanford,

edu)

http

:

//www

.

research

.

ibm.

com/people/g/grosof

/

Yannis

Labrou

Computer

Science

and

Electrical

Engineering

and Department

University

of

Maryland, Baltimore County,

Baltimore,

MD

21250,

USA

j

klabrouOcs

.

urnbc

.

edu

http

:

//www.

cs

.umbo

.

edu/~

jklabrou/

Hoi

Y.

Chan

IBM

T.J.

Watson

Research

Center,

RO.

Box

704,

Yorktown

Heights,

NY

10598,

USA

hychanOus

.

ibm

.

com

Abstract

We

address why, and especially how, to represent

business rules in

e-commerce

contracts.

By

con-tracts,

we mean

descriptionsofgoods andservices

offered or sought, including ancillary agreements

detailmg tenris ofa deal.

We

observe that rules

areusefulin contractstorepresent conditional

rela-tionships,e.g., interms

&

conditions, service

provi-sions, and surroundingbusiness processes, and

we

illustrate thispointwith severalexamples.

We

analyze requirements (desiderata) for

repre-senting such rules in contracts.

The

require-ments mclude: declarative semantics so as to

en-ablesharedunderstanding andinteroperability;

pri-oritized conflict handling so as to enable

modu-lar updating/revision; ease ofparsing; integration

into

WWW-world

software engineering;directe

x-ecutabihty;and computationaltractability.

We

give a representational approach that consists

of

two

novel aspects. First,

we

give a

new

fun-damental

knowledge

representation formalism: a

generalized version

_of

Courteous Logic

Programs

(CLP), which expressively extends declarative

or-dinarylogic programs

(OLP)

toincludeprioritized

conflicthandling, thus enablingmodularityin

spec-ifying and revisingrule-sets.

Our

approach to im-plementing

CLP

isacourteouscompilerthat

trans-Copyright

ACM.

To appear: Proceedings of the

1st

ACM

Conference on Electronic

Commerce

(EC99),

to be held Denver, Colorado,

USA,

Nov. 3-5, 1999.

Edited by Michael

R

Wellman.

New

York, NY:

ACM

Press, 1999.

http://www.ibm.com/iac/ec99/

or

hccp; //www. acm.org.

forms any

CLP

intoasemantically equivalent

OLP

withmoderate,tractablecomputationaloverhead.

Second,

we

give a

new

XML

encoding ofCLP,

called BusinessRules

Markup

Language

(BRML),

suitable for interchange between heterogeneous commercial rule languages.

BRML

can also

ex-press abroad subseto fANSI-draft

Knowledge

In-terchange

Format

(KIF)

which

overlapswith CLP,

Our

new

approach, unlike previous approaches,

provides not only declaratives emantics but also

prioritized conflict handling, ease ofparsing, and

integration into

WWW-world

software

engineer-ing.

We

argue that this

new

approach meets the

overall requirements to a greater extent than any

ofthepreviousapproaches, including than KIF, the

leadingprevious declarative approach.

We

have

implemented

both aspects of our

ap-proach; a free alpha prototype called

Common-Rules

was

released

on

the

Web

inJulyof1999,at

http

:

//alphaworks

.

ibm.

com.

An

extended version ofthis paper will be

avail-able as afo rthcoming

IBM

Research Report (at

http

:

//www.

research

.

ibm.

com).

1

Introduction

One

form of

commerce

thatcouldbenefitsubstantially from automation iscontracting,whereagentsformbinding.a

gree-able terms, and then execute these terms.

By

"agents",

we

mean

initially parties inthe

Economics

sense,e.g., asbuyers or sellers; however, once automated, these agents might be

By e-commerce

"contracts",

we

mean

inabroadsense:

de-scriptions

otgoods

andservices offered or sought,alongwith

applicable terms

&

conditions, i.e., ancillaryagreements

de-tailing teniis ofadeal.

Such

terms includecustomerservice

agreements, delivery schedules, conditions forreturns,usage

restrictions, and other issues relevant to the

good

or service provided.

Such descriptions are to be found in catalogs and

store-fronts,as well asinbidsandrequests

communicated

(e.g.,by

agents)during negotiations,procurements,andauctions.

The

overall contracting process comprises several stages,

including broadly:

1

.

Discovery: Agentsfind potential contractingpartners.

2. Negotiation: Contract terms are detemiined through a

processof

communication

betweenagents,often

involv-ingiterativemodificationofthecontract terms.

3. Execution: Transactions and other contract provisions

areexecutedbythe agents.

We

observe that

many

contract terms involve conditional

relationships,and canconvenientlybe expressedas rules, of-ten called business nileso r business policies. (Sometimes,

"business rule" is used to

mean

any kind ofsignificant

ap-plication logic, e.g., thealgebraic formula forcomputing an

insurance annuity.

By

"rule" in this paper,

we mean

more

specifically an implication(i.e.,

IF-THEN)

in

which

the

an-tecedent (i.e., the IF part)

may

contain multiple conjoined

(i.e.,

AND'ed)

conditions.)

For example,rules areusefulindescribing:

• terms

&

conditions,e.g.,rules forpricediscounting;

• service provisions,e.g.,rules forrefunds;and

• surroundingbusiness processes, e.g.,rules forleadtime

toplaceanorder.

(Section 2 elaborates on these examples.)

We

believe that

rules as an overall representational approach capture well

many

aspectsofwhat one

would

liketodescribeinautomated

contracts.

In this

work

we

areconcernedprimarily with the

negotia-tionstageofcontracting,andspecifically with

how

to

repre-sentbusinessrulesin contracts.

The

contractterms

may

or

may

notbemodifiedduringthe

negotiation stage. Ifnot, thenegotiation stage

may

be a

rel-ativelysimple processof

communication

followedby

accep-tance. Crucial during negotiation, however, isthatal 1 agents must understand andagree. Interms ofautomation, the

con-tract has to be

communicated

and digested by each agent,

with shared semantics.

(More

generally,

some

agentsmight

be

human,

as well as automatic; however, the aspects of

hu-man

interaction are

beyond

thescope ofthispaper.)

Our

goalisasharedlanguage with

which

agentscanreach

a

common

understanding ofrules in contracts, such that the

rules are relatively easily modifiable, communicatable, and

executable bytheagents.

Note that

we make

a sharpdistinctionbetween the

repre-sentational

mechanism

for

communicating

contractrules,and

the actual rule execution

mechanisms employed

by

partici-patingagents.

Our

concern hereiswiththe former,though of

course in designinga

communication

mechanism

one must

considerand anticipate the requirements ofexecution to be

performedby each oftheagents.

We

will take a declarative approach to business rules in

contracts.

By

"declarative" semantics for rules,

we

mean

in the sense of

knowledge

representation

(KR)

theory, in a

manner

abstracted

away

fromthe choice ofim plementation

approach: the semantics say

which

conclusions areentailed

(e.g., model-theoretically) by a given set ofpremises, with-outdependence

on

procedural or control aspectsofinference

algorithms. Inparticular,declarativesemanticsabstract

away

from whether the direction ofrule inferencing is

backward

versusforward.

2

Example

Roles

for

Rules

and

Prioritized

Conflict

Handling

Next,

we

give afew briefexamples, expressed innatural

lan-guage, ofbusiness rules incontracts.

As

we

go,

we

will see

both theneed forprioritized conflicthandling

—

becauseof

conflict,and theopportunity forprioritized conflicthandling

—

because ofnaturallyavailableprioritizationinformation.

Example

1

(Refund

Policy)

A

typical

example

ofaseller'srefundpolicyis:

• (Rule A:) "Ifbuyerreturns the purchased

good

forany

reason,within30days, then thepurchaseamount,minus

a

10%

restockingfee,willberefunded."

• (Rule B:) "Ifbuyerreturnsthepurchased

good

becauseit

isdefective,within I year,then thefullpurchase

amount

willberefunded."

• (Priority Rule:) "If both Rules

A

and

B

apply, then

Rule

B

'wins', i.e.,thefullpurchase

amount

willbe re-fiinded".

Here,

we

say arule"applies"

when

that rule's

body

(i.e.,

an-tecedent) issatisfied.

The

PriorityRule isnecessarybecause

itcanhappenthat thebuyerreturns the

good

becauseit is

de-fective within 30 days. Inthis case,Rules

A

and

B

conflict

with each other; both rules apply but theirconsequents are

incompatible witheachother.

The

conflictisresolvedby

pri-ority: Rule

B

isspecifiedtohavehigherprioritythanRuleA.

Example

2

(Lead

Time)

In business-to-business

commerce,

e.g., in manufacturing

supplychains,sellersoftenspecify

how much

lead time,i.e.,

minimum

advance notice before scheduled delivery date, is

required in order to place or

modify

a purchase order.

An

example

ofapartssuppliervendor's leadtimepolicyis:

• (Rule A:)"14 daysleadtimeifthebuyer isapreferred

• (Rule B:) "30 days lead time ifthe ordered item is a

minorpart."

• (Rule C:) "2 dayslead time it": the ordered item's

itein-typeisbackloggedatthevendor,andtheorderisa

mod-ification toreducethe quantityoftheitem,andthebuyer

isapreferredcustomer."

• (Prioriis Rule:)"II'Rules

A

and

C

both apply, then Rule

C

'wins', i.e.,2 dayslead time,"

The

rationale forRule

C

is thatthe vendorishaving trouble

fillingitsoverallorders(fromall itsbuyers) fortheitem,and

thusISpleasedtohave thisbuyerrelieve thepressure.

Rules A, B,and

C

may

conflict:

two

orthreeof

them

might

appK

to agivenpurchase order.

The

PriorityRule provides

partial prioritizationinformation-itsrationale might bethat

Rule

C

is

more

specific, or

more

recent,than Rule A.

How-ever,theaboverule-setleavesunspecified

how

toresolve

con-flictbetween Rules

A

andB, forexample;norelativepriority

between

them

isspecifiedasyet. Thisreflects a

common

sit-uation

when

rules accumulate overtime, or are specifiedby

multiple authors: atanygiven

moment

duringthe processof

incremental specification, there

may

be insufficient justified

priority toresolveallpotential conflicts.

Example

3(Bookstore Personalized Discounting)

Sellersoften providepersonalized price discounting.

A

topic

ofconsiderable interesttoday

among

e-commerce

sellers is

how

todothis

more

cheaplyand uniformly

by

automatingit.

An

e.xampleofabookstore'spersonalizeddiscounting policy

is:

• (Rule A:) "5 percent discount ifbuyer has a history of

loyalspendingatthe store."

• (Rule B:) "10percent discountif buyerhas a history of

bigspendingatthestore."

• (Rule C:) "5 percent discountifbuyerhasa storecharge

card."

• (Rule D:) "10_percentdiscountifbuyeris a

member

of

the store'sPlatinumClub."

• (Rule E:)

"No

discountif buyerhas alate-payment

his-toryduring thelastyear."

• (Priority Rules:)

"B

ishigher prioritythan allthe

oth-ers;

D

ishigher prioritythan

A

and than C;

E

ishigher

prioritythan

A

andthan

C

andthan D."

Here,the PriorityRulesspecifyasetofprioritycomparisons,

that are sufficient toresolveallthepotential conflicts

among

the rules.

More

Example

Roles

for

Rules

We

believethat

many

contractterms can bewell represented

asrules.

• Policiesabout cancellingordersareoften similarinfeel

totheexamples above aboutrefunds andleadtime.

• Policies about discounting for

groups

or preferred

customer organizations, e.g., hotel discounts for

AAA

members,

areoften similarin feeltotheexample above aboutpersonalized discounting.

• In supplychain settings: requests forproposals,and

re-sponding bids, often involveconditional relationships

between

price, quantity,

and

delivery date, e.g., "If

the order quantity is between

400

and 1000 units, and

the delivery date is between 15 and 30 daysfro

m

the

orderdate,then the priceis$48perunit.".

• In

product

catalogs,

many

properties ofa product are

most naturally specified as conditional onother

proper-tiesofthatproduct, rather thanbeingparticulartoan

in-dividual product. E.g.,"all laptopcomputersinclude an

internal

modem".

E.g., "all

women's

T-shirts are

avail-able in sizes

XS,

S,

M, and

L", "all men's T-shirts are

available insizes S,

M,

L,

XL,

and

XXL",

and "all

T-shirts are available in colors navy, khaki, and black".

E.g.,"all

V-neck

sweatersareavailableinfabricsacrylic

and cashmere".

• Policies aboutcreditworthiness, trustworthiness,

and

authorization are often naturallyexpressed interms of

sufficientand/or necessaryconditions.

Such

conditions

include: credentials, e.g., credit ratings or professional

certifications; third-party recommendations; properties

ofa transactioninquestion,e.g.,itssizeor

mode

of

pay-ment;andhistoricalexperience

between

theagents,e.g.,

familiarityorsatisfaction.

3

Rule

Representations: Previous

Approaches

including

KIF,

Requirements

Analysis

In section 1,

we

stated that in this

work

ourgoal isa shared

language with

which

agents can reach a

common

under-standing ofrules in contracts, such that the rulesa re rela-tively easily modifiable,

communicatable,

and executable

bythe agents.

In this section,

we

analyze and elaborate these

require-ments (i.e., criteria or desiderata,

which

we

bold-face

throughoutthissection)forarulerepresentation,anddiscuss

candidate previous approaches in light of them, as

motiva-tion for our approach.

We

begin

by

reviewing previous ap-proaches.

There are multiple approaches already in wide

imple-mented

commercial useforrepresentingbusinessrules

gen-erally (not for contracts in particular).

One

approach is

di-rectly as if-then code constructs in general-purpose

imper-ative

programming

languages such as C,

C++,

and Java'.

Other approaches are

more

specific to rules.

A

second

ap-proach is Prolog [3], a

programming

language oriented

to-wards backward-chainingrules.

A

thirdapproach, closely

re-lated toProlog,is

SQL

views. In

SQL-type

relationaldatabase

systems [22] aview isdefined, in eflect, bya setofrules.

A

fourtliapproach, fairlycloselyrelatedto

SQL

views,is

eveni-coiiJiiion-action rulesI"active rules"/"triggers" [22] ofthe kind found in

many

database systems and routing systems.

These are forward-directed, triggered by events such as

up-dating a database relation.

A

fifth approach isproduction

rules, a form offorward-chaining rules, ofthe kind in

sys-tems descended from the

0PS5

system [4]. Thereare other

approachesas well,e.g., inexpertsystems,knowledge-based

systems, and intelligent agent buildingtools, butthe

above-listed are probably the currently most commercially

impor-tant,especially

m

e-commerce.

A

sixthapproach forrepresenting business rulesis

Knowl-edge Interchange

Format

(KIF)^.

KJF

is not a directly

ex-ecutable representation. Rather,

KIF

is a language for

in-terchange of knowledge, including rules, between

heteroge-neous software systems, e.g.,agents.

More

precisely,

KIF

is a prefix' version offirst-order predicate calculus (i.e.,

first-orderclassical logic) with extensionsto supportthe "quote"

operator(thusenabling additional expressiveness akintothat

ofclassical higher-order logic) and definitions.

KJF

is cur-rently well along in the

ANSI

standards committeeprocess.

Supporting orendorsing

KIF

is alsobeing considered

infor-mallyinseveralotherstandardseffortsrelevanttoagent

com-munication,e.g., FIPA^'.KIF,however,isnot yetinwide

im-plementedcommercialuse.

Next,

we

elaborateon requirements andrelate

them

tothe

previous approaches.

One

group of requirements revolves

aroundheterogeneity. Specifically,the multiplicity of widely implemented approaches implies an immediate requirement

to cope with heterogeneity of implementations of

busi-ness rules.

The

ability to

communicate

with shared

under-standing then implies the requirements ofinteroperability

with declarativesemantics.

The

above-listedwidely

imple-mented

approacheslackfully declarativesemantics.

Communicatabilityandinteroperability implythe

require-ment

of ease ofparsing rule-sets that are being

communi-cated. Interoperability and practical executability imply the

requirementofintegration into

WWW-world

software

en-gineering overall.

The

XML

aspect of ourapp roach

facili-tates such parsingandintegration.

A

second group of requirements revolves around

expres-siveness.

A

basicoverall requirementisexpressive

power

in

specifyingrules.Practical executability,however,implies the

strong desire forcomputationaltractability inthesenseof

average-case and worst-case complexity. Expressive

power

hastobe balancedagainsttractability.

^http

:

//logic

.

Stanford.

edu/kif

/ and

http

:

//www. cs

.

umbo

.edu/kif/

^The current draft

ANSI

specification of KIF

(http

:

//logic

.

Stanford.

edu/kif

/dpans

.html) also

includesan infix versionofKIFintended for

human

consumption

ratherthanautomated exchange.

"Foundation for Intelligent Physical Agents:

http

:

//www

.f

ipa

.

org

Ease ofmodifiability implies the requirement of

expres-siveconveniencefortheprocessofspecification. Expressive

convenienceisinpartan aspectofexpressivepower,butalso

impliestheneedforconceptual naturalnessofsemantics.

An

important aspect ofexpressive

power

isthe ability to

convenientlyexpressrules thatarelogicallynon-monotonic,

i.e.,rules that

employ

negation-as-failure or are defaultrules.

In particular, it is important to conveniently express

pri-oritized conflict handling, i.e., where

some

rules are

sub-ject to overridebyhigher-priority conflicting rules, such as

by special-case exceptions, by more-recent updates, or by

higher-authority sources.

As

we

saw

in ourcontractrule-set

examples insection2, conflict, andthe need/opportunity for prioritizedoverride,frequentlyarise.

Most

commerciallyimportantrule systems (including the

above-listed widely implemented approaches)

employ

non-monotonic reasoning as an essential, highly-used feature.

Typically, they

employ

some

form ofnegation-as-failure.

Of-ten they

employ some

forni ofprioritized override between

rules,e.g.,thestaticrulesequence in Prologorthe

computed

rule-activation sequence/"agenda" in 0PS5-heritage

produc-tion rulesystems.

In

modern

software design, it is widely recognized thata

vital aspect ofmodifiability

ismod

ularity

and

locality in

revision, e.g., in the

manner

that subclassing and

informa-tion hiding provide in object-orientedprogramming.

Prior-itized conflict handling enables significantly easier

modifi-cation and

more modular

revision/updating.

New

behavior

can bespecified

more

often by simply addingrules, without

needingto

modify

theprevious rules. E.g., a

more

specific-caserulecan beadded andgiven higher-priority thana

previ-ousgeneral-caserule,without needingto

modify

the

general-case rule. This is similar to the modular/local gracefulness

inobject-oriented

programming

of addingasubclass without

needingto

modify

thesuperclass.

Another important aspect of expressive power, in rela-tion to practical executability, is the ability to conveniently

express procedural attachments. Procedural attachments

are the association of procedure calls with belief

expres-sions, e.g., in

Example

1,the associationofthe Java

method

CustomerAccount

.

setCredi tAmount

with the

logi-cal predicate

refund.

Procedural attachmentsare crucial in

order for rules to have actual effect

beyond

pure-belief

in-ferencing, e.g., forac tions tobe invoked/performedas a

re-sult after rule conclusions are inferred. Procedural

attach-ments are also very useful to invoke procedure calls

when

rule conditions are tested/queried.

Almost

all ofthe

above-listedwidely

implemented

approachesincludeprocedural

at-tachments.

However, procedural attachments are semantically

prob-lematic,andanopenresearch issuetodayis

how

togive

them

a semantics thatabstracts

away

from implementation details

and isthus akin tobeingdeclarative. (See the discussion of

K.IFhas been developed specifically forpuqioses of

com-munication, in responsetothe need tocopewith

implemen-tational heterogeneityofrulesand otherknowledge.

By

con-trast with the abo\e-listed widely implemented approaches,

KIF

has afullydeclarativesemantics; indeed,that isitsmain

intendedstrength. Itsdeclarativesemantics isbased

on

clas-sicallogic,primarilyfocusingonfirst-order logic. First-order logic is logically monotonic, highly expressive,and

compu-tationally intractable (toperform inferencing)forthegeneral case

KIF

can express a broad class ofrules. However, it has

several important shortcomings as a language for business

rules in e-commerce, including in contracts.

Perhapsm

ost crucially,

KIF

has a shortcoming ofits fundamental

knowl-edge representation (KR): it cannot (conveniently) express

logical non-monotonicity, including negation-as-failure,

de-faultrules,and prioritized conflicthandling;KI Fis logically

monotonic.

KIF

alsocannot(conveniently) express

procedu-ralattachments; itisapure-belief

KR. KIF

hasbeen designed

with an orientation towards

knowledge

as a non-executable

specification as

much

or

more

thantowards

knowledge

as

ex-ecutable. Also, the

KIF

efforthasfocused

more

ona highly

inclusivelyexpressive representation than

on

easeof

develop-ing translatorsinandoutofthatrepresentation (this is

some-thing the

XML

aspectof ourapproach improvesupon).

Inour \ievv. none oftheabove-listed previousapproaches

to representing business rules, nor any other previous

ap-proachthat

we

areawareof,satisfactorilymeetsthe

whole

set

of requirements

we

listedabove(in bold-face). Inparticular,

the widely-implemented approaches above lack sufficiently

declarative semantics; KIF, though declarative, lacks logical

non-monotonicity.

KIF'sdeclarativeapproachdoes,however,inspireusto

de-velopour

own

declarative approach.

4

A

New

Declarative

Approach

to

Rules:

Courteous

Logic

Programs +

XML

The

approach is tochoose Ordinary Logic

Programs

(OLP)

—

inthedeclarativesense([1]providesahelpfulreview), not

Prolog

—

asafundamental

KR,

plusto

embody

this

KR

con-cretely in

XML

forpurposes of

communication

betweenthe

contracting agents. ' _{Logic programsarenoton}

lyrelatively

powerfulexpressively,butalsopractical, relatively

computa-tionally efficient,and widelydeployed.

We

expressively extend the approach's declarative

fun-damental

KR

formalism to be Courteous Logic

Programs

(CLP).

CLP

expressivelyextends Ordinary Logic Programs

to include prioritized conflict handling, while maintaining

computational tractability.

CLP

isaprevious

KR

[10]

which

"Ordinary"logicprogramsarealsosometimes

known

as

"gen-eral"(e.g.,in_[1])or"normal"logicprograms,or as(thedeclarative versionof)"pureProlog".

we

haveherefurtherexpressively generalized, notablyto

han-dle pairwise mutual exclusion conflicts, rather than simply

conflictsofthe form

p

versus-ip.

4.1

First

KR

Step:

Ordinary

Logic

Programs

We

begin definingour approach

by

choosingthe

fundamen-tal

KR

forrules to be: declarative Ordinary Logic Programs (OLP),withthewell-founded semantics

(WFS)

[23], inhially

expressivelyrestricted to the predicate-acycliccase (defined

below). (Henceforth,

we

will leave "declarative" implicit.)

This is a "pure-belief"

KR,

i.e., it lacks procedural

attach-ments.

Each

ruleinan

OLP

has the form:

Ao

<-

Ai

/\ ...

h

Am

/\

~^m+l

A

...

A ~An.

Here,

n

>

m

>

0,and each A,isa logicalatom.

Aq

iscalled

the

head

(i.e., consequent) ofthe rule; the rest iscalled the

body

(i.e., antecedent) oftherule. Ifthe

body

isempty, the

<—

may

beomitted.

A

groundrulewith

empty body

iscalled

afact.

~

stands forthe negation-as-failureoperatorsymbol,

and isread in English as "fail". Intuitively,

~p

means

that

_p

isnot believed to be true, i.e., thatp's truth value is either

false or

unknown.

E.g.,thefirstrulein

Example

2might bewrittenas:

order

Modi

ficationNotice{'?Order,

day

sli) <—

pre

ferredCustomerO

f

{?

Buyer

,ISeller)

A

purchaseOrderClOrder,

?

Buyer,

?Seller)

.

Here, the prefix"?"indicates alogical variable.

Ordinary LP'shave beenwell-studied,and havea large

lit-erature(reviewed,forexample,in [I]). Forseveralbroadbut

restrictedexpressivecases, their(declarative)semanticsis

un-controversial: e.g.,forthepredicate-acyclic,stratified,locally

stratified, and

weakly

stratifiedcases; theseform a series of

increasingexpressivegenerality. However,

OLP's

have

prob-lematic semantics for the unrestricted case, due essentially

totheinteraction ofrecursionwith negation-as-failure.

"Re-cursion" here

means

thatthere is acyclic(path ofsyntactic)

dependency

among

thepredicates(or,

more

generally,

among

theground atoms) throughrules.

More

precisely,alogic

pro-gram

S's predicate

dependency graph

PDGs

is defined as

follows.

The

vertices ofthegraph are thepredicates that

ap-pearin S. {p,q) is a(directed) edgein

PDGs

iffthere isa

rule rin

£

with

p

in its head and q in its body.

"Predicate-acyclic"

means

thatthere are

no

cyclesinthepredicate

depen-dencygraph. "Stratified" (initsvariousflavors)

means

cycles

ofarestrictedkindareallowed.

The

well-founded semanticsisprobablythecurrentlymost popular semantics for the unrestricted case, and is our

fa-vorite. With

WFS,

the unrestrictedcase alwayshas a single

set ofconclusions, and istractable under

commonly-met

re-strictions(e.g.,

VBD

definedbelow).

Our

approach for an initial practically-oriented LP-based

business rules

KR

is, however, to keep to expressively

re-strictedcasesthathaveuncontroversial (i.e.,consensusinthe

predicate-acyclic.

Compared

to these uncontroversial cases, the

unre-strictedcase(e.g.,with

WFS)

is

more complex

computation-ally and, perhaps even

more

importantly, is

more

difficult in

termsofsoftware engineering, lireq uires

more

complicated

algorithms andisnot widelydeployed. Thepredicate-acyclic

expressive restnction can be checkedsyntacticallywith a

rel-atively simple algorithm and with relatively low

computa-tional cost.

An

OLP

(with

WFS)

consistsofasetofpremiserules,and

entails asetof(primitive)conclusions. Ina predicate-acyclic

OLP,

each conclusion has the formofa ground atom.

Intu-itively,eachconclusion

atom

isbelievedtobetrue,andevery

other(i.e.,non-conclusion)ground

atom

isnotbelievedtobe

true(recall

~

above).

Next,

we

discuss the advantages of

OLP's

(with

WFS).

(.\dv 1):

OLP

has a fully declarative semantics that is

use-ful and well-understood theoretically.

(Adv

2):

OLP

in-cludes negation-as-failure and thus supports basic logical

non-monotonicity.

(Adv

3):

OLP

has considerable

expres-sivepower,yet isrelativelysimple and isnotoverkill

expres-sively.

(Adv

4):

OLP,

unlikefirst-order-logic/KIF,is

compu-tationally tractable in thefollowing sense.

Under

commonly

met

expressive restrictions, e.g.,

VBD,

inferencing

—

i.e.,

rule-setexecution

—

in

OLP

can be

computed

in worst-case

polynomial-time. Here,

we

say that an

LP

is ''VBD"

when

either (a) it is ground, or (b) it has no logical fijnctions of

non-/^ero arity (a.k.a. the Daialog restriction^) and it has a

bounded

number

oflogical variables appearing ineach rule.

By

contrast, classical logic, e.g., first-order logic

—

and thus

KIF,isco-NP-hard underthe

VBD

restriction.

(Adv

5):

We

observepredicate-acyclic

OLP's

semantics is widely shared

among

many

commercially important rule-basedsystemsas

an expressive subset oftheir behavior. Prolog is the most

obviousfamilyof suchsystems. Relationaldatabases are

an-other such family;

many

SQL

viewdefinitions(andrelational

algebra operations) are in effect

OLP

rules. 0PS5-heritage

production rule systems are less closely related because of

their extensive use of procedural attachments, but insofar

as they

commonly

do pure-belief predicate-acyclic

inferenc-ing, their semantics is closely related to forward-directed

OLP's. Event-condition-actionrules are

somewhat

similarin

this regard to asimple form ofproduction rules. Other

sys-tems sharingthe semantics include

many

expert/knowledge-based systems and intelligent agent building tools;

many

of

these implement forward-directed predicate-acyclic OLP's.

Predicate-acyclic

OLP

semantics thusreflectsaconsensusin

therulerepresentation

community

thatgoes

beyond

the logic

programming

community.

(Adv

6); Predicate-acyclic

OLP's

are, in effect,widely

implemented

and deployed,includingin

Prolog'sand

SQL

relationaldatabases,but also

beyond

them.

"It isusually straightforwardtorepresentationally refomiulatea

rule-setsoas toreplacea logical flinction/havingarityfc

>

by

apredicate /phaving antyfc-I- 1,where inUiitivelythe(fe -|- l)""

argument correspondstothe resultofapplyingtheflinction.

(Adv

7): There isa largepopulation ofdevelopers (not just

researchers)

who

are familiarwiththem.

4.2

KR

Extension

to

Courteous

Logic

Programs

Courteous LP's

(CLP)

expressively extends Ordinary LP's

(with

WFS)

by adding the capability to conveniently

ex-pressprioritized conflicthandling,whilemaintaining

compu-tational tractability (e.g., under the

VBD

restriction).

CLP

is a previous

KR

[10]

which

we

have here further

expres-sively generalized, notablyto handlepairw'isemutual exclu-sionconflicts, ratherthansimply conflictsofthe form

p

ver-sus->p. (Here,->standsfor classicalnegation. Intuitively,

-p

means

p

isbelievedtobedefinitelyfalse.)

CLP

can be tractably

compiled

to

OLP.

Indeed,

we

have implemented sucha courteouscompiler[II] [13] [12].

The

compilerenablesmodularityinsoftwareengineeringand

easesimplementationand deployment: theCourteous

LP

ex-pressive capability canbeadded modularlytoanOrdinary

LP

ruleengine/system simply by addinga pre-processor.

Com-pilation's computational complexity iscubic, worst-case, but

oftenisclosertolinear.

Inthispaper,

we

donothave spacetogivefulldetailsabout

thegeneralized

CLP

formalismoritscourteouscompiler.

In-stead,here

we

willgivean overview

and

some

examples. For

details,see [12] andtheforthcoming extendedversionofthis

paper.

CLP

handles conflicts

between

rules using

partially-ordered prioritization information that is naturally available

basedonrelative specificity,recency,andauthority.Rulesare

subject to override by higher-priority conflictingrules. For

example,

some

rules

may

be overridden

by

otherrules thatare

special-caseexceptions,more-recentupdates, orfrom

higher-authoritysources.

Courteous LP's facilitatespecifyingsetsofrulesby

merg-ing, updating and accumulating, inastylecloser(than

Ordi-nary LP'sorthanclassicallogic/KIF)tonaturallanguage

de-scriptions.

The

expressive extensionprovidedby

CLP

isthus

valuable especially because it greatly facilitates incremental

specification,byoften eliminating theneedtoexplicitly

mod-ifypreviousrules

when

updatingormerging. Intermsofthe

rulerepresentationrequirements

we

gaveinsection3, this

en-ables significantlygreatermodularity,locality,easeof

modi-fication.expressiveconvenience, and conceptualnaturalness.

InCLP,prioritiesarerepresented via afactcomparingrule labels: overrides{rulel,rule2)

means

thatrulelhashigher

priority than rule2. Ifrulel and rule2 conflict,then rulel

will

win

theconflict.

Syntactically, a

CLP

rule differs from an

OLP

rule in

two

ways. First, it

may

have an optional rule label, used as a

handle forspecifyingprioritization. Second, eachruleliteral

may

beclassically negated. Syntactically,

OLP

is simply a

specialca seofCLP.

An

OLP

rulelacks alabeland doesnot

A

CLP

rulehasthe fomi:

{lab)

Lo

<- Li

A

...

A

Lm

A

~Lm+i

A

...

A

~L„.

Here,

n

>

m

>

0, and each I, isaclassical literal.

A

clas-sical literal is a Ibniiula ofthe t'onn -4 or -i.4, where .4 is

an atom. ->stands for the classical negation operator

sym-bol, and is read in English as "not", lab isthe rule's label.

The

labelisoptional. Ifomitted, the label issaid tobe empty.

The

label isnotrequiredtobeuniquewithinthe scope ofthe

overall logic program; i.e.,

two

rules

may

have the

same

la-bel.

The

label istreatedasa0-ary functionsymbol.

The

label

is preserved during instantiation; all the groundinstances of

the rule above have label lab. overrides and the labels are treated as partofthelanguageofthelogicprogram,similarly

toother predicateandfunctionsymbols appearinginthe logic

program.

Semantically, a

CLP

entailsasetof(primitive)conclusions

each of which is a ground classical literal. Classical

nega-tionisenforced:

p

and -^p areneverboth concluded, forany

(classicalliteral)p. Thiscan be viewedas theenforcingof an

implicitmutualexclusionbetween

p

and -ip.

In thenewlygeneralized versionof CLP,the

CLP

also

op-tionallyincludes aset ofpairwise mutual exclusion (mutex)

statements,along with therules.

These

mutex

's specify the

scope ofconflict.

An

unconditional

mutex

has thesyntactic

form-±

t- Li

A

L2.

where

each Lj isa classical literal. Semantically, eachsuch mutualexclusion specifiedbya

mutex

isenforced: Li and

L2

arenever both concluded (forany instantiation). These

mu-tex's are particularlyuseful forspecifyingthatatmost oneof asetofalternativesistobepermitted. E.g.,in

Example

1,itis

straightforwardtospecify via a

mutex

thattherefund

percent-age mustbeatmost one ofthevalues

{90%

,

100%}.

E.g., in

Example

2, itisstraightforwardtospecifyvia 3

mutex

'sthat

the leadtime must beat

most

one ofthevalues {2 days, 14

days, 30 days}. E.g., in

Example

3, it is straightforwardto

specify via 3mutex'sthatthediscountpercentagemust beat

most oneof the values

{0%, 5%,

10%}.

Itisexpressively

more

convenientsometimestousea

more

general form of mutex: a conditionalmutex, which has the

syntactic form:

1

^

Li

A

L2

I

(?y

7^?Z).

where

TV

and

?Z

are logical variables that appear

respec-tivelyin

Li

and ^2- E.g.,

±

<—

giveDiscount[1Cust,

lY

Percent)

A

giveDiscount{1Cust,

?Z

Percent)

I

(lY Percent ^?ZPercent).

This conditional

mutex

enables oneto specify with a single

mute.x statement(ratherthan withthreeor

more

unconditional

mutex's) that for a given customer

ICust

there

must

be at

most onevalueconcludedforthediscount percentage.

The

enforcement ofclassical negation can be viewedas a setoiimplicit unconditional mutex's,one foreach predicate

Q,

thateachhavetheform

1

<-

Q(?X1,

..

.,

IXni)

A ^g(?Xl,

..

.,

?Xm).

where

Q'sarityis

m.

Thisiscalled aclassicalmutex.

Example

4

(Ordering

Lead Time,

in

CLP)

Example

2 can be straightforwardly represented in

CLP

as

follows:

(a)

order

Modi

ficationNotice{?Order, dayslA)

<—

preferredCustomerOf{?

Buyer,

'^Seller)

A

purchaseOrder{'!Order,

'?

Buyer,

?Seller).

(b)

order

Modi

ficationNotice{?Order,

days30)

(—

minor

Part{? Order)

A

purchaseOrder{?Order,

?

Buyer,

?Seller).

(c) or

derModificationNotice{1 Order, days2)

<—

preferredCustomerOfC?

Buyer,?

Seller)

A

order

ModificationType{? Order,

reduce)

A

orderltemi

sInBacklogilOrder)

A

purchaseOrder{? Order,

1

Buyer,

ISeller).

overrides{c,a).

±

<—

order

Modi

ficationNotice{'?Order,?X)

A

order

ModijicationNotice{10rder, lY)

I

{IX ^lY).

To

represent this

example

directly as an Ordinary

LP

—

while handlingconflict appropriately in regard to priorities

and guaranteeing consistency

—

requires modifying the

rules to addextra "interaction"conditions thatprevent

more

than one rule applying to a given purchase order situation.

Moreover, adding a

new

rule requires modifying the other

rules to add additional such interaction conditions. This is

typicalofconflictingrule-sets

and

underscorestheadvantage ofthe prioritized conflict handlingexpressive feature (recall

the discussion of modularity andea se of modification in

section3).

Semantically, the prioritized conflict handling in

CLP

is

defined by a process ofprioritized

argumentation

among

opposing

candidates. Opposition is specified

by

the set of

mutex's.

Each

rule r

whose body

is satisfied, i.e., which

"fires", generates a candidate cfor r's(appropriately instan-tiated)headp. This candidate hasan associatedlabel,which

issimplythat rule r'slabel. Ingeneral, there

may

bemultiple

candidatesforagivenp,i.e.,ateamfor p. Ifandonlyifthere

isan opposing candidate

d

(i.e.,a candidate foranopposing

literalq)thathashigherprioritythan candidatec,then cis

re-futed.

Suppose

thereisanunrefuted candidate for p. Ifthere

arenounrefuted candidatesforany opposer ofp,then

p

wins,

i.e.,

p

isconcluded. However,it

may

bethatthereisan

unre-fiitedcandidate foranopposer ofp; in this case,theopposing

unrefuted candidates skeptically defeateachother.

The

con-flictcannot beresolvedbythespecifiedpriority;neither

_p

nor

itsopposerisconcluded.

Another

way

to view thisis as follows.

An

opposition-locale is a set of/i

>

2 ground classical literals that

op-pose eachother,suchthatat

most

one ofthoseliterals is

opposition-locale, ifthe maximal-priority candidates are all

forthe

same

literal,thenthatliteral wins.

The

definition of

CLP

includes

some

additional expressive

restrictions,which

we

donothavespaceto detailhere.

CLP

always producesa consistentsetofconclusions,

en-forcingall themutex's.

CLP

also has several otherattractive

well-beha\iorproperties, including about merging and about

natural belunior ofprioritization; however,

we

do not have

space hereto detail these.

The

courteous compiler in effect represents the

priori-tizedargumentation process in

OLP.

It introduces

some

ex-tra"adorning"predicatesto representtheintennediate stages

ofargumentation: candidates, unrefuted candidates,

skepti-cal defeat, etc..

The

compiler

makes

it simple to detect an

unresolved conflict, e.g., to raise an alarm about it in either

fonvardor

backward

reasoning.

From

the tractability ofcourteous compilation, it follows

directly thatCourteous

LP

inferencingunderthe

VBD

restric-tion istractable. It hasthe

same

worst-case time and space complexity as:

OLP

inferencing where the

bound

v onthe

number

ofvariablesperrulehasbeen increasedtow-I-2.

Notethat

CLP

overlapssyntacticallyandsemanticallywith

KIF

forabroadcase.

CLP

without negation-as-failure, with-out labels (or ignoring labels), and withoutconflict, is

syn-tacticallyarestricted (essentially,clausal)caseof first-order-logic(FOL)/KIF.Semantically,such

CLP

issoundbut

incom-plete

when compared

to

FOL/KIF,

inthatitsentailed

conclu-sions are equivalenttoa (conjunctive)setofgroundliterals.

4.3

XML

Embodiment:

Business

Rules

Markup

Language

Our

approach includes a second aspect

beyond

the

funda-mental

KR.W

e

embody

therulerepresentation concretelyas

XML

documents.

Next,

we

give, forthe firsttime, an

XML

embodiment

of

CLP.CalledBusiness Rules

Markup

Language (BRML),

this

XML

embodiment

functions as an interlingua between

het-erogeneousrulerepresentations/systems

which

different

con-tractingagents

may

be employing.

BRML

inheritsthe

declar-ativesemanticsofCLP.

BRML

alsois thefirst

XML

embodiment

of(declarative)

OLP

toour knowledge. Since

CLP

alsoexpressively covers

asubsetofKIF, asdescribed above,

BRML

is alsoan

XML

embodiment

ofthatsubset of

KIF

—

to our knowledge,the

first

XML

embodiment

of(any fragment

oO

KIF.

Figure I

shows

the

CLP

from

Example

4 encoded in

BRML.

Only

the first ruleofthat

Example

is

shown

in

de-tail,

"cliteral"

means

"classical literal",

"fcliteral"

means

arule

body

literal, i.e., a literal formed

by

optionally

applying the negation-as-failure operator outside/in-frontofa

classicalliteral.

In this paper,

we

do not have space to give full

de-tails about the

XML

encoding. For full details, see:

(1) the

CommonRules

prototype

download

package (at

<?xml

version="l

.

0"?>

<clp>

<erule rulelabel="a">

<head>

<cliteral

predicate=

"orderModi£icationNotice">

<variable name=

"Order"

/>

<

function name="daysl4

"/>

</cliteral>

</head>

<body>

<and>

<fcliteral

predicate=

"preferredCustomerOf

">

<variable name=

"Buyer"/

>

<variable

name="Seller"/>

</f

cliteral>

<fcliteral

predicate= "purchaseOrder"

>

<variable

name="Order"/>

<variable name

=

_"Buyer"/

>

<variable name=

"Seller" />

</fcliteral>

</and>

</body>

</erule>

</clp>

[rest

of

rules

&

mutex's

skipped]

Figure 1:

XML,i.

e.,

BRML,

for

Example

4.

http://alphaworks.ibm.com),

which contains the

XML

Data

Type

Definition

(DTD)

for

BRML,

explanationof

it,anda

number

of examples(esp. "orderingleadtime"there);

and (2)the forthcomingextended version ofthis paper.

The

current

DTD

isin draftform; updatesto itwillbe postedon

the authors' websites. See [14] for

how

BRML

fits intothe

largercontext ofagent

communication

languages, including the

FIPA Agent

Communication Language (ACL)

draft

stan-dard.

As

compared

totheusual plain

ASCII

textstyleof

embod-iment cf

KIF

or Prolog or

most

programming

languages,

the

XML

approach has several advantages. It facilitates

developing/maintaining parsers (via standard

XML

parsing

tools), and integrating with

WWW-world

software

engineer-ing.

XML

is easier to automatically parse, generate, edit,

and translate, because there are standard

XML-world

tools forthese tasks.

The

hyper-text(i.e., links)aspects of

XML

are alsouseful. For example, a rule set

may

via

XML

have

some

associated

URL's

whichpointto

documents

describing

that rule set's

knowledge

representation orauthors or

appli-cation context.

Or

it

may

haveassociated

URL's

whichpoint

totools forprocessing thatruleset, e.g.,toexecuteit, edit it,

analyze it, orvalidate it (syntactically or semantically).

Par-ticularly useful forournearer-term purposes isthatan

asso-ciated

URL

may

point to

documents

describing the

seman-tics and algorithms fortranslatorservices orcomponents, as

well as totranslator tools and examples. Representing

comple-ment

domain-specific ontologies(i.e.,vocabularies) available

ill

XML.

Many

suchontologiesexistalready,and

many

more

aree.vpected tobedevelopedinthene.\t fewyears,including

in

e-commerce

domains.

The

XML

approach also facilitates

integrationwith Electronic DataInterchange (EDI) andother

e-commerce components

that"talk"

XML.

We

have implemented sample translators that go (bidi-rectionally) from the

.\ML

interlingua to several

ac-tual rule systems as proof of feasibility. These rule

systems include

two

previously e.xisting

WFS

OLP

inferencing engines built by others and implemented

in C.

One

is exhaustive forward-direction:

Smod-els (version I), by llkka

Niemela

and Patrik Simons,

http

:

//saturn

.hut:.f

i/html/st;af

f

/ilkka

.html.

The

other is backward-direction:

XSB,

by

David Warren

el al, htitp:_/

/www

.

cs

.

sunysb

.

edu/~sbprolog.

In addition,

we

have implemented a sample translator to a

third, predicate-acyclic

WFS

OLP

inferencing engine

we

builtourselvesin Java. Furthermore,

we

haveimplementeda

sampletranslator toANSI-draft

KIF (ASCII

format).

5

Discussion

and

Future

Work

The implementation

of our approach

was

releasedas a free

alpha prototype called

CommonRules

on the

Web

in July

of 1999, al

http

:

//alphaworks

.

ibm.com.

This

pro-totype is a Java library that includesboth the

CLP

and the

BRML

aspects of ourapp roach. In particular, it includes a

courteous compiler and sample translators between

BRML

andseveral otherrulesystems/languages.

In

summary,we

believeour approach

combining

CLP

and

XML

meets the

whole

set of requirements

we

gave in

sec-tion3betterthan anyprevious approach. Indeed,

we

believe

ourapproach meetseveryone ofthose requirernentstoa sig-nificantdegree,withoneexception: theability toexpress

pro-ceduralattachments.

The

usefulness ofrules in adeclarative

KR

for

represent-ingexecutable specificationsofcontractagreementsisbased

largely on their following advantages relative to other

soft-ware specification approaches and

programming

languages.

First,rulesareatarelatively highlevel ofabstraction, closer

to

human

understandability, especially by business

domain

experts

who

are typically non-programmers. Second, rules

are relativelyeasy to

modify

dynamically and

by

such non-

programmers-In current work,

we

are expressively generalizing

fur-ther to Situated Courteous LP's, so as to enable

procedu-ral attachments as well

—

in a semantically clean

manner

(i.e., declaratively in a particular well-defined sense).

Situ-ated LP's[9] [16] [15],another expressive extensionof

Ordi-nary LP's,

hook

beliefs to drive procedural APIs.

Procedu-ral attachments forcondition-testing ("sensing")and

action-performing ("effecting'') are specified as part ofthe

knowl-edgerepresentation: via sensorand effectorlinl<statements.

Eachsensor or effectorlinkassociates a predicate with an

at-tached procedure.'

Incurrentwork,

we

are also expressively generalizing

CLP

and

BRML

furtherto relaxexpressiverestrictionssuchason

cyclicity/recursionrestriction,e.g.,tobestratifiedratherthan

predicate-acyclic.

Thereare severalother formalismsforprioritized LP'sthat

havesimilarsyntaxtoCourteous LP's(exceptforlacking

mu-tex's) but different semantics in regard to conflict handling

(see [10] [II] forareview).

A

directionin our current

work

is toexplore this dimension ofheterogeneity.

None

ofthese

otherfonnalismstoour

knowledge

hasas attractive a

combi-nationofusefulexpressivepower,software-engineering

mod-ularity,well-behavior(e.g.,consistency,uniquesetof

conclu-sions), tractability,andconceptual simplicity(e.g., in

prioriti-zationbehaviorandmerging). Inparticular,none canexpress

mutex's (besides implicit classical mutex's), and nonehas a

compilertoOLP's.

Thereareother,

more

expressively powerfiilapproachesto prioritizeddefaultreasoningsuchas PrioritizedDefaultLogic

[2] andPrioritized Circumscription [19] [18] [7] [8] that es-sentiallycanexpressmutex's, butinthese theprioritized

con-flicthandling imposes computationally intractableoverhead

[6].

Itappearsfairlystraightforwardtoextend our

BRML DTD

in stages soas to express full first-orderlogic and then full

KIF.

A

direction for future

work

is to create a

DTD,

maxi-mallycompatibly with

BRML,

thatexpressesfullKIF.

In other

work

[21],

we

have extended our contract rule

representationapproachwith negotiationfeaturesoriented

to-wards automaticconfigurationofauctions, includingto

spec-ify

which

attributes ofa contract are tobe thesubjectof

ne-gotiationorbidding.

Of

course, thereis

yetm

ore todotofiilfillourapproach's

promise, and achieve its ultimate goals. Further issuesfo r

fiiture

work

include:

meshing

more

closely with other

as-pects ofcontracts, e.g., transactions, payments, negotiation

and

communication

protocols [5] [20],EDI, and utility/cost-benefit; fleshing out the relationships to a variety of

com-mercially important rule representations/systems;

represent-ing constraints as in constraint satisfaction

and

Constraint

Logic Programs; and representing delegation as in

secu-rity/authorization policies [17].

An

extended version of this paper will be

avail-able as a forthcoming

IBM

Research Report (at

http

:

//www.

research

.ibra.com).

Acknowledgements

Michael Travers(wh ile at

IBM

T.J.

Watson

Research

Cen-ter)and

Xiaocheng

Luan

(of

UMBC,

whileat

IBM

T.J. Wat-son Research Center), contributed to the current

implemen-tationofthe

CLP

KR,

BRML,

andtheassociatedtranslators.

'Notethat"link" heredoesnotmean inthesenseof an

XML

or

MicliaclTravers' contribution

was

especiallytothe

XML

em-bodiment.

Miao

Jin

(UMBC)

contributedto the

XML

DTD.

Daniel Reeves and Michael Wellrnan (ofU. Michigan)

con-tributedtothe fomiulationofthe overallcontextand

motiva-tion lorautomatedcontractlanguages.

Thanks

to

anonymous

reviewersforeditingsuggestions.

References

[11 ChittaBaraland Michael Gelfond. Logic

programming

and

knowledge

representation. Journal

of

Logic

Pro-gramming.

19,20:73-148, 1994.

[2] GerhardBrewka. Reasoning aboutpriorities in default

logic. In Proceedings ofthe Twelfth National

Confer-ence on Artificial Intelligence (AAAI-94), pages

940-945,

Menlo

Park,

CA

/ Cambridge,

MA,

1994.

AAAl

Press/

MIT

Press.

[3]

[4]

[5]

[6]

[7]

W.

F.Cloc ksin andC.S. Mellish.

Programming

in

Pro-log. Springer- Verlag, 1981.

Thomas

Cooper

and

Nancy

Wogrin. Rule-based

Pro-gramming

with

OPS5.

Morgan

Kaufmann

Publishers,

San Francisco,

CA,

1988.

ISBN

0-934613-5

1

-6.

Asit Dan, D. Dias, T.

Nguyen,

M.

Sachs, H. Shaikh,

R. King, andS. Duri.

The

Coyote Project:

Framework

forMulti-party

E-Commerce.

InProc. 7thDelos

Work-shop on Electronic

Commerce.

Lecture Notesin

Com-puterScience. Vol. 1513. Springer- Verlag, 1998.

Georg

Gottlob. Complexity results for

nonmonotonic

logics. Journal of Logic

and

Computation, 2:397-425,

1992.

Benjamin

N.

Grosof

Generalizing Prioritization. In

Proc.

2nd

Intl.

Conf

on Principles of

Knowledge

Rep-resentation

and Reasoning

(KR-91), 1991.

[8]

Benjamin

N.

Grosof

Updating

and

Structure in

Non-Monotonic

Theories.

PhD

thesis,

Computer

Science

Dept.,Stanford University, Oct. 1992.

[9]

Benjamin

N.

Grosof

Building

Commercial

Agents:

An

IBM

Research Perspective (InvitedTalk). InProc.

2nd

Intl. Conference

and

Exhibition on Practical

Applica-tionsofIntelligentAgents

and

Multi-Agent Technology

(PAAM97J,

P.O.

Box

137,Blackpool, Lancashire,

FY2

9UN,

UK.

[10]

Benjamin

N.

Grosof

Prioritized conflicthandling for logicprograms. InJanMaluszynski,editor,Logic

Pro-gramming:

Proceedings ofthe International

Sympo-sium (ILPS-97),Ml

T

Press, 1997.

[II] Benjamin N.

Grosof

Compiling

Prioritized Default

Rules Into Ordinary Logic Programs.

IBM

Research

Report

RC

21472.

[12] Benjamin N.

Grosof

A

Courteous Compiler from Generalized Courteous Logic Programs

To

Ordi-nary Logic Programs (Preliminary Report).

Tech-nical report,

IBM

T.J.

Watson

Research Center,

http://www.research.ibni.eom/pcople/g/grosof/papers.html,

July 1999. Included in

CommonRules

documentation

released July 30, 1999 at http://alphaworks.ibm.com .

Revisedversion forthcomingas

IBM

ResearchReport.

[13]

Benjamin

N.

Grosof

DIPLOMAT:

Compiling Priori-tized Default RulesInto Ordinary Logic Programs, for

E-Commerce

Applications(extendedabstractof

Intelli-gentSystems Demonstration). InProc.AAAI-99,\^99.

Morgan Kaufmann.

Extendedversion is

IBM

Research Report

RC

21473.

[14]

Benjamin

N.

Grosof

and Yannis Labrou.

An

Approach

tousing

XML

andaRule-basedContent

Language

with

an

Agent

Communication

Language. InProc.lJCAl-99

Workshop

on

Agent

Communication

Languages, 1999.

[15]

Benjamin

N. Grosof,

David

W.

Levine, and Hoi Y.

Chan. Flexible procedural attachments to situate

rea-soningsystems. In U.S. Patent5,778,150(July7. 1998),

Washington,D.C.,

USA

[16]

Benjamin

N. Grosof, David

W.

Levine, Hoi Y. Chan,

Colin P.Parris, and Joshua S. Auerbach. Reusable

Ar-chitecturefor

Embedding

Rule-BasedIntelligencein

In-formationAgents. InProc.

ACM

Conf. onInformation

and Knowledge

Management

(CIKM-95) Workshop

on

IntelligentInformationAgents, 1995.

[17] NinghuiLi,JoanFeigenbaum, and

Benjamin

N.

Grosof

A

logic-based

knowledge

representation foraut

horiza-tion with delegation (extendedabstract). InProc. 12th

Intl.

IEEE

Computer

Security Foundations Workshop,

1999. Extended version is

IBM

Research Report

RC

21492.

[18] V. Lifschitz.

Computing

circumscription. In

Proceed-ingsIntl. Joint

Conf

on

AI

(IJCAI-85), 1985.

[19] J.McCarthy. Applicationsofcircumscriptionto

formal-izing

commonsense

knowledge. Artificial Intelligence,

28:89-116, 1986.

[20] Naftaly H.

Minsky

and Victoria Ungureanu.

A

Mech-anism for EstablishingPo licies for Electronic

Com-merce. In Proc. 18th Intl.

Conf

on Distributed

Com-putingSystems(ICDCS),

May

1998.

[21] Daniel

M.

Reeves,

Benjamin

N.Grosof,

MichaelW

ell-man, and

Hoi

Y.Chan.

Toward

a Declarative

Language

forNegotiatingExecutableContracts. InProc.

AAAI-99

Workshop

onArtificialIntelligence in Electronic

Com-merce

(AIEC-99).

[22] Jeffrey D.

UUman

andJennifer

Widom.

A

FirstCourse

in

Database

Systems. Prentice-Hall, 1997.

[23] A.

Van

Gelder, K. Ross,

and

J. Schlipf

The

well-founded semantics forgenerallogicprograms. Journal

DEC

mi