One of the most salient tasks in law is legal assessment, and concerns the problem of determining whether some case is allowed or disallowed given an appropriate body of legal norms. In this paper we describe a system and Protege 4 plugin, called OWL Judge, that uses standard OWL 2 DL reasoning for legal assessment. Norms are represented in terms of the LKIF Core ontology, as generic situation descriptions in which something (state, action) is deemed obliged, prohibited or permitted. We demonstrate the design patterns for de ning the norms and actual cases. Furthermore we show how a DL classi er can be used to assess individual cases and automatically generate a lex specialis exception structure using OWL Judge. We illustrate our approach with a worked-out example of university library regulations.
One of the most salient tasks in law is legal assessment, and concerns the problem
of determining whether some case is allowed or disallowed given an appropriate
body of legal norms. For legal experts this process becomes more and more
di cult as the amount of legislation continuously grows and the complexity
of legislative documents increases. Moreover, the structure of legal documents
di ers from those in other domains. Legislation tends to be highly interconnected
{ and interdependent { and normative con icts between di erent regulations
are resolved by meta legal rules, such as lex specialis and lex posterior. The
application of these rules can result in complex exception structures, which can
be di cult to keep track of for the average citizen. [
Legal knowledge-based systems allow us to manage the complexity of legislation and enable online e-government services. Transactions that require the application of complex legislation, such as tax bene ts or social security administration, are increasingly processed online. This gives citizens and businesses more direct access to a personalised and transparent insight in their rights and duties. Although there already exist several such systems, the wider acceptance and dissemination of legal knowledge technology is hampered by the lack of an open platform.
The Legal Knowledge Interchange Format (LKIF), developed within the
ESTRELLA1 project, aims to provide an open platform for legal knowledge
exchange between e-government services [
In the following sections we describe the requirements for legal assessment and explain our approach. We present OWL Judge which is developed to assist users in the task of assessing their individual case. All of this will be illustrated with a worked-out example of university library regulations. 1
Clancey [
FOLaw distinguishes seven types of knowledge: commonsense knowledge, world knowledge, normative knowledge, responsibility knowledge, meta-legal knowledge, creative knowledge and reactive knowledge. Any legal knowledge based system will incorporate at least one of these knowledge types.
The most characteristic category of legal knowledge is normative knowledge,
which re ects the regulatory nature of law. It has two functions: prescribing
behaviour, and de ning a standard of comparison for social reality. A norm
expresses an idealisation: what ought to be the case (or to happen) a ccording to
the will of the agent that created the norm [
Extend Legal Accessibility, see http://www.estrellaproject.org/.
2 Hybrid Architecture for Reasoning with Norms Exploiting Semantic web Services
world knowledge functions as an epistemological interface between the legal
system and social reality. World knowledge is an abstraction of commonsense [
Legal assessment concerns the problem of determining whether some case is allowed or disallowed given an appropriate body of legal norms. It involves the expression of an individual case, an interpretation of that case in terms of the world knowledge, and the application of normative knowledge to determine whether the case constitutes a norm violation. More precisely, the following steps are needed to perform this task: Case Input Create a description of the case that needs to be assessed. The facts that are provided should correspond to terms are used in the norms, i.e. both the norms and the individual case should commit to the same domain ontology.
Match The individual case is matched against the set of norms.
Resolving con icts Because it is not unlikely that the individual case matches
more than a single norm, the system identi es con icting norms and decides
which norm has priority over the other norms (e.g. according to the principle
of lex specialis).3
Final verdict Provide an outcome of the normative quali cation of the case. It
is desirable to present an explanation, e.g. why a certain norm applies to the
given input, showing which terms in a norm match the individual facts of
the case. Moreover the answer should be justi ed by reference to the norms
and original source. [
In the following sections we outline the representation in OWL 2 DL of the three types of knowledge necessary for legal assessment. A domain ontology for terminological knowledge de nes the concepts used as the basic building blocks for specifying case descriptions and norms. The ontology is a specialisation of the LKIF Core ontology. The norms are speci ed in a separate OWL le, and de ne the regulations that govern the situations expressible using the domain ontology. They are expressed as generic situations in which a state or action is quali ed as undesirable, permitted or prescribed (see Figure 1). The individual case description represents the facts that characterise an actual situation and is expressed in terms of the domain ontology as a set of related OWL individuals. Furthermore we will provide the corresponding OWL DL design patterns and show how a description classi er can be used to perform legal assessment of an individual case. 2
A norm is represented as a deontic quali cation of a generic case [
Qualified
Normatively_Qualified Disal owed
Al owed qualifies
Mental_Entity Qualification qualifies
Subjective_Entity
Mental_Object
Norm Obliged
Right
Permission al ows
equivalent disal ow al ows
Obligation expressed by the norm. A GC is de ned as a set of conditions 1 u ... u n in conjunctive normal form. Conditions are class axioms composed of classes and properties de ned by the domain ontology. An individual case C is a set of grounded propositions fc1; :::; cng, called circumstances, that describe a certain state of a airs. The match between a GC and an individual case is through realisation. For instance, a generic case GC1 that is used in the de nition of the norm \Students are not allowed to rent books":
GC1
is trivially satis ed by the individual case:
fAmy : Student; history book : Library Book; Amy checks out history bookg Obviously, a more speci c case GC2 will be subsumed by GC1. However the above example already shows that just representing a norm by a generic case is not enough. From the generic case itself, it does not become clear whether the expressed situation is allowed or not. Therefore we need the following deontic notions that enable us to normatively qualify a generic case: permission, obligation and prohibition. These notions are part of the LKIF Core ontology which is described in a bit more detail at the end of this section.
As the goal of our system is normative assessment, we would like to detect violations of the default situation. Norms apply only to cases that di er from this default situation. The majority of legislative documents by default allow a situation, unless some norm(s) state(s) otherwise. In some regulations, the default situation is disallowed. This is for instance the case in permit systems. The default situation should therefore be included as a generic case in any normative representation. All other generic cases speci ed by norms are subsumed by this default generic case. This allows us to make explicit any exceptions to the default by more speci c norms.
The way in which deontic operators interact can be rather complex. We therefore introduce design patterns to facilitate the speci cation of norms. The following paragraphs describe the behaviour of norms compared to the default, and provide the design patterns (see also Table 1).
Default situation: allowed In the \most common" case, everything is by default allowed. A match of an individual case with the GC of a permission does not have any normative consequences for example. Similarly, when the individual case does not match a prohibition, no normative consequences follow. On the other hand, a match with the GC of a prohibition, constitutes an exception to the default. These types of exceptions should be detected and given precedence over the default situation. However, this simplistic matching process becomes more complex in the case of no match with the GC of an obligation.
We take a ctive example from the library domain again: \Students are obliged to show their library card in order to rent a book. If in this example, someone does want to rent books (a match with the context), but does not show his library card (which is the speci c obliged part), the obligation is violated. However there would be no match with the generic case which expresses this (only a partial match), we would have failed to detect a violation of the default. To be able detect these violations, the GC is partitioned into that part which is explicitly allowed (A ) and that part which is explicitly disallowed (D ) by the obligation. Moreover a norm is typically only addressed towards a certain element of the GC, given some context. We therefore distinguish between the context of a norm and that part of the GC which the norm is directed towards. The pattern we follow in the representation of obligations is therefore as follows: O % &
A D Where the context is de ned as 1: 1 u ... u n (a student rents a book), and the obliged part of the GC is 2: n+1 (showing the library card). Renting a book is disallowed, but renting a book and showing a library card is allowed, which is the desired behaviour.
Default situation: disallowed Of course, where the default situation is disallowed, the normative quali cations di er signi cantly. For instance, if a norm expresses a permission, and there is no match with an individual case, we are still in line with the default situation. However, a match constitutes a direct exception to the default. Similarly, for obligations and prohibitions the exceptions change: a compliance with the allowed part of an obligation is an exception, where a compliance with the disallowed part of a prohibition is not. Therefore, if there is no match in case of a prohibition: we might have failed to detect a violation of the default. A prohibition expresses a disallowed situation (D ), but also implicitly represents an allowed (A ) situation (the complement of the disallowed case is an allowed situation). In case of the example \Students that are in the library, are prohibited to make noise" it is allowed to be in the library, but it is disallowed to be in the library and make noise. The design pattern is as follows: F % &
D A Where the context is de ned as 1: 1 u ... u n (being in the library), and the prohibited part of the GC is 2: n+1 (making noise).
The LKIF Core ontology de nes the class Norm and its subclasses Permission,
u 8allows Allowed u 9disallows Disallowed
The Prohibition and Obligation are equivalent because they are simply two di erent ways to put the same thing into words: a prohibition to smoke is an obligation not to smoke. The Permission is di erent in that it allows something, but does not prohibit anything. For the purpose of clarity we will refer to the subclasses of Normatively Quali ed as generic cases. The properties allows and disallows are disjoint subproperties of quali es; a norm cannot simultaneously allow and disallow the same situation. Although a GC describes an entire situation, it can be represented as a single class description because the entities in a single situation should be connected. On the other hand, this means the norm's quali cation is biased to the class that forms the entry point for describing the GC. 3
Now that we have explained our approach we will illustrate it by means of a worked-out example of a toy domain: university library regulations. We list relevant regulations and introduce a use case. We then show how the regulations are represented, and introduce OWL Judge.
Consider the following university library regulations: 1a) Students registered at this university are allowed to check out a book from this library 1b) Students registered at other universities are allowed to check out a book from this library provided that they are enrolled in at least one course given at this university. 1c) Students who have checked out more than ve books are not allowed to check out another book.
One of our students is Amy. She is registered at the University of Amsterdam and has an inquisitive mind: she has checked out 6 books on some general topic: fAmy : Registered Student; general book 1 : Library Book; general book 2 : Library Book; general book 3 : Library Book; general book 4 : Library Book; general book 5 : Library Book; general book 6 : Library Book; Amy checks out general book 1; Amy checks out general book 2; Amy checks out general book 3 Amy checks out general book 4; Amy checks out general book 5;
Amy checks out general book 6g According to the regulations, Amy's situation is allowed by article 1a, but disallowed by article 1c. However, these two articles contain an intuitive hierarchic pattern: the case described by article 1a subsumes that of article 1c. In fact, article 1c is an exception to 1a, because 1a implicitly expresses that students registered at other universities are not allowed to check out any books. The expected verdict of the system should therefore be that Amy's situation is disallowed, as article 1c is more speci c than article 1a, the lex specialis principle states that 1c trumps 1a.
Although the two relevant articles are article 1a and 1c, we rst need to specify the default situation. In the library regulations the default situation is disallowed; students are generally not allowed to check out books, unless stated di erently in the norms. The default norm and generic case apply to all situations where a book is checked out:
fdefaultnormg
Article 1a states that students registered at this university are allowed to check out a book from this library:
fart1ag
Article 1c states that students who have checked out more than ve books are not allowed to check out another book:
u
fart1cg
Article 1c expresses a prohibition where the default situation is disallowed. The GC is therefore partitioned into a part that is disallowed (the prohibition) and the thing that is allowed (the context). In this case it is permitted to check out books, checking out more than 5 books is prohibited. By using a cardinality restriction, checking out less than or exactly 5 books is allowed by this rule. 3.1
Exception structure As mentioned in the preceding paragraphs, multiple interacting norms can create complex exception structures. As our norms are represented as OWL classes, a DL classi er can generate the subsumption hierarchy of generic cases. This hierarchy actually re ects the lex specialis exception relations between norms. Moreover we can apply the following role inclusion axioms to make these exception
Because norms are nominals that consist of a single individual, these exception relations can be derived automatically, using Pellet for all norms. Take for example the Art1c Prohibition which disallows Art1a GC. The individual art1c, which represents the prohibition from article 1c, disallows our individual amy, since her situation matches with Art1c GC. However, amy is also classi ed as Art1a GC, and therefore amy is also allowed by art1a. In this way we can derive the exception relation between art1c and art1a:
fart1c exception art1ag
This inferred exception hierarchy is used by OWL Judge to resolve possible con icts, and helps to present a nal verdict to the user. 3.2
OWL Judge OWL Judge assists users in the task of legal assessment. It prompts the user to select an OWL le containing the norms, and a le containing a case description. Once the \check" button is pressed, Pellet is called to perform classi cation and realisation on the given les (see Figure 2).
First OWL Judge checks all individuals that exist in the le containing the
case description. Depending on their classi cation as Allowed or Disallowed, they
are displayed in respectively the \Allowed" and/or \Disallowed" column, shown
in the top left part of the screen. A user can click on the individuals in those
columns and retrieve an explanation of the classi cation. For the explanation,
OWL Judge uses the standard explanation facilities of Pellet [
OWL Judge also generates a nal verdict, which is especially interesting in situations where multiple norms apply to the individual case (if only one norm applies it is clearly the nal verdict as well). If an individual is both Allowed and Disallowed, OWL Judge tries to resolve this con ict by checking whether one of the norms allowing or disallowing it contains an exception relationship with the other norm: a norm trumps another norm, if the generic case of the rst norm is more speci c. This means some additional querying of the TBox and ABox is done by the plugin.
The most speci c one will be displayed in the appropriate \Verdict" column, shown in the top right of the screen. The user can again select the individual to view an explanation of OWL Judge's verdict. The screen shows that the individual amy is disallowed by defaultnorm and art1c, but allowed by art1a. The explanation indicates that article 1c is the most speci c norm, which makes the nal verdict \prohibited". 4
Currently, the individual case description has to be entered using a generic OWL
editor, such as Protege4 or Topbraid Composer5. This of course asks for quite
some experience in working with these kind of tools. Moreover a person that
creates the case description should have knowledge of what is present in the
ontology and in the norms, as the terms in the case description should correspond
to either the terms used in the ontology or in the norms. It would be very
bene cial to provide a more friendly user interface. Such an interface should
for example guide a user in what terms to use and try to complete the case
description as much as possible. Some work, cf. [
OWL Judge as it exists now implements our basic requirements, but there are
still some things we would like to address. For instance, it might be interesting
to enhance the explanation by allowing users to click on a certain individual
case to get more information about it. Moreover OWL Judge is not yet capable
of determining whether an individual case is Obliged, which is also something
that needs to be dealt with. Furthermore, we would like to further enhance the
explanations with forms of justi cation, such as a reference to the original source
of law. Preferably the original source of law is stored in the MetaLex/CEN format
4 http://protege.stanford.edu
5 http://www.topbraidcomposer.com
of [
The major advantage of using only OWL 2 DL to represent both conceptual and normative knowledge is that we can use an existing reasoner, Pellet, to perform all reasoning. There is no need to concern ourselves with an interaction between di erent formalisms. The question is whether OWL 2 DL is expressive enough to suit our needs. In some cases we would like to talk about things at the level of individuals, instead of at the level of concepts. For example, if we want to represent \a student that checks out a book belonging to a course he is enrolled in", this is currently impossible to express in DL because of the tree model property7.
Rule formalisms can easily represent this example just by using variables each
time we want to point to a certain student or course. Alternative approaches,
such as structured objects ([