SweetDeal: Representing Agent Contracts With Exceptions using XML Rules, Ontologies, and Process Descriptions

tags: Rules as Code Benjamin Grosof

Notes

Abstract

NOTER_PAGE: (3 . 0.15308291991495393)

SweetDeal is a rule-based approach to representation of business contracts

NOTER_PAGE: (3 . 0.20340184266477676)

builds upon the situated courteous logic programs knowl- edge representation in RuleML

NOTER_PAGE: (3 . 0.27852586817859676)

process knowledge descriptions whose ontologies are represented in DAML+OIL

NOTER_PAGE: (3 . 0.3465627214741318)

process ontology knowledge from the MIT Process Handbook

NOTER_PAGE: (3 . 0.6265060240963856)

1. INTRODUCTION

NOTER_PAGE: (4 . 0.33947554925584694)

automates (parts or all of) such business contracts by repre- senting and communicating them as modular sets of declarative logic-program rules.

NOTER_PAGE: (4 . 0.4585400425230333)

2. OVERVIEW OF THE REST OF THE PAPER

NOTER_PAGE: (8 . 0.24946846208362863)

3. SWEETDEAL, RULEML, and SWEETRULES: MORE BACKGROUND

NOTER_PAGE: (9 . 0.12119064493267187)

Contracts are represented using interoperable rules in XML. Declarative logic pro- grams (LP) are the fundamental knowledge representation (KR) in which these rules are expressed.

NOTER_PAGE: (9 . 0.294826364280652)

Rules represent part or all of an overall contract.

NOTER_PAGE: (9 . 0.5329553508150249)

Modification of a contract rulebase can be performed modularly during negotiation or completion

NOTER_PAGE: (9 . 0.6378454996456414)

Procedural attachments in the rules are used to perform external actions or queries

NOTER_PAGE: (10 . 0.11977321048901489)

advantages of the SweetDeal approach. What are the compet- ing approaches to representing contracts?

NOTER_PAGE: (11 . 0.2671863926293409)

SweetDeal is fairly unique in being rule-based, and quite unique in using SCLP

NOTER_PAGE: (11 . 0.5414599574769667)

Rules (vs. general code) provide a relatively high level of conceptual abstraction.

NOTER_PAGE: (12 . 0.12402551381998583)

Rules are especially good for specifying contingent provisions

NOTER_PAGE: (12 . 0.23245924875974486)

One may automatically reason about the contract/proposal by performing inferencing in the rule KR, for which computational tractability guarantees are available

NOTER_PAGE: (12 . 0.2678951098511694)

One may modify modularly, and thus relatively easily, the contract provisions: using prioritized defaults and rule modules

NOTER_PAGE: (12 . 0.783132530120482)

SweetRules enables bi-directional translation from SCLP RuleML

NOTER_PAGE: (14 . 0.3132530120481928)

The SCLP case of RuleML is expressively powerful.

NOTER_PAGE: (14 . 0.6009922041105599)

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.

NOTER_PAGE: (15 . 0.3997165131112686)

The SCLP KR has fairly attractive worst-case computational complexity

NOTER_PAGE: (15 . 0.7002126151665485)

The complexity, and scaleability, of Datalog SCLP KR is thus not much worse than that of SQL databases

NOTER_PAGE: (16 . 0.43656980864635014)

(SC)LP (i.e., RuleML) has one main expressive limitation, as compared to First Order Logic (FOL) – or to Description Logic: in LP one cannot conclude a disjunction (nor an existential).

NOTER_PAGE: (16 . 0.628632175761871)

FOL lacks nonmonotonicity

NOTER_PAGE: (17 . 0.24167257264351524)

FOL lacks procedural attachments

NOTER_PAGE: (17 . 0.27994330262225375)

although Epilog has operations, at least

4. MIT PROCESS HANDBOOK (PH)

NOTER_PAGE: (17 . 0.5124025513819986)

5. REPRESENTING THE PH PROCESS ONTOLOGY IN DAML+OIL

NOTER_PAGE: (22 . 0.1254429482636428)

