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.
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
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.
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.
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:
-
The contract
-
The original complaint
-
affidavits asserting that various activities specified by the contract
were performed
-
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]:
-
Federal laws preempt state laws
-
Laws passed recently preempt older laws
-
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>
- 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.
Copyright © 1999, Laurence L. Leff. All Rights Reserved. Legal XML Operating Rules apply.
|