D2 - MIning and REasoning with Legal texts · 5.1.1 Ontological extension of the LegalRuleML Meta...

D2.2

Computational ontologies for normative reasoning

Grant Agreement nº: 690974 Project Acronym: MIREL Project Title: MIning and REasoning with Legal texts Website: http://www.mirelproject.eu/ Contractual delivery date: 31/12/2017 Actual delivery date: 31/12/2017 Contributing WP WP2 Dissemination level: Public Deliverable leader: UNITO Contributors: UNITO, INRIA, UL

This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under the Marie Skłodowska-Curie grant agreement No 690974

Ref. Ares(2017)6380665 - 28/12/2017

http://www.mirelproject.eu/

MIREL- 690974 of 41 27/12/2017

D2.2


Document History

Version Date Author Partner Description

0.1 4/12/2017 Luigi Di Caro UNITO Initial draft

1.0 31/12/2017 Luigi Di Caro UNITO Final Version

Contributors

Partner Name Role Contribution

UNITO Luigi Di Caro Editor, Author, Reviewer

Editor, author and reviewer of the deliverable

INRIA Serena Villata Author Author of the deliverable

UL Livio Robaldo Reviewer Reviewer of the deliverable

Disclaimer: The information in this document is provided “as is”, and no guarantee or warranty is

given that the information is fit for any particular purpose. MIREL consortium members shall have

no liability for damages of any kind including without limitation direct, special, indirect, or

consequential damages that may result from the use of these materials subject to any liability which

is mandatory due to applicable law.

MIREL- 690974 of 41 27/12/2017

D2.2


Table of Contents

Executive Summary ............................................................................................................................. 5

Section 1: Introduction ........................................................................................................................ 5

Section 2: Background ......................................................................................................................... 5

Section 3: Selected Ontologies and Feature Analysis ......................................................................... 6

3.1 LKIF ................................................................................................................................................ 7

3.1.1 Description ......................................................................................................................... 7

3.1.2 Analysis of the features ...................................................................................................... 8

3.1.3 Considerations .................................................................................................................. 12

3.2 ODRL ............................................................................................................................................ 12

3.2.1 Description ....................................................................................................................... 12

3.2.2 Analysis of the features .................................................................................................... 13

3.2.3 Considerations .................................................................................................................. 15

3.3: L4LOD ......................................................................................................................................... 17

3.3.1 Description ....................................................................................................................... 17

3.3.2 Analysis of the features .................................................................................................... 17

3.3.3 Considerations .................................................................................................................. 18

3.4 LegalRuleML ................................................................................................................................ 19

3.4.1 Description ....................................................................................................................... 19

3.4.2 Feature Analysis ............................................................................................................... 19

3.4.3 Considerations .................................................................................................................. 19

3.5 CLO .............................................................................................................................................. 20

3.5.1 Description ....................................................................................................................... 20

3.5.2 Feature Analysis ............................................................................................................... 20

3.5.3 Considerations .................................................................................................................. 21

Section 4: Features Analysis of legal ontologies ............................................................................... 21

4.1 Types of features for legal ontologies ......................................................................................... 21

4.2. Features classification ................................................................................................................ 22

Section 5: MIREL-specific achievements ........................................................................................... 25

5.1 Normative Requirements as Linked Data.................................................................................... 25

5.1.1 Ontological extension of the LegalRuleML Meta Model .................................................. 25

MIREL- 690974 of 41 27/12/2017

D2.2


5.1.3 Core primitives ................................................................................................................. 26

5.1.3 Formalization .................................................................................................................... 27

5.1.4 Requirements as Linked Data ........................................................................................... 29

5.1.5 State of affairs as named graphs. ..................................................................................... 30

5.1.6 Deontic reasoning as SPARQL rules.................................................................................. 31

5.1.7 Proof of concept and experimentation ............................................................................ 33

5.2 European Legal Taxonomy Syllabus ............................................................................................ 33

5.2.1 Multi-linguality and Multi-jurisdictionality ...................................................................... 33

5.2.2 European Legal Taxonomy Syllabus - The ELTS Ontology Schema .................................. 35

Section 6: Conclusions and Research Challenges .............................................................................. 39

References ......................................................................................................................................... 39

MIREL- 690974 of 41 27/12/2017

D2.2


Executive Summary

The main objective of Deliverable 2.2 is to provide a description of the state of the art

regarding the main existing ontologies for enabling legal reasoning in the scope of the

MIREL objectives and current activities, together with the effort and the achievements

already reached within the project work.

In Work Package n.2 of the MIREL project, legal ontologies represent crucial building blocks

as they represent machine-readable conceptualisations of the domain allowing forms of

reasoning to be populated (manually, semi-automatically or automatically) and used in Work

Package n.3.

Introduction, background and related work on legal ontologies are the first sections of this

deliverable. Considerations on the key features of ontologies in the legal domain are

identified and illustrated. Then, MIREL-specific approaches for ontological representation

are presented. Finally conclusions and research challenges identified are discussed.

Section 1: Introduction

There is a large body of research and practice in building and reusing ontologies in the legal

domain. This research effort has been growing in importance in the last few years, due to the

rise of concepts such as Linked Open Data, and Legal Linked Open Data, while the growing

research on Semantic Web enabled reasoning mechanisms among data and resources.

In this document, legal ontologies will be examined in the first part of this deliverable. This

will be followed by an analysis of common and discriminative features of the existing

ontologies to be possibly used within the scope of the MIREL project. Finally, some effort is

then presented in terms of MIREL-specific solutions in specific legal contexts. Conclusions

and research questions end the deliverable.

Section 2: Background

Some parts of this section are shared with Deliverable 3.1.

An ontology can be defined as “A formal specification of a shared conceptualization of a

domain of interest”. Being formal means that the ontology should be machine-readable, so

as to allow for automatic processing. It must also be shared i.e., accepted by a community

of users. Typically an ontology is restricted to a given domain of interest and model concepts

MIREL- 690974 of 41 27/12/2017

D2.2


and relations that are relevant to a particular application domain or a particular task. Using

formal axioms allows for reasoning, and typically a concept rather than a term based

representation is language independent.

Semantic representations that can be used in the legal domain are lexicons, thesauri or

lightweight ontologies such as taxonomies offering a simple representation based on lexical

terms but without complex reasoning capabilities. Sources are legal texts in natural language.

In legal language the meaning of terms in a legal concept often differs from that in everyday

language. In addition, common problems in Natural Language Processing (NLP) such as

polysemy of terms, also appear. By providing formal definitions of concepts a semantic

representation can be useful for tasks such as data access and information retrieval,

publication exchange interoperability and harmonization Interoperability in particular is very

important in case of multilingual corpora, and comparison/ integration of sources, especially

from different legal systems.

Structured vocabularies such as taxonomies and thesauri are lists of terms organized in

hierarchies of broader and narrower terms and also associated terms using related term

relations. The definition of terms is restricted to the relationships with other terms into the

taxonomy, without complex concept constructs and semantic constraints. Thus complex

reasoning tasks are not supported, but tasks such as document tagging and classification as

part of retrieval of information are. Controlled vocabularies, taxonomies and thesauri,

referred to as Knowledge Organization Systems (KOS), have been used in digital libraries

among others and a recent development is the introduction of standards for their

representation and exchange on the web.

Section 3: Selected Ontologies and Feature Analysis

In the following sections, a number of selected relevant ontologies for enabling legal

reasoning are presented and analysed. In particular, each resource is described in terms of a

short description, its features, together with some further discussion points. This knowledge

has been then reorganized and evaluated in order to promote a list of candidate features which

can be considered for further research on legal ontologies within the scope and actual

activities of the MIREL consortium.

MIREL- 690974 of 41 27/12/2017

D2.2


3.1 LKIF

3.1.1 Description

The LKIF-Core ontology was developed within the ESTRELLA project1 for defining basic

legal concepts. The LKIF core legal ontology2 “consists of 13 modules, each of which