6. CONTRACT ONTOLOGY

NOTER_PAGE: (29 . 0.666194188518781)

We view a contract as a specification for one or more processes.

NOTER_PAGE: (30 . 0.5683912119064494)

7. INTEGRATING DAML+OIL ONTOLOGIES INTO RULEML RULES

NOTER_PAGE: (33 . 0.6761162296243799)

RuleML rules are specified “on top of” the DAML+OIL ontology. This same approach also applies to OWL

NOTER_PAGE: (33 . 0.7476966690290574)

The high-level goal of rules “on top of” ontologies has been an important topic of discus- sion in the Semantic Web community, including in architecting standards, since at least 1998. (However, before our work here, this had not been operationalized with a specific technical approach.)

NOTER_PAGE: (34 . 0.20411055988660526)

what? really?

RuleML rules can reference DAML+OIL ontologies.

NOTER_PAGE: (34 . 0.46562721474131824)

the names of predicates appearing in the RuleML rules may be URI’s that reference (i.e., denote) classes and properties in a DAML+OIL ontology.

NOTER_PAGE: (34 . 0.49893692416725727)

the names of individuals appearing in RuleML rules may be URI’s for indi- viduals in DAML+OIL.

NOTER_PAGE: (34 . 0.5712260807937634)

the referenced DAML+OIL ontological knowledge base is viewed as a background theory for the rulebase

NOTER_PAGE: (34 . 0.6038270729978739)

A DAML+OIL property is treated in RuleML as a binary predicate.

NOTER_PAGE: (34 . 0.6931254429482636)

A DAML+OIL class is treated in RuleML as a unary predicate.

NOTER_PAGE: (34 . 0.6945428773919207)

Assertions about instances in a class are treated as rule atoms

NOTER_PAGE: (34 . 0.7271438695960312)

Assertions about property links between class instances are treated as rule atoms in which the property predicate appears.

NOTER_PAGE: (35 . 0.12473423104181432)

how to define formally the semantics of such integration, i.e., of the hybrid KR formed by combining LP rules on top of DL ontologies

NOTER_PAGE: (35 . 0.38199858256555635)

Description Logic Programs is a KR that captures a large subset of the expressive intersec- tion of Logic Programs and Description Logic.

NOTER_PAGE: (35 . 0.554925584691708)

Description Logic Programs are (contained in) the expressive intersection of Description Logic and Horn Logic Programs. DLP is thus a subset of FOL.

NOTER_PAGE: (36 . 0.36569808646350105)

What makes it challenging to define the semantics of hybridizing the LP and DL KR’s is the potential for incompleteness or inconsistency.

NOTER_PAGE: (36 . 0.6413890857547838)

expressively re- stricting the ontologies (or the rules) – to be in the Description Logic Programs (DLP) KR

NOTER_PAGE: (37 . 0.2076541459957477)

DLP can be viewed as an “ontology sublan- guage” within the full LP KR.

NOTER_PAGE: (37 . 0.27852586817859676)

The approach in [19] is, however, quite limiting for practical purposes since it does not permit predicates defined in the DL ontology to appear in the heads of the LP rules.

NOTER_PAGE: (37 . 0.5357902197023388)

8. RULEML CONTRACTS WITH EXCEPTIONS USING THE PROCESS AND CONTRACT ONTOLOGIES

NOTER_PAGE: (37 . 0.7597448618001418)

9. CONCLUSIONS: SUMMARY OF NOVEL CONTRIBUTIONS

NOTER_PAGE: (54 . 0.29978738483345146)

10. CURRENT AND FUTURE WORK

NOTER_PAGE: (57 . 0.335223245924876)

Notes

Abstract

SweetDeal is a rule-based approach to representation of business contracts

builds upon the situated courteous logic programs knowl- edge representation in RuleML

process knowledge descriptions whose ontologies are represented in DAML+OIL

process ontology knowledge from the MIT Process Handbook

1. INTRODUCTION

automates (parts or all of) such business contracts by repre- senting and communicating them as modular sets of declarative logic-program rules.

