Ratio Juris. Vol. 3 No.

2 July 1990 (201-18)

copyright 0 Robert Kowalski and Marek Sergot 1990

The Use of Logical Models

in Legal Problem Solving*
ROBERT KOWALSKI AND MAREK SERGOT

Abstract. The authors describe a logic programming approach to the representation of

legislative texts. They consider the potential uses of simple systems which incorporate
a single, fixed interpretation of a text. These include assisting in the routine administration
of complex areas of the law. The authors also consider the possibility of constructing
more complex systems which incorporate several, possibly conflicting interpretations.
Such systems are needed for dealing with ambiguity and vagueness in the law. Moreover,
they are more suitable than single interpretation systems for helping to test proposed
legislation and for helping to give citizens advice.

1. Introduction
Within the Logic Programming Group at Imperial College the domain of law
is seen as a primary source of applications. These applications are intended both
to demonstrate and test developing techniques of logic programming, and to
suggest and motivate future extensions. In general terms, our approach can be
summarised as follows. We take some legislative text, typically a statute o r a
set of regulations, and represent its provisions in a formal, logical language.
(More precisely, given the nature of the language in which the original legislation
is expressed, we represent particular interpretations o r readings of these pro-
visions.) We thus obtain a logical representation of what the legislation expresses
(or again, more precisely, of what we think it is that the legislation expresses).
We construct in effect a model of the law which captures the essential feature
of interest and which can be executed or manipulated to support tasks related
t o the legislation.

* The work reported here was supported by the Science and Engineering Research Council. We
are happy to acknowledge the contributions of our colleagues Trevor Bench-Capon, Kave Eshghi,
Gwen Owen Robinson, Tom Routen, Fariba Sadri, Uri Schild, Murray Shanahan and David
Wolstenholme.
202 Robert Kowalski and Marek Sergot

In this paper we also refer to these representations as "logical models" of the