describes a set of closely related concepts from both legal and commonsense domains”. Thus

the LKIF core ontology is a library of ontologies relevant for the legal domain. The most

abstract concepts are defined in modules: top3, place4, mereology5, time/spacetime6. Basic-

level concepts are distributed across four modules: process7, role8, action9 and expression10.

These modules are extended by three modules that form the legal ontology: legal action11,

legal role12 and norm13. In addition to these legal modules, two modules are provided that

cover the basic vocabulary of two frameworks: modification14 and rules 15 . Finally, the

modules of the abstract, basic and legal level are integrated in the LKIF Core ontology

module16. The two framework modules are accessible through the LKIF Extended ontology

module17 which also imports the LKIF Core module.

1 http://www.estrellaproject.org/ 2 http://www.estrellaproject.org/lkif-core/ 3 https://github.com/RinkeHoekstra/lkif-core/blob/master/lkif-top.owl 4 https://github.com/RinkeHoekstra/lkif-core/blob/master/relative-places.owl 5 https://github.com/RinkeHoekstra/lkif-core/blob/master/mereology.owl 6 https://github.com/RinkeHoekstra/lkif-core/blob/master/time.owl 7 https://github.com/RinkeHoekstra/lkif-core/blob/master/process.owl 8 https://github.com/RinkeHoekstra/lkif-core/blob/master/role.owl 9 https://github.com/RinkeHoekstra/lkif-core/blob/master/action.owl 10 https://github.com/RinkeHoekstra/lkif-core/blob/master/expression.owl 11 https://github.com/RinkeHoekstra/lkif-core/blob/master/legal-action.owl 12 https://github.com/RinkeHoekstra/lkif-core/blob/master/legal-role.owl 13 https://github.com/RinkeHoekstra/lkif-core/blob/master/norm.owl 14 https://github.com/RinkeHoekstra/lkif-core/blob/master/time-modification.owl 15 https://github.com/RinkeHoekstra/lkif-core/blob/master/lkif-rules.owl 16 https://github.com/RinkeHoekstra/lkif-core/blob/master/lkif-core.owl 17 https://github.com/RinkeHoekstra/lkif-core/blob/master/lkif-extended.owl

MIREL- 690974 of 41 27/12/2017

D2.2


Figure 3: Top concepts of LKIF-core ontology

3.1.2 Analysis of the features

An analysis of the features of the LKIF ontology is reported in the scheme below. As with

the next sections on other ontologies, features are organized along some main categories. In

this case, they are the following three:

1. Purpose-oriented features

2. Modeling features

3. Semantic features

PURPOSE

Role: understanding the domain (core ontology), but also interoperability

between existing legal knowledge systems (it is the general purpose of the

system inside which LKIF is located)

MIREL- 690974 of 41 27/12/2017

D2.2


application: “translation of legal knowledge bases written in different

representation formats and formalisms”, provide a knowledge representation

formalism

granularity: core, but it counts several integrated modules

MODELING FEATURES

Methodologies of development: different. The methodology is elaborated starting

from the following works:

Hayest (1985) “Formal theories of common sense world”: instead of creating

the ontologies with a top-down approach, he suggests the use of (as much as

possible) independent clusters of interrelated concepts.

Uschold and King (1995) “Towards a methodology for building ontologies”:

they refer to the basic concepts and basic levels theory of Lakoff

mainly composed by 4 steps: (i) identify purpose and scope, (ii) ontology

capture and coding, (iii) integration with existing ontologies (iv) evaluation

construction: manual

Knowledge sources for terms extraction: LRI-Core, LLD, CLO

MIREL- 690974 of 41 27/12/2017

D2.2


SEMANTIC FEATURES

The ontology contains three levels:

1. top level In this level the classes are taken from the LRI-core ontology, so they are

taken from an existing ontology This level models basic concepts which are independent from the legal

concepts, but which are essential to describe any legal account. The basic concepts modelled in LKIF are: - Mental_Concept - Physical_Concept: models the involuntary changes. A change is “a

difference between the situation before and after the change”. Into a Change we can distinguish three types of changes: Initiation Continuation Termination Processes: they occur according to a certain procedure - Abstract_Concept - Occurrence: models spatio-temporal aspects as: Relative_Place Abstract_Place Interval Moment Some spatial relations: cover, coincide Some temporal relations: before, after, during

2. intentional level: this level model an agent’s intelligent behaviour which must be governed,

predicted and explained by law. The main concepts contained in this level are: - Action - Agen - Role - Propositional_Attitudes Intention, Belief and Desire - Expressions

MIREL- 690974 of 41 27/12/2017

D2.2


3. legal level In this level there is a distinction between: - the norm: is a situation put in words Obligation and Prohibition are equivalent classes (relation of equivalence) Permission: is in a higher level than Obligation and Prohibition because it doesn’t prohibit nothing - the situation the norm

applies to (indicated in the ontology as Qualified) Disallowed Allowed

The figure below represent an overview of the ontology structure.

MIREL- 690974 of 41 27/12/2017

D2.2


3.1.3 Considerations

The legal module of LKIF has some differences from ODRL and L4LOD, later discussed.

Here are some points for further analysis and evaluation:

1. LKIF models the notion of equivalence between the Obligation and Prohibition

concepts, while in ODRL the equivalence relationship between Obligation and Duty

is not present. The absence of this equivalence in ODRL subtends a different view of

the way in which the duty and the obligations are intended: this is highlighted by the

remedy relation which links a prohibition to a duty. The directionality of the remedy

relation “expresses an agreed obligation that must be fulfilled in the case that the

Prohibition has been infringed”, but the contrary doesn’t hold: in ODRL an obligation

(duty) is not complementary to a prohibition

2. In ODRL the concepts of Permission is in a higher level

3. Differently from ODRL (and L4LOD), LKIF models the situations the norms

applies to. So the definition of a Permission/Prohibition/Obligation goes hand-in-

hand with the definition of the situation it permits/prohibits/obliges.

Even if the Prohibition and Obligation concepts are modelled as equivalent norms, the

same parallelism is not maintained in the modelling of the Qualified concepts. Moreover

the Disallowed situation is not modelled as a subclass of Allowed, as it happens in the

norm hierarchy.

3.2 ODRL

3.2.1 Description

The Open Digital Rights Language (ODRL) is a policy expression language that provides a flexible

and interoperable information model, vocabulary, and encoding mechanisms for representing

statements about the usage of content and services. The ODRL Information Model describes the

underlying concepts, entities, and relationships that form the foundational basis for the semantics of

the ODRL policies.

Policies are used to represent permitted and prohibited actions over a certain asset, as well as the

obligations required to be meet by stakeholders. In addition, policies may be limited by constraints

(e.g., temporal or spatial constraints) and duties (e.g. payments) may be imposed on permissions.

The ODRL Information Model defines the underlying semantic model for permission, prohibition,

and obligation statements describing content usage. The information model covers the core concepts,

entities and relationships that provide the foundational model for content usage statements. These

machine-readable policies may be linked directly with the content they are associated to with the aim

to allow consumers to easily retrieve this information.

MIREL- 690974 of 41 27/12/2017

D2.2


The primary aim of the ODRL Information Model is to provide a standard description model and

format to express permission, prohibition, and obligation statements to be associated to content in

general. These statements are employed to describe the terms of use and reuse of resources. The

model should cover as many permission, prohibition, and obligation use cases as possible, while

keeping the policy modelling easy even when dealing with complex cases.

The ODRL Information Model is a single, consistent model that can be used by all interested parties.

A single method of fulfilling a use case is strongly preferred over multiple methods, unless there are

existing standards that need to be accommodated or there is a significant cost associated with using

only a single method. While the ODRL Information Model is built using Linked Data principles, the

design is intended to allow non-graph-based implementations.


An analysis of the features of the ODRL ontology is reported in the scheme below, organized in 4

categories:



3. Usability features

4. Semantic features

PURPOSE

Role: (flexible and interoperable information model, vocabulary, and encoding

mechanisms)

