Rule-Based System Tutorial for Legal XML Members

Document Number
UN_100XX_2001_05_10
Current Version
1.0 ( http://www.legalxml.org/DocumentRepository/UnofficialNote/Clear/UN_100XX_2001_05_10.htm )
Previous Version(s)
None.
Workgroup Information
Workgroup Name: Court Filing
Workgroup Chair(s): John Grecean, Moira Rowley
Workgroup Mailing List: courtfiling@legalxml.org
Workgroup Mailing List Archive: http://www.legalxml.org/Archive/CourtFiling.html
Workgroup Website: http://ww w.legalxml.org/CourtFiling/
Document Author(s)
Laurence L. Leff (mflll@wiu.edu)
Document Editor(s)
()
Short Statement of Status
Active

Abstract

A tutorial on Rule-Based Systems

Status of Document

This is a Legal XML Work Group Unofficial Note for review and discussion by interested Members.

Table of Contents

1. Introduction

	1.1 Problem
	1.2 Proposed Solution
	1.3 Assumptions
	1.4 Requirements
	1.5 Dependencies
	1.6 Definitions

2. Specification
        2.1 Conflicts

3. References

1. Introduction

We give a short tutorial, with appropriate links and references, to rule-based systems and XML. We specifically mention applications to the needs of the legal industry.

1.1 Problem

Every court has routine processing on the documents it receives. Examples include default judgment requests, garnishment orders, forcible detainers (evictions), continuance requests, etc.

There are already reports of applying automated reasoning to legal applications. L. Karl Branting used artificial intelligence in the drafting and justification for court documents. These include those produced by an appeals court after an appeal arrives such as the show cause order drafted when the notice of appeal is submitted after the specified time limit [Bra97]. Another example is the drafting of protection orders for pro se victims of domestic violence. It is in production use in three Idaho counties [Bra01]. Another system automatically converts legislation into an expert system [Al01]. The Credit Act Advisory System advises upon the Australian Credit act for banks [Str01].

When incoming documents are expressed in XML, this opens up the opportunity of having the computer performing this routine processing. One method by which one can specify this routine processing is a series of rules.

Many mail programs use a series of rules to specify the routing of input documents to folders. Sendmail, a very popular mail routing agent, has its own rule language for specifying the rewriting of RFC822 headers and other handling electronic mail by a mail server (SMTP) serving a large enterprise. [All97] Many municipalities in the Netherlands use rule-based processing for administering social assistance under their Social Security Act. [Osk97]

Rules can encapsulate expertise. A famous and early example is the Mycin system. On the basis of laboratory findings, it diagnosed blood diseases as well as top hematologists. [Buch84] When used in this fashion, systems that use rules, are known as expert systems. An important part of the success of an expert system is the ability to get the data it needs. MYCIN did not connect to the computers containing the patient laboratory results. This lead to its not being used. [Buch84] However, the data about the documents comprising a case can be encoded in the XML. This author has demonstrated expert systems that work with such XML [LEFF01]. Thus, there is an opportunity for Legal XML, Inc. to make Artificial Intelligence practical for Law. This would reduce costs for both courts and legal practitioners.

1.2 Proposed Solution

1.3 Assumptions

1.4 Dependencies

1.5 Requirements

1.6 Definitions

2. Specification

A rule-based system consists of a series of if-then statements.

A series of rules for processing a default judgment could be written in pseudo-English:

Rule One:
IF (defendant served) AND (NOT defendant submitted answer) AND (current day > defendant served date + 35) THEN
plaintiff is entitled to default judgment

Rule Two:
IF (plaintiff is entitled to default judgment) AND (NOT court-order delaying answer date) AND (plaintiff requested default judgment) THEN
issue default judgment order and route to judge for electronic signature

Notice that the reasoning is expressed as two rules. A rule-engine allows the user to specify them in either order. Had the user coded Rule Two first and then Rule One, the system would perform them in the correct order. In a conventional programming language such as COBOL, BASIC or Java, the order of the two if-then statements would be critical.

One could easily put these two rules in the correct order for such a language. However, modern legal practice would correspond to hundreds of rules, possibly authored by people with expertise in different parts of the problem. Having the system determine the correct order to try each rule makes it easier to implement such a system.

James Keane suggested to me in November that it would be advantageous to have the rules themselves coded in XML. I have done so leading to the results reported in [LEFF01].

The Rule ML group has a preliminary effort to encode rules in XML and to standardize same [RML01]. Using the DTD they posted on their web site, I encoded the rules above. However, I was unable to locate a "not" in their current operation, nor is their any standard method for comparing two numbers or dates, for example, to see if one date is after another. Nor do they provide any mechanism to mark up how the facts get set, e. g. a database connection or a connection to XML.


<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE rulebase SYSTEM "datalog.dtd">
<rulebase>
<if><atom>
<rel>EntitledDefaultJudgment</rel>
<var>plaintiff</var>
<var>defendant</var>
<var>case</var>
<var>date</var>
</atom>
<and><atom><rel>Served</rel>
<var>defendant</var>
<var>case</var>
<var>date</var>
</atom>
<not>
<atom><rel>SubmittedAnswer</rel>
<var>defendant</var>
<var>case</var>
</atom>
</not>
<atom><rel>Greater</rel>
<var>date</var>
<var>CurrentDate</var>
</atom>
</and>
</if>
<if>
<atom><rel>RouteDefaultJudgmentOrder</rel>
<var>defendant</var>
<var>case</var>
</atom>
<and>
<atom>
<rel>EntitledDefaultJudgment</rel>
<var>plaintiff</var>
<var>defendant</var>
<var>case</var>
<var>date</var>
</atom>
<not>
<atom>
<rel>
CourtOrderDelayingAnswer
</rel>
<var>defendant</var>
<var>case</var>
</atom>
</not>
<atom>
<rel>PlaintiffRequestedDefaultJudgment</rel>
<var>plaintiff</var>
<var>case</var>
</atom>
</and>
</if>
</rulebase>

I have been unable to find any rule system documentation other than my own [LEFF01] where the rules manipulate XML. My work involves the coding of rules that extract information from XML or that generates XML. I worked on two examples. The first is reasoning from contract data to a request for a default judgment. Four documents are read in:

  1. The contract
  2. The original complaint
  3. affidavits asserting that various activities specified by the contract were performed
  4. the request for default judgment.

The rules handle the situation where a business is suing for payment for goods and services. (These constitute 25% of all civil litigation. See [Leff01]). The computer will ensure that the plaintiff has asserted in affidavits that it completed each of its obligations. If so, and the plaintiff requested default judgment, the system will check that the amount asked for in the prayer is less than or equal to the amount specified in the contract. After checking for payments from the defendant, the software can generate a fact indicating default judgment should be awarded.

Here are some rules from that effort: The first sample rule shows extraction of payment from affidavit information. (Note that this involves mapping from Actor ID to human names.)


<Rule Name="RuleFour" Documentation = "Same as Rule Three but Payment">
<LHS>
<Check DocumentName="VariableName:dFour">
<assert>
<Template><TemplateName>RealName</TemplateName>
<Slot><SlotName>PartyName</SlotName><Value><Variable>ByParty</Variable>
</Value></Slot>
<Slot><SlotName>HumanName</SlotName><Value><Variable>ByRealName</Variable>
</Value></Slot></Template></assert></Check>
<Check DocumentName="VariableName:dFour"><Offer ID="VariableName:ContractID">
<Clause By="VariableName:ByParty" To="VariableName:ToParty"
ID="VariableName:ClauseID">
<Pay><TextVariable VariableName="Amount"/></Pay></Clause></Offer></Check>
<Check DocumentName="VariableName:dFour"><assert><Template>
<TemplateName>RealName</TemplateName>
<Slot><SlotName>PartyName</SlotName>
<Value><Variable>ToParty</Variable></Value> </Slot>
<Slot><SlotName>HumanName</SlotName><Value><Variable>ToRealName</Variable>
</Value></Slot></Template></assert></Check>
</LHS>
<RHS>
<Action>
<assert>
<Template><TemplateName>MustPay</TemplateName>
<Slot><SlotName>DocumentName</SlotName>
<Value><Variable>dFour</Variable></Value></Slot>
<Slot><SlotName>By</SlotName>
<Value><Variable>ByRealName</Variable></Value></Slot>
<Slot><SlotName>To</SlotName>
<Value><Variable>ToRealName</Variable></Value></Slot>
<Slot><SlotName>ContractID</SlotName>
<Value><Variable>ContractID</Variable></Value></Slot>
<Slot><SlotName>ClauseID</SlotName>
<Value><Variable>ClauseID</Variable></Value></Slot>
<Slot><SlotName>Payment</SlotName>
<Value><Variable>Amount</Variable></Value></Slot>
</Template>
</assert>
</Action>
</RHS>
</Rule>

This clause matches up the obligations extracted from the contract and the information in the "assert" clause of an affidavit.


<Rule Name="RuleSeven" Salience="-97" Documentation="See if there are any obligations that were not met">
<LHS>
<Check>
<assert>
<Template><TemplateName>Complaint</TemplateName>
<Slot><SlotName>Plaintiff</SlotName>
<Value><Variable>Plaintiff</Variable></Value></Slot>
<Slot><SlotName>Defendant</SlotName>
<Value><Variable>Defendant</Variable></Value></Slot>
<Slot><SlotName>LawsuitNumber</SlotName>
<Value><Variable>I</Variable></Value></Slot>
</Template>
</assert>
</Check>
<And>
<Check><assert>
<Template><TemplateName>Obligation</TemplateName>
<Slot><SlotName>ContractID</SlotName>
<Value><Variable>c</Variable></Value></Slot>
<Slot><SlotName>ClauseID</SlotName>
<Value><Variable>CID</Variable></Value></Slot>
<Slot><SlotName>By</SlotName>
<Value><Variable>Plaintiff</Variable></Value></Slot>
<Slot><SlotName>To</SlotName>
<Value><Variable>Defendant</Variable></Value></Slot>
</Template>
</assert>
</Check>
<Not>
<Check>
<assert>
<Template><TemplateName>ObligationMet</TemplateName>
<Slot><SlotName>ContractID</SlotName>
<Value><Variable>c</Variable></Value></Slot>
<Slot><SlotName>ClauseID</SlotName>
<Value><Variable>CID</Variable></Value></Slot>
</Template>
</assert>
</Check>
</Not>
</And>
</LHS>
<RHS>
<Action>

The second application is processing requests for default judgment in a court.

In this set of rules, information is extracted from the Sheriff's Service information and the Default Judgment requested. The rules look for an answer.

Finding none, the rules compare the date of service with the date that default judgment was requested. If 35 days elapsed, the software generates a default judgment request. The rule below shows how XML to be generated is expressed in XML. See the Action tag at the end.


<Rule Name="RuleSix" Documentation="If entitled to default judgment but there is no answer to be found">
<LHS>
<Check>
<assert>
<Template><TemplateName>DateOfDefaultJudgmentRequest</TemplateName>
<Slot><SlotName>PlaintiffName</SlotName>
<Value><Variable>P</Variable></Value></Slot>
<Slot><SlotName>DefendantName</SlotName>
<Value><Variable>D</Variable></Value></Slot>
<Slot><SlotName>CaseNumber</SlotName>
<Value><Variable>C</Variable></Value></Slot>
<Slot><SlotName>Principal</SlotName>
<Value><Variable>Principal</Variable></Value></Slot>
<Slot><SlotName>AttorneysFees</SlotName>
<Value><Variable>AttorneysFees</Variable></Value></Slot>
<Slot><SlotName>PreJudgmentInterest</SlotName>
<Value><Variable>PreJudgmentInterest</Variable></Value></Slot>
</Template>
</assert>
</Check>
<Check>
<assert>
<Template><TemplateName>EntitledToDefaultJudgment</TemplateName>
<Slot><SlotName>DefendantName</SlotName>
<Value><Variable>D</Variable></Value></Slot>
<Slot><SlotName>CaseNumber</SlotName>
<Value><Variable>C</Variable></Value></Slot>
</Template>
</assert>
</Check>
<Not>
<Check>
<Answer>
<DefendantList><Defendant>
<TextVariable VariableName="D"/></Defendant></DefendantList>
<CaseNumber><TextVariable VariableName="C"/></CaseNumber>
</Answer>
</Check>
</Not>
</LHS>
<RHS>
<Action>
<DefaultJudgment>
<PlaintiffList>
<Plaintiff><AnyContentVariable VariableName="P"/></Plaintiff>
</PlaintiffList>
<DefendantList>
<Defendant><TextVariable VariableName="D"/></Defendant>
</DefendantList>
<CaseNumber><TextVariable VariableName="C"/></CaseNumber>
<Principal><TextVariable VariableName="Principal"/></Principal>
<AttorneysFees><TextVariable VariableName="AttorneysFees"/></AttorneysFees>
<PreJudgmentInterest>
<TextVariable VariableName="PreJudgmentInterest"/>
</PreJudgmentInterest>
</DefaultJudgment>
</Action>
</RHS>
</Rule>

Experience indicates that incoming court filings and court documents will have errors [GR01]. Obviously, rules automatically generating judgments and orders would generate erroneous documents when the input documents had errors. Some of these checks might be done by the rule-based system more effectively than humans, e. g., confirming that names in a motion matched those on case-initiation.

However, human checks would be needed to prevent others. In some courts, documents might routed via workflow systems to clerks or staff attorneys to check the input for reasonability before further processing is done. Or the generated document would be routed to a judge who would examine it before being electronically signing it and making it official. That approach is envisioned in the default judgment project mentioned above.

2.1. Conflicts

An important issue in rules for legal work is conflicts.

In the criminal domain, one might have a rule defining the offense of burglary.
if EnterLocation(?person,?location,?time) & NoPermission(?person.time) &      ForcibleEntry (?person,?location,?time)
then
     CommittedBurglary(?person,?location,?time)

And we might have a rule that Burglary is a crime:

if CommittedBurglary(?person,?x,?time) then
     Crime(?person,?time)

And we might have a general rule that people are not criminals at a time they were under the Compulsion of Deadly Force:
if CompulsionDeadlyForce(?person,?time) then
     Not Crime (?person,?time)

Of course the combination of rules one and two conflict with rule three.

One solution would be to require every rule writer to include specific not conditions to cover all the exceptions. That is, Rule Two might have been coded as:
if CommittedBurglary(?person,?x,?time) & Not CompulsionDeadlyForce(?person,?time) then
     Crime(?person,?time)

Of course, it is tedious to have to code every exception. In this example, it would be tedious to have to write the exception for being under compulsion of deadly force for each crime. More importantly, it is not possible for a rule writer to be aware of all the exceptions to a given rule.

Thus, many researchers in legal argumentation and legal reasoning allow the assertion of a rule and an exception. Of course, the software must know about conflict resolution strategies. One can encode rules that determine which rule has priority when two rules conflicts.

In law, three popular rules for conflict resolution strategies are [Gord95]:

  1. Federal laws preempt state laws
  2. Laws passed recently preempt older laws
  3. More specific information have priority over those that are less specific.

Other researchers have built software that manipulates rules for argumentation purposes. They allow one party to assert a statement, and then the other party can determine a feasible exception or undercutter for the general rule that the first party proposed. The software tracks the order of arguments in a graphical manner [Loui97], [Ver99]. A review of this field can be found in [Loui00].

The conflict resolution problem is important in contracting and in defining business policies.

These two rules show a simple conflict in a business setting.

If OrderAmount(?person,?amount,?order) & greater (?amount,1000) then
     Discount(?person,?order,0.05)

If LatePay(?person)
     Discount(?person,?order,0.00)

The condition of one if might be checked in another if. For example, one might have a rule for determining LatePay
If PaymentReceived(?person,?p,?day) & greater (?day,90) then
     LatePay(?person)

Obviously, a layperson would see the conflict in two or three rules after manual inspection.

A business might have a series of sixty rules. Several different departments might have contributed to that set. In this situation, hidden conflicts might escape even the most careful human inspection.

Dr. Grosof has developed algorithms and software to read such rules and identify any conflicts automatically [Gro97], [Gro99]. He also developed a DTD and XML markup for expressing the kind of rules expressed above [Gro99]. Thus, his CommonRules Software, downloadable from alphaworks.ibm.com, reads rules expressed in XML, and checks them for inadvertant conflicts.

I encoded the rules from the above example using that DTD. Observe that each rule consists of a head tag and a body tag. The head tag is first. The conditional or if part is second. This is the opposite of the if-then-else form with which many are familiar. The expert systems OPS-5 and Jess and the one I wrote have the conditional part first. Prolog and the Common Rules DTD have the result first.


<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE clp SYSTEM "brml.dtd">
<clp>
<erule rulelabel="RuleOne">
<head>
<cliteral predicate="Discount">
<function name="percent5"/>
<variable name="?person"/>
<variable name="?order"/>
</cliteral>
</head>
<body>
<and>
<fcliteral predicate="OrderAmount">
<variable name="?person"/>
<variable name="?amount"/>
<variable name="?order"/>
</fcliteral>
<fcliteral predicate="greater">
<variable name="?amount"/>
<string value="1000"/>
</fcliteral>
</and>
</body>
</erule>
<erule>
<head>
<cliteral predicate="Discount">
<function name="zeropercent"/>
<variable name="?person"/>
<variable name="?order"/>
</cliteral>
</head>
<body>
<fcliteral predicate="LatePay">
<variable name="?person"/>
</fcliteral>
</body>
</erule>
</clp>




4. References

Al01
Allen, R., Chung, P., Mowbray, A., Greenleaf, G., "AustLII's Aide - Natural Language Legislative Rulebases," in The Eighth International Conference on Artificial Intelligence and Law: Proceedings of the Conference, May 21-25, 2001, Washington University, St. Louis MO USA, The Association of Computing Machinery, 2001, 223-224.
All97
Costales, B. and Allman, E., sendmail, 2nd Edition, O'Reilly Press, 1997.
Buch84
Buchanan, B. G., Shortliffe, E. H. Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heuristic Programming Project, Addison-Wesley, Reading, Massachusetts, 1984.
Bra97
Branting, L. K., Lester, J. D., Callaway, C. B., "Automated Drafting of Self-Explaining Documents," in The Six International Conference on Artificial Intelligence and Law, Proceedings of the Conference, June 30-July 3, 1997, The University of Melbourne Law School, Melbourne, Australia, The Association of Computing Machinery, 1997, 72-81.
Bra01
Branting, L. K., "Advisory Systems for Pro Se Litigants," in The Eighth International Conference on Artificial Intelligence and Law: Proceedings of the Conference, May 21-25, 2001, Washington University, St. Louis MO USA, The Association of Computing Machinery, 2001, 139-146.
Gr01
Grecean, J., Communication at the May 31-June 1, 2001 Legal XML Court Filing Workgroup Face-to-Face.
Gord95
Gordon, T., The Pleadings Game, Kluwer Academic Press, 1995
Gro97
Grosof, B. N., "Courteous Logic Programs: Prioritized Conflict Handling for Rules," IBM Research Report RC20836, December 30 1997 (expanded from Proceedings of the International Symposium on Logic Programming (ILPS-97), edited by Jan Maluszynski, MIT Press, Cambridge, MA, USA, pages 197-211. Held Port Jefferson, NY, USA, Oct. 12-17, 1997)
Gro99
Grosof, B. N. "An Approach to Using XML and a Rule-based Content Language with an Agent Communication Language," IBM Research Report RC 21491, May 28 1999. (http://www.research.ibm.com/rules/paps/rc21491.pdf)
Leff01
Leff, L., Automated Reasoning With Legal XML Documents, (http://www.wiu.edu/users/mflll/AILAW.PDF), 2001
Also, see two other papers by the same author: "Automated Reasoning With Legal XML Documents," Proceedings of the International Conference on Artificial Intelligence in Law, St. Louis, May 21-25, 2001
and "Rule Processing in the Legal XML Context," Proceedings of the Workshop on Practical AI in Law, St. Louis, May 21 2001.
Loui97
Loui, R. P. et. al., "Progress on Room 5," in The Six International Conference on Artificial Intelligence and Law, Proceedings of the Conference, June 30-July 3, 1997, The University of Melbourne Law School, Melbourne, Australia, The Association of Computing Machinery, 207-214, 1997.
Loui00
Chesnevar, C. I., Maguitman, A. G., and Loui, R. P., "Logical Models of Argument," ACM Computing Surveys, Vol. 31, No. 4, 337-383, Dec 2000.
Osk97
Oskamp, A. and Tragter, M., "Knowledge for Automated Legal Problem Solving: Theory Versus Practice," in The Six International Conference on Artificial Intelligence and Law, Proceedings of the Conference, June 30-July 3, 1997, The University of Melbourne Law School, Melbourne, Australia, The Association of Computing Machinery, 142-150, 1997.
RML01
Boley, H., Grosof, B., Tabet, S., Rule ML DTDs, 2001-01-25, Version 0.7 (www.dfki.uni-kl.de/ruleml/indtd.html)
This document has an excellent set of links to rule-based activities of interest to this membership.
Str01
Stranieri, A., Zeleznikow, J., "The Use of Legal Knowledge Based Systems at Victoria Legal Aid," Legal Knowledge Systems in Action: Practical AI in Today's Law Office, Proceedings of the ICAIL-2001 Workshop," May 21, 2001, St. Louis, MO, pages 12 - 26, 2001.
Ver99
Verheij, B., "Automated Argument Assistance for Lawyers," in The Seventh International Conference on Artificial Intelligence and Law: Proceedings of the Conference, June 14-18, 1999, The University of Oslo, Norway, Association for Computing Machinery, New York, NY, 1999.

Sponsored by FindLaw and Georgia State University Electronic Court Filing Project