In common law contexts, legal cases are decided with respect to precedents rather than legislation as in civil law contexts. Legal professionals must find, analyse, and reason with and about cases drawn from a set of cases (a case base). A range of particular textual elements of a case may be relevant to query and extract. Commercial providers of legal information allow legal professionals to search a case base by keywords and meta data. However, the case base and the search tools are proprietary, of limited, non-extensible functionality, and are restricted access. Moreover, no provider applies natural language processing techniques to the cases for text analysis, XML annotation, or information acquisition. In this paper, we discuss an initial experiment in developing and applying natural language processing tools to cases to produce annotated text which can then support information extraction.
In common law contexts, judges and juries decide a legal case to follow previously decided cases (precedents) rather than legislation as in civil law contexts.1 The set of such cases is the legal case base. Legal professionals must find, analyse, and reason with and about cases drawn from the case base in the course of arguing for a decision in a current undecided case. A range of elements of cases may be relevant to query and extract such as the citation index, participants, locale, jurisdiction, representatives, judge, prototypical fact patterns (factors), applicable law, and others. Commercial providers of legal information allow legal professionals to search the case base by keywords and meta data. However, the case base and search tools are proprietary, of limited, non-extensible functionality, and are restricted access. Moreover, no provider works with Semantic Web functionalities such as ontologies or rich XML annotations, nor are natural language processing techniques applied to the cases to support analysis to acquire information.
Text annotation of unstructured linguistic information is a significant,
difficult aspect of the “knowledge bottleneck” in legal information processing.
In this paper, we apply natural language processing tools to textual elements
in cases, which are unstructured text, to produce annotated text, from which
information can be extracted, thus contributing to overcoming the
bottleneck. The extracted information can then be submitted to further processes.
Where the annotations are associated with an ontology
The paper is a feasibility study for future research on information
extraction of case elements. 2 In this paper, we focus on case elements rather than
case factors (see
In 2, we discuss background and materials. In 3, we present the methodology, which uses the General Architecture for Text Engineering(GATE) system, sample components of system, sample results, and a work flow for further refinement.3 Finally, in 4, we review the paper and outline future work to evaluate and improve our results.
Legal case based reasoning with factors has been a topic of central concern in
artificial intelligence and law. For our purposes, there are two main branches
of research. One branch, knowledge representation and reasoning systems,
requires a knowledge base that is constructed by manual analysis (cf.
The other branch, information extraction, addresses the bottleneck using
natural language processing techniques which identify informative
components of the text and annotate them with XML. The annotated information
can be extracted with XQuery. Thus, the content of the documents can be
identified from its source linguistic realisation. There are a range of areas
where information extraction of legal texts has been carried out: ontology
construction (
The branches are related since the extracted information can be
represented in some knowledge base and reasoned with. For case based reasoning
with factors as in
In this light and in the current paper, we are interested in case information that would be relevant to searching for or extracting information from cases. For reasons of space, we only give a sample of the information we searched for and annotated: - Case citation, cases cited, precedential relationships. - Names of parties, judges, attorneys, court sort.... - Roles of parties, meaning plaintiff or defendant, and attorneys, meaning the side they represent. - Final decision.
With respect to these features, one would want to make a range of queries (using some appropriate query language) such as: - In what cases has company X been a defendant? - In what cases has attorney Y worked for company X, where X was a defendant?
As we initially based our work on information extraction from California
Criminal Courts in
We use the GATE framework
For our purposes, we have applied natural language processing modules such as Tokeniser, Gazetteer, and Java Annotation Patterns Engine (JAPE), each module providing input to the next. The last two modules are explained further below.
In addition to these functionalities, one can also use entity extraction and syntactic parsing components. For a particular domain, it is important to provide gazetteer lists and JAPE rules. In general, there is a cascade from lower level information in the parts of speech and gazetteer lists to higher level information where lower level information is used to compose more complex units of information. As a working strategy, the lists capture simple, unsystematic patterns, leaving the JAPE rules to capture systematic, complex patterns.
Figure 1 represents the work flow (derived from the work flow diagram in
A gazetteer is a list of lists. Each list is comprised of strings that are associated with a central concept or with some elements of the text. The lists annotate the words and strings with the MajorType of the list; they provide the bottom level of annotation on which higher level annotations are constructed using JAPE rules. The gazetteer lists discussed here are manually composed.
We initially worked with gazetteer lists from
A range of lists such as the two sampled below bear on “indicators” of structure. For example, “v.” is used in cases to indicate the opposing parties, so it can be used to leverage identification and annotation of parties which appear on either side of the indicator. These are not unproblematic: the indicator might incorrectly label an abbreviated first name. There may be better ways to find judges than the initial “J.”; in particular, as the list of judges is finite and give by the court system, it might be simplest to use such a list rather than applying text mining to finding it. - legal_casenames.lst. Terms that can be used to indicate case names: v., In Re,.... - judgeindicator.lst. The indicator J.. This is a problematic indicator if it is part of an individual’s name.
In other lists, we have phrases, abbreviations, and case citations. For phrases,
there are two strategies.
Some of the terms are functional; that is, both legal parties and counsel names are roles that individuals have with respect to a particular context. In one context, an individual may be a plaintiff, while in another the defendant. In annotating an individual with a functional role, e.g. an individual as plaintiff, we rely on local context within the text and do not presume that the individual’s annotation applies across cases.
Finally,
While it would be meaningful to index cases according to such content,
they present several problems. Clearly, whether something is a weapon or
criminal assault is context dependent since in some other context they might
not be. How could one bound the range of relevant terms appropriately and
give them interpretations that are relevant to the context? For example, isn’t
any object a possible weapon? These may be terms which, as discussed in
Given the bottom-level annotations provided by the lists, we have JAPE rules which make the annotations graphically represented and available for higher level annotations. Below is a partial list of annotations given by JAPE rules. - AppellantCounsel: annotates the appellant counsel. - DSACaseName: annotates the case name. - CauseOfAction: annotates for causes of action. - DecisionStatement: annotates a sentence as the decision statement. - JudgeName: annotates the names of judges.
Some of the JAPE rules simply translate the Lookup type into an annotation such as Weapon, while other rules use the Lookup type and context to annotate a text span such as AppellantCounsel and DecisionStatement. In the following sample rule, a sentence which contains a judgment term (e.g. affirm, overturn, etc) followed by a judge’s name is labeled a decision statement. The rule relies on a standard format, where the case decision is followed by the judge’s name; were similar patterns to appear in the case, then they too might be mis-annotated as a decision of the case.
Priority: 10 ( {Sentence contains JudgementTerm} ):termtemp {JudgeName} –> :termtemp.DecisionStatement = {rule = “DecisionStatement”}
In this section, we give some of the results of running our GATE application over our corpus, giving the results using the graphical output of GATE
We have the following sample outputs from our lists and rules applied to People v. Coleman, 117 Cal App. 2d 565. The coloured highlights on the case text are associated with the same coloured annotation. We can output an XML representation to indicate the annotation. In Figure 2, we find the address, court district, citation, case name, counsels for each side, and the roles. The results give a flavour of the annotations, though further work is required to refine them.
In Figure 3, we focus on additional information such as structural sections (e.g. Opinion), the name of the judge, and terms having a bearing on criminal assault and weapons. In Figure 4, we identify the decision.
In this paper, we have outlined and extended a proof of concept approach to text mining legal cases in order to extract a range of particular elements of information from the cases. While a relatively small system applied to a very small corpus, the lists and rules approach can be extended further and relatively easily. Further developments using this approach to text mining would be to relate the extracted information to an ontology which is directly incorporated into the GATE pipeline. A second development would be to engage a wide range of users (e.g. law school students) in a collaborative, on line annotation task using GATE TeamWare. Not only would this have didactic purposes (to focus the attention of students on close analysis of the text), but it would also help to build up a body of annotated texts for further research as well as development of a gold standard that could be used for machine learning.