organize and structure information, semantics integration and interoperation

Application: representing statements about the usage of content and services

Granularity: domain

MODELING FEATURES

Language: English

Ground ontology: not present

Level of structure: high

Temporal clauses: can be expressed in the form of logical expressions

MIREL- 690974 of 41 27/12/2017

D2.2


USABILITY FEATURES

Updates number and frequency: high

SEMANTIC FEATURES

taxonomical relations

abstract relations which are implemented by other relations

abstract concepts

support to the formulation of logical and boolean expressions

supported standards: json-ld, IRI (Internationalized Resource Identifier), DublicCode

for metadata

meronymy relations

ORDL defines a core vocabulary but it also allows some extensions

The scheme below presents an overview of the ODRL ontology.

MIREL- 690974 of 41 27/12/2017

D2.2


3.2.3 Considerations From the analysis of the resource, here are the points that can be considered as important for the

project:

allowed the presence of taxonomical (subClass)

allowed abstract relations (see: function [implemented by: assigner and assignee] and

relation [implemented by target])

allowed also abstract concepts, for example the concept Rule which is instantiated by

Permission, Duty and Prohibition.

Logic and Boolean expressions in the form od entity (see Contraint/LogicalContraint)

When policies are expressed with jslon-ld,the rows of the data model become fiel names

associated with the specific class from which the row starts

Meonymy relation (partOf) for the classes Party/PartyCollection and Asset/AssetCollection

Relations may have different cardinality values

The ODRL Information Model has the following classes:

Policy - A non-empty group of Permissions (via the permission property) and/or

Prohibitions (via the prohibition property) and/or Duties (via the obligation property). The

Policy class is the parent class to the Set, Offer, and Agreement subclasses:

o Set - a subclass of Policy that supports expressing generic Rules.

o Offer - a subclass of Policy that supports offerings of Rules from assigner Parties.

o Agreement - a subclass of Policy that supports granting of Rules from assigner to

assignee Parties.

Asset - A resource or a collection of resources that are the subject of a Rule (via the abstract

relation property). The Asset class is the parent class to:

o AssetCollection - a subclass of Asset that identifies a collection of resources.

Party - An entity or a collection of entities that undertake Roles in a Rule (via the abstract

function property). The Party class is the parent class to:

o PartyCollection - a subclass of Party that identifies a collection of entities.

Action - An operation on an Asset.

Rule - An abstract concept that represents the common characteristics of Permissions,

Prohibitions, and Duties.

o Permission - The ability to exercise an Action over an Asset. The Permission may

also have the duty property that expresses an agreed Action that must be exercised

(as a pre-condition to be granted the Permission).

o Prohibition - The inability to exercise an Action over an Asset.

o Duty - The obligation to exercise an Action.

Constraint/LogicalConstraint - A boolean/logical expression that refines an Action and

Party/Asset collection or the conditions applicable to a Rule.

The ODRL Information Model includes property relationships between the classes. Most are

explicitly named properties and some are abstract properties (specifically, relation, function, operand,

and failure). The abstract properties are generic parent properties that are designed to be represented

by child properties (sub-types) with explicit semantics.

For example, the two properties relation and function are designed to represent the conceptual relation

between the Rule and the Asset and Party classes.

MIREL- 690974 of 41 27/12/2017

D2.2


The Policy class has the following properties:

A Policy must have one uid property value (of type IRI [rfc3987]) to identify the Policy.

A Policy must have at least one permission, prohibition, or obligation property values of

type Rule. (See the Permission, Prohibition, and Obligation sections for more details.)

A Policy may have none, one, or many profile property values (of type IRI [rfc3987]) to

identify the ODRL Profile that this Policy conforms to. (See the ODRL Profiles section for

more details.)

A Policy may have none, one, or many inheritFrom property values (of type IRI [rfc3987])

to identify the parent Policy from which this child Policy inherits from. (See the ODRL

Inheritance section for more details.)

A Policy may have none or one conflict property values (of type ConflictTerm) for Conflict

Strategy Preferences indicating how to handle Policy conflicts.(See the Policy Conflict

Strategy section for more details.)

An ODRL Policy must either:

Only use terms defined in the ODRL Core Vocabulary [odrl-vocab], or

Use an ODRL Profile that declares the supported vocabulary used by expressions in the

Policy.

In the former case, the profile property must not be used. In the latter case, the profile property must

be used to indicate the IRIs of the ODRL Profile(s).

An ODRL Policy may be subclassed to more precisely describe the context of use of the Policy that

may include additional constraints that ODRL processors must understand. Additional Policy

subclasses may be documented in the ODRL Common Vocabulary [odrl-vocab] or in ODRL Profiles.

Below, an example of use case.

https://www.w3.org/TR/odrl-model/#bib-rfc3987

https://www.w3.org/TR/odrl-model/#permission

https://www.w3.org/TR/odrl-model/#prohibition

https://www.w3.org/TR/odrl-model/#duty-policy


https://www.w3.org/TR/odrl-model/#profile


https://www.w3.org/TR/odrl-model/#inheritance

https://www.w3.org/TR/odrl-model/#inheritance

https://www.w3.org/TR/odrl-model/#conflict

https://www.w3.org/TR/odrl-model/#conflict

https://www.w3.org/TR/odrl-model/#bib-odrl-vocab

https://www.w3.org/TR/odrl-model/#bib-odrl-vocab

MIREL- 690974 of 41 27/12/2017

D2.2


On this example, we can make some considerations:

json-ld: Json format for Linked data

uid is inherited direttamente da Policy

permission: in line with the requirements of class permission. That is:

“A Permission must have one target property value of type Asset”

“action” instead is specified because an action is always done on a target / resource

3.3: L4LOD

3.3.1 Description

L4LOD (Licenses for Linked Open Data) is a lightweight vocabulary for expressing the

licensing terms in the Web of Data. The vocabulary is not intended to propose yet another

license, but it is intended to provide the basic means to define in a machine-readable format,

i.e., RDF, the existing licensing terms. The vocabulary does not provide an exhaustive set of

properties for licenses definition. Implementations are free to extend L4LOD to add further

elements.


An analysis of the features of the L4LOD ontology is reported in the scheme below, organized in 4

categories:



3. technical features

4. usability features

PURPOSE

Role: organize and give a structure to the information

Application: vocabulary to express the license terms

Granularity: domain

MODELING FEATURES

Language: English

MIREL- 690974 of 41 27/12/2017

D2.2


Knowledge sources for terms extraction

Ground ontology

Level of structure: low

Temporal clauses: not included

TECHNICAL FEATURES

Knowledge representation formalism: RDF

USABILITY FEATURES

Updates number and frequency: the updates stopped on 13 March 2013

Ontology accessibility/availability: CC-By-SA

There are some similarities between some classes in ODRL and L4LOD as outlined in the

following image:


In both ODRL and L4LOD there is a root class (Policy and License) which is linked to the

classes Prohibition, Permission and Duty/Obligation through similar relations:

permission/permits, obligation/oblige, prohibition/prohibits. The difference is that ODRL

uses an abstract class to group the three classes. Both the resources have taxonomical

relations.

There is some weakness of L4LOD, among them the lack of a concept to model the exception

which is always present in all real licenses.

Below, an overview of the vocabulary references.

MIREL- 690974 of 41 27/12/2017

D2.2


3.4 LegalRuleML

3.4.1 Description

LegalRuleML takes inspiration from LKIF, particularly in terms of closely representing legal

knowledge and legal reasoning. LegalRuleML, derived from RuleML [7] encourages the

effective exchange and sharing of such semantic information between legal documents,

business rules, and software applications [6].

3.4.2 Feature Analysis

LegalRuleML has 2 modules:

1. Legal_metadata.xml: models the legal metadata concerning the legal rules

1. identification: information about the authors of the rules (because a norm can

have different interpretations equally legitimate under the legal point of view)

2. references: identification of the textual fragments involved in the rules modeled

3. sources: models the connection between textual fragments and rules (it is strictly

connected with references and allow the isomorphism requirement).