law: "model" because the representation stands for or imitates the law, and
"logical" because it comprises expressions of formal logic. (The phrase is poten-
tially confusing. The term "model" has a technical meaning in logic which we
do not intend here. Similarly "interpretation" is used throughout this paper in
its ordinary, natural sense.) We use the term "logical model" in a similar sense
to the use of the term "mathematical model" in engineering. In the same way
that a mathematical model is an idealisation of a problem domain, a logical
model of the law is an idealisation which captures only certain features of the
law, while ignoring others.
Several projects have been undertaken to establish the fitness of the approach
just outlined. The most widely known of these is the project relating to the British
Nationality Act 1981 (Sergot et al. 1986). A more detailed account of the
approach, and references to other smaller scale projects undertaken at Imperial
College, are provided by Sergot (1985). Recent projects include those described
by Stathis (19871, Lakhani (1988)and Roberts (1988).We have also been engaged
in a representation of a substantial part of the United Kingdom's Law Relating
to Supplementary Benefits and Family lncome Supplements ('The Yeliow Book')
incorporating both Acts of Parliament and statutory instruments (Bench-Capon
et al. 1987).
In previous accounts of our work on the applications of logic programming
to law, we have tended to emphasize the computational aspects of our approach.
We have been concerned with describing how logic programming techniques
can be used to build substantial applications in law, how the use of these tech-
niques compares with other approaches, and how we might overcome some
of the specific problems of representation that arise. In this paper, we want to
emphasize the nature of the applications that can be built, rather than present
details of the computational techniques involved.
Specifically, our aims in this paper are: (i) to summarise how logical models
of the law can be used to build practical systems; ( i i ) to describe some of the
possible applications of such models, and (iii) to indicate what can and what
cannot be expected of them.
We do not wish to imply that ours is the only group which is investigating
the use of logic programming in law. For example, there are several groups
throughout the world who are using the programming language PROLOG for
a variety of legal applications. Nor are we suggesting that logic programming
is the only computational technique that can be applied to various aspects of
the law. There is an extensive literature on these and related topics and a survey
is beyond the scope of this paper. A summary and comparison of the main
approaches is provided by Sergot (1987).
 The Use of Logical Models in Legal Problem Solving 203

2. Logical Models of the Law

There are many systems of formal logic. O u r "first generation" systems have
been based on the translation of legislation into a form of symbolic logic called
extended Horn clauses. Extended Horn clauses have the form of rules

A if B a n d . . .and C

where the conclusion A expresses an atomic relationship and the conditions B

and. . .and C express atomic relationships or negations of atomic relationships.
For example, the rule

x becomes a British citizen by section l.la

if x was born in the United Kingdom on date y
and date y is on or after Commencement
and x has a parent z
and z is a British citizen by section w on date y

is one representation of the first clause of the British Nationality Act 1981, which
states

A person born in the United Kingdom after commencement shall be a British citizen
if at the time of birth his father or mother is -
(a) a British citizen; or. . .

Commencement, the date on which the Act came into effect, was 1January 1983.
Extended Horn clauses are the basis for logic programming, and for the
programming language PROLOG. The rule above which represents the first
clause of the British Nationality Act, for example, runs as a procedure when
executed by PROLOG. One such procedure is -

to show person x becomes a British citizen by section 1.l.a of the Act:

show x was born in the United Kingdom,
find the date of birth y,
show y is after Commencement (1January 1983),
find a parent z of x, and
show z is a British citizen by some section w of the Act on date y.

In theory, PROLOG can be used to execute a collection of such rules directly.

In practice, it is preferable to use an "inference engine," such as APES (Hammond
and Sergot 1983). APES is an augmented form of PROLOG which can auto-
matically query the user for information about particular individuals, and
explain the reasoning used to draw its conclusions.
Our work has concentrated almost exclusively on providing systems which,
presented with a description of some real or hypothetical state of affairs, can
be used to determine whether some specific legal consequences would seem to
follow. The most obvious application of the British Nationality Act program, for
204 Robert Kowalski and Marek Sergot

example, is to test whether a given individual is or is not a British citizen

according to (a given interpretation of) the Act. There is no fundamental reason,
however, why the same representations should not be used for other legal
problem solving tasks: in systems which plan or advise on a sequence of legal
transactions to achieve some desired goal, or to help identify for a lawyer
possible lines of reasoning and argumentation, or in systems which are intended
to help in the formulation of legislation itself. The rest of the paper expands
on some of these possibilities.
First, however, it needs to be emphasized that we are concerned primarily with
constructing logical models which represent statutes or sets of regulations. We
are not concerned in this paper with the much more difficult problem of reason-
ing by means of cases, which is the main mode of reasoning in common law.
However, statute law and case law interact, particularly over the treatment of
vague concepts. In statute law, vague concepts (such as "being of good character,"
"intending to reside in the United Kingdom," or "having sufficient knowledge
of English') either are given a precise definition in terms of other concepts or,
more frequently, are left entirely undefined. In our construction of a logical
model of a given statute, we simply copy its treatment of these vague concepts.
If a concept is left undefined in the statute, it is left undefined in the logical model.
This, of course, means that for such a model to be used in practice, either
the user has to decide for himself whether or not a given undefined predicate
is deemed to hold, or else he must accept the fact that many, if not most, of
the conclusions derived from the model will be qualified by conditions still to
be decided. Thus a typical conclusion which might be derived as an answer
to the question
'Is Mary entitled to naturalise as a British citizen?'
might be
'Yes, if
she is of good character,
intends to reside in the U.K.,
has sufficient knowledge of English, and
the Secretary of State approves.'
To do more than this would require augmenting the logical model with additional
rules not present in the statute. These might be rules which represent the opinion
of some legal expert or they might be rules derived more formally from decisions
made in previous cases. This is the most common way that statute law interacts
with case law. We will have more to say about improving the treatment of
undefined, vague concepts towards the end of this paper.

3. Aids in the Routine Administration of Law

The most obvious way to use a logical model of legislation is to execute it directly
as a program in PROLOG, or in APES, or by means of some other "inference
 The Use of Logical Models in Legal Problem Solving 205

engine." This yields a program which can determine what consequences follow
logically from the model given some particular state of affairs. We thus obtain
a program which can be used for the routine application or administration of
the provisions from which we started. If executed by a system such as APES,
the program will automatically ask for information which is missing, and it
will be capable of explaining and justifying its conclusions.
What we have described is a program which operates by blind, mechanical
application of its rules. It follows that such a program is appropriate only in
areas of the law where we are interested in providing a system which routinely
applies a set of complex regulations without questioning their legal basis. To
avoid any misunderstanding, we state explicitly that most legal reasoning is
concerned with a different problem, namely that of identifying, interpreting
and reconciling the relevant legal sources (statutes, case reports and other sources
of law) and thus of determining what legal rules should apply, rather than the
much easier problem of actually applying the rules once they have been iden-
tified. Nevertheless, in the day to day practice of law, there are many situations
where routine tasks do have to be performed, and where rules and regulations
do have to be applied mechanically. When the rules and regulations involved
in these tasks are complex, then a system which can perform most of the detailed
routine work can be of significant help, even though it is addressing only the
most straightforward aspect of the legal decision making process.
The use of such a program does not imply handing over the responsibility
for making decisions to the computer. The program might be used instead to
check decisions and conclusions drawn independently by its user. Consider for
example the assessment of claims for Social Security benefits. A program could
"look over the shoulder" of the official assessing the claim, and compare his
calculations against its own model of the relevant legislation. When the two
disagree, the official might want to accept the advice given by the system;
alternatively, he might decide that there are additional factors in the case at
hand which have to be taken into account and that the advice given by the
system needs to be rejected.
Except perhaps for the ease of generating explanations, it would of course
be possible to build functionally identical programs for these routine applications
by using conventional programming techniques. Such programs are commonly
used already. A payroll program that automatically deducts the prescribed
amount of income tax from an employee's net monthly salary is an example.
Nevertheless, the approach that we are advocating does have significant advan-
tages over the use of conventional programming techniques, even for these
routine administrative tasks.
Conventional programs for legal applications incorporate representations of
the relevant rules and regulations into the routines which are used to apply the
regulations, This is a direct consequence of the nature of conventional pro-
gramming languages, which are designed to express how a program should
behave, rather than what it should compute. It is difficult or impossible to take a
206 Robert Kowalski and Marek Sergot

conventional program for some legal application and point to some part of it
and say "Here is the legislation." In contrast, a logic program for the same task
keeps its representation of the legislation (the logical model of the law) distinct
from the routines which make use of the legislation (the inference mechanism).
Compared with conventional programs, this means that logic programs (and
other programs implemented by means of the same techniques) are: easier to
build; easier to modify and maintain as the legislation changes; easier for a
human to interact with, by supplying missing information as it is required and
by obtaining explanations; and easier to understand and assess for accuracy.
(These advantages are relative. We are not claiming that such programs are
easy to build and we are not claiming that they are always easy to modify and
maintain. )
The understandability of a program is important for reasons other than simply
assessing its accuracy. For in many applications in law, no matter how trivial
or routine, it will be critical that the assumptions on which the program is based,
and the legal sources from which these are derived, should be open to scrutiny
and critical assessment. Without this possibility users are condemned to accept
the workings of a program at face value, and to rely to an unacceptable degree
on the legal skill of its author. Note also that we prefer to speak of the "accuracy"
of a program, rather than its "correctness." "Correctness" would suggest that
there is some objective notion of a correct reading of the law.
The approach as we have described it so far does not provide the ability to
construct programs for applications in law which are fundamentally different
from those we could construct with conventional programming techniques.
Rather, it provides us with a better method for constructing such programs,
with the ability to make these programs more flexible, and with the opportunity
to increase the range of applications we could tackle in practice. One of the
principal aims of our representation of the British Nationality Act was to
demonstrate the computational feasibility of applying logic programming tech-
niques in a realistically-sized application, and to show that this could be done
without compromising the "logical purity" of the underlying representation.
Certainly, the British Nationality Act is a particularly simple example of
legislation, where many of the complications (such as the absence of case law
when we embarked on our implementation) were either absent or could be
ignored. It is the relative absence of these complicating factors which influenced
our choice of the British Nationality Act at the outset.
The British Nationality Act, inoreover, is small in comparison with some
legislation. But it is also substantially larger and more complex than many of
the fragments that have to be represented when building a useful system for
the routine administration of some very specific aspect of some particular part
of the law. We feel that our representation of the British Nationality Act has
demonstrated the feasibility of constructing similar programs in many areas of
administrative law, and this is further supported by our representation of other
fragments of legislation (see earlier references to other projects).
 The Use of Logical Models in Legal Problem Soloing 207

Before considering other uses to which we might put a logical model of the
law, it is important to make one further qualifying remark. Our representation
of the British Nationality Act was undertaken with no expert legal assistance.
Our model of the Act expresses a layman's reading of the provisions. This in
itself renders our British Nationality Act program of limited practical value.
We could not use it in its present form for solving problems of British citizen-
ship in actual legal practice.
To construct a program dealing with the British Nationality Act that could
be used in practice, it would be necessary to enlist the help of an expert lawyer,
preferably several experts on citizenship and immigration law. We did not enlist
the help of such experts, partly because we had no access to this expertise, and
partly because we were interested to see to what extent it would be possible
to understand and apply the provisions of the British Nationality Act by
considering only its common sense or "layman's" reading. Access to an expert
adviser might well have changed the exact form of the rules in our program,
but it would not have changed the method we used to formulate and compute
with the rules.
Of course, if a program is to be used in practice, then expert legal advisers
are indispensable. Their role is to check the formulation for accuracy, to advise
on the reading of the various provisions, and to point to simplifications and
misunderstandings.
It is naturally most convenient if there is access to such an expert adviser
from the very beginning, and throughout the process of formulating the legisla-
tion as logical rules. This is not always realistic, given the demands on the time
of an expert lawyer and the costs of employing the services of such a person.
An alternative we have tried in other collaborative projects is to involve the
expert adviser primarily towards the end of a project. Apart from an initial
consultation to identify potential difficulties and misunderstandings, and
occasional meetings to clarify specific points, it is often possible to produce a
prototype representation, concentrating particularly on the computational
aspects of the formulation. At this stage, once the prototype is virtually
complete, the expert adviser can scrutinise and adjust the representation in the
light of his knowledge of the law. Note that whatever method is used, it is easier
to benefit from the advice of an expert when the underlying representation of
the law is explicit, laid open for examination, and separated from the computa-
tional procedures that apply it.
There is a further role for an expert adviser, which again we can illustrate
by reference to our British Nationality Act program. There may be several areas
in which an expert adviser might want to extend or modify our program to
provide a more useful practical system. He might want to include rules, for
example, to indicate what some of the vague concepts appearing in the Act but
not explicitly defined there are actually taken to mean in practice. He might
also want to draw on his experience, to advise on the best way of applying
the rules for particular kinds of users. He might recommend questions to ask
208 Robert Kowalski and Marek Sergot

early in the consultation, and questions to delay or avoid asking altogether.

Again, in the case of the British Nationality Act project, we did not incorporate
such additional expertise in our program, since our aim was to investigate the
computational feasibility of the approach rather than to construct a finished
system designed for a particular class of user. Experience in other projects, and
with applications in other domains, suggests that there are no outstanding
technical obstacles which need to be overcome to finish off a program in this
way, but that this stage of the process can often involve a considerable amount
of work and extra programming effort.

4. Other Uses of the Model

So far we have discussed the use of logical models of the law for constructing
programs to help with the application of routine aspects of administrative law.
We have laid particular emphasis on the importance of separating a represen-
tation of the law from the inference mechanisms that apply this representation
for some given purpose. This separation has practical significance, even for
relatively simple applications. But it also makes possible the use of logical models
of the law in more ambitious systems that address other parts of the legal
problem-solving process. In the following two sections we consider more
ambitious uses of logical models: to aid the drafting of legislation and to aid
the expert lawyer.
In this section we consider the possibility of using the same logical model
of the law in different systems intended for different kinds of users. Consider
Social Security legislation for example. One system might be tailored for govern-
ment officials who must administer the law, assess claims for benefit, and process
applications. A different system in the same general area might be required by
an agency whose task is to advise citizens on their various entitlements and
help them to formulate applications which have the greatest chance of success.
That the two systems have different requirements should be clear. The govern-
ment officials’ system will probably be more detailed. It will need to incorporate
a representation of various supplementary regulations, and of the local pro-
cedures, directives and guidelines that officials must take into account when
processing claims. The citizens’ advice system will not be concerned with such
detail. (And even if it were, it is unlikely that a government department would
be willing to make public all the internal regulations which it issues to its officers.)
Instead, the citizens’ advice system will require a broader coverage of the same
area of law. This might have to be augmented with an indication of what the
government’s attitude has been in the past, what the current policy seems to
be, and what chances a particular claimant has of having a claim accepted. It
might also be required to advise on courses of action which would increase the
chances of success.
As we indicated earlier, there would seem to be no reason why we could not
build these various systems separately. But we can expect that the two systems
 The Use of Logical Models in Legal Problem Solving 209

would overlap to a substantial extent, and that at the core of both systems would
be a representation of the relevant published legislation. It would be redundant
to construct this core representation twice. Certainly, the idea that we could
base both systems (and any others that might arise) on a single representation
of the relevant legislation is an attractive one. It is possible to illustrate how
this might be done on "toy" examples. But it remains to be seen how this works
out in practice in real applications. It could be that in a real application adding
the various supplementary representations causes such disruption to the common
model that we might just as well have built the two systems separately in the
first place. Although we gave Social Security legislation as an example, it should
be clear that the same considerations apply in all areas of the law. For a system
which helps to administer the law will always have different requirements from
a system which is used to help advise a client how best to prepare and present
his case.
Separating a model of the law from the routines that apply it makes it possible
to use the same model of the law with different modes of execution. For example,
both PROLOG and APES work by reasoning backwards from a conclusion we
want to establish to data we have available or that can be made available by
the user. As an alternative, it is also possible to reason forwards instead, looking
for conclusions we can draw from the available data. Forward reasoning as a
way of executing logic programs is especially attractive for deductive databases,
both for answering queries (e.g., Zaniolo 1988) and for checking new data for
consistency (e.g., Sadri and Kowalski 1988).
Other, more sophisticated theorem-proving techniques can also be used to
execute models of the law. However, implementing each new mode of execution
from scratch is unlikely to be cost-effective. Instead, it is much more attractive
to develop a range of programming "shells" with the functionality to support
these alternative modes of use. A "sheil" refers here to the inference mechanism
that executes the logical model, together with the auxiliary routines and facilities
required for the construction of finished applications. Programming "shells"
developed for legal applications can often be used in other application domains
as well. Again, we see in the law an ideal domain in which to develop a range
o f logic programming shells and test them out on substantial applications.

5 . Drafting Aids
In addition to these alternative ways of using a given logical model of the law,
we are also interested in the use of logical models at the drafting stage and in
the formulation of policy. Such uses of logical models of the law resemble uses
of executable specifications in Software Engineering. A specification in Software
Engineering is a precise description of what it is that a computer system is
supposed to do. Specifications are formulated at the design stage. Once they
are complete, they are used to drive the concrete implementation of the system
in terms of the chosen programming language. Specifications which are also
210 Robert Kowalski and Marek Sergot

executable in their own right are particularly useful, because they can be used
to illustrate the effects of proposed modifications, and to test that the final system
will indeed do what the user expects it to do. There is an obvious analogy in
law. One can imagine how a draftsman who is charged with formulating a piece
of new legislation or with modifying an existing piece might use an executable
model of his current draft to test that it “does” what he intended. He could
have available, for example, a library of stereotypical cases on which he can
try out changes to his current draft.
Analogies come to mind. An engineer who is designing a new bridge will
construct a computer model (usually a whole range of them) to test out various
aspects of the design (that the bridge would support its intended load, that it
would be possible to maintain, that it would not affect local road traffic
adversely, that the cost of building it would not exceed the budget, and so on).
There will always be aspects of the design that are impossible to test (how fast
the joints will corrode, for example). But no engineer would contemplate actually
building the bridge until all the tests that are possible had been completed. We
believe that there is now at least the possibility of making similar computer
models available to a legal draftsman.
Such computer models for the draftsman need not be limited to stimulating
the effect of legislation on a library of stereotypical cases. Mechanical theorem-
provers might be used to derive logical consequences from a logical model
representing the current or proposed new draft of a piece of legislation. One
use of this capability might be to test whether the legislation does possess
intended general properties - for example, whether a proposed (imaginary) Social
Security amendment has the intended effect of entitling all persons over a given
age to a pension under the new scheme. A failure to establish that such a general
property holds would identify mistakes or gaps in the legislation, suggesting
in turn how the defective draft might be improved.
The analogous use of theorem-provers to derive general properties of pro-
grams and program specifications is beginning to become practical in Software
Engineering. Indeed, the programming language PROLOG itself has its roots
in this work, and can be regarded as a theorem-prover of a particularly simple
kind. Viewed as a theorem-prover, PROLOG is too limited to support these
applications, but existing theorem-provers more general and more sophisticated
than PROLOG do have the ability to do so.
The use of theorem-provers to process models of legislation was foreseen as
early as 1957by Layman Allen (Allen 1957)when he argued for the use of symbolic
logic as a tool for drafting and potentially simplifying complex legal documents.
Allen’s ideas have been developed further and have had some influence on the
drafting style of legislators, particularly in some of the United States. In his original
paper, Allen suggested that automated tools might even be applied to help in the
construction of a legal document. He illustrated how a legal document could be
simplified and restructured using simple theorem-proving techniques similar to
those employed in the simplification and re-design of electrical circuits.
 The Use of Logical Models in Legal Problem Solving 211

What has not been established (to our knowledge) is whether the more general
possibility of deriving arbitrary consequences from logical models of the law
would provide practical help to the person engaged in drafting a piece of real
legislation. It is difficult to test out these ideas in practice. Legal draftsmen, in
the United Kingdom certainly, work under extreme pressure. It is unrealistic
to increase their workload in the short-term by asking them to experiment with
prototype systems that might eventually be developed to provide useful drafting
aids. However, it might be possible to undertake this exercise in organisations
outside the law. Complex regulations have to be drafted in all kinds of organisa-
tions. The person charged with drawing a set of such regulations will face
many of the same difficulties that a Parliamentary draftsman will encounter,
and will perhaps be better able to experiment with speculative systems under
development.
It must also be stressed that such drafting aids would be something of a
luxury. Simpler tools, such as special-purpose editing facilities and cross-
'

referencing aids, can be provided more easily and are likely to be more effective
in the short-term. We have recently been involved in a preliminary study
on the provision of such tools for a data base of legislative texts intended
primarily to support the work of Parliamentary draftsmen. Such a data base
is complementary to the logical models discussed in this paper, in that it
represents not the detailed "meaning" of a piece of legislation but rather its
structure (what it contains) and its relationship to other legislation. Humphreys
(1988) and Roy-Burman (1988) describe the background and intended usages
in more detail. We have experimented with the use of similar data bases to aid
the task of representing large and complex bodies of legislation (Bench-Capon
et a]. 1987).
We have also been involved in the provision of tools to help in the formulation
of policy and the formulation of law at the stage before detailed drafting begins.
Roughly, the intention is to provide legislators with a set of logical tools to
help assess the socio-economic implications of proposed changes to legislation,
to estimate the costs involved, and to anticipate potential shortcomings and
other undesirable consequences, before the changes are implemented in legisla-
tion. Here, in addition to the proposed legislation itself the logical model must
incorporate representations of goals and intentions (often vague and conflicting)
and underlying socio-economic theories (often vague and unarticulated) . This
work, still in its early stages, is described by Bench-Capon (1987).It is conducted
as part of an Alvey "Large Demonstrator Project" investigating the provision
of decision support systems in large legislation-based organisations like the
Department of Health and Social Security. Other components in the Demonstrator
project are systems to help in the assessment of claims and systems to advise
on entitlement to the various welfare benefits available. The other collaborators
in the project are ICL, Logica, and the Universities of Lancaster and Surrey (and
Liverpool since 1987).
212 Robert Kowalski and Marek Sergot

6. Systems for the Expert Lawyer

We shall now consider to what extent a logical model of the law might help
a practicing lawyer, who is concerned not with administering, formulating, or
modifying a piece of legislation, but rather with testing its implications and
analysing how best to exploit o r avoid these implications in the interests of his
client. There is no doubt that general practitioners of law would find it helpful
to consult a program on the detailed application of some specific area of the
law with which they are unfamiliar, especially if the program is augmented with
supplementary opinion from experts. But would the experts themselves find any
use for a program which can generate logical consequences from a representation
of some part of the law which they already know in detail?
We raise this question because we want to make clear what it means for
something to be a "logical consequence" and to stress what it is that our logical
models represent. In describing our work we have regularly claimed that our
programs derive logical consequences of a model of the law. We have never
claimed that our programs model the entire process of legal reasoning nor
that they derive logical consequences of the law itself.
Let us suppose that we have constructed a logical model of some piece of
legislation, the British Nationality Act for example. The ability to derive logical
consequences of this model gives us a method of investigating what follows from
the interpretation we have taken. If we accept the interpretation we must also
accept its logical consequences. Of course, there is more to legal decision-making
and legal reasoning that the mechanical application of some fixed set of legal
rules, and we are not suggesting otherwise. It might be, for example, that one
interpretation of the Act suggests (say) that Peter is a British citizen. Yet when
Peter argues his case in court it turns out he is not. This could happen for any
number of reasons. The court might rule that there is some other source of law
regarding British citizenship that has not been considered. It might rule that
our interpretation is mistaken because we have misunderstood the provisions
of the Act. It might even be able to rule that the Act itself is flawed, because
it conflicts with other more general legislation regarding basic human rights.
Deriving logical consequences tells us what follows from our chosen interpreta-
tion. It does not tell us whether this interpretation is the right one to take or
whether other considerations might not predominate.
Since our programs can only indicate what follows from one precise inter-
pretation of the law, we need to consider whether an expert lawyer would find
such an ability useful. Certainly, we should not conclude immediately that he
would not. There are areas of law where the relevant regulations are so complex
that even an expert lawyer has difficulty in determining how they apply in a
given case. This task can be difficult and prone to errors simply because it is
tedious, time-consuming or there is a mass of detail to be remembered and
considered. A computer program which takes care of the detail might be a
valuable aid even for an expert lawyer. And such a program can be useful even
 The Use of Logical Models in L e g d Problem Solving 213

though it incorporates a logical model which represents only one interpreta-

tion of the law. In practice there are many areas where lawyers work mostly
with one generally accepted interpretation of the law. After all, the day-to-day
administration of much administrative law also deals with only one fixed
interpretation of the law.
Of course we are not suggesting that all, or even most, areas of law are like
this. Even legislation which is detailed and apparently precise will often support
many different possible interpretations. These have to be considered and
compared, and there will be any number of other factors besides the legislation
itself which might be equally relevant. But a computer program can be useful
even if it only helps with one part of the overall task. A lawyer may want to
investigate in isolation what would happen if a particular interpretation of the
law were applied in a given case, independently of any other considerations.
(In the same way that an engineer would use a mathematical model of a bridge
to calculate the stresses in its various joints and spars. This model would help
him to decide in isolation whether the bridge will support its intended load,
but it does not begin to help with all the other factors he needs to consider,
such as how the bridge will affect road traffic or how much it will cost to build.)
The programs we have described can do more than indicate whether a specific
legal consequence does or does not appear to hold in some given set of circum-
stances. These programs can also state reasons why this should be so, in the
form of the explanations (or more precisely, the proofs) that they can generate.
They thus identify precisely the specific interpretation of the law that they
incorporate. It is the lawyer’s responsibility to assess whether this interpretation
is the one he wants to consider and what additional factors need to be accounted
for as well.
Nevertheless, restricting attention to a single fixed interpretation of the law
is obviously a fundamental limitation, even though it also has its uses. In the
next sections we consider the extent to which we can remove this restriction,
with particular emphasis on ambiguity and vagueness in the law and how these
features might be treated within a logical framework.

7. Ambiguity
Legislation - by which we mean statutes and published rules and regulations
- is written in natural language. Consequently, it is on occasion both ambiguous
and vague. Much of the legal decision-making process is concerned with the
resolution of ambiguity and vagueness, and these are problems which we must
confront if we are to provide computer programs that address more than the
most basic aspects of the legal process.
In practice problems of ambiguity and vagueness in the law are resolved in the
same way, by presenting and then analysing a set of reasoned arguments why
one particular interpretation rather than another should be taken in a given case.
Moreover, with both kinds of problem, much of the argumentation concerns
214 Robert Kowalski and Marek Sergot

previous cases and whether or not previous decisions create a precedent to be

applied in the given case. Nevertheless, despite such similarities, it is convenient
to separate the two for the time being.
Ambiguity in a legal document arises because the language used by the drafts-
man is inherently imprecise. A draftsman might have something extremely
precise that he wants to say, but the imprecision of the language he uses means
that he might not say what he intended, but something with several possible
interpretations instead.
Ambiguity might arise, for example, because of the binding of logical connec-
tives (Does "A or B and C" mean "A or (B and C)" or "(A or B) and C"?),because
of uncertainty over the reference of pronouns ("he," "she," "it," etc.), or because
of ellipsis (the ommission of one or more words needed to make the intended
meaning precise).
Ambiguity is a form of imprecision in the law which is usually inadvertent,
something that creeps in by accident, and something that most draftsmen will
want to avoid. The work of Layman Allen referred to earlier is aimed directly
at identifying ways in which a draftsman could improve the precision of his
writing by reducing or even eliminating inadvertent ambiguity altogether.
Suppose there is a legal provision which is ambiguous and which can be
interpreted in two different ways; suppose further that both interpretations are
reasonable (we have no reason to think a court of law would reject one as
fanciful); and suppose we genuinely cannot choose which one of them we should
take (which is the one that will be accepted by a court of law). Faced with this
state of affairs, we really have no option if we want to build a program which
accurately represents the current state of the law: We must incorporate both
interpretations. Now if a user consults the program, for example to investigate
how the law applies in the circumstances of a given case in hand, he will obtain
two answers, one answer indicating the consequences of taking one interpreta-
tion, and the other answer indicating the consequences of taking the alternative
interpretation. This is presumably the kind of program that an expert lawyer
would prefer, since it does not incorporate a single fixed interpretation of the
law. Nevertheless, there are two immediate problems with this proposal.
The first problem is a computational one. The easiest way of constructing
the program we have just described is to incorporate in it two separate models
of the law, each dealing with one possible interpretation. But suppose we have
a piece of legislation which contains ten separate provisions, and suppose each
of these has two possible interpretations. Then there are 1024 separate interpreta-
tions of the law which need to be represented. Obviously, we could not con-
template storing 1024 separate models of the law, particularly since we have
to allow in general for more than ten ambiguous provisions and more than two
possible readings for each.
One technique that is being used increasingly to overcome this type of
computational problem (wherever it occurs) is Assumption Based Truth
Maintenance (ATMS) introduced by de Kleer (1986).ATMS provides a general
 The Use of Logical Models in Legal Problem Solving 215

mechanism for maintaining and reasoning with several, mutually inconsistent

sets of logical rules while minimising storage and computational overheads.
Richard Southwick (1988)is investigating the incorporation of such mechanisms
in a logic programming framework. These mechanisms can be implemented by
metalevel reasoning, by reasoning about the alternative logical models and how
they are related to one another. This removes the need to store separate,
complete copies of the different interpretations of an ambiguous legal provision.
Instead, the metalevel describes how the various interpretations compare, and
this description is used to reason about the consequences of these interpreta-
tions without explicitly storing many separate models. PROLOG offers crude,
but powerful, facilities for metalevel reasoning. More powerful and more
logically correct forms of metalevel reasoning can be implemented in a manner
similar to that in which APES is implemented in PROLOG (see Bowen and
Kowalski 1982).
The second problem is not a computational one, and is more fundamental.
The process as we have described it requires us to recognise an ambiguity in
a legal text when we see it. In practice this will not be easy. For while it is possible
to detect ambiguity if we examine a legal text closely enough and for long
enough, it is unlikely that this scrutiny will always be undertaken by a person
who is faced with the formidable task of representing a large piece of legisla-
tion in logic (or anything else). Worse, some legal provisions are not ambiguous
at first glance, and only become so when an imaginative lawyer argues persua-
sively that they are. A lawyer rarely analyses a piece of legal text when it is
first published, trying to identify all the possible interpretations that the text
might have. Rather, he generally begins to do so only when the context of a
real case dictates it, and then only considers those parts of the text which are
relevant.
This second problem is more difficult to deal with. To do the job properly,
we would need to construct a program which can analyse and reason with
arbitrary legal texts, and identify the various possible meanings that the text
might have. This would be a program that could "understand' natural language
in a very real sense, and is one that we clearly could not build in the foreseeable
future (or ever). There is a slight possibility that we could build a program to
advise a lawyer on how to go about searching for the ambiguity that he needs.
This is a possibility we are not planning to investigate, although it would be
worth understanding better which syntactic forms in legislation give rise to
ambiguity and which do not - both to analyse existing legislation and to provide
guidelines for writing less ambiguous texts.
We do think, however, that it is worth building a program along the lines
we have outlined earlier, one that incorporates those interpretations we can
detect in advance. We can easily envisage allowing an expert lawyer to augment
and develop the program as new interpretations are discovered. From the
computational point of view, such a program is worth building simply because
of the technical problems that have to be overcome. Techniques for reasoning
216 Robert Kowalski and Marek Sergot

with several conflicting logical models in a single program open up a vast range
of possible applications. These possibilities are not limited to applications within
the law: The techniques apply equally in any area which requires reasoning about
uncertain or hypothetical states of affairs.

8. Vagueness and Case Law

Like ambiguity, vagueness is also a form of imprecision in the law, but one
that is usually intended. A draftsman will often make a conscious decision to
leave some concept undefined and vague, because he prefers that the meaning
of the concept should be determined later, in the context of real cases when
all the individual circumstances can be given proper consideration. A draftsman
could never anticipate all the possible combinations of circumstances that might
arise in the future and make explicit provision for them. Vagueness in the law
is essential. It enables the law to adapt to unanticipated circumstances and to
adjust gracefully to changing needs.
In the law, the meaning of a vague concept is decided piece-meal in the context
of individual cases. The applicability of a vague concept in a new case is decided
typically by analogy with previous cases. In an easy case, only one precedent
will apply and only one decision will be supported. In a hard case, different
previous cases might support different decisions. It might even be possible to
argue that no previous case is sufficiently similar to the new one, and that a
decision needs to be reached by reasoning from first principles.
Reasoning by means of analogy with previous cases can also be viewed as
a form of reasoning by means of rules - rules which are generally implicit. These
rules are generally encoded in the arguments supporting the decisions reached
in individual cases. Such rules, being implicit and ill-defined, do not have as
clear and well determined a meaning as rules embodied in statute law. Moreover,
such rules change over time as new cases arise.
This view of reasoning by means of rules encoding the decisions made in indi-
vidual cases can be incorporated in our models for reasoning with statute law.
Rules representing case-based reasoning can be combined with rules representing
st at utes .
As in our proposal for dealing with conflicting interpretations of statutes,
different rules arising from different cases can be inconsistent with one another
in certain cases. A system incorporating such rules would need to be flexible
and easy to change - as new cases suggest new rules or suggest refinements
to avoid inconsistencies arising between old rules.
One proposal for the treatment of vagueness along these lines is developed in
more detail elsewhere (Bench-Capon and Sergot 1987).Other proposals for dealing
with case law have been made by McCarty and Sridharan (1982),Gardner (1984)
and Ashley and Rissland (1987).At Imperial College, Schild (1988)has developed
a system which provides advice based on the general rules and guidelines which
are used in legal text books to summarise and describe areas of case law.
 The Use of Logical Models in Legal Problem Solving 217

9. Conclusion
We believe that logic programming techniques have already proved useful in
helping to construct first generation legal reasoning systems - systems that reason
with one fixed interpretation of a legislative text.
We expect that second generation systems - systems that can reason with
several interpretations and with conflicting rules arising from previous cases
- will not only help to test the technology further, but will help to identify
extensions of the technology which may prove useful also in other application
areas. Such expected extensions include the incorporation of ATMS knowledge
assimilation, and knodledge refinement techniques (see Kowalski 1979). We
believe that the law is an ideal domain for motivating such general extensions
of logic programming techology .
We would like to believe that our investigations will prove useful, not only
for building computer programs for legal applications, but more importantly,
for clarifying and improving the legal reasoning process whether performed with
or without the assistance of computers.

University of London
Imperial College of Science, Technology and Medicine
Department of Computing
180 Queen's Gate
London SW7 2BZ
United Kingdom

References
Allen, L. E. 1957. Symbolic Logic: A Razor-Edged Tool for Drafting and Interpreting
Legal Documents. Yale Law Journal 66: 833-79.
Ashley, K. D., and E. L. Rissland. 1987. But, See, Accord: Generating 'Blue Book'
Citations in HYPO. In The First International Conference on Artificial Intelligence
and Law, 67-74. New York: ACM Press.
Bench-Capon, T. J. M. 1987. Support for Policy Makers: Formulating Legislation with
the Aid of Logical Models. In The First International Conference on Artificial Intel-
ligence and Law, 181-89. New York: ACM Press.
, and M. J. Sergot. 1987. Towards a Rule-Based Representation of Open Tex-
ture in Law. In Computing Power and Legal Language. Ed. C. Walter. Greenwood:
Quorum Press.
Bench-Capon, T. J. M., G. 0. Robinson, T. W. Routen, andM. J. Sergot. 1987. Logic
Programming for Large Scale Applications in Law: A Formalisation of Supplementary
Benefit Legislation. In The First International Conference on Artificial Intelligence
and Law, 190-98. New York: ACM Press.
Bowen, K. and R. A. Kowalski. 1982. Amalgamating Language and Metalanguage in
Logic Programming. In Logic Programming. Ed. K . L. Clark and S.-A. Tarnlund.
London: Academic Press.
de Kleer, J. 1986. An Assumption-Based TMS. Artificial Intelligence 28: 127-62.
Gardner, A. v. d. L. 1984. An Artificial IntelligenceApproach to Legal Reasoning. Report
STAN-CS-85-1045. Department of Computing Science, Stanford University.
218 Robert Kowalski and Marek Sergot

Hammond, P., and M. J. Sergot. 1983. A PROLOG Shell for Logic Based Expert Systems.
Proceedings Expert Systems 83.
Humphreys, A. M. 1988. Proposals for a Statute Law Database. MSc thesis. Department
of Computing, Imperial College, London.
Kowalski, R. A. 1979. Logic for Problem Solving. New York: North Holland.
Lakhani, H. M. 1988. Stock Exchange Regulations in Logic. MSc thesis. Department
of Computing, Imperial College, London.
McCarty, L. T., and N. S. Sridharan. 1982. A Computational Theory of Legal Argument.
Technical Report LRP-TR-2. Laboratory for Computer Science Research. Rutgers
University.
Roberts, H. 1988. Knowledge Representation for Procedural Law. MSc thesis. Department
of Computing, Imperial College, London.
Roy-Burman, J. 1988. Database Modelling of the Physical and Conceptual Structure
of Statute Law. MSc thesis. Department of Computing, Imperial College, London.
Sadri, F., and R. A. Kowalski. 1988. A Theorem-Proving Approach to Database Integrity.
In Foundations of Deductive Databases and Logic Programming. Ed. J . Minker,
313-62. Los Altos, Ca.: Morgan Kaufman Publishers.
Schild, U. J. 1988. JURIX: A Legal Expert System. Department of Computing, Imperial
College, London. (Paper presented at 8th International Workshop on Expert Systems,
Avignon, 1988.)
Sergot, M. J. 1985. Representing Legislation as Logic Programs. Department of Corn-
puting, Imperial College, London. In Machine Intelligence 13. Ed. E. Hayes, D. Michie,
J. Richards. Oxford: Oxford University Press.
. 1987. The Representation of Law in Computer Programs: A Survey and
Comparison of Past and Current Projects. Department of Computing, Imperial
College, London.
, F. Sadri, R. A. Kowalski, F. Kriwaczek, P. Hammond, andH. T. Cory. 1986.
The British Nationality Act as a Logic Program. Comm. ACM 29: 370-86.
Southwick, R. 1988. Reasoning with Assumptions. Paper. Department of Computing,
Imperial College, London.
Stathis, K. 1987. A Logic-Based System for an Application in Law. MSc thesis. Depart-
ment of Computing, Imperial College, London.
Zaniolo, C. 1988. Design and Implementation of a Logic Based Language for Data
Intensive Application. Proceedings of the Fifth International Logic Programming
Conference and Symposium. Ed. R. A. Kowalski and K. A. Bowen, 1666-87.
Cambridge, Mass.: MIT Press.