With the advent of the digital transition,the need for control of access to information has significantly increased. In the EU in particular, Law Enforcement Agencies (LEAs) need to exchange information. In recent years, many regulations have emerged to control data processing and exchange. Texts other than the GDPR, such as the "Law Enforcement Directive (LED)", appeared to regulate specifically their processing of data. This paper aims to present an ontological representation of data sharing and processing between law enforcement agencies. After highlighting the lacking notions in existing domain ontologies like LegalRuleML, we propose an ontology that integrates the required elements for our application case. Furthermore we illustrate the validation and usage of this ontology through a rule-based reasoning mechanism for data related procedures between law enforcement agencies.
With the advent of the digital transition in many domains, the need for control of access to information has significantly increased. Nowadays, these controls tend to rely on an unambiguous description of data and knowledge, through ontologies and annotations of privacy or sensitivity levels. In the EU in particular, Law enforcement agencies (LEAs) need to exchange information regularly in the context of cooperation between the police forces.
In recent years, many regulations have emerged to control data processing. Among them
the GDPR [
The tables of legal provisions from the Handbook on European data protection law - 2018 edition1 allowed a more precise selection of specific articles and even paragraphs in these texts.
As of now, it has become more complex and time-consuming for LEAs to assess whether
the measures they would request as part of a data procedure are mandatory, permitted or
prohibited under the regulations. Thus, it is meaningful to consider a framework that would
provide support to LEAs and help them estimate the lawfulness of the procedures they intend to
perform. Several frameworks and tools, like DAPRECO [
To meet this requirement, we propose a framework consisting of the following components: • an ontology to create a knowledge base; it represents all the relevant aspects of the decision-making process including the legal rules, the data sets or data collections metadata, the actors involved in the data processing and their investigation objective; • a set of formal rules extracted from the regulations and represented thanks to the concepts and properties defined in the ontology; • a reasoning mechanism on the knowledge base able to verify the compliance of a use case to each formal rule.
In this paper, we will focus on presenting an ontology to describe criminal aspects as well as actions taken through investigation procedures by LEAs that involve data sharing and processing. The paper is structured as follows. In Section 2 we review existing works in legal 1https://fra.europa.eu/en/publication/2018/handbook-european-data-protection-law-2018-edition knowledge representation to identify which parts of them we could reuse. We then present in Section 3 our own ontology that makes it possible to represent legal rules, investigation contexts as well as dataset content and metadata. We finally report the ontology validation and experimentation process in Section 4 before concluding (Section 5).
The representation of legal knowledge is an important research field in knowledge management
that led to the development of several domain ontologies: PrOnto [
Our focus being the regulations about data exchanges between LEAs in various contexts, we want the ontology to allow to represent all the following aspects: • The context in which procedures for data acquisition or transfer are performed, since part of this context impacts the decision-making process. For example, requesting a data transfer in a national security emergency situation will have a diferent answer than in a non-emergency situation. • The characteristics of the data that would be involved in the procedure, for example whether or not some personal information is actually public. • The terminology used in the regulations as well as the deontic notions of permission, obligation, and prohibition, which are required to represent the formal legal rules we will be using for reasoning. • The structure of the regulations from which the formal rules are extracted as well as a way to link the formal rules to their sources.
Some of these aspects are already covered by existing works. For example, Akoma Ntoso3
allows the representation of executive, legislative and judicial documents in a structured manner
using an XML vocabulary dedicated to the legal field, notably by modeling the structure of such
texts. A "source" module of LegalRuleML [
LKIF-core6 [16] provides several useful concepts such as everything related to a Legal Agent,
its Roles, the Organizations he belongs to and the Actions he performs. These concepts are
reused in PrOnto [
Although the "deontic" module of LegalRuleML, or the deontic classification of rules in DPV
or in the Open Digital Rights Language (ODRL)7 could ofer a good base for representing
the deontic aspect of normative rules, the extension of LegalRuleML proposed by F. Gandon
et. al with the Normative Requirement Vocabulary (NRV) ontology [
The legal core ontology UFO-L [
However, we are focusing on the representation of procedures such as the EIO [
The review of existing legal models is summarized in table 1. Each ontology is evaluated on each aspect using 2 values, each on a scale between 0 and 2, and presented in this form : 2 / 1. The first value reflects how much of the aspect is represented in the ontology, 0 meaning it is not represented at all and 2 it is represented in an elaborate way. The second value indicates the extent to which the concepts used to represent an aspect satisfies the requirements, with 0 meaning it does not correspond at all and 2 it accurately meets the requirements. In cases where an aspect is not present at all in an ontology (which would result in a 0 / 0 evaluation), we leave the corresponding cell empty.
From this study emerges that LKIF-core, LegalRuleML and DPV are the most complete
candidates to be reused as basis for our ontology. These 3 ontologies cover most of the aspects
5https://w3c.github.io/dpv/dpv/
6https://github.com/RinkeHoekstra/lkif-core
7https://www.w3.org/TR/odrl-model/
8https://www.w3.org/TR/vocab-dcat-3/
needed and provide a lot of relevant high level concepts to build upon. Moreover, a study
conducted in 2017 for the design of UFO-L [
The construction of such an ontology has started with the manual extraction of concepts and properties from regulations. Rather than using a language model, given the (small) size of the text, text analysis was conducted manually in collaboration with a PhD student in law, who provided an expert interpretation of the rule relevance and representation.
To build the ontology, we referred to the following parts of the texts mentioned in Section 1
[
The definition of competency questions [19] is a standard way to characterize the scope of an ontology. They express the queries to be further requested to knowledge graphs that represent data using the concepts and properties in the ontology. They reflect the users’ interest. In the current project, the competency questions bear on possible issues or limitations in relation with data sharing among LEAs in the course of an investigation. Among the competency questions we defined, the main one are the following: • Which are the data or evidences involved in a procedure? What are their types / sub-types, e.g "Sensitive Personal Data"? • What is the situation in which a procedure takes place? • Which are the authorities involved in a procedure and what are their roles? • Are there people (suspects, witnesses,...) involved in a procedure and in which way are they involved? • Which rule expresses constraints on the use of a dataset in a standard context? in an emergency context? • What are the main features to characterise a dataset?
We will now detail the main concepts and classes present in the ontology to answer these
questions. Currently, the ontology includes 175 classes and 98 properties. Its structure remains
simple, with few additional axioms, as we have not yet formalized all the disjunctions between
classes for example. We propose several top classes, each representing a diferent aspect of the
problem, as illustrated in Appendix A:
Procedure class: its subclasses correspond to each type of procedure we are focusing on, such
as the EIO and EPOC. We will search for a possibility to align our Procedure with classes
like Process from LKIF-core [16];
Modality class and its sub-classes: These classes relate to the deontic aspect of regulations
such as Permission, Obligation and Prohibition. We aligned them with the
corresponding concepts from the NRV ontology [
Since Authorities are indeed central in all the aspects of the procedures we seek to represent, this is one of the most connected top class of the ontology. For example, a procedure such as an EIO emission has an issuing authority, a receiving authority, that may or may not be competent to treat the request, and a validation authority. Besides, in case of a data acquisition request, diferent pieces of data may be in possession each of a specific authority, and these authorities are requested to transfer data one to another one. These authorities are by nature organizations and thus are related to concepts appearing in other ontologies like in LKIF-core for example [16]; Data class: In an access control system, "Data" would play the role of "objects" in our modeling.
The numerous sub-classes of Data represent the diversity of datatypes involved in
datasharing situations. Although we noticed some similarities with concepts in the Data
module of PrOnto [
Action class: This general class encompasses several types of actions at diferent levels of the
data-sharing request scenario. First some actions are performed by authorities to initiate
a procedure or to ensure its continuation, with classes like EIO Emission. We also
consider all actions that can be requested through procedure forms, such as the transfer of
evidences or investigation data, with for example the Data Transmission class. These
"Actions" would be the ones appearing in a standard access control system to determine
the right to access data for someone depending on the action they want to perform on
them. Apart from the Transmission sub-class that is similar to the Transmit class
from the Action module of PrOnto [
Regarding the properties, we mainly consider properties linking procedures to their content and the authorities involved. As such, we find: • asks Measure from a Procedure to a Investigation Measure that indicates which investigation measures are required by a procedure like an EIO. • has Motive from a Procedure to a Ground of Justification to express the justification behind a procedure which is essential to evaluate if the investigation measures requested are adapted and proportionate to the situation • would Involve that allows to express the predicted / requested involvement of authorities, people (who could be suspects, victims, witnesses in investigation cases for example) but also of specific data in a procedure. • All the properties linking a procedure to the authorities involved in it such as has Issue Authority, has Reception Authority, hasCompetentAuthority and hasValidationAuthority. • We also represent the dates of emission, transmission or execution of a Procedure thanks to the data property hasEmissionDate, hasTransmissionDate and hasExecutionDate respectively.
Many properties characterize the actions requested in the procedures, with for example: • In case of actions like a transmission of information, we represent its source and destination authorities with the object properties fromTransmission and toTransmission. • Several Boolean data properties allow to indicate if an action is necessary, adapted, or even if it would cause harm to someone. An evolution of the model involves refining the representation of these properties by switching from a boolean indicator to more detailed information like who it would cause harm to.
The ontology has not yet been published since it is still being tested and validated through experimentation.
As part of the ontology validation process, we used it in a framework of decision support system
for data sharing or data processing requests by LEAs. Given a set of rules from regulations
and given a data sharing request (DSR), the goal is to determine if the data sharing request is
permitted, prohibited or mandatory according to the law. This framework, inspired by Gandon
et. al work about normative requirements [
The SPARQL query associated with this article is as follows, given the definition of nru:Rule1 as a Permission Rule in the knowledge graph beforehand: INSERT { g r a p h ? g { n r u : R u l e 1 n r v : h a s C o m p l i a n c e ? g } } WHERE { g r a p h ? g { ? a c t i o n a : E m i s s i o n . ? a c t i o n : i n v o l v e s P r o c e d u r e ? e i o . ? a c t i o n : i s N e c e s s a r y " t r u e " ^ ^ x s d : b o o l e a n . ? e i o : a s k s M e a s u r e E I O ? m e a s u r e .
? m e a s u r e : c o n d i t i o n s I d e m " t r u e " ^ ^ x s d : b o o l e a n . }
To test the framework, we manually created 20 data-sharing requests allowing to test the
triggering conditions of each rule. For example, to test article 6 paragraph 1 of [
An authority "authority_1" issues a European Investigation Order (EIO) for the authority "exec_auth_1" and with a validation authority "valid_auth_1". This EIO asks for a specific investigation measure: the seizure of materiel from a certain "Arthur Watts" living at "address_01" to prevent a proof destruction. The EIO also indicates that it is "necessary".
We express this DSR as a named graph in RDF format, by populating the ontology to form a knowledge base, which we present here using the TriG syntax: <∗ named graph u r i ∗ > { : E I O _ e m i s s i o n _ 0 1 a : P r o c e d u r e E m i s s i o n ; : i n v o l v e s P r o c e d u r e : EIO_01 ; : h a s I s s u e A u t h o r i t y E I O : a u t h o r i t y _ 1 ; : h a s E x e c u t i o n A u t h o r i t y E I O : e x e c _ a u t h _ 1 ; : h a s V a l i d a t i o n A u t h o r i t y E I O : v a l i d _ a u t h _ 1 ; : i s N e c e s s a r y " t r u e "^^ xsd : b o o l e a n . : EIO_01 a : EIO ; : asksMeasureEIO : measure_01 . : measure_01 a : I n v e s t i g a t i o n M e a s u r e ; a : M a t e r i a l S e i z u r e ; : h a s J u s t i f i c a t i o n M e a s u r e : r i s k _ o f _ e v i d e n c e _ a l t e r a t i o n ; : i n v o l v e s P e r s o n M e a s u r e : Arthur_Watts ; : i n v o l v e s L o c a t i o n M e a s u r e : a d d r e s s _ 0 1 . }
The reasoning engine, here a SPARQL endpoint, matches the conditions of the SPARQL request and the RDF triples in the named graph. Then, with all the conditions met, a new triple is added to the named graph to indicate that the DSR it represents complies with "Rule1", meaning that the requested procedure shall be permitted.
This paper presented a new ontology usable in a decision-making support framework dedicated to data management between law enforcement agencies. This ontology captures the specific elements needed to represent legal rules, the context of data-related procedures among LEAs as well as the involved dataset metadata. We showed how it can be used in a rule-based reasoning engine to determine the compliance of procedures involving data sharing and processing in LEAs like EIO and EPOC to regulations.
Future work includes validating the ontology thanks to methods like OOPS! 9 and OQuaRE [20] to ensure its correctness. After generating the ontology documentation and metadata, we will make it available online. Another short term perspective will be to improve the ontology reusability by splitting it into meaningful modules as well as by adding alignments with domain and core ontologies.
Since the legal text selection that we conducted in this study, these legal texts have been
updated and new texts have been voted. For example, [
Testing other frameworks of rule-based reasoning is also part of future work to develop a full
decision support system. We are planning to use a formalism based on the LKIF [
The work in this paper is partially funded by the H2020 project STARLIGHT10 (“Sustainable Autonomy and Resilience for LEAs using AI against High priority Threats”) that received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 101021797. We would also like to thank Ronan PONS, PhD student in Law, who assisted this work by providing his insight as legal expert. 9https://oops.linkeddata.es 10https://www.starlight-h2020.eu/ [14] H. J. Pandit, D. Lewis, Modelling provenance for gdpr compliance using linked open data vocabularies, in: Proceedings of the 5th Workshop on Society, Privacy and the Semantic Web - Policy and Technology (PrivOn2017) co-located with ISWC 2017, CEUR-WS volume 1951, 2017. URL: https://ceur-ws.org/Vol-1951/PrivOn2017_paper_6.pdf. [15] H. J. Pandit, B. Esteves, G. P. Krog, P. Ryan, D. Golpayegani, J. Flake, Data privacy vocabulary (dpv) – version 2, 2024. arXiv:2404.13426. [16] R. Hoekstra, J. Breuker, M. Di Bello, A. Boer, The lkif core ontology of basic legal concepts,
International Journal of High Performance Computing Applications - IJHPCA (2007) 43–63. [17] G. Guizzardi, A. Benevides, C. Fonseca, D. Porello, J. Almeida, T. Prince Sales, Ufo: Unified foundational ontology, Applied Ontology (2022). doi:10.3233/AO-210256. [18] C. Grifo, J. Castello, Ontology of healthcare compliance based on just culture paradigm, in: workshop RELATED’21: Relations in the Legal Domain, @ International Conference on Artificial Intelligence and Law 2021, June 21–25, 2021, Sao Paulo, SP, Ceur-ws vol-2896, 2021, pp. 25–43. URL: https://ceur-ws.org/Vol-2896/RELATED_2021_paper_3.pdf. [19] M. Uschold, M. Gruninger, Ontologies: principles, methods and applications, The Knowledge Engineering Review 11 (1996) 93–136. doi:10.1017/S0269888900007797. [20] A. Duque-Ramos, J. T. Fernández-Breis, M. Iniesta-Moreno, M. Dumontier, M. E. Aranguren, S. Schulz, N. Aussenac-Gilles, R. Stevens, Evaluation of the oquare framework for ontology quality, Expert Syst. Appl. 40 (2013) 2696–2703. URL: https://doi.org/10.1016/j.eswa.2012. 11.004. doi:10.1016/J.ESWA.2012.11.004. [21] EUR-Lex, Regulation - 2023/1543 - en - eur-lex, https://eur-lex.europa.eu/legal-content/
EN/TXT/?uri=CELEX:32023R1543, 2023. Last Accessed: 19/06/2024. [22] EUR-Lex, Directive - 2023/977 - en - eur-lex, https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX:32023L0977, 2023. Last Accessed: 19/06/2024. [23] EUR-Lex, Directive - 2023/1544 - en - eur-lex, https://eur-lex.europa.eu/legal-content/EN/
TXT/?uri=CELEX:32023L1544, 2023. Last Accessed: 19/06/2024. [24] T. F. Gordon, Combining rules and ontologies with carneades, in: Proceedings of the 5th International RuleML2011@ BRF Challenge, CEUR Workshop Proceedings, Citeseer, 2011, pp. 103–110.
Figure 3: Overview of the ontology core elements