4. events: defines temporal events (without any sematic, which is given by

timesInfo)

5. timesInfo: provide semantic information about the events

6. rulesInfo: meta-information about the rule

7. hierarchy: ranging of the rules in the defeasibility logic

2. Legal_operators.xml: defines the legal operators (deontic operators and behaviours)


LegalRuleML [6] has key features which do not appear in other ontologies such as LKIF:

MIREL- 690974 of 41 27/12/2017

D2.2


temporal aspects are not linkable to any part of a rule with arbitrary granularity;

the temporal aspect is not managed with appropriate operators;

violation-reparation and, in general, behaviors are not richly modelled;

defeasibility is not linked to the temporal parameters;

suborder lists of atoms, where the order is determinant, are not possible.

3.5 CLO

3.5.1 Description

CLO organises juridical concepts and relations on the basis of formal properties defined in

DOLCE+. The development of the Core Legal Ontology (CLO) takes into account

methodologies proper of foundational ontologies [19], proposals in the field of legal

ontologies (e.g. [20], Breuker et al. in [21]), as well as a large literature on legal knowledge

representation and legal philosophy.

3.5.2 Feature Analysis

An analysis of the features of the CLO ontology is reported in the schemes below:

PURPOSE

Role: understanding the domain

Application: supports three kinds of legal tasks in the Civil Law countries (i)

conformity checking, legal advice and norm comparison

MODELING FEATURES

Language: English

Ground ontology: DOLCE+

Level of structure: high

MIREL- 690974 of 41 27/12/2017

D2.2



There exists a distinction between:

• legal description or conceptualization: which includes norms, regulations crime

types, etc.

• situations or legal facts or cases: legal state of affairs, non-legal state of affairs that

are relevant to the Law, and purely juridical state of affairs.

Then, a dependence between descriptions and situations is considered: a descriptions is a

reification of a theory that formalises the content of a norm. That is, every legal description

classifies and constrains a state of affair. This means that a description is satisfied by a

situation when at least some entity in the situation is classified by at least some concept in

the description. In CLO the satisfy (SAT) relations is implemented. Moreover, a legal case is

a reification of a state of affairs that is a logical model of the theory.

Section 4: Features Analysis of legal ontologies

The objective of this section is the interpretation and analysis of the existing legal ontologies

to identify common rather than task-specific features to be used and revisited within the

objectives of the MIREL project.

4.1 Types of features for legal ontologies

Candidate features have been extracted from existing ontologies, surveys, and research

articles. Here we present a list of the sources together with the extrapolated features.

Source 1 (S1): University of Loughborough survey18

scope/goal [also in S2]

standard methodologies of development (e.g., NEON, METHONTOLOGY)

naming and spelling consistency all over the ontology

the ontology is based on (or has reused) other ontologies

the language the ontology is built in (e.g. OWL) [also in S2,S3]

updates number and frequency

ontology accessibility/availability (user license)

18 https://lborobusiness.eu.qualtrics.com/jfe/form/SV_cN5scAnvfy8QLoF

MIREL- 690974 of 41 27/12/2017

D2.2


Source 2 (S2): “Types and roles of legal ontology” by Andre Valente [1]

role (chosen from: organize and structure information, reasoning and problem

solving, semantic indexing and search, semantic integration and interoperation,

understanding the domain) [also in S1]

application

type

o knowledge representation formalism: the language the ontology is built in

(RDF, ONTOLINGUA, DOLCE-DAML, OWL, KIF, PROTEGE) [also in

S1,S3]

o level of structure (i.e. number of relation)

type of reasoning (e.g. instance classification, rule base reasoning, class or frame

reasoner)

Source 3 (S3): “Theory and methodology in Legal Ontology Engineering: experiences and

future direction” by Casanovas, Sartor et al. in “Approaches to legal ontologies” [4]

applications (which seem the role of S2)

granularity (domain specific vs core)

degree of formality (highly axiomatized vs. lexical or language-oriented) [also in

S1, S2]

methodologies of development (top-down, bottom-up, middle-out)

knowledge sources for concept and term extraction (official legal sources vs. legal

expert interview and ethnographic work)

construction

language

4.2. Features classification In this section, the types of features are analyzed across the selected sources S1, S2 and S3

of the previous section. The table below presents an overview of this comparison,

highlighting common vs specific types of features.

Sources S1 S2 S3

Role (chosen from 5 types)

scope/goal x

role x

Application (specifies the scope of application inside the role) x x

MIREL- 690974 of 41 27/12/2017

D2.2


Granularity (core/domain) x

Methodologies of development

standard methodologies x

top-down, bottom-up, middle-out x

Construction (manual, semi-automated, automated) x

Language (the human language used, not the KRF)

Knowledge sources for terms extraction x

Ground ontology (the ontology is based on (or has reused) other

ontologies)

x

Knowledge representation formalism

knowledge representation formalism x

language the ontology is built x

degree of formality x

Level of structure (number of relations) x

Type of reasoning x

Temporal clauses

Updates’ number and frequency x

Ontology accessibility/availability (user licence) x

MIREL- 690974 of 41 27/12/2017

D2.2


A proposal of classification of the features may be described by the following labels: purpose,

modeling, technical, usability, and semantic. The table below presents such classification.

PURPOSE-CENTERED features

Role

Application

Granularity

MODELING features

Methodologies of development

Construction

Language

Knowledge sources for terms extraction

Ground ontology

Level of structure

Temporal clauses

TECHNICAL features

Knowledge representation formalism

Type of reasoning

MIREL- 690974 of 41 27/12/2017

D2.2


USABILITY features

Updates number and frequency

Ontology accessibility/availability

SEMANTIC features

Semantic relations (taxonomical, etc.)

Abstract concepts / relations

Section 5: MIREL-specific achievements

In this section, two MIREL-focused works on ontological representation are presented. The

first contribution has been published at the 30th international conference on Legal

Knowledge and Information Systems (JURIX) 2017 [5]. The second contribution has been

published in the Journal of Applied Ontologies [22].

5.1 Normative Requirements as Linked Data

The work is about a proposal of a proof of concept for the ontological representation of

normative requirements as Linked Data on the Web. More precisely, starting from

LegalRuleML, we presented an extension of this ontology to model normative requirements

and rules. An operational formalization of the deontic reasoning over these concepts on top

of the Semantic Web languages is then developed.

5.1.1 Ontological extension of the LegalRuleML Meta Model

In this section, a description of the competency questions that motivate an extension of the

LegalRuleML ontology, and then we detail the core concepts of our new legal ontology as

well as their formalization in OWL.

Among the many approaches to design an ontology [2], the writing of motivating scenarios

is a very usual initial step of specifications to capture problems that are not adequately

MIREL- 690974 of 41 27/12/2017

D2.2


addressed by existing ontologies [3]. The motivating scenario for us here is to support the

annotation, detection and retrieval of normative

requirements and rules. We want to support users in information retrieval with the ability to

identify and reason on the different types of normative requirements and their statuses. This

would be possible through ontology population approaches, but the lack of an existing

ontology covering these aspects slows this process, as well as the further development of

more advanced applications in legal computer

science.

In a second step of ontology specification, a standard way to determine the scope of the

ontology is to extract from the scenarios the questions and answers it should be able to

support if it becomes part of knowledge-based system. These so-called competency questions

[3] place demands on the targeted ontology, and

they provide expressiveness requirements. The competency questions we target for this

ontology are:

What are the instances of a given type of requirements (and its sub-types), e.g.,

obligation?

Is a requirement violated by one or more states of affairs, and if so, which ones?

Is a given description of rules and states of affairs coherent?

What are the rules, documents and states of affairs linked to a requirement, and by

what relations?

5.1.3 Core primitives

To support the competency questions and relying on definitions from Legal-RuleML [9] and

deontic reasoning [10, 11], we identified a set of core primitives for an ontology capturing

the different aspects of normative requirements, and supporting the identification and