2. OVERVIEW OF THE REST OF THE PAPER

3. SWEETDEAL, RULEML, and SWEETRULES: MORE BACKGROUND

Contracts are represented using interoperable rules in XML. Declarative logic pro- grams (LP) are the fundamental knowledge representation (KR) in which these rules are expressed.

Rules represent part or all of an overall contract.

Modification of a contract rulebase can be performed modularly during negotiation or completion

Procedural attachments in the rules are used to perform external actions or queries

advantages of the SweetDeal approach. What are the compet- ing approaches to representing contracts?

SweetDeal is fairly unique in being rule-based, and quite unique in using SCLP

Rules (vs. general code) provide a relatively high level of conceptual abstraction.

Rules are especially good for specifying contingent provisions

One may automatically reason about the contract/proposal by performing inferencing in the rule KR, for which computational tractability guarantees are available

One may modify modularly, and thus relatively easily, the contract provisions: using prioritized defaults and rule modules

SweetRules enables bi-directional translation from SCLP RuleML

The SCLP case of RuleML is expressively powerful.

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 SCLP KR has fairly attractive worst-case computational complexity

The complexity, and scaleability, of Datalog SCLP KR is thus not much worse than that of SQL databases

(SC)LP (i.e., RuleML) has one main expressive limitation, as compared to First Order Logic (FOL) – or to Description Logic: in LP one cannot conclude a disjunction (nor an existential).

FOL lacks nonmonotonicity

FOL lacks procedural attachments

4. MIT PROCESS HANDBOOK (PH)

5. REPRESENTING THE PH PROCESS ONTOLOGY IN DAML+OIL

6. CONTRACT ONTOLOGY

We view a contract as a specification for one or more processes.

7. INTEGRATING DAML+OIL ONTOLOGIES INTO RULEML RULES

RuleML rules are specified “on top of” the DAML+OIL ontology. This same approach also applies to OWL

The high-level goal of rules “on top of” ontologies has been an important topic of discus- sion in the Semantic Web community, including in architecting standards, since at least 1998. (However, before our work here, this had not been operationalized with a specific technical approach.)

RuleML rules can reference DAML+OIL ontologies.

the names of predicates appearing in the RuleML rules may be URI’s that reference (i.e., denote) classes and properties in a DAML+OIL ontology.

the names of individuals appearing in RuleML rules may be URI’s for indi- viduals in DAML+OIL.

the referenced DAML+OIL ontological knowledge base is viewed as a background theory for the rulebase

A DAML+OIL property is treated in RuleML as a binary predicate.

A DAML+OIL class is treated in RuleML as a unary predicate.

Assertions about instances in a class are treated as rule atoms

Assertions about property links between class instances are treated as rule atoms in which the property predicate appears.

how to define formally the semantics of such integration, i.e., of the hybrid KR formed by combining LP rules on top of DL ontologies

Description Logic Programs is a KR that captures a large subset of the expressive intersec- tion of Logic Programs and Description Logic.

Description Logic Programs are (contained in) the expressive intersection of Description Logic and Horn Logic Programs. DLP is thus a subset of FOL.

What makes it challenging to define the semantics of hybridizing the LP and DL KR’s is the potential for incompleteness or inconsistency.

expressively re- stricting the ontologies (or the rules) – to be in the Description Logic Programs (DLP) KR

DLP can be viewed as an “ontology sublan- guage” within the full LP KR.

The approach in [19]​ is, however, quite limiting for practical purposes since it does not permit predicates defined in the DL ontology to appear in the heads of the LP rules.

8. RULEML CONTRACTS WITH EXCEPTIONS USING THE PROCESS AND CONTRACT ONTOLOGIES

9. CONCLUSIONS: SUMMARY OF NOVEL CONTRIBUTIONS

10. CURRENT AND FUTURE WORK

Notes that link to this note

The approach in [19] is, however, quite limiting for practical purposes since it does not permit predicates defined in the DL ontology to appear in the heads of the LP rules.