classification tasks. We called that ontology Normative Requirement Vocabulary (NRV),

and made it available and dereferenceable following the Linked Data principles. The

namespace is http://ns.inria.fr/nrv# with the preferred prefix nrv respectively submitted both

to LOV [8] and to http://prefix.cc.

The top class of the ontology is the Normative Requirement which is defined as the set of the

requirements implying, creating, or prescribing a norm. Then we have a number of upper

classes to capture different features of the requirements:

the classes Compensable Requirement, Non Compensable Requirement,

Compensated Requirement characterize the requirements with respect to their

relation to compensation.

the classes Violable requirement, Non Violable Requirement, Violated Requirement

and Compliant Requirement characterize the requirements with respect to their

relation to a Compliance or a Violation.

MIREL- 690974 of 41 27/12/2017

D2.2


the other classes follow the same logic, and they distinguish requirements with respect

to their perdurance, persistence, co-occurance and preemptiveness.

Using these upper classes, we positioned and extended three primitives from the

LegalRuleML Meta Model (i.e., Prohibition, Permission, Obligation), each one inheriting

from the appropriate super classes we introduced. For instance, Permission inherits from Non

Violable Requirement and Non Compensable Requirement, while Obligation inherits from

Violable Requirement and Compensable Requirement. Specializations of these classes are

then used to introduce the notions of Achievement, Maintenance and Punctual. For the

complete list of classes and their definitions, we refer the reader to the online documentation

available at the namespace URL. These primitives and definitions provide the taxonomic

skeleton of our NRV ontology.

5.1.3 Formalization

In this section, we provide some formalization details (ontological commitment) and their

translation into OWL (computational commitment). We will use the TriG syntax [14] for

RDF, and the prefixes we use in the rest of this article are:

lrmlmm: http://docs.oasis-open.org/legalruleml/ns/v1.0/metamodel#

owl: http://www.w3.org/2002/07/owl#

rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs: http://www.w3.org/2000/01/rdf-schema#

rulemm: http://docs.oasis-open.org/legalruleml/ns/v1.0/rule-metamodel#

xml: http://www.w3.org/XML/1998/namespace

xsd: http://www.w3.org/2001/XMLSchema#

nrv: http://ns.inria.fr/nrv#

nru: http://ns.inria.fr/nrv-inst#

We captured the disjointedness expressed in the upper classes representing exclusive

characteristics of normative requirements (compensable / non-compensable, violable / non-

violable, persistent / non persistent):

:NormativeRequirement a rdfs:Class ;

owl:disjointUnionOf ( :CompensableRequirement :NonCompensableRequirement )

;

owl:disjointUnionOf ( :ViolableRequirement :NonViolableRequirement ) ;

owl:disjointUnionOf ( :PersistentRequirement :NonPersistentRequirement ) .

We initially considered the disjointedness of a compliant requirement and a violated

requirement, however this disjointedness is not global but local to a state of affairs and

therefore it does not translate to a general disjointedness of classes, i.e., a requirement may

be violated by a state of affairs but compliant with an

MIREL- 690974 of 41 27/12/2017

D2.2


other one at the same time. However, this led us to capture this issue as a property

disjointedness, since a requirement cannot be violated and be compliant with the same state

of affairs at the same time:

:hasCompliance a owl:ObjectProperty ; rdfs:label "has for compliance"@en ;

rdfs:domain :ViolableRequirement ; rdfs:range lrmlmm:Compliance ;

owl:propertyDisjointWith :hasViolation .

Obligations are an example of non-disjoint union between achievements and maintenances,

since a punctual requirement is both an achievement and a maintenance:

lrmlmm:Obligation a rdfs:Class ;

rdfs:subClassOf :ViolableRequirement ;

rdfs:subClassOf :CompensableRequirement ;

owl:unionOf ( :Achievement :Maintenance ) .

:Achievement a rdfs:Class ; rdfs:label "achievement"@en ;

owl:disjointUnionOf ( :PreemptiveAchievement :NonPreemptiveAchievement ) ;

owl:disjointUnionOf ( :PerdurantAchievement :NonPerdurantAchievement ) ;

rdfs:subClassOf lrmlmm:Obligation .

:Maintenance a rdfs:Class ; rdfs:label "maintenance"@en ;

rdfs:subClassOf lrmlmm:Obligation .

Violated and compensated requirements could be defined with restrictions on the properties

hasViolation and hasCompensation:

:ViolatedRequirement a rdfs:Class ;

rdfs:subClassOf :ViolableRequirement ;

owl:equivalentClass [ a owl:Restriction ;

owl:onProperty :hasViolation ;

owl:minCardinality 1 ] .

:CompensatedRequirement a rdfs:Class ;

rdfs:subClassOf :CompensableRequirement ;

owl:equivalentClass [ a owl:Restriction ;

owl:onProperty :hasCompensation ;

owl:minCardinality 1 ] .

Likewise we could be tempted to define a compliant requirement with the following two

restrictions:

1 :CompliantRequirement a rdfs:Class ; rdfs:label "compliant requirement"@en ;

2 rdfs:subClassOf :ViolableRequirement ;

3 owl:equivalentClass [ a owl:Restriction ;

4 owl:onProperty :hasCompliance ;

5 owl:minCardinality 1 ] .

MIREL- 690974 of 41 27/12/2017

D2.2


6 owl:equivalentClass [ a owl:Restriction ;

7 owl:onProperty :hasViolation ;

8 owl:maxCardinality 0 ]

.

However we removed the second part (lines 6-8) of the restriction since it reintroduces a

disjunction between the compliant and violated requirement classes.

The notions of compliance and violation are not generally disjoint but only disjoint locally

to a state of affair, i.e., a normative requirement can be violated and compliant at the same

time but with respect to different states of affairs.

However, OWL definitions cannot rely on RDF 1.1 named graphs, which we will use for

representing states of affairs. Therefore we will need another mechanism to capture this kind

of constraints.

Because we used disjoint unions, the ontology is in OWL DL, i.e., SHOIN(D), and more

precisely, in the AL(U)C(H)RN family, i.e., AL attributive language, (U concept union), C

complex concept negation, (H role hierarchy), R limited complex role inclusion axioms,

reexivity, irreexivity, role disjointedness, and N

cardinality restrictions.

We decided to declare the signature of properties (e.g., hasViolation, hasCompensation) at

the ability level (e.g., violable requirement, compensable requirement), and not at the

effective status level (e.g., violated requirement, compensated requirement) because each

status will be local to a state of affairs.

Therefore, in the end, we avoided too strong restrictions and signatures. If we remove

cardinality restrictions, unions and disjointedness, the ontology becomes compatible with

OWL EL and OWL RL which could be interesting for implementations relying on rule-based

systems, especially when we consider the extensions

proposed in the following sections.

5.1.4 Requirements as Linked Data

Using the LegalRuleML Meta Model and the NRV ontology we can now start to represent

normative requirements as Linked Data. Let us introduce two examples.

The first one is a rule stating that according to Australian law one cannot drive over

90km/h:

<http://gov.au/driving-rule> a lrmlmm:Source ;

rdfs:label "driving rules in Australia"@en .

nru:LSS1 a lrmlmm:Sources ;

lrmlmm:hasLegalSource <http://gov.au/driving-rule> .

MIREL- 690974 of 41 27/12/2017

D2.2


nru:LRD1 a lrmlmm:LegalRuleMLDocument ;

lrmlmm:hasLegalSources nru:LSS1 ;

lrmlmm:hasAlternatives [ lrmlmm:fromLegalSources nru:LSS1 ;

lrmlmm:hasAlternative nru:PS1 ] ;

lrmlmm:hasStatements nru:SS1 .

nru:SS1 a lrmlmm:Statements ;

lrmlmm:hasStatement nru:PS1 .

nru:PS1 a lrmlmm:PrescriptiveStatement, lrmlmm:Prohibition ;

rdfs:label "can't drive over 90km"@en .

The second example is a rule stating that employees of CSIRO must wear their badge when

they are inside CSIRO facilities:

<http://csiro.au/security-rule> a lrmlmm:Source ;

rdfs:label "security rules in CSIRO"@en .

nru:LSS2 a lrmlmm:Sources ;

lrmlmm:hasLegalSource <http://csiro.au/security-rule> .

nru:LRD2 a lrmlmm:LegalRuleMLDocument ;

lrmlmm:hasLegalSources nru:LSS2 ;

lrmlmm:hasAlternatives [ lrmlmm:fromLegalSources nru:LSS2 ;

lrmlmm:hasAlternative nru:PS2 ] ;

lrmlmm:hasStatements nru:SS2 .

nru:SS2 a lrmlmm:Statements ;

lrmlmm:hasStatement nru:PS2 .

nru:PS2 a lrmlmm:PrescriptiveStatement, lrmlmm:Obligation ;

rdfs:label "you must wear your badge inside CSIRO facilities"@en .

5.1.5 State of affairs as named graphs.

The ability to define contexts and group assertions was one of the main motivations for

having named graphs in RDF 1.1 [15]. The notion of state of affairs at the core of deontic

reasoning is naturally captured by named graphs where all the statements of each state of

affairs are encapsulated as RDF triples in a named graph, identifying that precise state of

affairs. We provide here four examples of states of affairs respecting (2 and 3) or breaking

(1 and 4) the rules of the normative statements described above. The core idea is to represent

each state of affairs as a named graph typed as a factual statement of LegalRuleML.

:StateOfAffairs1 a lrmlmm:FactualStatement .

GRAPH :StateOfAffairs1 { rdfs:label "Tom" ;

:Tom :activity [ a :Driving ;

:speed "100"^^xsd:integer ;

rdfs:label "driving at 100km/h"@en ] .

}

MIREL- 690974 of 41 27/12/2017

D2.2



GRAPH :StateOfAffairs2 {

:Jim :activity [ a :Driving ; rdfs:label "Jim" ;

:speed "90"^^xsd:integer ;

rdfs:label "driving at 90km/h"@en ] .

}


GRAPH :StateOfAffairs3 { rdfs:label "Jane" ;

:Jane :location [ rdf:value :CSIRO ;

:start "2017-07-18T09:30:10+09:00"^^xsd:date ;

:end "2017-07-18T17:00:10+09:00"^^xsd:date ] ;

:badge [ rdf:value :CSIRO ;

:start "2017-07-18T09:30:10+09:00"^^xsd:date ;

:end "2017-07-18T17:00:10+09:00"^^xsd:date ] .

}


GRAPH :StateOfAffairs4 { rdfs:label "Steve" ;

:Steve :location [ rdf:value :CSIRO ;

:start "2017-07-18T09:30:10+09:00"^^xsd:date ;

:end "2017-07-18T17:00:10+09:00"^^xsd:date ] ;

:badge [ rdf:value :CSIRO ;

:start "2017-07-18T10:30:10+09:00"^^xsd:date ;

:end "2017-07-18T17:00:10+09:00"^^xsd:date ] . }

5.1.6 Deontic reasoning as SPARQL rules

Since the notion of named graph that appeared with RDF 1.1 is absent from OWL 2 and its

constructors, we need to implement the reasoning on states of affairs by other means. The

SPARQL language is both a standard and a language able to manipulate named graphs so we

propose to use SPARQL rules.

In this section, we explore the coupling of OWL reasoning with SPARQL rules to formalize

and implement some deontic reasoning. Description Logics (DL) support reasoning on the

description of concepts and properties of a domain (terminological knowledge or T-Box) and

of their instances (assertional knowledge or

A-box). They are the basis of the Web Ontology Language (OWL). The classical inferences

supported by DL are instance checking, relation checking, subsumption checking, and

consistency checking [16]. While these inferences are useful to reason about deontic

knowledge (e.g., a compensable requirement must also be

a violable requirement), they do not cover all the inferences we want to support here in

particular deontic rules (e.g., a requirement is violated by a state of affairs if, during a specific

period of time, a given constraint does not hold). These rules rely on complex pattern

MIREL- 690974 of 41 27/12/2017

D2.2


matching including, for instance, temporal interval comparison that go beyond OWL

expressiveness.

As a proof of concept, the following rules check the violation or compliance of the statements

made by the previous states of affairs. The core idea is to add to each named graph of each

state of affairs the deontic conclusions of the legal rules relevant to it. The following rules

update compliance and violation for the driving speed requirement:

# Driving rules

DELETE { graph ?g { nru:PS1 nrv:hasCompliance ?g } }

INSERT { graph ?g { nru:PS1 a nrv:ViolatedRequirement ;

nrv:hasViolation ?g } }

WHERE { graph ?g { ?a a :Driving ; :speed ?s . }

FILTER (?s>90) }

;

DELETE { graph ?g { nru:PS1 a nrv:ViolatedRequirement ;

nrv:hasViolation ?g } }

INSERT { graph ?g { nru:PS1 nrv:hasCompliance ?g } }

WHERE { graph ?g { ?a a :Driving ; :speed ?s . }

FILTER (?s<=90) }

The following rules update compliance and violation for the CSIRO badge requirement:

# Badges rules

INSERT { graph ?g { nru:PS2 a nrv:ViolatedRequirement ; nrv:hasViolation ?g }}

WHERE { graph ?g { ?x :location [ rdf:value ?o ; :start ?ls ; :end ?le ]

optional { ?x :badge [ rdf:value ?o ; :start ?bs ; :end ?be ] .

FILTER (?bs<=?ls && ?be>=?le) } }

FILTER ( ( ! bound (?bs)) ) }

;

INSERT { graph ?g { nru:PS2 nrv:hasCompliance ?g } }

WHERE { graph ?g { ?x :location [ rdf:value ?o ; :start ?ls ; :end ?le ]

?x :badge [ rdf:value ?o ; :start ?bs ; :end ?be ] . }

FILTER (?bs<=?ls && ?be>=?le) }

The following rules update compliance for the state of affairs after violations were checked:

# Housekeeping: compliance rules

INSERT { graph ?g {?n a nrv:CompliantRequirement } }

WHERE { ?g a lrmlmm:FactualStatement .

?n a nrv:ViolableRequirement .

graph ?g { ?n nrv:hasCompliance ?g }

minus { graph ?g { ?n nrv:hasViolation ?g } } }

;

MIREL- 690974 of 41 27/12/2017

D2.2


DELETE { graph ?g {?n a nrv:CompliantRequirement } }

WHERE { ?g a lrmlmm:FactualStatement .

?n a nrv:ViolableRequirement .

graph ?g { ?n nrv:hasViolation ?g } }

5.1.7 Proof of concept and experimentation

To validate and experiment with the ontology, the Linked Data and the rules, we used two

established tools: the latest version of the Protege platform -17] and the reasoners it includes

were used to check the NRV OWL ontology which was found coherent and consistent; the

latest version of CORESE [18] was used to load the LegalRuleML and NRV ontologies, the

Linked Data about the rules and the states of affairs, and the SPARQL rules to draw the

conclusions for the two first states of affairs concerning speed limitation.

5.2 European Legal Taxonomy Syllabus

This contribution described a new concept of legal ontology together with an ontology

development tool, called European Legal Taxonomy Syllabus (ELTS). The tool is used to

model the legal terminology created by the Uniform Terminology project on EU consumer

protection law as an ontology.

5.2.1 Multi-linguality and Multi-jurisdictionality

Achieving shared conceptualisations of law is difficult in any legal system. The problem is

confounded in Europe, which is increasingly governed by multiple jurisdictions - European,

national and sometimes regional as well - and with many official languages. The last

amendment to Regulation No. 1 of 15 April 1958 recognises twenty-four languages as having

the status of official and working languages in European institutions. This poses a significant

challenge, since each of the twenty-eight Member States that make up the European

Community have their own cultural baggage that no one, let alone the Community legislature,

is able to escape. The Sapir-Whorf hypothesis (Hoijer, 1954) maintains that it is impossible

for a concept in one language to be imported wholesale into another language due to linguistic

relativity.

Nevertheless, the European Union steadfastly seeks to achieve ‘harmonisation’ of laws in

whole sectors of diverse legal disciplines. Harmonisation of EU law is a complicated matter.

For Regulations, the implementation is automatically ‘binding in its entirety and directly

applicable in all Member States’, while Directives are ‘binding, as to the result to be

achieved, upon each Member State to which it is addressed, but shall leave to the national

authorities the choice of form and methods. The procedure of creating European Union laws

in a multi-lingual environment has its own complications.

MIREL- 690974 of 41 27/12/2017

D2.2


Although debates on legislation in the European Parliament and Council can take place in all

official languages with the assistance of interpreters, the working draft legislation under

discussion is usually only available in one language - English or French or occasionally

German. At the end of the drafting phase, a team of specialist legal translators translate the

text into the other official community languages, subject to consistency checks by the EU’s

General Translation Team.

A research group at the European Commission, aiming to consolidate existing EU law,

worked on

the ‘Principles of the Existing EC Private Law’ or ‘Acquis Principles’ (ACQP), which would

provide a common terminology as well as common principles to guide uniform

implementation and interpretation of European law. The Acquis Principles were sketched by

scholars in European Private Law from the socalled Acquis Communautaire, a collection of

the existing body of EU primary and secondary legislation as well as European Court of

Justice decisions. This glossary aims to minimise conceptual differences and semantic

ambiguity in the EU legal process, and is of great importance in the activities of translators

as well as legal professionals.

Whether the Acquis Principles can truly address the considerable challenges it seeks to

address is a moot question. For instance, it does not solve the problem of conceptual and

terminological misalignment altogether, since Directives need to be transposed into national

law using terms that

make sense within the national legal system. In fact, it is precisely this second level of

translation that causes most problems. Transposing a rule often means having to use and

adapt a different, and sometimes conflicting, lexical baggage to the traditional national one.

The incoherent mix of different cultures and traditions results in translations that are often

inaccurate or insufficiently precise from a legal point of view.

There are several possibilities in the transposition process, as depicted in Figure 1, where the

lines connecting concepts from the EU level to national ones represent the “implement”

relation. The figure below illustrates possible misalignments (1)-(5) between the European

MIREL- 690974 of 41 27/12/2017

D2.2


and national levels. Details are published in [22].

5.2.2 European Legal Taxonomy Syllabus - The ELTS Ontology Schema

As stated in the Introduction, ELTS is composed of a legal ontology schema, a web-based

legal ontology tool conforming to the ontology schema, and a multi-lingual legal ontology

on European consumer law constructed with the tool. In this section, we present the legal

ontology schema by describing the motivations behind it resulting from the legal analysis in

Section 2 of [22].

In this section, we will present the online tool to construct and browse the ontology, showing

for each feature of the tool relevant examples from the consumer law ontology derived from

the terminology of the Uniform Terminology project we use as a benchmark to show the

feasibility and expressivity of our approach.

The European Legal Taxonomy Syllabus is an ontology framework designed to address the

issues raised in Section 2 of [22]. The most important insight from lawyers, which informed

our design, was that the meaning of a legal term depends on its context (jurisdiction, domain,

legislation, timeframe, interpretation).

We designed an ontology schema that aims to make these considerations explicit. Our system

attempts to model interpretations beyond the letter of the law as well as temporal evolution

of concepts in an intuitive way, allowing users to traverse different definitions and determine

which definitions are most relevant to their query.

From a pragmatic need to model European law and national transpositions, the ontology

framework

MIREL- 690974 of 41 27/12/2017

D2.2


must be both multi-lingual, multi-jurisdictional and multi-level. This allows links to be made

between different national ontologies, so that users can find similar terms in other languages

and other jurisdictions, and compare their meaning.

The schema has been designed to support the definition of concepts on the basis of a

comparative law methodology. We chose to adopt a bottom-up approach to ontology

creation, i.e., to compare low-level concepts among different legal systems. In our view, a

comparative law methodology ensures a non-superficial understanding of legal terms.

Starting from low-level elements rather than

abstract or composite concepts fosters evidence-based conceptualisations and generally gives

rise to less disagreement among ontology contributors.

We also adopt the view of comparative law that legal concepts are influenced by formants

other than legislation, and ensure that the ontology should provide space for annotation and

citations of case law and doctrine.

The main purpose of the European Legal Taxonomy Syllabus tool is to support the work of

legal practitioners, scholars and translators in multi-lingual and multi-jurisdictional contexts

such as the European Union, to help share technical knowledge and analyse the law in all its

complexity. As a secondary aim, the system can be used to build automated tools, e.g., for

information retrieval and translation.

Since the ontology framework is primarily designed for human reference, it supports

lightweight rather than axiomatic ontologies. In the classification of Giunchiglia and

Zaihrayeu [23] we use (informal) lightweight ontologies. Designing a full-fledged ontology

(expressed, for example, in OWL-DL) is a difficult and error-prone task even for experienced

users.

The choice of building a lightweight ontology was motivated by the need to develop a more

user-friendly system, thereby enlarging the possible audience of contributors and users, and

at the same time, reducing the costs of building an ontology. It was also driven by the

consideration that many peculiarities of law, such as interpretation, penumbra, interaction

with social values, metaphors and dynamics are far from having commonly accepted

solutions in logic.

Our analysis of the legal domain led us to identify the following features in the ontology

schema to allow the representation of relevant information in the legal domain. Such features

are not always straightforward to represent using standard approaches to ontology design.

Terms and concepts: the varying and highly contextualised meaning of legal terms means

that there needs to be a structured way to allow more than one meaning for terms in a legal

ontology. ELTS separates terms and concepts, allowing terms to be mapped to different

concepts and to have concepts mapped to more than one term (in the same language, or in

different languages in the case of multi-lingual nations and of EU law). Terms can be either

MIREL- 690974 of 41 27/12/2017

D2.2


single words or multi-words (cf. examples below). Therefore we have many-to-many

relations between terms and concepts, thereby allowing both synonymity and polysemy.

Since we are in a multi-lingual context, a term in our system is structured as the term itself

together with the jurisdiction identifier and the relevant language, in order to account for

multiple languages in the same jurisdiction. The idea of neatly separating the lexicon from

the conceptual level is of course not new and is the foundation of several models, including

the well- known Lemon lexicon model.

Sources: each concept is linked to its legal source(s), possibly more than one, since a concept

can arise from multiple parts of legislation and also from the interaction of legislation, case

law and doctrine. However, listing the sources is not enough. For the sake of clarity, concepts

are associated with a description in natural language. Nevertheless, it is important to identify

the legal sources, since they contain important information about scope and purpose.

Domains: in addition to the contextual information of legal sources, the concepts are classed

in domains, traversal with respect to the jurisdictions and levels, in order to organize

knowledge and improve search and browsing. Each concept can be associated with more than

one domain.

Multi-lingual and multi-jurisdictional: the multi-jurisdictional nature of the EU requires

not only a multi-lingual ontological framework associating concepts with terms in different

languages, but

also a multi-jurisdictional one. The ELTS schema involves separate ontologies for each

jurisdiction

whose concepts are in turn mapped to terms in relevant languages. Specific relations connect

concepts from the ontologies of different jurisdictions, which are separate from the relations

within the same ontologies. In particular, the relation “implement”, described in more detail

below, connects concepts in the EU ontology with concepts in the national ontologies.

Multi-level: besides being multi-lingual and multi-jurisdictional, the ELTS schema

distinguishes between the EU level and national levels: these constitute separate ontologies.

Note that the EU level contains a single ontology, where all concepts have associated terms

in the different languages of the Member States considered. This, however, is a

simplification, since it is possible that there are unwanted divergences among different

languages even at the EU level. Concepts in the EU level ontology can be associated with

terms in all the languages of the Member states. Concepts in the different ontologies at the

national level can be associated only with the terms of the languages of the nation they belong

to.

Ontological relations: due to the holistic nature of the law, legal concepts are better

understood in relation to others. Therefore within each ontology, the concepts are linked via

ontological relations such as “is-a”, “part-of” and by more specific legal relations such as

legal “purpose”, expressing the legal goal (e.g., “consumer protection”) that the legal system

aims to achieve with that concept. Relations among concepts may change over time (as stated

below).

Implementation relation: Concepts at the EU level can be connected to national level

concepts by an implementation relation, representing how the concept has been transposed

into one national legal system. Given the separation of terms and concepts, the term

MIREL- 690974 of 41 27/12/2017

D2.2


associated with an EU level concept is not necessarily the same term used to express the same

concept in the implementing legislation at national level. The relation is many-to-many, since

a national level concept may be the fusion of more than one EU level concept and/or a

Member State may express an EU level concept in multiple ways.

Dynamic nature of meaning: the ontology schema must account for the fact that almost

every legislation brings new definitions of terms that effectively replace prior

conceptualisations. Therefore the ontology must represent the current legal situation, and yet

researchers may still need to refer to deprecated conceptualisations for historical purposes or

to trace the evolution of terms. This also raises the problem of what happens to the ontological

relations associated with the replaced concept, a sort of frame problem. Since we are dealing

with a semi-automated context, the proposed solution is that the new concept should inherit

all the relations of the replaced one and it is the responsibility of the knowledge engineer to

remove the outdated ones and possibly introduce new relations in accordance with

authoritative interpretations.

Interpretation: there is a tension in the law between the highly contextual character of

meaning, which leads to multiple meanings for one term, each one associated with specific

sources, and the need to systematise legal knowledge. The legislator can introduce in a new

legislation a new meaning for a term, whose utility can go beyond the context of that

legislation. Due to interpretation, the meaning of the term can be extended also to other

concepts denoted by the term in other contexts. The frequent merging of meanings assigned

to legal terms that takes place in legal reasoning or simultaneous transposition of multiple

directives means that more complex concepts can emerge which do not necessarily replace

contextual meanings in all situations. This situation cannot be simply modelled by “is-a”

relations, since the concepts resulting from the interpretation are neither necessarily more

general in meaning, nor necessarily the simple intersection of the more contextualized

meanings. Rather, what is generalized is the context of use of the concept. Moreover, the

original contextual meaning of a term must always be available to the user and not only the

merged one deriving from interpretation.

Conceptual drafts: the ontology must be able to accomodate the conceptualization also of

draft legislation, to compare the resulting “draft” ontology. Glossaries created to achieve

consistency in legal terminology, such as the CFR and ACQP above, may contain

conceptualisations that are yet to be accepted officially. ELTS allows the creation of

temporary legal ontologies whose concepts are linked to current legal ontologies until such

time as the old concepts are replaced when the draft

legislation becomes law.

MIREL- 690974 of 41 27/12/2017

D2.2


The ETLS ontology UML schema is represented below. Details are published in [22].

Section 6: Conclusions and Research Challenges

In this deliverable, an overview of the background and the existing ontologies for legal

reasoning are examined and evaluated in terms of definitions and expressivity.

Then, a work of analysis on the common and specific features is presented, in order to trace

a line across domains, requirements and the representation of legal norms in conjunction with

an ontology based representation.

Finally, a specific work on an ontology extension is presented. This contribution has been

published at the 30th international conference on Legal Knowledge and Information Systems

(JURIX) 2017 and represents a first effort in the scope of the MIREL project on Work

Package 2, taking into account Work Packages 3 and 4 and their requirements.

References

[1] Valente, Andre. "Types and roles of legal ontologies." Law and the semantic web.

Springer Berlin Heidelberg, 2005. 65-76.

[2] F. Gandon, Ontology Engineering: a Survey and a Return on Experience, RR-4396,

INRIA. 2002.

[3] M. Uschold, M. Gruninger, Ontologies: Principles, methods and applications, The knowl-

edge engineering review, 11(2), 93{136, 1996, Cambridge University Press.

MIREL- 690974 of 41 27/12/2017

D2.2


[4] Sartor, Giovanni, et al. "Approaches to Legal Ontologies: Theories, Domains,

Methodologies. Law." Governance and Technology series. Springer (2011).

[5] Gandon, Fabien, Guido Governatori, and Serena Villata. "Normative Requirements as

Linked Data." The 30th international conference on Legal Knowledge and Information

Systems (JURIX 2017). 2017.

[6] Athan, Tara, et al. "Oasis legalruleml." Proceedings of the Fourteenth International

Conference on Artificial Intelligence and Law. ACM, 2013.

[7] Boley, Harold, Adrian Paschke, and Omair Shafiq. "RuleML 1.0: the overarching

specification of web rules." International Workshop on Rules and Rule Markup Languages

for the Semantic Web. Springer, Berlin, Heidelberg, 2010.

[8] Vandenbussche, Pierre-Yves, et al. "Linked Open Vocabularies (LOV): a gateway to

reusable semantic vocabularies on the Web." Semantic Web 8.3 (2017): 437-452.

[9] Athan, Tara, et al., OASIS LegalRuleML, Proceedings of the Fourteenth International

Conference on Articial Intelligence and Law, ACM, 2013.

[10] M. Hashmi, G. Governatori, M.T. Wynn, Normative requirements for regulatory

compliance: An abstract formal framework. Omnes Information Systems Frontiers 18(3), pp.

429-455, 2016

[11] K. Efstratios, N. Bassiliades, G. Governatori, G. Antoniou, A Modal Defeasible

Reasoner

of Deontic Logic for the Semantic Web, International Journal on Semantic Web and

Information Systems, (IJSWIS) 7 (2011): 1, doi:10.4018/jswis.2011010102

[14] World Wide Web Consortium, RDF 1.1 TriG, W3C Recommendation, 25 February

2014.

[15] F. Gandon, O. Corby, Name That Graph or the need to provide a model and syntax

extension to specify the provenance of RDF graphs., W3C Workshop | RDF Next Steps, Jun

2010, Palo Alto, United States.

[16] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, P. F. Patel-Schneider, The

Description Logic Handbook: Theory, Implementation, Applications. CUP, 2003.

[17] N.F. Noy, M. Sintek, S. Decker, M. Crub�ezy, R. W. Fergerson, and M. A. Musen,

Creating

semantic web contents with protege-2000, IEEE Intelligent Systems, 16.2 (2001): 60-71.

MIREL- 690974 of 41 27/12/2017

D2.2


[18] O. Corby, R. Dieng-Kuntz and C. Faron-Zucker, Querying the semantic web with corese

search engine, In Proc. of the 16th European Conf. on Articial Intelligence, pp. 705-709

(2004), IOS Press.

[19] Masolo C., Borgo S., Gangemi A, Guarino N, Oltramari A. The WonderWeb Library of

Foundational Ontologies”, IST 2001-33052 Wonder Web.

http://wonderweb.semanticweb.org/deliverables/documents/D18.pdf, 2003.

[20] Visser P., T. Bench Capon, Ontologies in the Design of Legal Knowledge Systems,

towards a Library of Legal Domain Ontologies, in Proceedings of Jurix 99, Leuven,

Belgique.

[21] Benjamins R., Casanovas P., Breuker J., Gangemi A. Law and the Semantic Web. Berlin,

Springer, 2004.

[22] Ajani, Gianmaria, et al. "The european legal taxonomy syllabus: a multi-lingual, multi-

level ontology framework to untangle the web of european legal terminology." Applied

Ontology (2017).

[23] Giunchiglia, F. and Zaihrayeu, I. (2009). Lightweight ontologies. In Encyclopedia of

Database Systems, pages 1613–1619. Springer, Berlin.

D2 - MIning and REasoning with Legal texts · 5.1.1 Ontological extension of the LegalRuleML Meta...

Documents

Transcript of D2 - MIning and REasoning with Legal texts · 5.1.1 Ontological extension of the LegalRuleML Meta...