Acknowledgements

The first and foremost acknowledgement I would like to make is in thanking my supervisors - Dave Lewis and Declan O’Sullivan. This work has been made possible by their vision, encouragement, motivation, and guidance.
I would also like to express my thanks to my parents - pappa and mummy - who always have and continue to provide support and motivation since I came to being. Thank you Annalina Caputo for your understanding, strength, and friendship in this journey. Thank you Gauri Noolkar for asking me to always keep moving ahead and for pushing me through the difficult times.

The environment at work and away was a joy thanks to the many people whom I met and were around. It is a pleasure to know you - Gary, Nicole, Lucy, Ademar, Brendan, Jamie, Javier, Kris, Christoph, Anirban, Ramisa, Anuj, Dominika, Sahil, Judie, Jeremy, and many others.

Thank you to Sabrina, Axel, Javier for giving me the opportunity to visit Vienna and work there. Thanks to Rob, Christoph, and Eoin for providing guidance and assistance, and to Mark for pushing me to apply myself in the real world.
This work is supported by the ADAPT Centre for Digital Content Technology which is funded under the SFI Research Centres Programme (Grant 13/RC/2106) and is co-funded under the European Regional Development Fund.

Abstract

The General Data Protection Regulation (GDPR) is a landmark law regarding privacy and data protection. GDPR stipulates potentially large fines if an organisation is found to not be compliant. This has resulted in research involving use of technological resources to meet and evaluate compliance requirements. Such approaches involve representing information about processing activities in a machine-readable format, verifying its correctness, and evaluating whether it meets the obligations of GDPR.

Under GDPR, an organisation is required to maintain and demonstrate documentation showing its compliance to the obligations and requirements regarding processing activities. This documentation involves information on how the activities were planned, evaluated for compliance, and executed. In addition to these, if consent is used as a legal basis to justify the processing, then information about how that consent was obtained also needs to be recorded in order to evaluate and demonstrate its adherence to requirements specified by GDPR.

Utilising semantic web technologies provides a machine-readable and interoperable representation of information that can be queried and verified based on open standards such as RDF, OWL, SPARQL, and SHACL. This thesis presents the use of semantic web technologies to represent and associate information regarding processing of personal data and consent with GDPR for assistance with its compliance. In particular, it addresses three deficits within the current state of the art for utilising linked data approaches for GDPR compliance. The first of these is regarding associating information with the text and concepts of GDPR which would enable the adoption of a linked data approach to automation and management of compliance documentation. The second concerns representations of activities regarding the planning and execution of processes concerning personal data and consent. The third involves representing information required to evaluate and demonstrate compliance with the requirements of consent.

The outcomes of the work are presented in the thesis in the form of major contributions of GDPRtEXT - a linked data representation of the text of GDPR and a glossary of concepts relevant for its compliance, GDPRov - an OWL2 ontology based on PROV-O for modelling activities associated with personal data and consent in ex-ante (planning) and ex-post (execution) phases, and GConsent - an OWL2 ontology for representing information regarding consent. The thesis also presents minor contributions describing application of semantic web technologies in the form of querying and validation of information using the SPARQL and SHACL standards.

List of Abbreviations & Acronyms

List of RDF Namespace Prefixes

1 Introduction

1.1 Background & Motivation

To date, 132 of the 206 states listed by the United Nations (UN) have a privacy law which regulates the usage of personal data (Greenleaf 2019). However, their intended application suffers from a disconnect with the rapid progress in technology. In particular, the use of internet as a medium for data exchange and its pervasiveness and connectivity to individuals via devices such as the smartphone has led to industrial data harvesting at large scales (Christl and Spiekermann 2016). To counter this problem, lawmakers in the European Union (EU) passed the General Data Protection Regulation (GDPR) (“Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation)” 2016) in 2016 with the aim of providing individuals with the right to information and control over use of their personal data, and to simplify requirements for organisations through a unified regulation across the EU.

The GDPR has received a large amount of attention due to its prospective fines which can potentially be up to 4% of an organisation’s annual turnover or €20 million - whichever is greater. As of February 2020, there have been over 215 publicly known instances of fines associated with the GDPR (“GDPR Enforcement Tracker - List of GDPR Fines” 2019), the largest of which was the €50 million fine to internet giant Google (“The CNIL’s Restricted Committee Imposes a Financial Penalty of 50 Million Euros Against GOOGLE LLC | CNIL” 2019). Being a regulation and replacing the Data Protection Directive (DPD) (“Directive 95/46/EC of the European Parliament and of the Council on the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of Such Data” 1995), GDPR provides a uniform set of compliance requirements across the EU, and is the basis of national privacy laws implemented in its member states (McCullagh, Tambou, and Bourton 2019). Furthermore, GDPR has influenced other privacy laws, such as the California Consumer Protection Act (CCPA) (“Assembly Bill No. 375 Chapter 55: An Act to Add Title 1.81.5 (Commencing with Section 1798.100) to Part 4 of Division 3 of the Civil Code, Relating to Privacy” 2018), thereby further expanding similarities in compliance requirements across the globe.

The most visible change of the GDPR for most individuals is the ubiquitous ‘consent dialogue’ on websites that requests ‘consent’ - one of the legal basis for processing of personal data in GDPR. Despite being a legal requirement, consent dialogues have been accused of being non-transparent and subverting the spirit of the GDPR (Machuletz and Böhme 2019; Utz et al. 2019). The issue of consent itself has received significant interest in development and utilisation of technological solutions for compliance due to the right to withdraw consent provided by the GDPR which enables an individual to revoke their previously given consent and requires processing of personal data based on it to be halted. Opinions published by legal experts and bodies, in absence of case law on this issue, have expressed the need for greater transparency regarding activities associated with use of consent (“Opinion of Advocate General - Case C‑673/17” 2019).

Compared to other privacy laws, including its predecessor DPD, GDPR provides significantly stricter and detailed requirements for processing of personal data and requires organisations to explicitly document information in relation to its obligations in order to be compliant. This information consists of identification of GDPR clauses applicable to the practices of an organisation and the steps taken to fulfil requirements and obligations for compliance. From a technical or information management point of view, GDPR specifies interactions between entities in a clear manner. An example of this is an organisation using consent as the legal basis being required to provide information about processing activities to the data subject. Furthermore, this information is required to be maintained, evaluated, and documented to demonstrate compliance upon request by authorities. At the same time, this information is also associated with other stakeholders - such as through privacy policies, user agreements, terms and conditions, or even data processing agreements. This makes it clear that information associated with GDPR compliance is also used in other applications and involves multiple stakeholders.

As GDPR is a data protection law, its compliance is concerned primarily with processing of personal data, its legality, and associated operations within an organisation. This includes processing in both tenses - past as well as future - where an organisation is obligated to first determine and ensure its requirements and activities involving processing of personal data are valid as per the GDPR, and to then maintain a record of such activities as the processing takes place. These are defined¹ within the legal domain by the terms ‘ex-ante’ to specify compliance assessment before activity takes place (preventative) and ‘ex-post’ to specify compliance assessment after the activity has taken place (corroborative).

While the GDPR does not explicitly mention a ‘phase’ of compliance, its use enables associating the information to the planning and processing operations carried out within an organisation. The planning of processing operations also involves investigation of whether the intended operations will be compliant to the legal obligations, and the required corrections to ensure they continue to be so. The processing operations carried out also need to be inspected to ensure they met the requirements set forth in the planning stage and that the processing itself was legally compliant.

The combination of new requirements and significant fines has provided an incentive to utilise technology in meeting the obligations and requirements stipulated by GDPR towards its compliance. Existing efforts, such as the International Organization for Standardization (ISO), have addressed this change by updating standards to meet increased requirements with global privacy laws. In the context of GDPR, ISO/IEC 27001² defines requirements for an information security management system, and its extension ISO/IEC 27701³ defines a privacy information management system, which together provide a framework for managing privacy risks associated with personal data processing. Adherence to such standards provides a commonality in the information management practices of an organisation, and assists in the compliance process by providing a structured interpretation and demonstration of practices based on the standardised specifications.

Technological development of solutions for legal compliance face two problems in general - the first being algorithmic interpretation of requirements associated with legal compliance. This is difficult as the text used in a legal document such as GDPR does not readily lead to algorithmic compliance due to ambiguity and uncertainty in its legal interpretation - especially in domain specific use-cases. In addition, because GDPR has been enforced for a comparatively short period - the interpretation of its clauses as requirements for compliance relies on clarification through legal opinions and decisions by supervisory authorities and courts. The second problem is that regardless of how technology is used in the compliance process, formal investigations of legal compliance require information to be documented and associated with the specifics of the law they intend to comply with - in this case the articles and clauses of GDPR. Traditionally, this is carried out through creation of documentation by legal experts, lawyers, and legal departments. Therefore, technological solutions addressing GDPR compliance must also provide information documentation in addition to assessment of compliance.

Incorporating legal compliance into organisational requirements has led to several approaches such as: use of symbolic (mathematical) logic, knowledge representation of legal text as logical rules, deontic rights specifying rights and obligations, defeasible logic based on exceptions, first order temporal logic, access control, markup based representations, and goal modelling of obligations (Otto and Anton 2007). While there has been significant work in the use of technology to adopt these approaches towards addressing and evaluating compliance in the last decade (Sadiq, Governatori, and Namiri 2007; Otto and Anton 2007; Gordon, Governatori, and Rotolo 2009; Fellmann and Zasada 2014; Akhigbe, Amyot, and Richards 2015; Elgammal et al. 2016; Kirrane, Mileo, and Decker 2016), the issue of associating information with legal documents has received relatively less attention. Where contemporary methods are sufficient to meet legal requirements, their use of text-based document formats prevents effective technological solutions that can be scaled, automated, or utilised in an information management system. To enable such approaches, information associated with compliance must be represented using machine-readable formats that enable the use of querying to retrieve information as well as validation methods to ensure its correctness. Furthermore, the need to share information between stakeholders defined within the GDPR provides motivation towards developing interoperability in information and solutions - which also provides transparency in the compliance process. By using open and interoperable standards, the commonality in representation and interpretation of information benefits stakeholders and reduces costs associated with innovation regarding information management and regulatory compliance.

Governmental agencies across the globe have addressed the issue of information interoperability by adopting the principles of Linked Data (Bizer, Heath, and Berners-Lee 2011) and have produced interoperable standards (Palmirani, Sperberg, et al. 2018; European Union, Publications Office, and ELI Task Force 2015; van Opijnen 2011) to facilitate use of information in technological solutions. These standards implement principles of the Semantic Web (“Semantic Web - W3C” 2015) by utilising the Resource Description Framework (RDF) (“RDF 1.1 Primer” 2014) to specify information in an interoperable, extensible, and machine-readable manner. This has paved the way for development of technologies that address challenges associated with legal compliance through greater use of automation and operations at large scales. Consequently, the use of Linked Data and Semantic Web within the legal domain has resulted in the development of ontologies for organising and structuring information, reasoning and problem solving, semantic indexing and search, semantic integration and interoperability, and understanding the domain (Rodrigues et al. 2019).

Semantic Web is also being used to address the challenges associated with GDPR compliance through commercial⁴ solutions as well as large-scale European research projects such as SPECIAL (“Scalable Policy-Aware Linked Data Architecture for Privacy, Transparency and Compliance (SPECIAL)” 2019), MIREL (“MIREL - MIning and REasoning with Legal Texts” 2019), DAPRECO (“DAta Protection REgulation COmpliance (DAPRECO)” 2019), BPR4GDPR (“BPR4GDPR” 2019), and RestAssured (“RestAssured” 2019). The technological solutions developed within these utilise ontologies to represent the information required for compliance and a corresponding approach that expresses and evaluates obligations to assess compliance. In general, semantic web technologies provide numerous advantages, such as: their basis in standards maintained through community and stakeholder engagement by W3C; an interoperable information representation specification that serves as the base for other specifications that build on top of it to provide knowledge modeling, querying, and validation; and the ability to easily build upon an existing knowledge-system by extending the underlying data models while retaining compatibility. These advantages make semantic web technologies and ideal and useful toolset in the legal compliance domain, and especially the GDPR given the emphasis of its requirements on information and documentation for compliance.

The work presented in this thesis also utilises the Semantic Web to address GDPR compliance. It focuses on the representation of activities associated with processing of personal data and consent as a subset of information relevant to the investigation of GDPR compliance. These activities correspond to how organisations plan their processing of personal data and execute or implement them, and are therefore relevant to the planning and management of operations within organisations. This includes activities associated with acquiring consent owing to the role of consent as a legal basis and the assertion that consent itself is also personal data. The novelty of this work lies in the application of linked data principles to associate information with GDPR and the advantages this provides in utilising semantic web technologies to represent, query, and validate information relevant for compliance.

The role of semantic web in this is towards representing information relevant for GDPR compliance that can be associated with the text of GDPR following Linked Data Principles. This involves use of existing standards of RDF (“RDF 1.1 Primer” 2014) and Web Ontology Language (OWL2) (“OWL 2” 2012) to represent information as ontologies, SPARQL (“SPARQL 1.1 Query Language” 2013) for querying information, and Shapes Constraint Language (SHACL) (Knublauch and Kontokostas 2017) to validate information. The use of semantic web standards and technologies enables the information to be persisted in a machine-readable, interoperable, and queryable form - and thus readily lends itself to automation using technological solutions in the areas of legal compliance and its documentation.

In terms of scope, the work presented in this thesis addresses only the representation and management of information associated with GDPR compliance, and is not intended to provide an authoritative assessment of compliance as only supervisory authorities and courts have legal authority in this matter. In the same vein, the research presented in this thesis is also not intended to replace professional opinions such as that offered by lawyers and legal experts. Instead, the intention of the work is to demonstrate the applicability and feasibility of using technology as a tool to assist with the compliance process.

1.2 Research Question

The research question investigated in this thesis is:

Research Question

To what extent can information regarding activities associated with processing of personal data and consent be represented, queried, and validated using Semantic Web technologies for GDPR compliance?

1.2.1 Definitions

The following definitions are used in the context of the research question outlined above and this thesis:

• information regarding activities: information about how processes, services, tasks, or other similar concepts are planned, executed or carried out, along with the resulting outcomes and the artefacts used or required;

• activities associated with processing of personal data: information about how personal data will be or has been obtained (its source), its usage - including storage, sharing, analysis, or other forms of processing;

• activities associated with consent: information about how consent will be or has been obtained, its usage as a legal basis, the information represented by consent, and its planned or recorded withdrawal;

• querying: retrieving information using a structured representation based on the underlying representation of information;

• validation: assessment of information to meet a constraint or requirement;

• associate or link information with GDPR: to establish an association or link between information and clauses or concepts of the text of GDPR;

• subset of GDPR: a subset of the clauses defined in the text of the GDPR;

• ex-ante compliance: compliance regarding processing before it has taken place, i.e. A-priori;

• ex-post compliance: compliance regarding processing after it has taken place, i.e. A-posteriori;

• compliance questions: questions that retrieve information relevant for determination of compliance;

• transparency of information: specifying or providing information in a way that enables others (external entities) to understand and analyse it.

1.2.2 Research Objectives

The research question represents a broad investigation which is difficult to address as a whole. Therefore, it is reconstructed as multiple ‘sub-research questions’ which are smaller in scope and provide specific aims in the form of research objectives. These objectives are influenced by the analysis of the state of the art and subsequent identification of gaps in Section 3.7 as potential opportunities to answer the research question. The first two objectives are structured on the identification of information required for GDPR compliance. The third objective focuses on the use of semantic web technologies for information representation, while the fourth and fifth objectives are associated with querying and validation of information respectively.

The GDPR is a legal document structured into 173 Recitals, 99 Articles, and 21 Citations. Of these, not all clauses are relevant to activities associated with personal data and consent. Therefore, the first research sub-question concerns investigation and identification of the sub-set of GDPR regarding activities associated with personal data and consent, along with information on the ex-ante and ex-post aspects of such activities towards compliance. This provides the first objective as:

RO1: Identify the subset of GDPR relevant for activities associated with processing of personal data and consent regarding compliance.

Following identification of the relevant sub-set of GDPR, information required to represent activities needs to be identified through ‘compliance questions’ representing an investigation process to identify the actors, entities, and relationships relevant for GDPR compliance. This provides the second objective as:

RO2: Identify information required to represent activities associated with processing of personal data and consent in investigation of GDPR compliance.

The identified information is then represented as semantic web ontologies consisting of concepts and relationships. This representation acts as the information model upon which questions or queries can be executed to retrieve information for determining compliance. The formalisation of information as an ontology provides a controlled vocabulary for validation of information to determine its sufficiency and correctness before determining compliance.

Instead of representing all required information in a single large ontology, modular ontologies provide better reuse and are easier to engineer (Suárez-Figueroa, Gómez-Pérez, and Fernández-López 2012). A modular ontology is limited in scope towards representing a specific information category, and therefore is more consistent in its representation of concepts, and is easier to evaluate as compared to a larger ontology in which different concepts may have differing semantic connotations. Modular ontologies also provide better motivation for reuse though selective choosing of concepts in a module without dependency of concepts in other modules.

With this as motivation, the larger objective of RO3 for creating an ontology to address the research question is divided into three modular ontologies of: RO3(a) - associating information with clauses and concepts of GDPR; RO3(b) - representing information about activities associated with processing of personal data and consent; and RO3(c) representing information about consent. This provides the third objective as:

RO3: Create OWL2 ontologies for representation information about: (a): concepts and text of GDPR (b): activities associated with processing of personal data and consent (c): consent required to determine compliance

’Compliance questions’ retrieve information required to determine compliance, and are important in the documentation process. The information retrieval can be automated by utilising SPARQL queries to represent compliance questions using corresponding concepts and relationships from the developed ontologies. This provides the fourth objective as:

RO4: Represent compliance questions using SPARQL to query information about activities associated with processing of personal data and consent

The determination of compliance includes assessing whether a given information satisfies all obligations and requirements, and also involves validation of information itself in terms of correctness and completeness. In software engineering processes such assessments are automated as ‘tests’ that validate data and produce a report to record documentation. The same principle is utilised here to assess information for correctness and completeness based on requirements of GDPR. This is done using SHACL which enables expressing validation requirements over developed ontologies and produces a report which can be persisted and linked back to the GDPR for documentation of compliance. This provides the fifth objective as:

RO5: Utilise SHACL to: (a): validate information for GDPR compliance regarding activities associated with processing of personal data and consent (b): link validation results with GDPR

1.3 Research Methodology

1.3.1 Reviewing the State of the Art

A review of the state of the art (SotA) regarding approaches towards GDPR compliance was conducted at several stages of the research from March 2016 to September 2019. Publications associated with research objectives were driving factors in providing requirements to conduct a SotA review to capture the approaches and progress at that particular time. In addition, a general review of legal models for compliance was also conducted to identify relevant approaches which could be reused towards addressing requirements of the GDPR. The inclusion of approaches in SotA largely focused on the use of semantic web technologies and the extent of their applicability towards addressing the requirements of the GDPR.

An understanding of GDPR was obtained from sources including the official text of GDPR (“Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation)” 2016), its interpretation and clarification provided by authoritative bodies such as Data Protection Commissions in various jurisdictions, Article 29 Working Party (A29WP), and the European Data Protection Board (EDPB). In addition, guides and expert opinions provided by legal experts and organisations were utilised as non-authoritative sources to better understand requirements of GDPR compliance. Information requirements associated with compliance presented within the thesis are based on these sources and through studying case law related to interpretation of the GDPR where accessible.

Approaches and resources within SotA were reviewed where information was open and accessible - such as through academic publications and project deliverables. Where such information was not accessible - such as in commercial products and some resources in academic projects - only the available information was included in the review of SotA. Publications and resources were discovered through Google Scholar, Scopus, IEEExplore, ACM Digital Library, and through events such as conferences and events, and through dissemination networks such as Twitter. Zotero was used as a bibliography tool for managing references and notes.

1.3.2 Information Gathering

The gathering of information regarding requirements of GDPR and its compliance was done through a literature review of official and authoritative documentation published by legal bodies and organisations. In order to understand the requirements of GDPR and stakeholders involved, a model was developed to understand requirements for information interoperability for each stakeholder. The information about GDPR and its requirements was used to create ‘compliance questions’ to guide the ontology development process by acting as ‘competency questions’ (see Section 1.3.3) and to act as queries for retrieving information relevant to the compliance process. The questions also provided the basis for creating information validation constraints. This process fulfilled research objectives RO1 and RO2 and is described in Chapter 4.

1.3.3 Ontology Engineering

The ontologies developed to fulfil research objective RO3 used methodologies commonly adopted and recommended within the semantic web community. A general introductory guide for creating ontologies (Noy, McGuinness, and others 2001) was used to understand and start the process of ontology engineering. The actual construction of ontologies followed a combination of NeON methodology (Suárez-Figueroa, Gómez-Pérez, and Fernández-López 2012) and UPON Lite (De Nicola and Missikoff 2016) - where NeON was used to identify existing scenarios and gather requirements and UPON Lite was used to derive actionable steps or tasks to build and test the ontology using an agile development process. The combination provided a methodology for identifying relevant information from the GDPR (using NeOn) and iteratively building and updating an ontology to represent it (using UPON Lite). The methodology is described in more detail in Section 5.1, with a summary as:

1. Identification of aims, objectives, scope

2. Identify and analyse relevant information

3. Create use-cases and competency questions

4. Identify concepts and relationships

5. Create Ontology

6. Evaluate

7. Progressive iterations following steps 2 to 6

8. Dissemination

Each ontology was documented with metadata based on best practices advocated by the semantic web community⁵ for automatic generation of documentation using the WIDOCO tool (Garijo 2017). The namespace IRI was defined with persistent identifiers through the use of W3ID⁶. The ontology itself was archived in the public open repository Zenodo⁷ which provided it with DOIs. All code and resources associated with the ontologies are published in GitHub - an open and public code repository. The ontology and related resources were hosted on Trinity College Dublin servers to enable resolution of their IRIs on the internet.

1.3.4 Querying Information for GDPR Compliance

The querying of information utilised SPARQL and fulfilled research objective RO4. The methodology to represent compliance questions as SPARQL queries utilised questions from a real-world document published by the Irish Data Protection Commission for assisting organisations in evaluation their readiness for GDPR. The querying was demonstrated by representing each question within the document as a SPARQL query using the developed ontologies and executed over a synthetic use-case.

1.3.5 Information Validation Framework for GDPR Compliance

In order to demonstrate the validation of information, a modular framework was proposed in Section 6.2 consisting of creating a ‘compliance graph’ separate from the data graph for storing information relevant to compliance. This facilitated the querying and validation of information associated with compliance in a modular approach using SPARQL and SHACL respectively. The constraints and assumptions created from constraint questions in Chapter 4 were represented using SHACL and used to validate information based on obligations and requirements of GDPR compliance. Its application was demonstrated through a use-case evaluating validity of consent in a real-world website.

1.3.6 Evaluation Methodology

A summary of evaluations methods used in the thesis is presented in Table 1.1

1.3.6.1 Evaluating Ontologies

The developed ontologies presented in Chapter 5 were assessed in their sufficiency and completeness to answer the competency questions they were designed for. In addition, use-cases related to situations differing in compliance requirements were used to assess the ontology in terms of sufficient representation of related information. These use-cases were compiled from GDPR-related case law, SotA, and synthetic situations, and validated regarding information requirements with a legal expert. Ontologies were also evaluated using best practices advocated by the community throughout its development using a semantic reasoner to ensure logical consistency in expressed facts and axioms, and by using the OOPS! (Poveda-Villalón, Gómez-Pérez, and Suárez-Figueroa 2014) online service to detect common pitfalls in ontology design. Finally, the sections in this thesis describing each ontology present a comparison against similar ontologies identified in SotA to analyse novelty, strengths, and weaknesses. The sections also present relevant peer-reviewed publications where ontologies were presented and discussed. Citations to these publications were used to identify relevant approaches and to investigate criticisms and comparisons with other ontological representations.

An ad-hoc evaluation of ontologies is also presented through their use in querying and validation of information for research objectives RO4 and RO5. This demonstrated the sufficiency of each ontology to provide sufficient concepts for representing information to facilitate querying and validation processes.

1.3.6.2 Evaluating Querying of Information

The use of SPARQL to query information based on compliance question as presented in Section 6.1 was evaluated by applying it to questions in a document published by the Irish Data Protection Commission. The SPARQL queries utilised developed ontologies to represent the given question as a compliance question and provided an opportunity to evaluate the extent to which the ontology could represent these concepts. The approach itself was evaluated based on the extent to which the questions in the document could be expressed as SPARQL queries. Where a question could not or was not expressed using SPARQL, an analysis was carried out to determine the reason - such as the question not being in scope of the research question.

1.3.6.3 Evaluating Information Validation Framework

The framework developed for validating information using constraints derived from compliance questions is presented in Section 6.2. Its evaluation consisted of generating a synthetic use-case using the consent mechanism of a real-world website where the constraints related to consent and personal data activities were validated on information from the website . The use-case enabled representation of activities in both ex-ante and ex-post phases where ex-ante represented validity of the consent dialogue being presented, and ex-post represented determining validity of given consent. The information regarding activities related to personal data and consent within the use-case was represented using developed ontologies. SHACL was then used to define constraints derived from competency questions with links to GDPR added to the constraints using developed ontologies and custom properties.

The evaluation consisted of demonstrating use of SHACL and developed ontologies to express the constraints and the ability to link constraints and its validation results with relevant clauses of GDPR. The approach also demonstrated the use of validation results as actionable tasks for compliance associated with clauses of GDPR. The framework and the application were compared with approaches within the SotA to demonstrate novelty in use of SPARQL and SHACL for GDPR compliance.

1.4 Contributions of this Thesis

The two major contributions of this thesis are (based on ontologies in RO3): first - enabling association of information with the text of GDPR following linked data principles, and second - ontologies for representing information about activities associated with processing of personal data and consent. Minor contributions include formulating an information model of entities and their relationships in GDPR (based on information in RO1 and RO2), using semantic web technologies for querying (based on RO4) and validating (based on and RO5) information required for compliance. Resources associated with the contributions⁸, including published papers⁹, have been made accessible under open licenses (MIT, CC-by-4.0) for reproducibility and to foster adoption and re-use by the community.

1.4.1 GDPR as a Linked Data Resource

The first major contribution of this thesis is the GDPRtEXT resource - which provides a linked data version of the text of GDPR and a glossary of its concepts. It fulfils research objective RO3(a) and enables fulfilment of RO5(b) by exposing each individual article or point within the text of GDPR as a unique resource using semantic web to enable links to be established between information and clauses of the GDPR. As these links are machine-readable, they can be used in approaches to automate the generation and querying of information associated with GDPR - such as for compliance, management of business processes, or generation of privacy policies. Furthermore, GDPRtEXT extends and is therefore compatible with the ELI ontology (Thomas et al. 2019) used by the European Publications Office to publish legislations - including GDPR. ELI currently provides representations only at the document level, which GDPRtEXT extends for representing clauses at a granular level. GDPRtEXT thus provides its features in a manner compatible and interoperable with ELI.

It is currently common practice to refer to concepts within legal documents such as GDPR by associating them with their defining or relevant clauses within the document. GDPRtEXT provides a glossary (and vocabulary) of concepts defined or referred to within GDPR to assist with use of concepts associated with its compliance. Each concept or term is associated with its definition or articles of relevance within GDPR by using the linked data version of text provided by GDPRtEXT. This provides another way to link information to GDPR through use of concepts and has been used to indicate the source in definitions of terms and relationships within the other developed ontologies (see Section 1.4.2).

GDPRtEXT fills an important gap in the state of the art (as investigated in Chapter 3) by providing a mechanism to link information with the text of GDPR in a machine-readable manner. It is the only provider of a semantic web glossary of terms associated with GDPR and its compliance with a reference to their definition and usage within the text of GDPR. While there are other comparable and relevant methods to address such information (Agarwal et al. 2018; Palmirani, Martoni, et al. 2018a), GDPRtEXT is currently the only one that uses and extends ELI (“Council Conclusions Inviting the Introduction of the European Legislation Identifier (ELI)” 2012) - the official metadata standard for European legislation documents, and is also the only open and accessible ontology regarding GDPR and its concepts (Leone, Di Caro, and Villata 2019).

GDPRtEXT has been released¹⁰ under an open license (CC-by-4.0) and has been incorporated into Ireland’s open data portal¹¹. The provision of machine-readable concepts and reference to clauses of the GDPR makes GDPRtEXT an important resource for use in legal knowledge graphs.

1.4.2 Ontologies for representing activities about Personal Data and Consent

The second major contribution of this thesis are the two semantic web ontologies - GDPRov for representing information about activities associated with processing of personal data and consent, and GConsent for representing information associated with determining compliance of consent. Both ontologies define concepts and relationships using GDPRtEXT to indicate source within GDPR.

Together with GDPRtEXT, GDPRov and GConsent enable representation of activities required to evaluate and validate compliance with the GDPR. Apart from advancing state of the art, the ontologies also provide a vocabulary of terms and concepts relevant for GDPR compliance, and demonstrate the use of legal documents as a source for ontologies using linked data principles. Their usefulness has been demonstrated in approaches of: representation of information in privacy policies (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018a), generation of privacy policies from metadata (Harshvardhan Jitendra Pandit, O’Sullivan, and Lewis 2018b), and automating change-detection and its effects on activities (Harshvardhan J Pandit, O’Sullivan, and Lewis 2018). GDPRov¹² and GConsent¹³ are published under an open license (CC-by-4.0).

1.4.2.1 GDPRov

GDPRov enables representation of the processes and activities associated with the life-cycle of personal data and consent, and fulfils the research objectives RO3(b) and RO3(c). GDPRov extends PROV-O (Lebo et al. 2013) - which is the W3C standard for defining provenance information - to define ex-post (activity logs indicating things that have happened) information, and P-Plan (Garijo and Gil 2014) to define ex-ante (as an abstract model, template, or plan) representations of PROV activities based on scientific workflows. This enables it to represent planned activities as a model or template which is required to assess ex-ante compliance, and to associate it with its corresponding executions which are required to assess ex-post compliance. The linking of information between ex-ante and ex-post phase in GDPRov comes from its basis in scientific workflows. It also provides the opportunity to exploit this association for a more efficient approach in evaluation of compliance, as proposed and demonstrated in Section 6.2, and summarised as a contribution in the sections below.

The state of art contains ontologies for representing activities and their provenance related to the GDPR (Pasquier et al. 2018; Palmirani, Martoni, et al. 2018a), including those utilising PROV (Ujcich, Bates, and Sanders 2018; Piero A Bonatti, Dullaert, et al. 2018), and holistic approaches combining ex-ante and ex-post compliance (Dullaert et al. 2019). In comparison, GDPRov provides the most exhaustive vocabulary of concepts based on the GDPR (based on comparisons demonstrated in Chapter 5), and is the only ontology to provide ex-ante and ex-post concepts within the same ontology. GDPRov thus advances the state of the art by providing the most comprehensive vocabulary for modelling and representing activities based on GDPR concepts.

1.4.2.2 GConsent

The determination of consent validity under the GDPR requires additional information (Politou, Alepis, and Patsakis 2018; Party 2018) which is not captured using GDPRov as it does not relate to representation of activities and artefacts. Therefore, a separate ontology called GConsent was created (and is the basis for formulating research objective RO3(c)) to provide necessary concepts and relationships for representing information relevant for management of consent. GConsent focuses on representation of only consent information as required to evaluate its compliance. It acts as a distinct modular ontology which can be used by itself to represent consent, or in conjunction with GDPRov to represent consent and its related activities.

While GDPRov and GConsent both represent consent, the focus of GDPRov is on representing activities and artefacts associated with consent, while GConsent represents information associated with management of consent based on GDPR compliance requirements. Another perspective on this is that GDPRov represents a specific semantic view based on the notion of capturing provenance of activities in ex-ante and ex-post phases, while GConsent represents a state-based representation of consent. The application of these ontologies within use-cases in Chapter 6 show, both ontologies share some concepts and overlap, but are complimentary in their use and represent different aims in their representation of information.

GConsent provides the necessary concepts and relationships to express information about consent in terms of entities such as individuals or agents, purposes and processing, involvement of third parties, medium and context of provision, relationship between instances (e.g. withdraws, updates), and the novel concept of ‘consent states’ which enables management of consent as an entity. In comparison with state of the art, GConsent provides greater representation of information related to consent and is the most comprehensive ontology for representing consent (based on comparisons demonstrated in Chapter 5).

1.4.3 Querying Information Related to Compliance using SPARQL

A minor contribution of this thesis is the utilisation of SPARQL to query information relevant for GDPR compliance, which fulfils research objective RO4. The use of developed ontologies, namely GDPRtEXT, GDPRov, and GConsent - provide representation of concepts associated with GDPR for use in SPARQL queries to represent compliance questions derived from state of the art (see Chapter 4).

Where approaches in state of the art also use SPARQL to represent questions for compliance (Agarwal et al. 2018; Palmirani, Martoni, et al. 2018b), the work presented in Section 6.1 is the only one within the state of the art to demonstrate derivation of queries from questions associated with an investigation of compliance, i.e. compliance questions as presented in Section 4.2. A practical application of this demonstrates SPARQL queries derived from questions provided by the Irish Data Protection Commission for assisting organisations with their GDPR compliance readiness (“GDPR Readiness Checklist Template for SMEs” 2017) and shows use of SPARQL in assisting the investigation process associated with compliance. This application of SPARQL was published in a peer-reviewed publication (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018d) and was presented to members of the Irish Data Protection Commission as part of research developed in this thesis.

1.4.4 Framework for Validating Information using SHACL Compliance

Another contribution of this thesis is the approach for using SHACL to validate information and linking the results with relevant clauses of GDPR for compliance, which fulfils research objective RO5. While SPARQL is sufficient to query information and in some cases to determine compliance based on presence or absence of information, the use of SHACL provides a standardised approach for validation of information based on representing constraints and persisting the results of validation.

The validation using SHACL is part of a proposed framework presented in Section 6.2 which consists of creating a ‘compliance graph’ for storing information relevant in the investigation and demonstration of compliance. The validation requirements are derived from constraints and assumptions based on compliance questions in Section 4.2.3, and are represented using SHACL with a link to relevant clauses of the GDPR defined using GDPRtEXT to indicate their role in the compliance process. The constraints expressed using SHACL utilise concepts and relationships from GDPRov and GConsent to represent validation requirements, and re-use SPARQL queries created for RO4 to retrieve information. The validation results are persisted and annotated with GDPRtEXT to link them with the GDPR, thereby providing a form of documentation for information validation associated with compliance.

The framework suggests a more efficient form of validation by reusing ex-ante validation results in ex-post evaluations by abstracting common constraints belonging to ex-ante information and validating them in the ex-ante stage itself so that only specific constraints associated with instances in the ex-post stage - such as provenance information - need to be validated. The demonstration of the framework and approach consists of evaluating consent on a real-world website to generate a ‘compliance report’ listing status of validations linked to GDPR. The framework and approach have been published in peer-reviewed publications (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018c, 2018b; Harshvardhan J Pandit, O’Sullivan, and Lewis 2019)

Related work in state of the art uses a variety of approaches for validation and assessment of compliance. The SPECIAL project demonstrates use of OWL2 reasoners to validate consent at ex-ante and ex-post stages (Piero A. Bonatti 2018; Dullaert et al. 2019) and the application of ODRL policies as a compliance checking mechanism (Agarwal et al. 2018; Vos et al. 2019). The MIREL project proposes the use of deontic logic for legal reasoning using LegalRuleML (Palmirani, Martoni, et al. 2018b; Monica and Guido 2018), while the BPR4GDPR project proposes checking provenance logs for conformance to predetermined processes (ex-post analysis) (Mehr 2019). The use of SHACL utilising P-Plan workflows to validate policies expressed in ODRL for GDPR compliance has been proposed (Lieber 2019) as a doctoral consortium paper - which provides future directions for application of this research. Compared to state of the art, the approach presented in this thesis is novel in its utilisation of SHACL to validate information and link its results with the GDPR for compliance. It is also novel in its combination and reuse of ex-ante and ex-post validations for compliance.

1.4.5 Information Interoperability Model of the GDPR

A minor contribution of this thesis consists of an information interoperability model based on representing categories of entities (stakeholders) as defined by GDPR and their interactions with respect to interoperability of information shaped by GDPR compliance requirements. The model, described in Section 4.1, conceptualises interactions between stakeholders based on information identified as part of RO1 and RO2, and provides an overview of requirements regarding information and interoperability shaped by GDPR.

The model provides categorisation of information requirements based on provenance, agreements, consent, certification, and compliance; and assists in exploration of existing standards - including semantic web - by outlining requirements and applications of information based on interoperability between entities. It advances state of the art by providing the first systemic analysis of information flows and interoperability between stakeholders, and serves to provide a framework for developing and evaluating potential consensus on interoperability of information for compliance between stakeholders. The model, its analysis, and application in the context of right to data portability was published in peer-reviewed publications (Pandit and Lewis 2017; Harshvardhan J. Pandit, Debruyne, et al. 2018) and as a book chapter (Pandit et al. 2020).

1.4.6 Participation in DPVCG

The Data Privacy Vocabularies and Controls Community Group¹⁴ (DPVCG) is a W3C community group working towards developing a vocabulary associated with personal data processing based on relevant laws such as GDPR. The group was created by members of the SPECIAL project in May 2018 and currently consists of community members from diverse domains such as academia, legal experts, lawyers, and industry stakeholders.

The work done within DPVCG in its 18 months of operation has produced the Data Privacy Vocabulary¹⁵ (DPV) - an ontological resource for representing information associated with processing of data. The DPV represents a community agreement of vocabulary and semantics of terms and concepts associated with GDPR, and provides a degree of interoperability in representing information for legal compliance. The work regarding creation of DPV has been published in a peer-reviewed conference (Harshvardhan J. Pandit and Polleres 2019), and has also been listed as a deliverable within the SPECIAL project (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernandez, et al. 2019). The author of this thesis is listed as an editor and contributor in both publications, and is the co-chair DPVCG since January 2020.

The research presented in this thesis had an impact in the creation of DPV through use of developed ontologies as an input as well as through direct participation of the author as an active contributing member. An overview of DPV is therefore presented in Section 5.5 along with comparisons to developed ontologies (GDPRtEXT, GDPRov, GConsent) and SotA. To summarise the comparison, DPV provides a high-level abstraction of terms and concepts, whereas the ontologies in this thesis provide representations of information with more granularity and detail - which makes their usage with DPV complimentary rather than contradictory.

1.4.7 Publications

The following peer-reviewed publications present the research in this thesis (grouped by relevance, ordered chronologically reversed):

1.4.7.1 Ontologies representing information for GDPR compliance

The following publications are associated with RO3 - developing ontologies for representing the concepts and relationships within the GDPR.

1. “GConsent - A Consent Ontology Based on the GDPR” (Harshvardhan J. Pandit, Debruyne, et al. 2019)
   H. J. Pandit, C. Debruyne, D. O’Sullivan, and D. Lewis.
   16^th European Semantic Web Conference (ESWC), 2019. This publication presents the GConsent ontology for representing information about consent as required by GDPR. GConsent fulfils research objective RO3(c), and provides a detailed representation of consent for information management and documentation. GConsent is described in Section 5.4.

2. “GDPRtEXT - GDPR as a Linked Data Resource” (Harshvardhan J. Pandit, Fatema, et al. 2018)
   H. J. Pandit, K. Fatema, D. O’Sullivan, and D. Lewis.
   15^th European Semantic Web Conference (ESWC), 2018. This publication presents the GDPRtEXT resource consisting of a linked data representation of the text of GDPR, and a glossary of its concepts. It also provides a mapping from clauses of the DPD to GDPR based on reuse of compliance methods developed for DPD for GDPR. GDPRtEXT fulfils research objective RO3(a), and is instrumental in providing semantic association between information and GDPR for approaches presented in this thesis. GDPRtEXT is described in Section 5.2.

3. “Modelling Provenance for GDPR Compliance using Linked Open Data Vocabularies” (Pandit and Lewis 2017)
   H. J. Pandit, and D. Lewis.
   5^th Workshop on Society, Privacy and the Semantic Web - Policy and Technology (PrivOn2017), co-located with the 16^th International Semantic Web Conference (ISWC), 2017. This publication presents the GDPRov ontology for representing the provenance of personal data and consent for GDPR, and discusses use of its concepts in SPARQL queries for retrieving information associated with compliance. GDPRov fulfils research objective RO3(b), and provides ex-ante and ex-post representations for activities associated with personal data and consent for GDPR. GDPRov is described in Section 5.3.

4. Compliance through Informed Consent: Semantic Based Consent Permission and Data Management Model (Fatema et al. 2017)
   K. Fatema, E. Hadziselimovic, H. J. Pandit, C. Debruyne, D. Lewis, and D. O’Sullivan.
   5^th Workshop on Society, Privacy and the Semantic Web - Policy and Technology (PrivOn2017), co-located with the 16^th International Semantic Web Conference (ISWC), 2017. This publication presents an early (pre-GDPR enforcement) collaboration in developing a preliminary ontology for representing consent and a data management model for GDPR. The early work was crucial towards understanding complexities of consent, and provided valuable feedback towards development of GConsent.

5. “Linked Data Contracts to Support Data Protection and Data Ethics in the Sharing of Scientific Data” (Hadziselimovic et al. 2017)
   E. Hadziselimovic, K. Fatema, H. J. Pandit, and D. Lewis.
   Workshop on Enabling Open Semantic Science (SemSci), co-located with the 16^th International Semantic Web Conference (ISWC), 2017. This publication presents an early collaboration (pre-GDPR) towards developing an ontology for representing data sharing agreements for GDPR by extending the ODRL ontology. The ontology enables representation of obligations associated with propagation of rights between parties that share or exchange data.

1.4.7.2 Querying and validating information for GDPR compliance

The following publications are associated with RO4 - querying for information, and RO5 - validating information for compliance.

1. “Test-driven Approach Towards GDPR Compliance” (Harshvardhan J Pandit, O’Sullivan, and Lewis 2019)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   14^th International Conference on Semantic Systems (SEMANTiCS), 2019. This publication presents implementation of approach for validation of information by utilising the use-case of consent in a real-world website. It utilises SHACL to validate information represented by GDPRov and GConsent, and uses GDPRtEXT to associate constraints and results with GDPR. It also demonstrates use of SPARQL to identify tasks and reports related to compliance by querying validation results. The approach demonstrates usefulness of combining ex-ante and ex-post approaches in terms of efficiency and compliance. This research fulfils research objective RO5 and is presented in Section 6.2.

2. “Queryable Provenance Metadata For GDPR Compliance” (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018d)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   14^th International Conference on Semantic Systems (SEMANTiCS), 2018. This publication presents use of SPARQL queries to represent questions associated with compliance by using GDPRtEXT and GDPRov ontologies. It demonstrates effectiveness of SPARQL in retrieving information for GDPR compliance, and fulfils research objective RO4. This work is presented in Section 6.1.

3. “ Exploring GDPR Compliance Over Provenance Graphs Using SHACL” (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018b)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   14^th International Conference on Semantic Systems (SEMANTiCS) - Posters track, 2018. This publication presents an overview of the approach for validating information using SHACL and associating results with specific articles of GDPR. The approach proposes persistence of validation results to create a ‘compliance graph’ that can be queried and validated for documenting information for compliance. This work is presented in Section 6.2.1.

4. ”Towards Knowledge-based Systems for GDPR Compliance” (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018c)
   H. J. Pandit, C. Debruyne, D. O’Sullivan, and D. Lewis.
   International Workshops on Contextualized Knowledge Graphs (CKG), co-located with 17^th International Semantic Web Conference (ISWC), 2018. This publication explores creation of a knowledge-based framework based on utilisation of information associated with compliance using semantic web technologies for applications such as creation of reports, documentation, and assessment of compliance for different stakeholders. The approach was used in conjunction with the above publication in addressing research objective RO5.

1.4.7.3 Model for information interoperability based on requirements of GDPR compliance

These publications present a model of interaction between entities as defined by the GDPR, and explore information categories and their interoperability requirements based on existing standards, including those provided by the semantic web. The model provides an overview of information flows between stakeholders, and the role of interoperability in facilitating information for compliance between them. This research is presented in Section 4.1.

1. “Standardisation, Data Interoperability, and GDPR” (Harshvardhan J. Pandit, Debruyne, et al. 2018)
   H. J. Pandit, C. Debruyne, D. O’Sullivan, and D. Lewis.
   Book Chapter in Shaping the Future Through Standardization, 2019

2. “An Exploration of Data Interoperability for GDPR” (Pandit et al. 2020)
   H. J. Pandit, C. Debruyne, D. O’Sullivan, and D. Lewis.
   International Journal of Standardization Research (IJSR) , Vol. 16 Issue. (1), 2018

3. “GDPR Data Interoperability Model” (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018e)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   23^rd European Academy for Standardisation Annual Standardisation Conference (EURAS), 2018

1.4.7.4 Investigated applications of research - Information Management

The following publications do not directly address the research question, but consist of applying the research presented in this thesis towards processes that assist with the compliance process.

1. “Towards Generating Policy- Compliant Datasets” (C. Debruyne et al. 2019)
   C. Debruyne, H. J. Pandit, D. O’Sullivan, and D. Lewis.
   13^th IEEE International Conference on Semantic Computing (ICSC), 2019. This publication presents an approach for generating just-in-time datasets consisting of personal data based on given consent to ensure processes are compliant in their usage of consent.

2. “GDPR-driven Change Detection in Consent and Activity Metadata” (Harshvardhan J Pandit, O’Sullivan, and Lewis 2018)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   4^th Workshop on Managing the Evolution and Preservation of the Data Web (MEPDaW), co-located with 15^th European Semantic Web Conference (ESWC), 2018. This publication proposes an approach for detecting changes related to use of personal data and consent in activities by utilising the ex-ante component of P-Plan to represent activities and comparing them using a graph-based algorithm.

1.4.7.5 Investigated Applications of Research - Privacy Policies

The following publications do not directly address the research question, but consist of applying the research presented in this thesis towards privacy policies.

1. “Extracting Provenance Metadata from Privacy Policies” (Harshvardhan Jitendra Pandit, O’Sullivan, and Lewis 2018a)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   7^th International Provenance & Annotation Workshop (IPAW), par t of Provenance Week, 2018. This publication discusses use of GDPRov to represent extracted information about activities associated with personal data within a privacy policy.

2. “An Ontology Design Pattern for Describing Personal Data in Privacy Policies” (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018a)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   9^th Workshop on Ontology Design and Patterns (WOP), co-located with 17^th International Semantic Web Conference (ISWC), 2018. This publication presents an ontology design pattern that uses GDPRov and GDPRtEXT to represent information about personal data and its processing in a privacy policy.

3. “Personalised Privacy Policies” (Harshvardhan Jitendra Pandit, O’Sullivan, and Lewis 2018b)
   H. J. Pandit, D. O’Sullivan, and D. Lewis.
   4^th International Workshop on TEchnical and LEgal aspects of data pRIvacy and SEcurity (TELERISE), co-located with 22^nd European Conference on Advances in Databases and Information Systems, 2018. This publication discusses personalisation of privacy policies by using information about an individual’s personal data processing and using GDPRtEXT and GDPRov to annotate it for a machine-readable representation.

1.4.7.6 Data Privacy Vocabulary

The following publication presents work related to creation of the Data Privacy Vocabulary by DPVCG and describes the methodology used with relation to the existing vocabularies - including those presented in this thesis - namely GDPRtEXT, GDPRov, and GConsent. The DPV is described in Section 5.5.

1. “Creating A Vocabulary for Data Privacy” (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019)
   H. J. Pandit, A. Polleres, B. Bos, R. Brennan, B. Bruegger, F. J. Ekaputra, J. D. Fernández, R. G. Hamed, E. Kiesling, M. Lizar, E. Schlehahn, S. Steyskal, R. Wenning
   18^th International Conference on Ontologies, DataBases, and Applications of Semantics (ODBASE), 2019.

1.5 Thesis Overview

The rest of this thesis is structured as follows:

Chapter 2: Background on GDPR and Semantic Web

This chapter presents a summary of information required to understand the work presented in this thesis. The chapter consists of two sections: the first describes concepts and requirements of GDPR, while the second section describes semantic web technologies with an overview of its standards and vocabularies.

Chapter 3: State of the Art

This chapter reviews existing work and approaches regarding regulatory compliance with a specific focus on those addressing GDPR compliance. The chapter starts by providing an overview of approaches used for legal compliance. It then presents an in-depth review of approaches utilising semantic web technologies to address GDPR compliance requirements, followed by other approaches for GDPR compliance. Approaches which do not directly address the GDPR, but are relevant to legislative compliance and semantic web are also presented. The chapter then presents an analysis of the state of the art and concludes with a discussion on identified gaps and limitations.

Chapter 4: Information Required for GDPR Compliance

This chapter presents information required for GDPR compliance of activities associated with processing of personal data and consent in ex-ante and ex-post phases. The chapter starts by presenting an information model for interoperability of information between stakeholders defined by the GDPR. The model provides an analysis of information interoperability requirements based on requirements of GDPR compliance and the role of existing standards in addressing them. This is followed by expressing information requirements as analytical questions - termed ‘compliance questions’ - whose answers provide the information necessary to evaluate compliance. The chapter then concludes with identification of constraints and assumptions which can be used to validate information for GDPR compliance.

Chapter 5: Representing Information for GDPR Compliance using Ontologies

This chapter presents the OWL2 ontologies developed to represent information associated processing of personal data and consent for GDPR compliance. The ontologies present concepts for answering compliance queries presented in Chapter 4. The first ontology presented is GDPRtEXT - which provides a method to link information with concepts and clauses of GDPR through a linked data version of its text and a vocabulary of concepts. The second ontology presented is GDPRov - which enables representation of provenance information regarding personal data and consent as models or templates and their executions or activity logs. The third ontology presented is GConsent - which enables representation of information associated with consent. The chapter presents an overview of concepts and relationships for each vocabulary, its relation with GDPR, and the competency questions used to guide its development. The chapter also presents a brief overview of the Data Privacy Vocabulary and its comparison with the other presented ontologies and the SotA.

Chapter 6: Querying and Validating Information for GDPR Compliance

This chapter presents use of SPARQL to express compliance queries using ontologies presented in Chapter 5. The chapter also presents a framework to validate information using SHACL based on constraints identified in Chapter 4. The framework demonstrates use of semantic web technologies in validating information for GDPR compliance by utilising a combination of ex-ante and ex-post validations and linking of results with GDPR for documentation of information for compliance.

Chapter 7: Conclusion

This chapter concludes the thesis with a summary of key findings and outcomes of the presented work. It discusses the extent to which the thesis serves to address the research question(s) and objective(s), and outlines directions for future work in terms of potential applications and extension through related work.

2 Background: GDPR and the Semantic Web

This chapter presents the necessary background information for understanding the research presented in this thesis. The first section (Section 2.1) provides a short introduction to the General Data Protection Regulation (GDPR) in terms of terminology, information requirements for compliance, and sources of additional information regarding GDPR compliance. The second section (Section 2.2) provides an introduction to Semantic Web technologies based on the formulation of the research question and objectives regarding information representation, querying, and validation.

2.1 General Data Protection Regulation (GDPR)

The General Data Protection Regulation (GDPR) (“Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation)” 2016) is the current data protection law applicable within the European Union (EU) and the European Economic Area (EEA) and regulates use and processing of personal data. It supersedes its predecessor - the Data Protection Directive (DPD) (“Directive 95/46/EC of the European Parliament and of the Council on the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of Such Data” 1995) - and provides greater requirements and transparency for compliance, with potentially large and significant amount in fines if organisations are found to have violated its obligations. A significant aspect of GDPR are its principles and rights which are intended to afford greater privacy and control to an individual regarding use of their personal data.

By virtue of being a regulation as opposed to a directive, GDPR is considered enforceable law with local and national data protection laws acting in conjunction rather than replacing it. The GDPR has attracted global attention and scrutiny due to its requirements for compliance and potential fines, as well as for providing rights that enhance privacy. It has influenced other privacy laws across the globe with the California Consumer Protection Act (CCPA) being a recent example (Marini et al. 2018).

2.1.1 Terminology

The legal terminology utilised in GDPR is intended to clarify the roles, actions, and concepts referred in its obligations. The definition of personal data (Article 4-1) is based on linking, association, or relevance of any information with an individual - and represents a significant change from its predecessor as well from other laws which rely upon the concept of Personally Identifiable Information (PII). The individual the personal data relates to is termed as Data Subject (Article 4-1) - a distinct term from other relevant laws that use individual or PII Principal.

GDPR regulates processing of personal data (Article 4-1) - which is defined as any action over or utilising personal data as: “collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;” (“Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data and on the Free Movement of Such Data, and Repealing Directive 95/46/EC (General Data Protection Regulation)” 2016).

A Controller is defined (Article 4-7) as the entity or organisation that determines purpose and means of processing of personal data. As such, controller is the primary organisation regarding GDPR compliance and is subject to additional obligations given its role in determining processing of personal data. One or more controllers can act together to determine purpose and processing, in which case they are defined as Joint-Controllers (Article 26).

A Processor is defined (Article 4-8) as an entity which processes personal data on specified instructions of a controller (Article 28) and is not allowed to deviate from the instructions or utilise the personal data for other purposes. A processor is also referred to as (sub-)contractor in some contexts. A processor may appoint other sub-processors in order to carry out processing, where sub-processors are required to follow the same obligations as the processor.

A Data Protection Officer (DPO) is defined (Article 37) as an individual appointed by a controller or processor to oversee compliance and processing of personal data, monitor internal processors, and collaborate with supervisory authorities as required.

A Regulatory or Supervisory Authority or Data Protection Commission is a governmental organisation with responsibility to evaluate and enforce GDPR compliance. These bodies are established by national or federal governments and have jurisdiction over their appointed regions. The GDPR specifies responsibilities of such bodies and provides avenues for their co-operation across jurisdictions (Article 56, 60, 62).

GDPR provides several rights to the data subject (Chapter 3) which are obligated to be provided by controller(s). Since rights are mandatory - their implementation, provision, and exercising must be monitored as part of compliance.

Lawful Basis or Legal Basis is the provision under which processing of personal data is permitted by GDPR, of which there are six primary ones (Article 6). Legitimate Interest refers to legal basis where controller or third party needs personal data in order to provide or carry out its operations and services (Article 6-1f). Other legal basis include the carrying out a contract (Article 6-1b), compliance to legal obligation (Article 6-1c), public interest or as part of official authority (Article 6-1d), and other provisions and specifics introduced by national governments (Article 6-2). Consent of the Data Subject is the legal basis to be used where other legal basis are not applicable, and which requires consent of data subject. Consent is subject to further obligations and requirements depending on the use-case which determine its validity.

2.1.2 Transparency and Requirements

Controllers are required to provide information to data subjects about processing activities regarding type of processing taking place and who is carrying it out. This information is usually part of ‘privacy policy’ and contains: (a) identity of controller(s); (b) purpose of processing; (c) legal basis; (d) transfer of data and categories of recipients; (e) data storage periods; and (f) the existence of rights.

In addition to above, a controller is required to monitor and maintain documentation detailing their processing of personal data categories along with particulars of data included within each category. Every personal data being processed must be associated with a source. GDPR specifies certain personal data categories as ‘special categories’ based on their sensitivity and need for additional measures regarding security and accountability. Such special categories contain additional obligations for compliance which must be enforced if an organisation is using them.

2.1.3 Data Protection Impact Assessment

A Privacy Impact Assessment or Data Protection Impact Assessment is an obligation of the controller to conduct and document an impact assessment of data processing before it is executed (Article 35). GDPR lays out conditions under which a DPIA is mandatory to be conducted - which includes processing that results in a high risk to rights and freedoms of data subjects, use of special categories of personal data, automated processing with significant effects, and use of evaluation or scoring.

A DPIA can be conducted for a specific processing activity, for a project, or for the entire organisation - and must be carried out “prior to the processing” (Articles 35-1, 35-10). The aim of DPIA is to identify and mitigate data protection risks, plan for implementation of solutions to those risks, and assess viability of a project at an early stage. Documentation of DPIA process allows demonstrating compliance with GDPR and minimising risks of legal difficulties in carrying out the processing.

Carrying out DPIA requires identification of information flows in terms of collection, storage, usage, sharing, and erasure of personal data within defined processing activities. A DPIA needs to be updated or carried out again if there are changes in processing activities.

2.1.4 Sources of Additional Information

2.1.4.1 Data Protection Authorities

A Data Protection Authority (DPA) is the authority responsible for upholding EU laws and rights regarding privacy and data protection through enforcement and monitoring of compliance. Its title and reference differs by language and jurisdiction - for example the Data Protection Commission (DPC) in Ireland is also sometimes referred to as Data Protection Commissioner’s Office. A DPA is also referred to as Regulator given their task of regulating processing of personal data. In some nations (such as Germany) the data protection authorities are established in federal states or regions rather than a singular nation-wide office. The data protection authorities are also governed by national data protection laws in addition to the EU laws such as GDPR, and are responsible for their upholding as well.

The data protection authorities in each of their jurisdictions have published guidance and documents for assisting organisations and data subjects in understanding the GDPR and its compliance requirements. The authorities in Ireland¹⁶, United Kingdom¹⁷, and France¹⁸ have provided this information in English.

2.1.4.2 Article 29 Data Protection Working Party and European Data Protection Board (EDPB)

The Article 29 Working Party (Art. 29 WP) was an advisory body to the European Parliament and its bodies, and consisted of representatives from data protection authorities of each EU member state, the European Data Protection Supervisor, and the European Commission. The body was established following the Data Protection Directive (DPD) and was replaced by European Data Protection Board (EDPB) under GDPR. The working party provided expert advice to member states, and published opinions on application of laws affecting right to protection of personal data - including the GDPR. To this end, it published¹⁹ a number of documents clarifying or expressing opinions on interpretation of GDPR.

The EDPB is the European body replacing the Art. 29 WP with the purpose to ensure consistent application of GDPR and to assist in co-operation between various data protection authorities. EDPB is tasked with issuing guidelines, recommendations, and identifying best practices related to interpretation and application of GDPR. It advises the European Commission on matters related to protection of personal data in EU and EEA by adopting consistency in cross-border cases, encouraging development of codes of conduct, establishing certification mechanisms for data protection, and promoting cooperation and effective exchange of information and good practices among national supervisory authorities. The EDPB has published²⁰ documents for providing information and assistance to individuals, controllers & processors, and regulators.

2.1.4.3 STAR & STAR II

STAR²¹ (Support Training Activities on the data protection Reform) was an European project that provided materials to support training of DPAs and DPOs for GDPR. Its resources are published in an open and publicly accessible form²². The project has produced a handbook for assisting stakeholders in understanding GDPR and preparing for its compliance. The project also provides an evaluation questionnaire and compliance checklist (“GDPR Compliance Checklist” 2019) consisting of a list of questions and criterion to assess preparedness with requirements of GDPR. The resources published by the STAR projects provide documentation regarding GDPR compliance that is adopted by organisations and regulatory authorities.

2.1.4.4 PRIPARE

PRIPARE²³ (PReparing Industry to Privacy-by-design by supporting its Application in REsearch) was an European research project that provided a set of documents regarding privacy engineering covering activities such as privacy risk management, requirement analysis, design strategies, maintenance and compliance. It published the PRIPARE methodology handbook (“Privacy and Security by Design Methodology Handbook” 2015) which provides guidelines for privacy and security by design. The handbook incorporates information based on a draft of GDPR²⁴ It provides foundational methodologies and reference models for carrying out privacy analysis, designing and implementing privacy enhancing systems, with templates for impact assessments and conformance.

2.2 Semantic Web Technologies

The term ‘Semantic Web’ refers to extension of World Wide Web with machine-readable and interoperable metadata to enable encoding of semantics with data. This is achieved through use of standards developed by World Wide Web Consortium (W3C) to promote common data formats for interoperability and data exchange protocols using the infrastructure of the web.

2.2.1 RDF, RDFS, and OWL

2.2.1.1 Resource Description Framework (RDF)

The representation of semantics starts with specification of facts or ‘knowledge’ using RDF²⁵, which provides representation of information as ‘triples’ whose collective expression can be visualised as a graph. RDF triples are serialised using syntax languages such as XML²⁶, or the more human-readable Turtle²⁷, or the web friendly JSON-LD²⁸. RDF triples utilise the same identifier system as world wide web and are specified using IRIs²⁹ - a generalised form of URIs which itself are a generalised form of URLs³⁰. A database storing RDF is called a triple-store and enables creation of graphs of RDF data and provides an interface for querying it.

A RDF triple consists of a subject, an object, and a predicate - where predicate describes the relationship from subject to object. An example of RDF triple specified using the Turtle language to indicate chapter number of an entity is expressed as -
<http://example.com/ch2> foaf:name "Background"@en .
The subject in this triple is the IRI <http://example.com/ch2> representing a resource, with the predicate foaf:name representing relationship of associating a name as indicated by the string in object field "Background"@en with @en specifying use of English language.

The subject is written in shorthand notation indicating it starts with the same IRI as the data file it is described in. An IRI can become too long for readability and is usually written using shorthand prefixes. The predicate is a property provided by an external ontology called ‘Friend of a Friend’ (FOAF³¹), which is referenced by its prefix foaf as shorthand for its entire IRI. The object is a string in this case, but could itself be another RDF triple or resource - in which case it would be specified as an IRI.

2.2.1.2 RDF Schema (RDFS)

RDFS provides concepts for expressing classes, properties, and data types in order to represent schemas using RDF. It also provides commonly required relationships such as specifying labels of resource, indicating related resource, or specifying domain and range of properties. The example in code below expands upon the triple described in RDF to express chapter as a class with its number as a property, and specifies human-readable labels for each resource.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix : <http://example.com/> .
:Chapter rdf:type rdfs:Class ;
    rdfs:label "Chapter"@en .
:chnum a rdfs:Property ;
    rdfs:label "number"@en ;
    rdfs:range xsd:integer .
:Ch2 rdf:type :Chapter ;
    foaf:name "Background"@en ; 
    :chnum 2^^xsd:integer .

2.2.1.3 Web Ontology Language (OWL)

While RDFS enables expression of hierarchies, more formal representations of knowledge modelling and logic require additional constructs. These are represented using OWL³² as an ontology consisting of set of ‘individuals’ (also called classes) and a set of ‘property assertions’ which relate individuals to each other. An ontology may also consist of set of axioms which place constraints on sets of individuals and types of relationships permitted between them. These axioms provide semantics which can be used to infer additional information using semantic reasoners based on information explicitly provided. Knowledge expressed using OWL can be (and generally is) expressed using RDF, which makes it possible to encode and store ontologies in as RDF data.

2.2.2 SPARQL Protocol and RDF Query Language (SPARQL)

SPARQL³³ is a query language for retrieving data expressed using semantics provided by RDF. SPARQL queries information following the RDF specification, and thus specifies queries to act on data expressed as ‘subject-predicate-object’ triples. SPARQL queries can also retrieve information from traditional (SQL) databases which store data in non-RDF form through mapping³⁴ which permits its semantics to be applied across a large variety of existing data stores.

A SPARQL endpoint is an interface for access and querying over stored data. Such endpoints can be exposed over the web to provide querying capabilities through the internet, with DBPedia³⁵ - a semantic web representation of Wikipedia - providing a well-known example.

2.2.3 Shapes Constraint Language (SHACL)

SHACL³⁶ is the W3C standard for expressing constraints that validate RDF data. The input over which SHACL constraints are validated is called the data graph. Constraints in SHACL are called ‘shapes’ based on the notion of checking if data fits a shape, with the set of constraints being validated called as shapes graph. SHACL constraints are themselves also expressed in RDF which makes it possible to serialise them as a data graph and perform querying over it.

The output of a validation process is a conformance report which uses a validation report vocabulary provided by SHACL and indicates failing validations and status of validation of a whole. A conformance report provides boolean indication of whether the any of given set of validations have failed or conversely whether all validations have passed.

SHACL core refers to features defined within the SHACL standard specification. Extensions have been developed which provide additional features for expression and validation of constraints. SHACL-SPARQL provides use of SPARQL queries to retrieve data failing a given constraint, and is mentioned within SHACL specification. SHACL validations are performed using a ‘validator’ - an implementation and interpretation of SHACL standard that provides at least the validation features described in SHACL-core.

Shape Expressions language (ShEx)³⁷ is an alternative to SHACL that provides a similar conceptual language for expressing constraints and validating RDF data. The design of ShEx emphasises human readability inspired from Turtle, whereas SHACL follows the abstract RDF syntax. ShEx and SHACL were aimed to converge into a common standard, but this has not happened to date - and therefore both are maintained as separate technologies. Both SHACL and ShEx have seen significant adoption by the community.

2.2.4 Standardised Ontologies

2.2.4.1 Provenance Ontology (PROV-O)

PROV-O³⁸ is a standardised ontological representation of the PROV Data Model³⁹ (PROV-DM) which is the W3C standard for representing provenance information using semantics provided by RDF and OWL. PROV-O provides classes, properties, and restrictions to represent and interchange provenance information within different contexts. It can be specialised to create new classes and properties to model provenance information for different applications and domains.

2.2.4.2 Open Digital Rights Language (ODRL)

ODRL⁴⁰ is a policy expression language that provides an information model, vocabulary, and encoding mechanisms for representing statements about usage of content and services as policies. The ODRL Information Model describes underlying concepts, entities, and relationships that form the foundational basis for semantics of ODRL policies. Policies are used to represent permitted and prohibited actions over one or more assets and can also contain obligations required to be met by stakeholders. Policies can also specify constraints - such as temporal or spatial - and duties which are required to be carried out. ODRL conformances is based on evaluating whether a given information representing an use-case or context satisfies all the expressions described in a given policy.

3 State of the Art

This chapter presents the state of the art (SotA) regarding technological approaches for GDPR compliance with a particular focus and emphasis on those that utilise semantic web technologies.

Legal compliance as a field is quite broad due to the extent of laws which can be abstract (or universal) in their application or are enacted for a specific domain. Achieving legal compliance is itself a large field of research, with technical approaches providing a special attraction in all domains due to potential of automation and co-ordination with information management systems. For the purposes of this thesis, the scope and focus is on technical approaches to assist legal compliance process within the domain of GDPR compliance.

Before delving into approaches concerning GDPR, it is imperative to have an understanding of the field concerning technological approaches used in legal compliance. As all approaches for legal compliance share their motivation and aims, understanding their commonality and rationale enables placing the work associated with GDPR compliance within the broader scope of legal compliance. It also provides investigation of avenues where existing approaches developed for other areas of legal compliance could be reused for GDPR, while providing the necessary background for understanding some of the decisions made by approaches concerning GDPR compliance in reusing existing technologies developed for legal compliance.

Surveys analysing approaches over a period of time provide a good overview of the use of technology in addressing legal compliance. One such survey analyses technological approaches for legal compliance within the 50 years of 1957-2007 (Otto and Anton 2007) to provide categorisation based on representation of information and a set of Requirements Engineering Objectives (REO) an approach must follow to assist the legal compliance process. While the survey paper does not explicitly refer to linked data principles (Bizer, Heath, and Berners-Lee 2011), some of the REO are fulfilled by utilising linked data and semantic web to provide an interoperable representation based in standards to define the required metadata regarding legislations.

Where legal compliance is closely tied to functioning of an organisation, requirements of compliance need to be incorporated into relevant activities (commonly called business processes) within the organisation. As GDPR regulates use of personal data and requires organisations to adopt practices such as provision of rights, the study of compliance approaches from the perspective of business processes is also relevant in understanding state of the art. For this, two key surveys provide the necessary overview of relation between business processes and compliance. The first survey (Fellmann and Zasada 2014) relates to use of business processes within different phases of compliance, and provides basis for categorising approaches as ex-ante (a-priori, ad-hoc) and ex-post (a-posteriori, post-hoc) depending on whether compliance is relevant before the activity (in this case processing of personal data) has taken place or after. The second survey (Akhigbe, Amyot, and Richards 2015) analyses approaches utilising business processes for compliance and concludes that compliance approaches are basically limited to identifying relevant requirements from laws and regulations and ensuring that business processes comply with them without much attention to compliance enactment.

‘Legal Ontologies’ is an umbrella term used to represent ontologies that represent information associated with the legal domain. Key surveys in this domain categorise and analyse ontologies based on purposes (Rodrigues et al. 2019)(Leone, Di Caro, and Villata 2019), access control (Kirrane, Mileo, and Decker 2016), rights expression languages (Pellegrini et al. 2018), privacy policy languages (van de Ven and Dylla 2016), and privacy requirements engineering (Gharib, Giorgini, and Mylopoulos 2016). Ontologies have been extensively used for formal representations of information, rules (Kirrane, Fernández, et al. 2018), rights (Pellegrini et al. 2018), legislations (Leone, Di Caro, and Villata 2019), business processes (Elgammal et al. 2016), policies (van de Ven and Dylla 2016), and requirements (Gharib, Giorgini, and Mylopoulos 2016). In areas of compliance, standardisation of representations for norms and requirements has seen efforts such as LegalRuleML (Palmirani et al. 2011) which uses temporal and defeasible logic, and has been applied for compliance checking over business processes (Governatori et al. 2016). On similar lines, Compliance Management Ontology (Syed Abdullah, Sadiq, and Indulska 2012) proposes shared conceptualisation of business process management, culture management, obligations, programme, resources, risk management, and solutions. There has been a noted lack of guidelines regarding their reuse, particularly within the legal compliance domain (Casanovas, González-Conejero, and Koker 2017) where evaluation of developed ontologies is a challenge due to requirement of specialists or legal experts being involved in modelling stage (Rodrigues et al. 2019).

The state of the art in technologies used for legal compliance thus presents encompassing representations for documents, requirements, rules, obligations, policies, and business processes associated with legal compliance. An adopter has a range of approaches to choose from based on existing work and formalisms where the selection of an approach is dependant on requirements, goals, and its role in legal compliance process.

Given the motivation of this thesis in utilising semantic web technologies and the research question exploring activities associated with personal data and processing for GDPR compliance, the state of the art is presented as an overview of approaches within the scope of these topics. The other approaches are also presented to for relevance of work developed within the domain.

The chapter is structured as follows: the first section (Section 3.1) presents an overview of the methodology used to identify and analyse state of the art. The second section (Section 3.2) presents approaches using semantic web technologies to address GDPR compliance, with the third section (Section 3.3) presenting approaches addressing GDPR compliance using technologies other than semantic web. The fourth section (Section 3.4) presents approaches regarding privacy policies in context of GDPR which feature information relevant to compliance process while not directly addressing compliance itself. The fifth section (Section 3.5) presents approaches that concern representation of consent as required by GDPR. The chapter concludes with an analysis of SotA (Section 3.7). It identifies gaps within SotA and discusses research opportunities to address them.

3.1 Methodology

3.1.1 Identification and classification of approaches

Identification of approaches was carried out throughout development of research presented in this thesis given the evolving nature of information about GDPR and legal opinions on its compliance. This exercise was carried out from March 2016 until September 2019 at which point the analysis presented here was carried out and encoded into the thesis. Given the research question and motivation of this thesis, the scope of work considered as state of the art was defined as: approaches addressing GDPR compliance through technological solutions - with a particular emphasis on the approach being published in an accessible manner so as to enable it analysis.

Peer-reviewed publications were the primary source of knowledge regarding approaches, and were identified using scholarly indexing services such as Google Scholar⁴¹, IEEE Explore⁴², ACM Digital Library⁴³, Scopus⁴⁴, and DBLP⁴⁵. In addition to these, information was gathered through dissemination networks such as Twitter⁴⁶ and public mailing lists. Searches using keywords such as GDPR, GDPR Compliance, and Consent were used to identify relevant approaches in these sources and added to a reference manager (Zotero⁴⁷). Authors and affiliations of identified publications were also used as keywords to find additional relevant resources. In cases where publications acknowledged funding or projects, an effort was made to identify its online website and access the list of publications. This provided information about the project’s aims and objectives, and its future goals and directions.

Publications behind pay-walls which could not be accessed either as a pre-print found elsewhere or by requesting authors for access were not included in state of the art and are not presented in this thesis as they cannot be analysed or compared without access to the work. Requests for access to resources mentioned within a publication was made where possible, with a resource considered ‘open’ if published and ‘accessible’ if it could be accessed. Commercial solutions of GDPR compliance are not considered to be within state of the art given their closed nature and lack of knowledge regarding implementations.

The identified approaches were collected and categorised based on their relevance to the research question of this thesis. Approaches addressing GDPR with a particular emphasis on utilising semantic web are presented in Section 3.2 with other approaches addressing GDPR compliance presented in Section 3.3.

3.1.2 Criteria for Analysis

Analysis of state of the art is based on two surveys regarding classification of approaches for legal compliance (Otto and Anton 2007) and phases of compliance (Fellmann and Zasada 2014) that provide context and features to represent the analysis. The research questions and objectives provide the basis for constructing a set of questions for investigation of approaches within state of the art. The questions are stated below with an indication to relevant research question and objective guiding this thesis:

1. Which aspects of GDPR compliance does the approach target? (RO1, RO2)

2. How does the approach represent information associated with GDPR and its compliance? (RO3)

3. How does the approach link information with GDPR? (RO3(a))

4. How does the approach represent activities associated with processing of personal data and consent? (RQ3(b))

5. Does the approach provide indication of ex-ante and ex-post phases of activities for compliance? (RO2, RO3)

6. How does the approach represent information associated with consent? (RO3(c))

7. How does the approach query information relevant to compliance? (RO4)

8. How does the approach validate information relevant to compliance? (RO5)

9. How does the approach evaluate GDPR compliance? (RO5)

Based on these, approaches within SotA are analysed to identify if they: (i) represent clauses and concepts of GDPR, (ii) provide a data model of concepts such as an ontology, (iii) represent information for ex-ante compliance, (iv) represent information for ex-post compliance, (v) model process flows/activities, (vi) model consent information, (vii) evaluate GDPR compliance, (viii) specify requirements for compliance, and (ix) provide their resources in an open and accessible manner to enable its analysis.

These questions and criteria are used to assess and analyse approaches with the outcome presented in Section 3.7 at the end of this chapter. The analyses is presented in sections associated with representation of GDPR, representation of activities, representation of consent, querying of information for compliance, and evaluation of GDPR compliance.

3.2 Approaches for GDPR compliance utilising Semantic Web

SPECIAL

SPECIAL⁴⁸ (Scalable Policy-aware Linked Data Architecture For Privacy, Transparency and Compliance) is an European H2020 Project that aims to provide technical solutions for data protection requirements associated with use-cases involving big data. It features extensive use of semantic web technologies across a variety of compliance related tasks such as recording provenance logs of data processing (Kirrane, Fernández, et al. 2018), providing visual interfaces for consent (Drozd and Kirrane 2019a, 2019b), compliance checking of processing activities based on given consent (Westphal, Fernandez, and Kirrane 2018; Vos et al. 2019; Fernandez et al. 2019), and efforts towards standardisation of related vocabularies⁴⁹ (Piero A Bonatti, Bos, et al. 2018; Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019). Collaborations between SPECIAL and other projects have produced relevant work such as an approach for compliance checking using ODRL (Agarwal et al. 2018; Vos et al. 2019) and the application of SPECIAL’s framework in a Smart City use-case (Fernandez et al. 2019). Information about methodologies used, developed technologies, and their evaluations is accessible through peer-reviewed publications and public deliverables⁵⁰.

SPECIAL uses a distributed ledger to store processing logs for data processing activities that is evaluated for compliance based on given consent in ex-ante and ex-post phases. The logs are stored using Policy Log vocabulary (Piero A Bonatti, Dullaert, et al. 2018) with data processing activities represented by Usage vocabulary (Piero A Bonatti, Kirrane, et al. 2018a). Compliance evaluation is performed using custom reasoning algorithms (Piero A. Bonatti 2018; Bonatti, Petrova, and Sauro 2019) in a semantic reasoner. Consent request and management is provided through interactive visual interfaces in a web browser (Drozd and Kirrane 2019a, 2019b). The project has been successfully applied to use-cases provided by its commercial partners⁵¹ as well as in an external use-case related to use of IoT in Smart Cities (Fernandez et al. 2019). Figure 3.1 presents an overview of SPECIAL architecture along with its components and utilised technologies.

The ontology developed to represent data processing activities is called ‘Usage Policy’ (Piero A Bonatti, Kirrane, et al. 2018a) and is described in more detail in D2.5 (Piero A. Bonatti, Kirrane, Petrova, Sauro, and Schlehahn 2018). In this, ‘base policy’ is an OWL2 expression denoting intersection of personal data categories, processing operations, purposes, recipients, and storage. Policies are expressed by through OWL2 unions over multiple base policies with differing expressions. SPECIAL provides additional vocabularies for purposes, personal data categories, processing operations, and recipients for using with the Usage Policy based on its use-cases. The general form of a base policy is:

ObjectIntersectionOf(
    ObjectSomeValuesFrom(spl:hasData SomeDataCategory)
    ObjectSomeValuesFrom(spl:hasProcessing SomeProcessing)
    ObjectSomeValuesFrom(spl:hasPurpose SomePurpose)
    ObjectSomeValuesFrom(spl:hasRecipient SomeRecipient)
    ObjectSomeValuesFrom(spl:hasStorage SomeStorage)
)

The storage expression is itself a policy comprising of OWL2 expressions specifying storage location, duration, and interval. The general form of a storage policy is:

ObjectIntersectionOf(
    ObjectSomeValuesFrom(spl:hasLocation SomeLocation)
    ObjectSomeValuesFrom(spl:hasDuration SomeDuration)
    DataSomeValuesFrom(spl:durationInDays Interval)
)

For a given policy P_c representing activities permitted by given consent and policy P_s representing processing activity, compliance is evaluated by checking whether P_c complies with P_s - checked using a semantic reasoner to evaluate P_c ⊆ P_s as an OWL2 subsumption. In SPECIAL’s implementation, this is performed using an algorithm (Piero A. Bonatti 2018; Bonatti, Petrova, and Sauro 2019) implemented as a custom semantic reasoner optimised for speed by performing only those operations associated with checking compliance between policies. An extension of the Usage Policy for representing additional requirements of GDPR was discussed in the deliverable D2.6 (Piero A. Bonatti, Kirrane, Petrova, Sauro, Kerschbaum, et al. 2018).

Activities are recorded as a log entry using Policy Log vocabulary (Piero A Bonatti, Dullaert, et al. 2018) as represented in Figure 3.2 by LogEntry, and are evaluated for compliance using semantic reasoner in both ex-ante and ex-post phases.

The Policy Log vocabulary, described in D2.7 (Kirrane, Milosevic, et al. 2018), reuses existing vocabularies of DCAT and PROV-O (Lebo et al. 2013), and is used to record immutable record of activities and their legal basis in consent. Each log entry (Log) contains information about agents that created the log (prov:SoftwareAgent), link to data subject, and information about processing through LogEntryContent which contains information represented using concepts from base policy. Information about consent is recorded through PolicyEntry and consists of consent assertion (given consent) and consent revocation (withdrawn consent).

Methodologies associated with vocabularies produced by SPECIAL project are based on utilisation of metadata in compliance process (Wenning and Kirrane 2018). The creation of policy vocabularies from use-cases is described through public deliverable D1.5 (Piero A. Bonatti, Colbeck, et al. 2018), with creation of log vocabulary described in D3.2 (Kirrane, Milosevic, et al. 2018). The vocabularies publicly accessible online with their documentation.

SERAMIS

SPECIAL has produced ODRL models for deontic representations of GDPR requirements through collaborations with other projects. The first in these collaborations is with the Austrian SERAMIS⁵² (Sensor-Enabled Real-World Awareness for Management Information Systems) project and has produced a web-based tool called ‘PriWUcy’ for evaluating compliance assessments of GDPR articles (Agarwal, Kirrane, and Antunovic 2017; Agarwal et al. 2018). The tool uses a model of GDPR created representing GDPR obligations using ODRL. A set of preliminary assessment questions provides inputs over which the model is applied to identify actions and obligations to be fulfilled as part of assessment. The developed ODRL model, depicted in Figure 3.3, is extended from the core ODRL model to represent additional constraints of - Feature, Discretional, and Dispensation. The ODRL policies are associated with relevant clauses of GDPR through developed classes representing chapters, articles, and paragraphs within the text of the GDPR. The approach relies on identifying and representing assets, parties, actions, duties, and constraints in GDPR using the developed ODRL model.

Vos et al.

The ODRL profile was further developed for modelling regulatory obligations and business policies based on GDPR towards compliance checking and providing explanations of the reasoning process (Vos et al. 2019). Additional classes and properties were added for specifying the legal basis, purpose, location, and safeguards associated with processing. Policies representing articles in GDPR are checked against permissions by activities to perform a data processing operation. For example, the following listing shows a request to transfer personal data to a third country based on consent, which would be checked against corresponding policy representing Article 46 of GDPR.

<http://example.com/policy:bp-transfer> a orcp:Set ;
    odrl:profile <http://example.com/odrl:profile:regulatory-compliance> ;
    orcp:permission
    [ odrl:action orcp:Transfer ;
        orcp:data orcp:PersonalData ;
        orcp:responsibleParty orcp:Controller ;
        orcp:organisationType orcp:InternationalOrganisation ;
        orcp:sender <http://example.com/CompanyA_Ireland> ;
        orcp:recipient <http://example.com/CompanyA_US> ;
        orcp:recipientLocation orcp:ThirdCountry ;
        orcp:purpose orcp:PersonalRecommendations ;
        orcp:legalBasis orcp:Consent ;
        odrl:dataSubjectProvisions orcp:EnforceableDataSubjectRights ;
        odrl:dataSubjectProvisions orcp:LegalRemediesForDataSubjects
    ] .

Compliance is checked by converting ODRL policies into InstAL - a domain-specific language for writing models based on events and states which translates to Answer Set Programming (ASP) and is evaluated using a Answer Set Solver⁵³. When a policy is found to be non-compliant, explanations are generated based on ‘fluents’ - facts that are true if present and false if absent - through a reasoning process. The implementation is publicly accessible through an online repository⁵⁴.

CitySPIN

The second collaboration consists of applying SPECIAL’s GDPR compliance framework in the Austrian CitySPIN⁵⁵ (Cyber-Physical Social Systems for City-wide Infrastructures) project (Fernandez et al. 2019) which utilises linked data platforms to ingest data from multiple sources in a smart city scenario and utilises it for data processing pipelines and analytics. An important component of the project is management of consent utilising SPECIAL’s policies (Piero A Bonatti, Dullaert, et al. 2018; Piero A Bonatti, Kirrane, et al. 2018a) and compliance framework (Kirrane, Fernández, et al. 2018). Figure 3.4 presents an overview of CitySPIN and its relation with SPECIAL vocabularies. The auxiliary vocabularies provided by SPECIAL for purpose and data categories (SPECIAL-MCM in figure) were extended for use-cases associated with CitySPIN (CPSS Core vocabulary and UC vocabulary in figure). The figure uses white blocks indicating concepts from SPECIAL’s vocabularies and greyed blocks indicating additional concepts defined by CitySPIN. The defined policies are checked in ex-ante and ex-post phases using SPECIAL compliance checking algorithm (Piero A. Bonatti 2018; Bonatti, Petrova, and Sauro 2019), with a prototype implementation demonstrating ex-ante compliance checking in ad-hoc widgets sharing personal data (Fernández et al. 2019). Details about the project and its implementation are available through public deliverables D6.1 (“D6.1 Privacy Policy Formalization” 2018) and D6.3 (“D6.3 Transparency Framework” 2019).

The use-cases utilised within SPECIAL project and a discussion of their legal requirements is provided in deliverables D1.5 (Piero A. Bonatti, Colbeck, et al. 2018) and D1.6 (Schlehahn and Wenning 2018). A dashboard representing information of processing activities and consent was created to represent logged information (Raschke et al. 2017) with its usability and testing described in deliverables D4.3 (Raschke et al. 2019) and D4.4 (Milošević et al. 2019). A separate visual interface for interactive consent was developed based on presenting components of usage policy to individuals in an interactive format (Drozd and Kirrane 2019b). The interface provides visual representations of associations between purposes, processing, data categories, recipients, and storage which allows individuals to explore and manage their consent. It also offers visual paradigms for representation of information as tabs, breadcrumbs, hierarchies, and graphs for visualisation and exploration of information.

The use-cases utilised within SPECIAL project and a discussion of their legal requirements is provided in deliverables D1.5 (Piero A. Bonatti, Colbeck, et al. 2018) and D1.6 (Schlehahn and Wenning 2018). A dashboard representing information of processing activities and consent was created to represent logged information (Raschke et al. 2017) with its usability and testing described in deliverables D4.3 (Raschke et al. 2019) and D4.4 (Milošević et al. 2019). A separate visual interface for interactive consent was developed based on presenting components of usage policy to individuals in an interactive format (Drozd and Kirrane 2019b). The interface provides visual representations of associations between purposes, processing, data categories, recipients, and storage which allows individuals to explore and manage their consent. It also offers visual paradigms for representation of information as tabs, breadcrumbs, hierarchies, and graphs for visualisation and exploration of information.

MIREL

MIREL⁵⁶ (Mining and Reasoning with Legal Texts) is an European H2020 Project that aims to create a framework for interpretation of legal texts into formal representations for querying norms, checking legal compliance, and decision support. The project uses semantic web to provide normative requirements (Gandon, Governatori, and Villata 2017), use natural language processing over legal texts (Teruel et al. 2018), and creating ontologies based on GDPR (Monica et al. 2018) for legal compliance (Palmirani, Martoni, et al. 2018a) and reasoning (Palmirani, Martoni, et al. 2018b). The project also involves creation of icons for data protection based on the developed ontologies (Arianna and Monica 2019). Information about the project is available through peer-reviewed publications and public deliverables⁵⁷. Details about the project and its developed resources, namely PrOnto, have been described in publications, but are not open or publicly accessible as of September 2020.

The developed ontology is called PrOnto (Privacy Ontology) (Monica et al. 2018), and provides concepts regarding GDPR associated with data types and documents, agents and roles, processing purposes, legal bases, processing operations, and deontic operations for modelling rights and duties. It reuses existing vocabularies (Palmirani, Martoni, et al. 2018b) and has been applied within the Cloud4EU project⁵⁸ for legal compliance checking of eGovernment systems as well as the DAPRECO project. PrOnto was developed using MeLOn (Methodology for building Legal Ontologies) developed by the MIREL project (Palmirani, Martoni, et al. 2018b, 2018a; Monica and Guido 2018).

PrOnto consists of modules representing (i) documents and data (depicted in Figure 3.5), (ii) actors and roles, (iii) processing and workflow, (iv) legal rules and deontic formula, (v) purposes and legal bases. It also includes modules for risk analysis and measures - which it utilises to represent risk management processes such as DPIA as workflows (Palmirani, Martoni, et al. 2018b). Reasoning is utilised based on the deontic operators within the ontology, and violations are connected with violated obligations thereby providing traceability in steps that created the violation. LegalRuleML is extended to represent obligations and rules for compliance.

A proof-of-concept application for detecting violations of the GDPR (Monica and Guido 2018) utilised PrOnto to model the legal concepts, along with Akoma Ntoso to model the legal text, LegalRuleML to model norms, and Regorous to apply LegalRuleML rules over BPMN and generate a report. The application utilises a web editor for modelling legal rules in connection with the legal text and ontology.

DAPRECO

DAPRECO⁵⁹ (Data Protection Regulation Compliance) is an Luxembourgian project relating to the creation of a knowledge base for formal compliance with the terms and provisions of the GDPR. It aims to provide formalisms in deontic logic and natural language semantics for handling legal norms in written language. The project has researched correlation of standards with laws (Bartolini, Lenzini, and Robaldo 2016), creation of an ontology to model concepts in the GDPR (Bartolini, Muthuri, and Santos 2017), modelling the norms of the GDPR using logic formalisms (Bartolini, Lenzini, and Santos 2018), and annotating BPMN for GDPR compliance (Bartolini, Calabró, and Marchetti 2019). The project involves collaborations with the MIREL project, particularly in the creation and utilisation of PrOnto for addressing GDPR (Monica et al. 2018; Palmirani, Martoni, et al. 2018b, 2018a; Bartolini, Calabró, and Marchetti 2019). In turn, DAPRECO provides a practical application of PrOnto as an use-case for legal compliance over business activities (Bartolini, Calabró, and Marchetti 2019; Bartolini, Lenzini, and Santos 2019).

While PrOnto represents a more mature and progressive deliverable of the project’s ontology for GDPR, the earlier ontology - referred to as data protection ontology (Bartolini, Muthuri, and Santos 2017) - is relevant for its modelling of concepts and norms based on an draft of GDPR. This ontology uses OWL2 to model concepts of GDPR and was specified to be a work in progress in its publication⁶⁰. Its methodology consists of using structure provided by the Handbook on European Data Protection Law⁶¹, and consists of concepts associated with - data protection principles, rules of data processing constituting duties of data controller, and data subject’s rights. The ontology reuses concepts from LKIF Core (Hoekstra et al. 2007) to represent rights, rules, legal and natural persons. It establishes relations such as hasObligation between a Controller and a LegalObligation concept, and consentGrantedBy between Consent and DataSubject - representing relations derived from GDPR. The ontology was evaluated using OOPS! (Poveda-Villalón, Gómez-Pérez, and Suárez-Figueroa 2014) and was documented using LODE (Peroni, Shotton, and Vitali 2013). The ontology can be accessed publicly⁶². The Competency Questions (CQ) representing functional requirements for the ontology were used in its evaluation through SPARQL queries, and are follows:

1. What are the obligations of a data controller?

2. What are the functions of a data processor?

3. What are the rights of the data subject?

4. How do the rights of the data subject relate to the obligations of the data controller and the functions of the processor?

5. How can a data subject interact and/or enforce their rights against a data controller?

6. What are the possible fines and sanctions issued in response to violations by data controllers?

7. Who supervises a data controller?

Subsequent applications of PrOnto in the project utilise Reified Input/Output logic (RIO) (Robaldo and Sun 2017) - a formalism for normative reasoning based on reification applied to natural language semantics. The rules are expressed using LegalRuleML and are associated with activities using BPMN. This is utilised to allocate tasks related to data protection to stakeholders, and to track compliance across different phases of a software development life-cycle. The project uses these to create a knowledge base (Bartolini, Lenzini, and Santos 2019) with feedback from stakeholders by providing a human-readable version of RIO logic rules utilised to model the GDPR. The project also researchers automating comparison of GDPR with ISO/IEC standards by extracting RIO rules from their texts and analysing them for comparisons. The resulting knowledge base is used in collaboration with MIREL to provide semantic extraction and annotation over ECHR (European Court of Human Rights) judgements (Cardellino et al. 2017) as described in MIREL’s deliverables D2.4 (Robaldo 2017).

BPR4GDPR

BPR4GDPR⁶³ (Business Process Re-engineering and functional toolkit for GDPR compliance) is an European H2020 project that aims to provide a reference compliance framework for GDPR. The framework is stated to provide specification of sophisticated security and privacy policies, modelling technologies and tools for incorporation of provisions in process models and resulting executable processes, with means for automating verification and alignment. This is planned to be achieved using mechanisms for automating procedures that result in processes that are compliant by design. The project intends to implement the concept of Compliance-as-a-Service (CaaS) by providing a set of tools that fit the needs of various organisations subject to GDPR compliance. Information about the project is available through peer-reviewed publications and project deliverables⁶⁴.

The project uses an ontology to represent the information model as depicted in Figure 3.6 (Lioudakis and Cascone 2019). The ontology consists of concepts and relationships regarding data types, roles, operations, and organisation types amongst other contextual concepts. The ontology is serialised using OWL2 and contains ‘default instances’ representing a ready to use set of instances based on use-cases described in deliverable D3.1 (Lioudakis and Cascone 2019).

Compliance assessment is performed using the compliance meta-model ontology depicted in Figure 3.7 and described in deliverable D2.3 (Dellas 2019). The compliance ontology is used to dictate and evaluate processes by considering them as workflows where actions or operations are connected to each other in terms of dependencies and data flows performed by actors which can include assets or artefacts.

Process mining is performed on knowledge extracted from event logs of information systems to discover, monitor and improve processes not assumed or modelled prior to evaluation. This is utilised to create a process monitoring architecture which contains four sub-components of: functionality associated with pre-processing, conformance checking, rules, and model repair. The approach intends to ‘repair’ process models by analysing failed conformance checks, converted rules, and results of conformance checking to identify parts of process model not compliant with rules.

The public deliverable D3.1 (Lioudakis and Cascone 2019) defines rules derived from GDPR which represent a minimal set of configurations for BPR4GDPR architecture before it is adapted to a particular use-case, i.e. its default configuration. These rules are intended to act as constraints in conformance checking and used to repair the processes by identifying components that need to be changed to satisfy rules.

Elluri et al.

Elluri et al. (Lavanya Elluri and Joshi 2018; L. Elluri, Nagar, and Joshi 2018) present an ontology of rules and obligations for cloud data providers and consumers based on GDPR for Payment Card Industry Data Security Standard (PCI DSS). The ontology for GDPR (Lavanya Elluri and Joshi 2018) is comprised of concepts for components - ‘Consumers and Providers’, ‘Fines and Enforcement’, ‘Breach & Notification’, ‘Data Protection Officer’, and ‘Data Subject’. This is combined with ontology developed for PCI DSS and Clous Security Alliance (CSA) for addressing their combined legal requirements and obligations (L. Elluri, Nagar, and Joshi 2018). The resulting ontology, depicted in Figure 3.8, consists of concepts and relationships associated with stakeholders, obligations for providers and consumers, and security requirements.

The development methodology used to develop the ontology had three steps: (i) Preprocessing, (ii) Ontology Development, and (iii) Validation. The preprocessing stage consisted of extracting relevant chapters and concepts from text of GDPR, PCI DSS, and CSA - and representing them using a preliminary ontology. These were then mapped with corresponding terms from CSA ontology. This stage also involved identifying data protection rules as permissions, obligations, dispensations, and prohibitions using a keyword-based approach. Matching of concepts and rules was performed using a tool that utilised text extraction and regular expressions to match contents with developed ontologies.

The validation of ontology compared text of privacy policies of cloud service providers using the developed ontology and tools. The extracted terms from policies were populated as instances of concepts from developed ontology to create a RDF representation of policy. Apart from this description, the papers do not provide further details of semantic representations or examples of extracted information, nor an use-case demonstrating capabilities. The ontology is referenced with an accessible link⁶⁵ (Lavanya Elluri and Joshi 2018), though it does not provide documentation or examples of its usage. Analysing the ontology shows instances of relevant chapters and articles within GDPR applicable to PCI DSS and CSA, and declared as generic resources without reference to actual text or IRI of GDPR.

Related work within the same project by Joshi and Banerjee (Joshi and Banerjee 2019) concerns use of ontology to represent personal data categorisations and data privacy policies for automated enforcing of access control mechanisms regarding sharing of data with third parties through a blockchain. The data privacy policy, depicted in Figure 3.9, shows concepts and relationships for information regarding processing. The privacy policy contains information about data collection purpose, data collected, protection measures, use limitations, consent requirements, and access control.

The modelling of concepts includes some notably different relationships such as association of storage duration within collection purpose, usage limitation relating to data recipients, attributes associated with consent, and inclusion of redress. The developed ontology is utilised to extract and represent instances from privacy policies, enhance it using a reasoner, and to store resulting access control representations in blockchain. The work is based on utilising an existing privacy policy as a smart contract for sharing of data between provider and consumer. It is important to note that the work relates to use of PII as opposed to personal data as defined by GDPR. Furthermore, the policy does not encode information about rights as required by GDPR.

Ujcich et al.

Ujcich et al (Ujcich, Bates, and Sanders 2018) present a data provenance model of GDPR utilising PROV-O (Lebo et al. 2013) to represent activities and data as semantic-web representations. The data model from the publication is depicted in Figure 3.10 and provides an overview of concepts using PROV-O (Lebo et al. 2013) diagrams to denote concepts. The approach uses the activity ‘Justify’ to represent rationale for processing personal data and has annotations depicting its starting and ending times, as well as a ‘Justification’ - which represents legal basis of processing. The ontology focuses on workflows involving exercising of rights under GDPR, and provides examples of provenance for data rectification and withdrawal of consent.

The approach presented in the publication uses design patterns to describe use of ontology in specific cases regarding exercising of rights. The design pattern for provenance associated with consent does not associate data directly with consent owing to data being potentially updated independent of consent. The design pattern is further extended in the publication to represent data sharing with a processor for marketing. The publication provides a discussion on verification of compliance based on provenance through questions which can be queried over the data represented using presented ontology.

Specifying purposes as defined by GDPR is not clarified in this approach as the concept of Justify is temporal in its use and limited to processing of personal data it is associated with. The approach also does not provide any information on modelling of more complex processing operations where more than one legal basis could be applied, or where processing operations need to be expressed in several steps. The approach also does not model information about consent or rights, and does not provide ex-ante representations of activities.

Personal Information Controller Service (PICS)

PICS is a project with the objective of enabling users to discover and control use of their personal data by providing a platform for authentication and management between service providers and personal information. The platform architecture (Winckler et al. 2019) consists of three components: (i) personal data controller - provides an user interface allowing users to connect and mediate data to third-party services, (ii) ToS analyser - interprets terms of service and policies of providers using an ontology, and (iii) data mining traces of use - which enables discovery of web services utilising personal data shared with service provider. The platform delegates data storage to an external storage and does not store personal data itself. Authentication is performed at every interaction, and requires users to provide physical authentication using a wearable device.

The ontology used by ToS analyser (Benfenatki et al. 2018) consists of concepts associated actions on data (such as deletion, disclosure, fusion, sharing), governance (laws, ownership, rights, terms of service), security strategies, and data protection. The ontology itself is not public or accessible and the publication does not provide details about its concepts or use beyond that of utilisation in ToS analyser.

ADvoCATE

ADvoCATE (Rantos et al. 2019) is a consent management platform for data processing in IoT that uses blockchain to record given consent, detects conflicts in data sharing policies, and provides recommendations for managing unwarranted exposure of personal data. In ADvoCATE, the consent notary component is responsible for obtaining and verifying consent signed by both the controller and data subject, and is used to prepare smart contracts for processing based on given consent. The consent management component utilises smart contracts to update user policies to enforce access control over stored personal data. Blockchain is utilised to store versioned hashes of consent linked to smart contracts enforcing them to provide traceability of consent by maintaining a record of consent and its relevant actions.

ADvoCATE has two components - Intelligent Policies Analysis Mechanism (IPAM) and Intelligent Recommendation Mechanism (IReMe) - to identify contradictory rules and policies regarding consent and adapt privacy strategies in real-time. A reference implementation described in the publication uses ontology of GDPR concepts by Bartolini et. al (Bartolini, Muthuri, and Cristiana 2015) to model data protection requirements, and uses Ethereum as a blockchain platform with Solidity for programming smart contracts. Examples of consent requests presented contain information about personal data category with collection medium and period, retention period, purpose, recipients (EU/Non-EU), use of automated processing, profiling, manual processing, and IDs for controller, device, and device type.

Ontology by Geko & Tjoa

Geko & Tjoa (Geko and Tjoa 2018) proposed an ontology for capturing interdependence between GDPR and information security requirements for assisting with compliance requirements involving security. The ontology, depicted in Figure 3.11, consists of hierarchical concepts representing obligations of GDPR and information security. It has concepts regarding entities (Controller, Processor, Data Subject), rights, principles, personal data, obligations, and security. These are related using properties associated with fulfilling roles and obligations, ensuring data security, and provision of rights.

The publication describes an example use-case where additional concepts are added to represent security concepts of access control, audits, data classification, information risk assessment, security awareness, and security policy. Further concepts are also mentioned for representing technical measures of encryption, logging, network security, physical security, privacy by design and default, and pseudo-anonymisation. The publication explicitly mentions that the ontology has not been evaluated. The publication also does not provide access to the ontology or its documentation.

3.3 Other approaches addressing GDPR compliance

Layered Privacy Language (LPL)

LPL (Gerl et al. 2018) presents a formal model for specification of legal requirements regarding consent, data provenance, data retention and other privacy related concepts associated with GDPR. The objective of LPL to provide technical systems with a machine-readable privacy policy and privacy by design. LPL defines the following requirements for a privacy language: (i) differentiation between data-source and data-recipient to enable fine-grained access-control; (ii) modelling of purpose-based privacy policies with modelling of data, retention and anonymisation enabling privacy models; (iii) layering of privacy policies to ensure provenance; and (iv) human-readability.

The LPL structure, depicted in Figure 3.12, consists of LayeredPrivacyPolicy (LPP) as the root element representing a privacy policy or a legal contract. The element contains attributes for recording version information and an URI to privacy policy containing its human-readable description. Each LPP can refer to an UnderlyingPrivacyPolicy to enable tracking of privacy policies across multiple entities. LPP is associated with data sources and its use in (multiple) purposes. The purpose is further associated with data recipients, data, privacy models, and data retention.

LPL contains the concept of Entity-Hierarchy where permissions provided to parent entity can be controlled at granular levels through child entities, such as for different departments within an organisation. Similarly, Purpose-Hierarchy represents trees of purposes where a child purpose inherits rights from parent purpose. In this hierarchy, Regulated Purpose specifies purpose required or obligated by law. Authorisation of entities and purposes is carried out by searching for rules matching the entity and purpose or their parents in hierarchy.

A critical analysis of LPL for Article 12-14 of GDPR was carried out (Gerl and Pohl 2018) and presented as requirements identified in articles of GDPR with indication of whether corresponding LPL concepts fulfil stated requirements. The analysis was used to propose changes to LPL for incorporating additional concepts that fulfil the requirements.

Lodge et al.

Lodge et al. (Lodge, Crabtree, and Brown 2018) present the Databox application development environment (SDK) for developing IoT apps utilising requirements to meet GDPR compliance. The SDK is provided with the objective to simplify compliance by utilising provided tools and design patterns. The approach is based on identifying applicable requirements from text of GDPR and classifying them as based on risk or transparency.

The SDK enables modelling of applications as information flows consisting of four node types: data-stores - devices or services that generate data; processors - nodes that operate on data; profiler - nodes that infer new information about data subject; and outputs - nodes that perform action on data. Using the SDK, application developers can inspect ongoing risk breakdowns based on developed application, and track personal data as it moves through the application. The SDK also enables creation of GDPR-compliant contracts that embed required information to provide informed consent, and provide automatic tooling for runtime data flow inspection.

Risks are detected based on whether data is exported out of platform, triggers physical actuation, utilises insecure hardware, or uses unverified libraries. Tracking of personal data is provided by enforcing all outputs from a node to provide personal data schema consisting of top-level attributes associated with description of personal data, its source, and sensitivity.

GDPR compliant contracts are created by utilising information flows to construct an agreement that is presented to the user. The agreement is visualised as multi-layered notice that represents information taken from a manifest file containing all possible configurations in terms of data collection and usage. Developers can mark an information as required or optional to indicate its basis in consent.

Consent and Data Management Model by Peras

Peras (Peras 2018) presented 10 guidelines for implementing a consent management framework based on requirements of GDPR. These guidelines are based on adopting requirements of consent and provision of rights in a data management system. The publication presents an analysis of existing consent and data management models⁶⁶ where elements and attributes of the model are used for comparison. Based on this, a consent and data management model, depicted in Figure 3.13, is proposed consisting of contact interface for interactions between controllers and data subjects, consent management module, context management module, data management module, and origin management.

Tom et al.

Tom et al. (Tom, Sing, and Matulevičius 2018) presented a conceptual model of GDPR representing entities, actions, artefacts, rights, and their interactions. The publication provides a table of GDPR articles and their related entities and associations within the model which it uses for evaluating completeness. The model, depicted in Figure 3.14, contains concepts regarding consent, purpose, data processing, technical measures, and actors such as controller, processor, data subject, and supervisory authority.

The attributes of each concept are modelled based on database schemas and represent conditions or additional information associated with the concept. For consent, boolean attributes define whether it was freely given, can be withdrawn, is unambiguous, was in affirmative action, and is distinguishable. Similarly, purpose has boolean attributes regarding whether it is in legitimate interest, does not require identification, is in public interest, for legal obligation, of vital interest to the data subject, and whether it indicates contract of processing. Certain attributes can refer to a table of concepts or instances, such as the PersonalData attribute of category referring to DATA_CATEGORY. The publication provides examples of personal data categories, actor types (private, public, natural person, legal person, official), technology categories, processing operations, and generic stereotypes (secure channel, communication protection, encryption).

The model was utilised to develop an approach for analysing GDPR compliance over business process models using BPMN (Pullonen et al. 2019). The approach, termed PE-BPMN (Privacy Enhanced BPMN) and depicted in Figure 3.15, utilises BPMN to capture Privacy Enhancing Techniques (PETs) for capturing information flows. The approach is utilised in a mobile app scenario to analyse information disclosure. The information disclosure analysis is performed for identifying whether an object (personal data) is disclosed a defined by it being received or intercepted by another party regardless of intent or policy. Objects can be visible, accessible, or hidden based on whether the actor obtains and owns them, whether data is protected or requires additional permissions, and whether it is protected by some PETs. The associated publication (Pullonen et al. 2019) presents details of an implemented prototype and its application in use-cases involving secure storage of data using encryption and PETs.

The approach is similar to the use of semantic web ontologies to represent concepts and use of a semantic reasoner to evaluate compliance, such as in SPECIAL (Section [sec:sota:SPECIAL]). The use of BPMN differentiates the approach from other semantic representations of information, and the analysis provides a limited evaluation of compliance based on disclosure of personal data. While the approach contains concepts for representing information associated with how personal data is processed, it does not provide evidence of its use in evaluating other requirements of compliance - such as analysis of consent, or investigation of activities associated with sensitive personal data.

Coletti et al.

Coletti et al. (Coleti et al. 2019) proposed visual design patterns to provide transparency regarding personal data processing in mobile applications. These design patterns consist of recommendations for user interface and experience regarding providing information about processing and rights as per requirements of GDPR. Their approach identifies relevant information to be provided for transparency a: (i) contact information for Controllers, Processors and Data Protection Officers, (ii) information about purpose of use, legal basis, and rights, (iii) information about location as a specific form of data and processing, (iv) information about actions and algorithms utilised in processing, (iv) data sources, and (v) period of use and storage of data.

The visual design patterns organise this information into different layouts and screens to provide a simple view to data subjects. A ‘springboard’ consisting of overview of different sections is provided through which information about each topic can be obtained. The approach recommends a three-layered approach consisting of - (1) purpose, legal basis, and rights; (2) subgroups of information such as specific laws related to legal basis, actionable tasks regarding rights; and (3) textual information with a search field.

Corrales et al.

Corrales et al. (Corrales, Jurčys, and Kousiouris 2019) propose embedding legal requirements in smart contracts as a programmatic algorithm by encoding answers to a questionnaire as a compliance framework for data processing in the cloud. The questionnaire contains 15 questions related to legal and technical issues including privacy, data protection, and data security. The answers to questions are boolean and consist of affirmative (YES) or negative (NO). The algorithm for compliance checks whether questions have been answered in a way that meets requirements of GDPR. The pseudo-code presented in the publication consists of steps checking answers which can also be visualised as a flow-chart or decision making steps.

The approach is based on assessment of questionnaire responses rather than analyses of process representations. While questions used are useful in investigation of compliance, the approach does not provide any guideline or assistance regarding gathering information required to answer them, or even evaluating information apart from boolean responses.

LUCE

LUCE (Havelange et al. 2019) (A Blockchain Solution for monitoring data License accoUntability and CompliancE) is a platform for facilitating compliance with licensing terms by enabling data accountability through recording of data use and purpose using blockchain. The platform specifically aims to provide compliance assistance for GDPR and its rights. LUCE has objectives to : (i) automatically manage and enforce licensing terms attached to datasets, ii) record and make available information pertaining to how and for which purpose datasets are reused, and iii) enable compliance with GDPR rights regarding data access, rectification, and erasure. The architecture, depicted in Figure 3.16, consists of four layers for management of metadata, entities, data, and blockchain.

Data providers publish their dataset metadata into a Yellow Page shared directory where requesters can search for matching datasets. Each dataset is accompanied with licensing information for access and reuse. A transaction for reusing data is implemented as a smart contract containing associated licenses as obligations. Requesters accepting licensing agreements are provided with access tokens which are tracked within smart contracts for compliance. The License-Monitoring sub-module continuously checks actions performed by data requester for compliance with licensing terms and records actions in a file to record log of events. Access tokens are valid for specific time periods after which renewal is granted based on prior compliance with licensing terms checked using event logs. A data provider can also check accesses to data and status of requester’s compliance. GDPR rights are enforced and supplemented by using smart contracts to perform actions such as retrieving information to provide regarding right to access and obtaining IDs for deletion regarding right to erasure and rectification. The prototype implementation described uses Ethereum⁶⁷ as blockchain platform and Solidity⁶⁸ as smart contracts language.

Decision Provenance by Singh et al.

Singh et al. propose the concept of ‘Decision Provenance’ which uses methods based on provision to identify decision pipelines and actions taken in an system at design and run-time. Decision provenance is aimed to facilitate oversight, audit, compliance, risk mitigation, and user empowerment, and relates to accountability of algorithmic systems. The paper provides a discussion of GDPR, identifying legal impetus to identify and record provenance information regarding processing of personal data and management of rights. The utilisation of data flows in a system to map actions, steps, and boundaries is utilised as motivation for its use in compliance management systems based on adapting legal requirements for design and use of data flows. With this, ‘decision provenance’ is defined as “use and means for provenance mechanisms to assist accountability considerations in algorithmic systems”.

The information required to be recorded and utilised for decision provenance concerns the history or provenance of data and a broader view of system behaviour and interactions including those with entities. The publication also describes usefulness of information in ex-post analysis. Regarding compliance, decision provenance is described with uses for tracking of conditions associated with processing, consent, purposes, rights, and sharing. The collected information is also described for uses in performing audits and investigations by authorities as well as the organisation itself.

The publication makes specific mention of PROV-O (Lebo et al. 2013) for representing provenance information, supplemented by ontologies for describing additional information about data processing. An example cited in this context concerns the use of PROV-O to represent provenance for GDPR compliance (Ujcich et al. (Ujcich, Bates, and Sanders 2018) - see Section).

Sion et al.

Sion et al. (Sion et al. 2019) presented an approach for data protection by design in software architectures towards incorporating requirements of GDPR. The approach is developed towards automation of data protection impact assessment (DPIA) using (i) meta-model constraints, (ii) model analysis, and (iii) interaction with stakeholders. It uses architectural notations such as UML and Data Flow Diagrams (DFD) to express the model of a system. The publication provides a discussion of necessary information for creation of a meta-model for GDPR which includes the following:

• Use of GDPR terminology as opposed to abstract architectural notations;

• Core abstractions such as ProcessingPurpose;

• Documentation regarding abstractions - such as collection, further processing, the purpose itself, its legal basis (termed LawfulGround), involved actors and their roles, and datasets and data-types involved for a purpose.

The presented meta-model, depicted in Figure 3.17, utilises UML to denote concepts and relationships. Apart from expressing concepts such as purpose, processing, personal data type, and data subject type, the meta-model expresses controllers, processors, recipients and third parties as legal roles expressed through an actor. Additionally, it has a distinct concept for further processing to represent processing other than that of primary purpose. Exceptions to obligations provided by GDPR are captured as prohibition and exemption types.

The meta-model is used to express the model or architecture of a system which is then evaluated or validated utilising constraints. One of these, described in the publication, is “soundness criteria” - which is relevant to completeness and correctness of a model. Examples of these are - “every chain of Processing needs to start with a Collection”, and “Every input DataSet to a Processing needs to be the output DataSet of a Processing that is located earlier in the chain of Processing”. These can be collectively expressed as constraints for every data used in processing to have a source whether by collection or as output of processing activity. The publication also provides examples of incorporating legal requirements in the meta-model, with examples for purpose limitation, minimisation, and automated decision making involving special categories of personal data.

The approach is validated through an use-case in health domain involving a patient monitoring system (PMS) using DFD to denote architectural notations in Eclipse Modelling Framework with graphical visualisations created using Sirius viewpoint specification. The soundness checks were performed using Acceleo Query Language supported by Sirius, with further described as implementing compliance assessment rules using VIATRA’s graph-based pattern language.

privacyTracker

privacyTracker (Gjermundrød, Dionysiou, and Costa 2016) is a framework that provides data traceability through privacy by design principles for GDPR compliance. The framework utilises policies to mediate access to information stored in as Customer Records and consists of 3 modules regarding data collection, data distribution, and data traceability. The Customer Record is a XML document utilising XSD to store personal data and contains two sections - a mandatory metadata section and an optional section. The metadata section contains fields for record identification, data tractability, and cryptography controls. The optional section consists of fields indicating public data, private data that can be disclosed based on consent, and data provided by the enterprise itself.

The record identification field contains a URI based on string concatenation of company name, user email address and auto-generated random identifier. This URI is unique within the framework but changes when data is distributed to another entity. In addition, the identification field also stores timestamps associated with record genesis, (local) record creation, and expiration. The data tractability fields record links to the entity that generated the record (backward-to-root reference), entities the record was obtained from (backward reference), and entities the record is disclosed to (forward reference). The cryptography controls store a signed copy of received record and a signature as hash code of complete record. The distribution module enables sharing of data via an API through which granular requests can be made. Records of distributions are signed cryptographically and verified for tractability. Enforcing rights is simplified by traversing the stored distribution records starting from original record as root and moving towards leaves. A prototype of implementation consisted of 6 companies and used MySQL and PHP as technological framework. The records were stored using XML are then ingested into the database and queried using SQL.

The analysis of GDPR presented in connection with privacyTracker provides a list of requirements required to be satisfied by compliance frameworks, which are: Articles 5(1a), 5(1d), 6(1a), 6(1c), 7(1), 7(3), 12(1), 12(2), 14(1a), 14(1ac), 14a(2g), 15, 16(1), 17(1), 17(2a), 17a(1), 18(2), 19(2)). These provide obligations to record and demonstrate evidence regarding handling and sharing of consumer data.

Metrics for Transparency by Spagnuelo et al.

Spagnuelo et al. (Spagnuelo, Bartolini, and Lenzini 2016) define eight quality metrics for transparency regarding data processing associated with GDPR. In this context, transparency is defined based on quality factors of ‘Informativeness’, ‘Understandability’, and ‘Accessibility’ associated with providing information; and ‘Validity’ and ‘Accessibility’ associated with providing mechanisms. Each metric is associated with one or more questions that retrieve information regarding quality factors associated with quantitative scoring. The metrics provide a quantifiable representation of transparency in a system and are used in a use-case to evaluate Microsoft Health-Vault - a commercial product. The metrics are as follows - accuracy, currentness, conciseness, detailing, readability, availability, portability, and effectiveness.

meta-model for PLA by Diamantopoulou et al.

Diamantopoulou et al. (Diamantopoulou et al. 2017) present a meta-model for representing Privacy Level Agreements (PLA) with the aim of establishing contracts between controllers and individuals. The meta-model, depicted in Figure 3.18, represents privacy preferences as questionnaires where each question refers to specific data categories and answers represent individual’s preferences regarding data sharing. The meta-model associates preferences with threats, risks, and security measures through data and controller. Requests for sharing data are associated with data and preferences, and can be accepted or denied based on values of linked preferences. The meta-model is specified to be designed for use-case in eGovernance scenarios where public administrators can provide data and value based on citizens preferences represented through the meta-model.

Robol et al.

Robol et al. (Robol, Salnitri, and Giorgini 2017) proposed a modelling and reasoning framework based on socio-technical systems (Dalpiaz, Paja, and Giorgini 2016) - an approach for incorporating interaction between people and technology. The proposed framework extends STS-ml - a goal-based modelling language provided in STS - with relevant concepts regarding privacy by design and GDPR compliance. The extended modelling language consists of three views - social, information, and authorisation - based on concepts and context of interactions between them. Social views incorporate actors and their goals and documents, as well as delegations and transmissions. Information views consist of associating actors with information and tangible documents. Authorisation views consist of interactions with actors based on authorisations which are validated by legal basis over some information towards a particular goal. The modelling concepts are explained using a health-domain use-case.

Reasoning is based on using concepts in policies that are validated for compliance. The policies use formal representations of rules based on conditions and constraints for compliance with the notion of well-formedness of models. One notable aspect of this work is use of concepts from socio-technical approaches to represent GDPR concepts. In particular, goal is used to simulate purpose, actors are used to conceptualise individuals and controllers, and authorisation is used to simulate valid legal basis. The approach enables use of STS modelling and reasoning to develop rules for expressing GDPR compliance requirements and validations.

Basin et al.

Basin et al. (Basin, Debois, and Hildebrandt 2018) proposed an approach that aligns purpose as defined by GDPR with business processes and uses formal models of inter-process communication to audit GDPR compliance. The approach also uses models of data flows to derive privacy policies. The definition of business process used consists of having a set of activities that take inputs and produce outputs, have a beginning and an end, and are ordered. The inter-process communication is based on data-flow graphs where different processes interact and share same sets of data for different purposes.

The auditing mechanism is based on validating whether an implementation conforms to process collections i.e. implemented activities conform to modelled processes, process collection conforms to privacy policy i.e. modelled processes conform to those specified within a privacy policy, process collection conforms to GDPR, and privacy policy conforms to GDPR. The process collection is defined as a tuple PC = (P, D, DU, DC) consisting of processes (P), data classes (D), data usage (DU ⊂ DxP), and data collection (DC ⊂ DxP). Consent compliance is based on evaluating whether process collection permitted by consent is permissive based on the defined privacy policy. Similarly, data minimisation is evaluated by assessing whether all data collected is utilised in some process.

RestAssured

RestAssured⁶⁹ is an European H2020 project that aims to enable secure data processing in the cloud with sticky policies for decentralised data life-cycle management. The project aims to achieve this by using run-time models for data protection assurance and automated risk management. Run-time detection, prediction, and prevention of data protection violations is achieved using a catalogue of risk patterns representing data protection vulnerabilities of cloud systems (Palm 2018; Schoenen, Mann, and Metzger 2018). The pattern meta-model and its validation is described in deliverable D5.1 (“D5.1 Concept for End-User Privacy Policy Violation Detection” 2018). Information about the project is available through peer-reviewed publications and deliverables⁷⁰.

The project addresses GDPR through a conceptual model incorporating concepts necessary for compliance as depicted in Figure 3.19 (“D6.1 Methodology for Decentralized Data Lifecycle Management” 2018). The model is utilised in data protection policy specification consisting of data protection contract, sticky policies, and specification of obligations. The model is utilised to provide a customised privacy policy that allows users choice of preferences for selected services (Gol Mohammadi et al. 2019). The data protection contract is composed of 4 main parts - description of service that needs to access data, specification of data needed to be accessed by service and whether access is mandatory, list of usages where usage is composed of textual description that describes purpose of usage and associated processing action as well as list of needed data types, and specification of data that will be published by service. The obligations are defined based on their enforcement in relation to access control (before, at same time, after), and are specified with three pieces of information: (i) obligation type (before, after, with), (ii) event trigger, and (iii) action to be performed. The serialisation of obligations is done using XACML 3.0. The deliverable D7.1 (“D7.1 RestAssured Security and Privacy Engineering Methodology” 2018) refers to use of RDF to represent concepts and relationships as a graph consisting of three layers representing: (i) core model of schema that captures fundamental concepts e.g. assets, roles, threats, and their relationships; (ii) domain model of datasets that encode domain-specific knowledge e.g. detailed threats and their possible control strategies; and (iii) system models that represent an actual system upon which risk assessment is being performed.

OPERANDO

OPERANDO⁷¹ (Online Privacy Enforcement, Rights Assurance & Optimisation) is an European H2020 project that aims to provide a platform for users to specify preferences via a dashboard which is then compared with online service providers’ privacy policies and converted into access control rules. The deliverable D3.1 (“D3.1 Guidelines on Legal Aspects” 2016) describes legal requirements of GDPR in context of OPERANDO’s objectives, while deliverable D6.4 (“D6.4 Final (Product) Version of Privacy Enhanced Tools” 2017) describes architecture and working of privacy tools. Information about the project is available through peer-reviewed publications and public deliverables⁷².

The platform operates in an online environment and uses APIs between services which pass information using JSON. A User Privacy Policy (UPP) (“D6.7 Final (Product) Version of Security Aware Tools” 2017) is stored in platform database and represents user’s preferences (and consent). The UPP records preferences using fields for information identifiers, personal data category, ranked preference (0 to 10, higher indicating greater concern), role (of person acting on data), action (performed on data), purpose, and recipient. The UPP also contains information on access policies created based on comparing user’s preferences against an online service provider’s privacy policy.

The online service provider’s privacy policy (OSP) (“D6.7 Final (Product) Version of Security Aware Tools” 2017) consists of fields defining workflows and contained steps with information about requester subject (role of service provider), requested data, and action to be performed. The OSP also contains information about access policies for which service provider has privileges to perform requested operations in specified roles. Information about how UPP and OSP are utilised in an API to enact an access request is provided through deliverable D6.4 (“D6.4 Final (Product) Version of Privacy Enhanced Tools” 2017).

My Health My Data (MHMD)

My Health My Data⁷³ (MHMD) is an European H2020 project that aims to develop infrastructure based on blockchain and smart contracts to provide personal data accounts in the cloud that can be managed using dynamic consent interfaces and to provide peer-to-peer connections between stakeholders. The project uses blockchain to log data transactions in a secure, transparent, and accountable manner, with de-identification and encryption to protect identity and sensitive information. The safety and security of data is tested using re-identification and penetration simulations. Information about the project is available through peer-reviewed publications and public deliverables⁷⁴.

The project is applied over use-cases of health data and devices as described in deliverable D1.1 (“D1.1 Initial List of Main Requirements” 2017), which uses an ontological resource to model the common data ontology - described in deliverable D4.2 (Teodoro et al. 2018). The common data ontology consists of modular health data ontologies representing synthetic data shared by the project’s commercial partners as an use-case. Access to data is provided through an API that includes parameters describing requested data category and consent. The API returns matching datasets which can then be utilised for data processing activities. The consent description parameter of API is a text field consisting of values such as “synthetic data” and “fully anonymised” which reflect state of data and its requirements in terms of consent.

Though the project aims to utilise GDPR as a source of legal requirements and strives to design its framework to meet compliance requirements by both design and default, there is no publicly available information regarding specifics of how GDPR compliance is achieved or represented. It focuses on privacy preserving and security aspects of data storage by using technological solutions such as access control and transparent logging to design specifications based on legal requirements. The project does explores impact of GDPR on storing data in a blockchain, especially regarding right to be forgotten (Bayle et al. 2018).

3.4 Approaches involving Privacy Policies

These approaches involve utilisation of privacy policies for various purposes associated with data protection and user empowerment. While they do not target GDPR compliance, they are relevant as they involve analysis of information associated with compliance - such as purposes, data categories, and rights - and provide an overview of GDPR’s impact and uptake in the real-world.

Usable Privacy Project

The UsablePrivacy project (Sadeh et al. 2013) utilised natural language programming over manually annotated corpus of privacy policies to create a system for automatic classification of policies. It utilised semantic web technologies (Oltramari et al. 2018) to represent annotations and information within a privacy policy, and to query information for retrieval. Its datasets have been utilised in other similar approaches (Harkous et al. 2018; Linden et al. 2018) concerning automatic analyses over privacy policies.

Polisis and other approaches based on Usable Privacy Project

Galle et al. (Galle, Christofi, and Elsahar 2019) presented an argument for a similar corpus (to UsablePrivacy) of GDPR-specific privacy policies based on increased requirements of GDPR compliance, presence of information, and use of simpler text. While such a dataset has not been published to date, there have been approaches incorporating GDPR specific information in privacy policy analysis. Polisis (Harkous et al. 2018) is one such approach that analyses privacy policies using Wilson et al.’s taxonomy of privacy concepts (Wilson et al. 2016) (depicted in Figure 3.20). Further GDPR specific work using the same approach collects and compares policies in pre-GDPR and post-GDPR versions to identify impact of GDPR (Linden et al. 2018). The approach uses a list of queries derived from ICO’s GDPR compliance checklist to obtain coverage of GDPR in terms of queries answerable in privacy policies.

PrivacyGuide

PrivacyGuide (Tesfay et al. 2018; Westphal, Fernandez, and Kirrane 2018) provides visualisation of privacy policies and information categories as a dashboard. It uses a similar approach to UsablePrivacy and Polisis in classifying statements in policies and extracting information using machine learning. In terms of information, its models contain concepts for: data collection, protection of children, third-party sharing, data security, data retention, data aggregation, control of data, privacy settings, account deletion, privacy breach notification, policy changes. The approach is based on identifying a set of keywords for each concept and classifying statements based on their presence.

3.5 Approaches related to Consent

These approaches concern representation of consent and provide information about existing efforts towards its management and analysis. They are relevant as they involve information associated with provision of consent, its impact in real-life, and complexities associated with its representations.

Grando et al.

Grando et al. (Grando et al. 2012) present an ontology-based model of permissions and obligations resulting from informed consent within medical domain. The approach, depicted in Figure 3.21, consists of using XACML for rules implementing a consent management system by utilising reasoning using SWRL.

Consent Receipt Specification

The Consent Receipt specification⁷⁵ (Lizar and Turner 2017) is a standardisation effort by Kantara Initiative - a non-profit industry professional trade association with a mission to - “improving trustworthy use of identity and personal data through innovation, standardisation and good practice in the domain of digital identity management and data privacy”. Consent receipt provides a list of fields for capturing context of given consent and is meant to provide a record of transaction regarding personal data. Its fields, depicted in Figure 3.22, capture information about timestamp the consent was given at, entities involved (controllers), PII involved, purposes, and recipients.

3.6 Upcoming research projects addressing GDPR

This section lists upcoming research projects that address or incorporate GDPR compliance in their requirements and are currently developing solutions to meet their objectives and aims. These are presented to include them in the larger context of approaches associated with GDPR compliance, but are not analysed as part of SotA relevant to this thesis given their nascent research output.

PDP4E

PDP43⁷⁶ (Methods and Tools for GDPR Compliance through Privacy and Data Protection Engineering) is an European H2020 project that aims to provide tools and guidance for incorporating privacy and data protection into software development life-cycles (SDLC) to implement data protection by design. Currently, the project lists one deliverable on its website, D2.1 (“D2.1 Multistakeholder Specifications” 2019), which provides information on legal analysis of GDPR in terms of requirements and obligations for software, and identifies roles and responsibilities within for SDLC.

DEFeND

DEFeND⁷⁷ (Data Privacy Governance for Supporting GDPR) is an European H2020 project that aims to create a platform for providing services to organisations regarding GDPR compliance. The platform will provide services regarding data management and governance, data breach reporting, process management, and GDPR planning and reporting. The peer reviewed publication (Piras et al. 2019) presents more details about the architecture and its components.

The Data Assessment Component (DAC) consists of Organisation Data Collection (ODC) module which uses an questionnaire to collect information about organisational scope, data processing, processes, and activities - and is used to evaluate the organisation with relevant aspects of GDPR. The questionnaire responses from ODC are given to Assessment Translator (ATr) module which converts them to an XML-schema in order to create Data Assessment Model (DAM) - a goal-based requirement engineering model of actors, assets, establishments and data flows.

The DAM is used by Data Privacy Analysis Component (DPAC) to perform analysis about DPIA, data minimisation, privacy-by-design/default, and threat mitigation. The outcome of analysis is a Data Privacy Model (DPC) which is utilised to specify and evaluate at design and run-time the operations of consent management, data access rights, security and privacy technologies. The project also aims to create a dashboard to provide organisations with control and monitoring of operations to achieve GDPR compliance, and to enable data subjects to interact with the platform based on consent.

PAPAYA

PAPAYA⁷⁸ (PlAtform for PrivAcY preserving data Analytics) is an European H2020 project that aims to provide privacy preserving techniques and technologies for performing analytics tasks on encrypted data by untrusted third-party data processors. The project uses obligations of GDPR to structure outcomes in terms of Privacy Enhancing Technologies (PETs) which are provided through an interoperable platform. The project focuses on application of privacy by design principle to provide usability, transparency, and auditability to end users regarding processing of their data. Information about the project is available through peer-reviewed publications⁷⁹.

SMOOTH

SMOOTH⁸⁰ is an European H2020 project that aims to assist micro enterprises become compliant with GDPR by designing and implementing tools for awareness about GDPR obligations and analysing their level of compliance. The project objectives include creation of a platform for automatic assessment of privacy protection documents (including privacy policies), stored data, and processing of personal data on websites or mobile apps to create a compliance report. Further details about the project are currently not available.

SODA

SODA⁸¹ (Scalable Oblivious Data Analytics) is an European H2020 project that aims to provide tools for performing analytics over encrypted data at large scales while providing compliance with GDPR. The project will utilise use-cases within health domain to demonstrate privacy-preserving aspects of its technologies. SODA incorporates requirements of GDPR and provides guarantees regarding compliance through use of its tools and technologies. The analysis of legal requirements arising from GDPR and role of SODA in addressing them is presented in deliverable D3.1 (Spindler, Horváth, and Dalby 2017). Further information about the project is available through peer-reviewed publications and public deliverables⁸².

DECODE

DECODE⁸³ is an European H2020 project that aims to provide tools for data ownership by using blockchain with attribute-based cryptography. The project will be piloted in Amsterdam and Barcelona and will focus on enabling citizens to manage and control data generated through IoT devices. The project objective is to provide data as a shared resource for collective benefit and crowd-sourced information. Smart contracts will be used to enable control of data and will be stored in a distributed ledger (such as blockchain). Information about the project is available through its public deliverables⁸⁴.

The specification of information required for legal compliance as well as processing is defined in terms of ‘entitlements’, which include personal data category, description, purpose, condition (alternate purpose), expiry date (storage duration). These are collected across use-cases, normalised to find commonalities, and utilised in smart policies to record information about processing. The deliverable D3.5 (Roio and Sachy 2018) describes collected entitlements from pilot use-cases in Barcelona. The analysis of legal requirements and their incorporation in the DECODE project is described in D1.8 (“D1.8 Legal Frameworks for Digital Commons DECODE OS and Legal Guidelines” 2017).

MOSAICrOWN

MOSAICrOWN⁸⁵ (Multi-Owner data Sharing for Analytics and Integration respecting Confidentiality and OWNer control) is an European H2020 project that aims to enable data sharing and collaborative analytics in multi-owner scenarios. Its objectives are to provide a data governance framework that captures and combines protection requirements specified by multiple parties, and provides protection techniques for enabling efficient and scalable data sharing and processing. The project intends to create an approach for combining selective encryption, blockchain, and smart contracts to enable data owners to leverage data markets to monetise their data in a con-trolled way.

PoSEID-on

POSEID-on⁸⁶ (Protection and control of Secured Information by means of a privacy Enhanced Dashboard) is an European H2020 project that aims to safeguard rights of data subjects while simultaneously supporting organisations in data management and processing by ensuring GDPR compliance. Its objective is to create a privacy enhancing dashboard for personal data protection using an implementation of permissioned blockchain and smart contracts to provide accountability, transparency, and compliance. The project aims to develop technologies for automated detection of unexpected and potentially harmful behaviours in order to monitor privacy risks and notify threats to data subjects during transactions. Information about the project is available through its public deliverables⁸⁷.

Deliverable D2.1 (“D2.1 - Use Cases Analysis and User Scenarios” 2018) provides information on use-cases, user stories, personal data required, and third parties involved. Deliverable D3.1 (“D3.1 PoSeID-on Blockchain - Interim Implementation” 2019) presents the architecture with information about smart contracts utilised on permissioned blockchain to support permissions regarding requesting, granting, revoking, notifying, checking, and accessing permissions regarding use of PII. Each permission event is logged to blockchain and consists of data processor, data subject, and personal data field involved. Deliverable D4.3 (“D4.3 Risk Management Module & Personal Data Analyser - Interim Implementation” 2019) describes use of natural language programming approaches to detect PII in stored data as a measure of risk detection and management.

3.7 Analysis

3.7.1 Overview of SotA

The analysis of state of the art was carried out using the methodology presented earlier in Section 3.1. The approaches were first analysed to identify relevance for categories of information identified in the methodology. Table 3.1 presents this information by using a check mark (✓) to indicate the approach uses or provides information about that topic, with its absence indicating that the approach does not address that topic or no information about its use could be found. The column headings represent identified categories of information, and represent - (T): type of work where PRJ indicates a research project and RES indicates research publication, (R): if it models GDPR clauses and concepts, (M): if it provides an ontology, (EA): if it represents information for ex-ante Compliance, (EP): if it represents information for ex-post compliance, (P): if it models activities, (C): if it represents consent, (Cm): if it evaluates compliance, (Rq): if it specifies requirements for GDPR compliance, and (O): it provides resources in an open and accessible manner.

Of the 44 approaches listed in the table, upcoming research projects are not considered part of state of the art and are therefore not analysed. The 5 approaches related to privacy policies and 2 approaches related to consent do not directly address GDPR compliance, but provide representation of information relevant to modelling of information. The analysis is primarily carried out over 29 approaches which directly address GDPR compliance. The following observations are made based on an overview of Table 3.1:

• Research Projects: Of 29 approaches presented as addressing GDPR, 9 are outcomes or part of a research project (column T). Of these 9 projects, 6 approaches are part of 12 that utilise semantic web and feature cross-collaboration in their research and outputs. If cross-collaborations between projects are consolidated under the project providing primary resources for GDPR compliance, 2 projects - SPECIAL and MIREL - are notable in their scope of utilising semantic web and produced resources.

  The research projects are primarily funded by European Union research grants for addressing or incorporating GDPR as a requirement. Given that the GDPR is an European regulation, it is not surprising to have research projects funded by EU for researching applications of technology for compliance. These projects represent dedicated resources in terms of funding and personnel, and feature collaboration between universities, research institutes, and industry - which includes participation of legal experts, authorities, and legal domain organisations.

  In terms of output, deliverables of research projects represent a wider consensus between stakeholders and evaluation in terms of use-cases that are provided by commercial partners. These provide valuable insights into stakeholder requirements and developed solutions within state of the art.

• Representation of GDPR clauses: Of 29 approaches addressing GDPR compliance, only three approaches provide a representation of GDPR (column R) and do so in a machine-readable format. Of these 3, MIREL and DAPRECO use PrOnto ontology and aligned resources produced by MIREL - and therefore can be consolidated into a single approach using PrOnto.

• Modelling of GDPR concepts: 20 of 29 approaches addressing GDPR compliance also model concepts from GDPR as an ontology or data model (column M). Additionally, all of 5 approaches involving privacy policies also provide concepts relevant to GDPR. The extent of concepts defined varies between each approach based on its aims and objectives. However, none of these approaches provide a glossary of terms or concepts associated with GDPR compliance. No approach indicates source of its concepts within GDPR except as textual annotations to a clause (e.g. Article 4-11) in some cases.

• Representing activities: 13 approaches represent and utilise information about activities associated with GDPR compliance (column P). Of these, 6 approaches utilise semantic web to represent information about processes and activities, while other 7 approaches utilise other forms of information representations.

• Ex-ante and Ex-post representations: 12 approaches represent information in ex-ante phase (column EA), and 10 approaches represent information in ex-post phase (column EP). Of these, 6 approaches represent information in both phases. The other 13 approaches do not specify any indication of which phase they represent or do not consider phases in their representations.

• Consent: Only 9 approaches represent information about consent based on GDPR (column C), of which 3 do so using semantic web. This information concerns attributes associated with request for consent, context of given consent, and information about its withdrawal. Additionally, two approaches specifically mentioned in context of consent (Grando et al. and Consent Receipt) do not address GDPR but provide information representation relevant to consent.

• Compliance Evaluation: Evaluation of compliance is carried out by 18 approaches (column Cm), with 8 of those utilising semantic web in some form.

• Suggestions and requirements: 9 approaches provide requirements or suggestions to achieve compliance (column Rq). Of these, 7 approaches produce suggestions after an evaluation of compliance.

• Open access to resources: Of 29 approaches, only 4 approaches have published their resources in an open and accessible format (column O). The other resources either provide information on their work through publications or project deliverables, and do not provide a link to access referenced resources.

Following these observations, a more detailed description of analysis is provided for areas identified in Section 3.1. These correspond to investigation of state of the art regarding relevance to research objectives.

3.7.2 Representation of GDPR

The overview presented in Table 3.1 shows only three approaches representing structure of GDPR and enabling machine-readable linking of information to specific parts of its text. Of these, two (MIREL and DAPRECO) utilise PrOnto (Palmirani, Martoni, et al. 2018b, 2018a) and are therefore consolidated into a single work for purposes of analysis. Therefore, there are only two distinct approaches for representation of GDPR in state of the art.

Table 3.2 presents an overview of these approaches, along with ELI ontology (“Council Conclusions Inviting the Introduction of the European Legislation Identifier (ELI)” 2012) used in publication of metadata associated with legislations including GDPR. The granularity of ELI ontology in representing metadata is limited to specifying information at document level, i.e. it defines GDPR as a legislation but does not provide metadata about its structure or contents. The EU Publication Office, which is in-charge of publishing legislations and maintains ELI ontology, has indicated⁸⁸ they are working on updates to ontology - these are represented in the table as ‘ELI+’ for descriptive purposes and completeness of analysis.

The table demonstrates that there are very few approaches working with machine-readable representations of GDPR, even when a large number of approaches utilise machine-readable formats for information associated with specifying information for compliance assessment. The table also shows that none of existing approaches address drawbacks of ELI, but instead utilise other vocabularies to achieve granularity regarding GDPR. For this, Agarwal et al. (Agarwal et al. 2018) use RDFS, while PrOnto uses Akoma Ntoso to represent hierarchy of text within GDPR. Apart from ELI, neither of other two resources are open and publicly accessible (row OA), and they do not use a persistent identifier (row PID) enabling sustained use over time. Also, no approach provides a glossary of terms utilised or defined by GDPR.

3.7.3 Representation of activities

The modelling of activities in SotA is elaborated in Table 3.3 in terms of its use in terms of phase (ex-ante or ex-post), concepts modelled, and representation. The column headings used are as follows - (Repr): representation of activities, (EA): Ex-ante modelling, (EP): Ex-post modelling, (Pu): Purpose, (Pr): Processing, (DS): Data Sharing, (Rp): Recipients, (St): Data Storage, (Rg): Rights, (LB): Legal Basis. The table uses a check mark (✓) to indicate that the approach represents a feature, while a blank denotes no information was found regarding its representation. The use of a blank is indicative of the possibility that a feature exists but is not published or accessible, or that it may be developed in future given ongoing work in these approaches.

The table shows use of BPMN notation and semantic web ontologies to model activities for GDPR, which includes reuse of existing ontologies PROV-O (Lebo et al. 2013) and PWO (Gangemi et al. 2017). The approaches model activities across both ex-ante and ex-post phases with 4 approaches modelling both phases.

Approaches modelling activities do not necessarily model their concepts to match or align with terminology utilised by GDPR. In cases where terminology is relevant to GDPR compliance, source of concepts and relationships used are not provided. Therefore, it is left up to an adopter’s ‘common sense’ to interpret terms correctly, and to manually align such ontologies with other legal resources.

In approaches that utilise PROV-O and PWO to represent activities, developed ontologies extend existing ontologies by defining concepts relevant to GDPR. As PROV-O represents provenance information, and therefore records information about activities that have already been carried out (in the past), use of PROV-O to represent ex-ante activities involves recording information of planned activities as a provenance record. PROV-O defines the concept Plan to represent a plan of activities, but it is not utilised by any approach. P-Plan, an extension of PROV-O which further expands on Plan to define templates of activities as workflows, is also not utilised by any approach. PWO, by comparison, represents workflows and is therefore capable of expressing ex-ante information. However, the use of PROV-O provides commonality and interoperability by virtue of being a standardised vocabulary.

Most approaches model some combination of purpose, processing, data item or category, sharing of data, recipients, and data storage within their representations. In comparison, representation of rights and legal basis associated with processing of personal data is not common with only a few approaches providing concepts for their representation. This is due to use of consent as an implicit legal basis in approaches with assumption that activities associated with rights are separate and distinct operations from processing activities.

3.7.4 Representation of Consent

Representation of consent in SotA is elaborated in Table 3.4, with the column headings as follows - (PD): Personal Data, (Pu): Purpose, (Pr): Processing, (Sh): Data Sharing, (St): Data Storage, (Rp): Recipients, (S): Data Source, (W): Withdrawal of consent, (D): Delegation, (V): Visualisation, (SE): Significant effects of processing, (Ct): Context, (T): Type. The table uses a check mark (✓) to indicate that whether an approach represents that feature, while a blank denotes that no information was found regarding its representation. The use of a blank is indicative of possibility where that exists but is not published or accessible, or that it may be developed in future given ongoing work in these approaches. Some upcoming research projects have been included based on published information about their use and representation of consent.

In analysed approaches, there is no specific vocabulary to represent all attributes of consent as required for compliance with GDPR. Instead, aspects of given consent are represented in view of compliance requirements - such as within provenance of process flows or as a record of given consent. In this, all approaches define personal data involved, and most define purpose of processing.

However, overall, approaches lack metadata regarding consent as required to evaluate its validity based on GDPR. Few approaches explicitly define processing activities involved, data storage, data sharing and recipients. Only one approach enables representation of data source, and few approaches define right to withdraw consent. Furthermore, only one approach defines significant effects of processing as required to be provided for obtaining valid consent. Only two approaches capture context such as medium associated with consent. Only one approach provides types of consent (explicit or implicit). No approach considers possibility of delegation - such as when a parent or guardian provides consent in lieu of a minor/child.

Given consent, which includes information about choices made by data subject, is required to be recorded in order to demonstrate compliance with GDPR. Furthermore, the mechanism used to provide and obtain consent is also required to be recorded in order to assess its validity with requirements of given consent under GDPR. Therefore, process flows associated with provision of consent choices and obtaining consent are required to be recorded and can utilise the same mechanism as for defining process flows regarding processing activities. In this, existing approaches combine the two process flows by implicitly assuming legal basis of their processing activity to be consent, but do not capture context of given consent. In comparison, Consent Receipt is specifically designed to capture a record of given consent as a receipt of transaction involving personal data. However, it does not contain required fields to express information about consent as required by GDPR.

From this, it is clear that existing state of the art does not provide sufficient means to represent information required to assess compliance of consent as defined by GDPR.

3.7.5 Querying of information associated with GDPR Compliance

The approaches described in state of the art do not provide guidelines or directions on querying of information as compared to representation of information and evaluation of compliance. Approaches that use RDF for information representation demonstrate or mention use of SPARQL for retrieval of information but do not provide evidence of practical applications of such queries being used to answer questions associated with compliance.

In comparison, approaches related to privacy policies focus on querying as part of their objective in retrieving relevant information from text of a privacy policy. In this, the UsablePrivacy project is notable in its use of SPARQL to retrieve information. Linden et al. demonstrate an approach that uses queries derived from GDPR-compliance checklists provided by ICO to identify coverage of GDPR within privacy policies (Linden et al. 2018).

Some research projects utilise legal experts to provide questions which are then translated into competency questions and used in development of ontologies and technology. Projects such as SPECIAL and MIREL demonstrate use of SPARQL queries derived from competency questions to retrieve information using developed ontologies. The details of this are sparse in their deliverables with some examples providing an insight into their use, but queries themselves are available for reuse. Additionally, none of existing approaches demonstrate an application of such queries to assist with compliance such as by adopting some authoritative document outlining compliance investigation process through queries or questionnaires.

From this, it can be summarised that while projects focus on automation of information representation and compliance evaluation, utilisation of querying to assist in compliance process has not seen significant development in legal compliance domain or has not been published in a reusable manner. Approaches involving privacy policies by comparison utilise querying to simplify information retrieval, its understanding, and demonstrate potential application towards legal compliance documentation.

3.7.6 Evaluation of GDPR Compliance

The evaluation of GDPR compliance in analysed approaches is summarised in Table 3.5, with column headings are as follows - (M): Method used for evaluation, (Sc): Scope of evaluation, (EA): Ex-Ante, (EP): Ex-post, (MR): Machine-readable outcome, (R): Suggests remedies and recommendations, (LG): Links results to GDPR. The table uses a check mark (✓) to indicate whether an approach represents that feature, while a blank denotes that no information was found regarding its representation. The use of a blank is indicative of a possibility that feature exists but is not published or accessible, or that it may be developed in future given ongoing work in these approaches. Some upcoming research projects have been included based on published information about their intended use of compliance evaluation methodologies.

From the table, most approaches (9 of 22) focus on evaluation of process flows followed by obligations fulfilment (6 of 22) and given consent (3 of 22). In terms of method or formalism used, semantic web (OWL, RuleML) show significant utilisation (8 of 22). It can be summarised that approaches evaluate compliance in either ex-ante (17 of 22) and ex-post (12 of 22) phase, with some approaches covering both phases (7 of 22). Most approaches (18 of 22) produce a machine-readable outcome or artefact from the evaluation process that can be persisted for documentation purposes. Some approaches suggest remedial measures (9 of 22) to correct or rectify lapses in compliance based on evaluation. Only three (of 22) approaches link the evaluation and its outcomes to GDPR. Based on this, it can be concluded that the state of the art provides a variety of approaches and methodologies for evaluating GDPR compliance in ex-ante and ex-post phases, and features remedial measures to suggest corrections to achieve compliance. It is also evident that most outcomes of compliance evaluation are not associated or linked with aspects of GDPR - which is a gap in terms of how compliance information should be documented.

One noticeable absence in these approaches is the use of a validation mechanism such as SHACL or ShEx for RDF data validation. In approaches that utilise semantic web representations of information, use of SHACL - a W3C specification - would provide the means to express and ensure correctness of information, validate it using constraints, and persist results in RDF. SHACL can also be used only for verification of information before its evaluation for GDPR compliance, or conversely for checking of results post-evaluation to record a state of compliance. The absence of SHACL, and information validation in general, is therefore a noticeable gap within state of the art.

While most approaches record a machine-readable representation of compliance evaluation, there is a lack of work regarding how such information can be used for documentation and demonstration of compliance. In approaches that link evaluations with GDPR, none explore the possibility of compliance coverage of GDPR carried out using recorded information. The links used in these approaches are either textual or based on interpretation of GDPR using developed ontologies - such as in PrOnto.

The source of compliance criteria within research projects are requirements and specifications provided by legal experts. The methodologies specified within these approaches do not provide access to specific queries or criteria fulfilled by its compliance evaluation. In case of research projects, evaluation of compliance is often driven by use-cases supplied by commercial partners which may restrict access to information deemed commercially sensitive. In approaches that produce recommendations or remedies from evaluation, it is unclear as to how these are recorded against evaluation and tracked in terms of changes made to processes across time - i.e. how compliance of a system evolves through these changes.

From this, it can be concluded that state of the art demonstrates use of technologies, and more specifically semantic web, in evaluation of GDPR compliance. It also demonstrates machine-readable artefacts as outcome of evaluations which are then used to suggest remedial measures to achieve compliance. These provide opportunities for utilising evaluation outcomes in documentation of ongoing compliance and documenting coverage of compliance GDPR. Furthermore, evaluation in these approaches is carried out under assumption of validity of existing data and does not consider absence of required information. This also provides an opportunity for assisting the compliance process by carrying out evaluations that check for validity of information in terms of existence and correctness.

3.8 Gaps and Opportunities for Further Work

The following list provides avenues for carrying out research based on opportunities identified from gaps within state of the art towards achieving the research objectives of this thesis:

1. Machine-readable representation of GDPR: A linked-data representation of GDPR based on existing ELI ontology with sufficient granularity to represent recitals and sub-paragraphs within articles. This will provide an ELI-compatible resource to link information with GDPR.

2. Glossary of terms and concepts associated with GDPR: A glossary of terms and concepts relevant to GDPR compliance that can provide interoperability between machine readable approaches, and using a machine-readable representation of GDPR to indicate source of information.

3. Representation of activities associated with processing of personal data in ex-ante and ex-post phases: A cohesive representation of activities across both ex-ante and ex-post phases that can indicate how an ex-ante activity acts as a plan for executing an ex-post activity. This will provide an indication of planned compliance in ex-ante stage, verification of compliant processing in ex-post stage, and evolution of compliance in a system across time based on changes to information in both phases. The PROV-O ontology provides a basis to represent activities using an standardised ontology based on similar use within state of the art.

4. Representation of consent information: An ontology for representing information associated with consent covering all requirements of GDPR. This can incorporate or reuse representation of activities from above to indicate activities associated with consent.

5. Demonstration using authoritative compliance queries: Implementing retrieval of information for compliance using questions and checklists published by data protection offices to demonstrate practical application of research in compliance process.

6. Validating information for compliance evaluation: An approach to validate information to ensure its existence and correctness in order for it to be used in evaluating compliance. The approach needs to incorporate both ex-ante and ex-post phases, and can incorporate relationship between the two phases to demonstrate ongoing compliance. The use of SHACL is ideal for this purpose given that it is a semantic web standard and has the ability to persist its results in RDF which provide opportunity to query and use them for creating compliance documentation linked to GDPR.

These gaps directly influenced the establishment of research objectives presented in Section 1.2.2 in terms of using semantic web technologies for information representtion, querying, and validation for GDPR compliance.

4 Analysing GDPR Compliance Requirements

The analysis of state of the art in Chapter 3 provided identification of opportunities for addressing the gaps within it. These opportunities relate to research objective RO3 regarding construction of ontologies, RO4 for querying, and RO5 for information validation. In order to achieve these, it is imperative to have an understanding of GDPR and its compliance requirements as required by research objective RO1. The requirement gathering process is shaped by the scope of research question - which for this thesis is representation of activities associated with processing of personal data and consent. The identified requirements then need to be expressed in a form which will facilitate representation of information as ontologies, its querying, and validation in compliance process. This is required to fulfil research objective RO2.

The approaches presented in SotA in Chapter 3 directly delve into obligations and requirements of data controllers to demonstrate compliance or towards data subject’s consent and rights. Since requirements of GDPR compliance are also influenced by other stakeholders such as processors and authorities which play an unspecified role in the context of information associated with compliance, such roles consist of interactions between stakeholders and involve communication of information such as instructions provided by a data controller to a processor. Therefore, along with requirements of compliance, it is also important to understand interactions between stakeholders, information involved in such interactions, and requirements of information in terms of its interoperability between them.

As an example, consider a data controller that can have any number of internal representations of information necessary to demonstrate compliance, but an investigation by a supervisory body requires such information to be provided as per their stated requirements in an mutually understandable form. Furthermore, a processor contracted by a controller may also be required to present information relevant in investigation of compliance - which would also need to be mutually understandable by the processor, controller, and investigating authority. When utilising technological solutions for management of compliance information, analysis of information interoperability requirements enable identifying applications of such solutions within a larger context comprised of multiple stakeholders involved in the compliance process.

This chapter therefore first presents an analysis of GDPR in terms of stakeholders and interoperability of information between them to construct a model of information interoperability in Section 4.1. The model provides an analysis of requirements in terms of information and interoperability from the perspective of interactions between entities. This provides an overview of information requirements which is used to find additional applications for existing information representation approaches and to identify gaps which can be addressed through future opportunities. Such analyses and requirements gathering related to GDPR also benefit the larger community and domain by providing information for standardisation activities in understanding role of information and its interoperability between stakeholders, such as those for DPVCG (see Section 1.4.6).

Following the above, Section 4.2 frames ‘compliance questions’ that provide information requirements necessary to evaluate compliance, with its methodology presented in Section 4.2.1, and Section 4.2.3 presenting assumptions and constraints that can be used to validate information for correctness and completeness. The use of compliance questions as competency questions in development and evaluation of ontologies is presented in Chapter 5, and use of constraints for validations is presented in Chapter 6.

4.1 Interoperability Model of Information based on GDPR

This section presents a model of interoperability for information associated with stakeholders based on an analysis of GDPR in terms of interactions between stakeholders and information involved in such interactions. The model enables understanding role of stakeholders in compliance process in terms of information requirements and provides a framework to establish relationship between interactions and information required for compliance. The model also provides motivation to incorporate interoperability as a core requirement within representations of information towards GDPR compliance. This provides context for development of ontologies presented in this thesis in terms of their intended application and usefulness to stakeholders associated with GDPR compliance.

The model serves to place contributions presented in this thesis within the larger context of stakeholders involved in GDPR compliance process. It guides the design and impact of ontologies presented in Chapter 5 in terms of establishing interoperability as a requirement based on potential exchange of information between stakeholders. Additionally, it also provides context about the roles and activities of stakeholders regarding information management and documentation for GDPR compliance.

The work described in this section was published within the interoperability and standardisation community as a conference paper (Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018e) which was later expanded upon in a journal article (Harshvardhan J. Pandit, Debruyne, et al. 2018) and a book chapter (Pandit et al. 2020).

Interoperability Model

The creation of a model is based on identifying categories of entities as defined within GDPR and identifying interactions between them. Figure 4.1 visualises interactions between entities, and consists of Data Subject (DS), Data Controller (DC), Data Processor (DP) and Supervisory Authority⁸⁹ (SA) as entities defined within GDPR. The points of interactions consist of potential information exchange between entities and are guided by requirements of compliance. For example, interaction between data subject and data controller consists of data subject providing personal data to controller, while the controller is required to provide a copy of provided personal data for fulfilment of rights granted by GDPR.

The model and information categories serve to provide a larger context of information requirements of GDPR and demonstrate areas for application of contributions presented in this thesis. They also provide future development and application of presented work to other areas of GDPR compliance. More specifically, they provide opportunities where developed work can be extended or re-applied to represent additional information regarding activities associated with GDPR compliance - such as for data breach records, carrying out rights, recording compliance procedures, or data processing agreements.

Information Categories

The analyses of information flows between entities (additional description presented in publications (Harshvardhan J. Pandit, Debruyne, et al. 2018; Harshvardhan J. Pandit, O’Sullivan, and Lewis 2018e)) provides categorises of information requirements as: provenance records, consent information, data processing agreements, compliance information, and seals/certifications - of which provenance records and consent have a direct bearing on the stated research objectives. Carrying out further investigation and analyses of interactions and information involved is out of scope for research presented in this thesis given the focus of research question on information about activities associated with processing of personal data and consent. To this end, analyses of information categories presented below concerns only categories of provenance and consent, and provides requirements for design of ontologies required by research objective RO3.

Provenance records

Provenance in this case refers to information about entities and activities involved in the compliance process where a record is required to be kept and exchanged for compliance purposes. For example, GDPR requires controllers and processors to maintain provenance records of processing activities carried out under their responsibility in order to maintain and demonstrate compliance to supervisory authorities. Provenance records are also required to be maintained to enable provision of rights to data subjects, and for information sharing between controllers and third parties.

The information stored within provenance records is related to demonstrating compliant processing of personal data and fulfilment of obligations towards demonstration of compliance. They are modelled within state of the art (see Chapter 3) variously as logs, life-cycles, workflows, activities, and process flows. The term provenance in this case refers to both ex-ante and ex-post phases and is indicative of provenance of information to specify its existence. Therefore provenance in ex-ante phase means record of a model or plan used to indicate future processing of personal data, while that in ex-post phase refers to record or log of processing.

Since provenance information as described above encompasses information about artefacts and processes related to compliance, sharing this information in an interoperable format with other entities benefits both in their obligations regarding compliance. For example, controllers and supervisory authorities sharing interoperable compliance documentation can use the same set of tools and approaches for interacting with information. Also, by recording processes associated with compliance as provenance records, the same interoperable methods can be used to maintain, document, and demonstrate compliance. This is especially useful where information is to be shared between joint controllers and processors that need to exchange plans of processing for agreement as well as logs for successful implementations.

Since a data controller is required to ensure their intended activities are compliant as well as maintain records of processing activities regarding use of personal data, provenance records to be documented consist of intended plan of processing activities and their execution. Similarly, provenance records of consent requests and provision also need to be maintained to demonstrate compliance. Given the similarity in requirements for maintaining provenance records for different reasons, it is beneficial to provide a singular interoperable representation of provenance activities in a form that can capture and represent all aspects of provenance records required for compliance.

Consent information

As per GDPR, consent is an assent or agreement by a data subject regarding processing of their personal data for specified purposes by one or more entities. For compliance, a controller must record information regarding how consent was requested and choices provided by a data subject as given consent. GDPR has several obligations and requirements when it comes to valid consent, with additional requirements depending on sensitivity of personal data and processing. Artefacts associated with choices offered for consent therefore need to be preserved to demonstrate the validity of consent obtained using those choices. Similarly, consent revocation or revisions also need to be recorded and linked to earlier instances of consent to demonstrate a change was valid as per requirements of GDPR.

The processes associated with offering consent choices, retrieving and recording given consent, enabling withdrawal of consent, and executing revocation in internal processes need to be documented for compliance by relevant controller(s). These are associated across both ex-ante and ex-post phases where consent choices, provision of right to withdrawal, and demonstrating utilisation of consent in processing are demonstrated as ex-ante measures while given consent and revoked consent are ex-post artefacts.

If consent is considered as an instance of personal data, the same information model used to document processing of personal data can be re-purposed or reused to represent activities associated with consent. In addition to this, activities need to capture different stages of consent and personal data by representing their life-cycles which involve processes and artefacts which use them or are dependant on them to indicate their evolution and use over time.

Stating interoperability as a requirement

The model and analyses of information flows between entities provides motivation for establishing interoperability in representation of information to be exchanged. As the scope of thesis focuses on representation of activities associated with processing of personal data and consent, requirements gathered from this analysis relate primarily to information associated with provenance of activities and information about consent. Within this scope, ensuring potential reuse towards other categories through future extensions is provided by developing an interoperable ontology by using standards that can be utilised to also represent data processing agreements and compliance agreements in the future. This involves using standards of RDF and OWL2 to represent ontologies along with reuse of existing standardised vocabularies such as PROV-O and ELI. In addition, the research also provides transparency by using terminology of GDPR in developed ontologies, indicating requirements used to shape design of ontology and indicating source of concepts within GDPR.

Representing provenance is not limited to representation of processing of personal data, but is also applicable to information about other categories - consent, data processing agreements, compliance, and certifications. Therefore, utilising the same or compatible representation in representing provenance across all use-cases has advantage towards cohesive management of all associated information for compliance - and provides an objective for future work in expanding contributions presented in this thesis.

With this motivation, the next parts of this chapter provide requirements gathered for representing information regarding processing of personal data and consent while also including other relevant information such as data breaches and provision of rights to indicate potential applicability and reuse of developed ontologies in representing information through provenance records for GDPR compliance.

4.2 Compliance Questions

This section presents ‘compliance questions’ whose answers provide information necessary for evaluating GDPR compliance. The questions are essential to development of information representations within compliance management systems by providing requirements for structuring of information and its validation. Within this thesis, they are used to guide development of ontologies as competency questions (see Chapter 5) and validation of information (see Chapter 6). The questions presented here are by no means exhaustive but represent gathered requirements from authoritative sources. As supervisory authorities and courts continue to clarify and interpret compliance requirements of GDPR, these questions are expected to change and expand in future.

4.2.1 Methodology

The questions were created by studying authoritative sources regarding GDPR compliance consisting of data protection commissions, legal experts and agencies - that have published guidelines and resources to assist organisations with the process of establishing and maintaining GDPR compliance. In this process, each identified clause or article of GDPR pertaining to the research question was formulated as a question, with the above mentioned sources providing indication on how the question should be interpreted and requirements for its compliance. The questions were derived from reading and understanding of compliance requirements and are intentionally expressed as a ‘simple question’ whose answering requires minimal information in order to determine requirements of such information towards constructing an ontological representation of it.

For questions presented in this thesis, following sources were used or referenced in addition to text of GDPR:

• Guidelines, clarifications, and discussions on interpretation of GDPR published by European Data Protection Board⁹⁰ (EDPB)

• Guidelines, clarifications, and discussions on interpretation of GDPR published by Article 29 Working Party⁹¹ and endorsed by EDPB

• Resources published Data Protection Commission⁹² (Ireland) - with particular focus on document ‘GDPR guidance for SMEs’⁹³

• Resources published by Information Commissioners Office⁹⁴ (United Kingdom), with particular use of ‘Data protection self assessment for organisations’⁹⁵

• Resources published by federated data protection offices in Germany, in particular the audit checklist published by Lower Saxony Data Protection Authority⁹⁶ self-translated from German to English⁹⁷

• Resources regarding GDPR compliance published by professional institutions within legal compliance domain, specifically - Nymity⁹⁸ and IAPP⁹⁹

• Executive and Court decisions regarding GDPR compliance, tracked through an online community service https://www.enforcementtracker.com/ which also denotes relevant articles of GDPR

The questions pertaining to consent and its associated processing activities were validated through consultation with a law professor at Trinity College Dublin who served as a legal domain expert and validated the questions and information required to answer them. This consisted of providing a spreadsheet containing categories of questions along with their assumptions and constraints as information requirements, with the feedback consisting of whether stated information was correct, utilised correct terminology, and changes in statements to suit legal interpretations. Other questions pertaining to processor obligations, data breach requirements, and rights were not validated through this process due to unavailability of expert and their lower priority in relevance to the research question.

The author of this thesis was part of an informal consultation on a real-world (details confidential) research project at MasterCard regarding creation of a semantic web ontology for expressing consent information based on requirements of the GDPR. The consultation consisted of identifying information for representing consent based on requirements of GDPR and designing an ontology to represent it. This process provided real-world requirements about management of consent information which had an influence on compliance questions associated with consent and design of GConsent ontology presented in Section 5.4.

The collected questions were rephrased and divided into smaller more granular questions towards establishment of information requirements and constraints. Each question was assigned an ID to enable tracking its use. Where possible, each question was associated with specific clauses of GDPR by denoting an article or recital relevant to it. Each question was analysed in terms of information requirements to identify assumptions that clarify interpretation of the question, and constraints that express a condition that can be tested and used to validate information. For each identified constraint, a failing test case was identified that did not satisfy the condition and could be used to test its validation.

The list of questions is presented in Section 4.2.2 with assumptions and constraints presented in Section 4.2.3. Along with compliance questions regarding activities associated with processing of personal data and consent, the list also contains questions about additional activities associated with right to be informed and reporting of data breach by controllers. These questions are used in development of ontologies that demonstrate application of a common approach to represent activities related to processing of personal data, consent, data breach, and provision of rights for GDPR compliance.

4.2.2 List of Questions

The questions are categorised based on the topic they focus on within the context of compliance. Where a question was directly derived from specific clause(s) a reference to the clause(s) is provided at end of sentence¹⁰⁰. In order to provide a context for application of questions within real world, a group of use-cases are provided in Section 4.2.2.1. An overview of compliance questions and their categorisation as follows:

• Section 4.2.2.2 Compliance questions pertaining to records of processing activities to be kept by controllers: CMQ.1 - CMQ.15.

• Section 4.2.2.3 Compliance questions pertaining to records of processing activities to be kept by processors: CMQ.16 - CMQ.25.

• Section 4.2.2.4 Compliance questions pertaining to legal basis of processing activities: CMQ.26 - CMQ.27.

• Section 4.2.2.5 Compliance questions pertaining to personal data: CMQ.28 - CMQ.34.

• Section 4.2.2.6 Compliance questions pertaining to given consent: CMQ.35 - CMQ.69.

• Section 4.2.2.7 Compliance questions pertaining to change in consent state: CMQ.70 - CMQ.87.

• Section 4.2.2.8 Compliance questions pertaining to provision of right to be informed: CMQ.88 - CMQ.105.

• Section 4.2.2.9 Compliance questions pertaining to reporting of data breach by controllers: CMQ.106 - CMQ.120.

4.2.2.1 Use-cases

To identify application of compliance questions in various scenarios within real world, 15 categories of use-cases were identified to determine necessary information required to identify their ontological representations. The use-cases are based on identifying information affecting compliance requirements and identifying variances which affect representations of that information. These were useful to guide development of ontologies by serving as test scenarios where an ontology could be applied and evaluated for representing information. These use-cases are not intended to be comprehensive or normative from a legal compliance point of view, but are helpful in understanding presented work by providing a context for their application.

A summary of these use-cases is as follow:

1. Obtaining / Declaring Consent (its state)

   1. The consent is given

   2. Consent was given, but is now invalidated (by the controller)

   3. Consent was given, but was withdrawn (by the Data Subject)

   4. Consent was requested (by the controller)

   5. Consent was requested, but was refused (by the Data Subject)

   6. Consent state is unknown (e.g. when importing data about consent)

2. Entity the consent is about

   1. The consent is about a Data Subject who is not a minor

   2. The consent is about a Data Subject who is a minor

3. Activity for Data Subject

   1. There was an age verification process associated with the consent (such as for minors)

   2. There was an identity verification process associated with the consent

4. Entity that provided consent

   1. Consent was provided by the Data Subject it is about

   2. Consent was not provided by the Data Subject it is about, but was provided by a Delegation

      1. Consent in the Delegation was provided by another Data Subject

      2. Consent in the Delegation was provided by a Person

      3. Consent in the Delegation was provided by another Delegation

5. Role within Delegation

   1. Entity is the Parent/Guardian of the Data Subject

   2. Entity is a third-party to the Data Subject

6. Activity of Delegation

   1. There was some verification process to assert the authentication of the delegation

7. Personal Data associated with consent

   1. Consent was given for specific instances of personal data e.g. John/Jane Doe

   2. Consent was given for categories of personal data e.g. Name

8. Medium of Consent

   1. consent is given via a web-form

   2. consent is given as a signed paper document

   3. consent is given as a verbal confirmation

   4. consent is given implicitly in some form (medium)

   5. consent is given via delegation in some form (medium)

9. Activity responsible for consent

   1. Activity created consent as a new entity

   2. Activity modified existing consent

10. Previous consent and relationship

    1. Consent has no previous instance

    2. Consent has a previous instance and replaces it

11. Differences between consent instances

    1. Something changes between two consent instances (e.g. personal data category is added)

12. Time constraints

    1. consent expires (has a tangible expiry such as a specific date or duration)

    2. consent does not expire (is valid for “as long as required”)

13. Third party Association

    1. Personal Data is collected from a third party

    2. Personal Data is stored with a third party (processor)

    3. Personal Data is shared with a third party

    4. Processing involves third party

    5. Purpose involves third party

14. Role of Third Party

    1. Third Party is a Processor contracted by the Controller

    2. Third Party is another Controller

    3. Third Party is another entity (regulatory/supervisory/governmental)

15. Storage Duration and Locations for Personal Data

    1. Data is stored for a fixed time (specific instance or duration)

    2. Data is stored for an indefinite duration (“for as long as required”)

4.2.2.2 Compliance questions pertaining to records of processing activities to be kept by controllers

1. How are the records of processing activities maintained? (R82,A30,A30-3)

2. What is the name and identity of the controller(s) and their representatives/DPOs? (A30-1a)

3. What are the purposes of processing? (A30-1b)

4. What are the categories of data subjects? (A30-1c)

5. What are the categories of personal data? (A30-1c)

6. Is data shared?

7. If data is shared, what are the categories of recipients to whom the personal data is or will be disclosed? (A30-1d)

8. If data is shared, what are the identities of the recipients to whom the data is or will be disclosed? (A30-1d,A30-1e)

9. If data is shared, are the recipients to whom the data is or will be disclosed based in a Third Country or International Organisation? (A30-1e)

10. If data is shared, and the recipients are in a Third Country or International Organisation, what are the safeguards associated with data transfer? (A30-1e)

11. Is data stored?

12. Where data is stored, its erasure is based on what criteria: time limit or condition or event?

13. Where data is stored, what are the time limits or conditions or events for erasure for different categories of data? (A30-1f)

14. What are the technical and organisational security measures w.r.t to the processing of personal data? (A30-1g)

15. Where data is shared, what are the purposes for sharing of personal data with the recipients?

4.2.2.3 Compliance questions pertaining to records of processing activities to be kept by processors

1. How are the records of processing activities maintained? (R82,A30,A30-3)

2. What is the name and identity of the processor(s) and their representatives/DPOs? (A30-1a)

3. What is the name and identity of the controller(s) the processor is acting on behalf of? (A30-2a)

4. What are the categories of processing carried out on behalf of the controller? (A30-2b)

5. If data is shared, what are the categories of recipients to whom the personal data is or will be disclosed? (A30-1d)

6. If data is shared, what are the identities of the recipients to whom the data is or will be disclosed? (A30-1d,A30-1e)

7. If data is shared, are the recipients to whom the data is or will be disclosed based in a Third Country or International Organisation? (A30-1e)

8. If data is shared, and the recipients are in a Third Country or International Organisation, what are the safeguards associated with data transfer? (A30-1e)

9. What are the technical and organisational security measures w.r.t to the processing of personal data? (A30-1g)

10. Where data is shared, what are the purposes for sharing of personal data with the recipients?

4.2.2.4 Compliance questions pertaining to legal basis of processing activities

1. What is the legal basis for processing of data?

2. What is the legal basis for the purpose for processing of data?

4.2.2.5 Compliance questions pertaining to personal data

1. What are the sources of personal data?

2. What personal data are collected from the data subject?

3. Where personal data are not collected from the data subject, what are their sources?

4. Where data has been anonymised, what techniques were used for anonymisation?

5. Can pseudo-anonymised data be de-anonymised by the organisation using information it already possesses or is available to it?

6. Where personal data is collected, is it pseudo-anonymous?

7. What are the special categories of personal data being processed?

4.2.2.6 Compliance questions pertaining to given consent

1. Who is the Data Subject associated with consent? (A4-11)

2. What are the Personal Data associated with consent? (R32,A4-11)

3. What are the Purposes associated with consent? (R32,R42)

4. What are the Data Processing associated with consent? (R32,A4-11)

5. What is the current Status of consent? (A7-3)

6. Who are the Data Controllers associated with consent?

7. Who provided consent? (A7-2)

8. Was consent provided by Delegation? (A8-c)

9. If consent was provided by Delegation, what was the role played by Delegate with respect to the Data Subject?

10. If consent was provided by Delegation, how was the delegation executed?

11. If consent was provided by Delegation, how was the delegate authenticated? (A8-2)

12. Who was the consent given to?

13. If consent was not given to the Data Controller, what is the relationship between the entity it was provided to and the Data Controller?

14. How was the consent given/obtained?

15. What artefacts were involved in the giving/obtaining of consent?

16. What were the choices provided for consent?

17. What was the statement or affirmative action indicating given consent?

18. How was the right to withdraw consent communicated to the data subject?

19. At what location was the consent given?

20. What is the medium associated with consent? (R32,A7-2)

21. What is the timestamp associated with the consent?

22. What is the expiry of the consent?

23. Is the purpose or processing associated with a third party?

24. What is the role played by the third party in the purpose or processing?

25. Does the processing of data involve storage of data?

26. If personal data is being stored, what is the duration of storage for Personal Data?

27. If personal data is being stored, what is the location of storage?

28. Are processing associated with consent of automated nature? (R71,A9-2c,A22-2c)

29. Does the processing of data involve transfer to a Third Country or International Organisation? (R111,A49-1a)

30. If processing of data involves transfer to a Third Country or International Organisation, what is the identity of the Third Country or International Organisation?

31. Do the personal data associated with consent belong to a special category? (R51,A8-2a)

32. How is personal data associated or linked to the data subject?

33. Is the Data Subject of legal age to provide their own consent? (A8)

34. What are the specific laws that determine the legal age to provide consent? (A8-1)

35. Does the Data Subject have a specific relationship with the Data Controller? (R43)

4.2.2.7 Compliance questions pertaining to change in consent state

In this, the definition of change in consent is where the state/status of consent is changed. Example: unknown to not asked or not given, from given to withdrawn, from given to invalidated. Changes where the result is given consent or obtained consent where none existed is considered as given consent with compliance questions listed in the previous section.

1. Who is the Data Subject associated with consent? (A4-11)

2. What are the Personal Data associated with consent? (R32,A4-11)

3. What are the Purposes associated with consent? (R32,R42)

4. What are the Data Processing associated with consent? (R32,A4-11)

5. What is the current state/status of consent? (A7-3)

6. Who are the Data Controllers associated with consent?

7. Who changed the state/status of consent?

8. Was consent changed by Delegation?

9. If consent was changed by Delegation, what was the role played by Delegate with respect to the Data Subject?

10. If consent was changed by Delegation, how was the delegation executed?

11. If consent was changed by Delegation, how was the delegate authenticated? (A8-2)

12. How was the consent state/status changed?

13. What artefacts were involved in the change in state/status of consent?

14. If change in consent was done by the Data Subject, what was the statement or affirmative action indicating change to their consent?

15. At what location was the consent changed?

16. What is the medium associated with change in consent? (R32,A7-2)

17. What is the timestamp associated with the consent?

18. If the current state/status of consent is valid for processing, what is the expiry of the consent?

4.2.2.8 Compliance questions pertaining to provision of right to be informed

1. How was information relevant for the right to be informed provided to the data subjects?

2. When was the information relevant to right to be informed was provided to the data subject?

3. Was the name and contact details of the controller’s representative provided to the data subject under the right to be informed?

4. Was the name and contact details of the DPO provided to the data subject under the right to be informed?

5. Was the purposes for processing provided to the data subject under the right to be informed?

6. Was the legal basis for processing provided to the data subject under the right to be informed?

7. Where the legal basis for processing was legitimate interest, was this communicated to the data subject under the right to be informed?

8. If personal data is not obtained from the data subject, were the categories of personal data obtained communicated to the data subject under the right to be informed?

9. If personal data is not obtained from the data subject, were the sources of data communicated to the data subject under the right to be informed?

10. Where personal data is shared, were the recipients or categories of recipients communicated to the data subject under the right to be informed?

11. If personal data is transferred to a third country or international organisation, were the identity of the third country or international organisation communicated to the data subject under the right to be informed?

12. Where personal data is stored, were the retention period communicated to the data subject under the right to be informed?

13. Were the rights available communicated to the data subject under the right to be informed?

14. If the data subject provided consent, was the right to withdraw consent provided under the right to be informed?

15. Was the right to lodge a complaint with a supervisory authority provided to the data subject under the right to be informed?

16. Where personal data needs to be provided under statutory or contractual obligation, was this communicated to the data subject under the right to be informed?

17. Where personal data needs to be provided under statutory or contractual obligation, and if this data needs to be obtained from the data subject, was this communicated to the data subject under the right to be informed?

18. Where automated-decision making, including profiling is used, was this communicated to the data subject under the right to be informed?

4.2.2.9 Compliance questions pertaining to reporting of data breach by controllers

1. When did the data breach occur?

2. When did the controller become aware of the data breach? (R85,R33-1)

3. Was the data breach notified to the supervisory authority?

4. When was the notification of data breach provided to the supervisory authority? (R85)

5. How was the notification of data breach provided to the supervisory authority? (R85,R33-1)

6. Is the data breach likely to result in a high risk to the rights and freedoms of the natural person whose data is associated with it? (R86,A33-1,A34-1)

7. Who are the data subjects whose personal data are associated with the data breach?

8. Was the data breach notified to the data subjects?

9. When was the notification of data breach provided to the data subjects?

10. How was the notification of data breach provided to the data subjects? (R85,R33-1)

11. How did the notification of data breach to the data subject provide information about the data breach? (R86,A34-2)

12. How did the notification of data breach to the data subject provide information about mitigating potential effects? (R86,A34-2)

13. What data was involved in the data breach?

14. What technical measures were in place for the protection of data involved in the data breach? (R88)

15. What steps were taken to prevent or mitigate the effects of the data breach?

4.2.3 Assumptions & Constraints

An assumption is defined as information or condition that always holds true and is useful in the interpretation of the compliance question. A constraint is defined as a condition that the information pertaining to compliance question must satisfy in order for it to be valid. The assumptions and constraints are listed with reference to the relevant compliance question at the end in brackets. An overview of the assumptions and constraints based on the categories of compliance questions is as follows:

• Section 4.2.2.2 Compliance questions pertaining to records of processing activities to be kept by controllers: CMQ.1 - CMQ.15 has Assumptions A.1 - A.5 and Constraints C.1 - C.18

• Section 4.2.2.3 Compliance questions pertaining to records of processing activities to be kept by processors: CMQ.16 - CMQ.25 has Constraints C.16 - C.32

• Section 4.2.2.4 Compliance questions pertaining to legal basis of processing activities: CMQ.26 - CMQ.27 has Assumptions A.6 and Constraints C.33 - C.34

• Section 4.2.2.5 Compliance questions pertaining to personal data: CMQ.28 - CMQ.34 has Assumptions A.7 and Constraints C.35 - C.38

• Section 4.2.2.6 Compliance questions pertaining to given consent: CMQ.35 - CMQ.69 has Assumptions A.8 - A.28 and Constraints C.39 - C.69

• Section 4.2.2.7 Compliance questions pertaining to change in consent state: CMQ.70 - CMQ.87 has Assumptions A.30 - A.39 and Constraints C.70 - C.87

• Section 4.2.2.8 Compliance questions pertaining to provision of right to be informed: CMQ.88 - CMQ.105 has Constraints C.88 - C.113

• Section 4.2.2.9 Compliance questions pertaining to reporting of data breach by controllers: CMQ.106 - CMQ.120 has Constraints C.114 - C.130

4.2.3.1 Assumptions

1. Processing activities as a whole can involve multiple controllers - (CMQ2)

2. Data recipient categories refer to a collection or abstraction of recipients based on some context such as purpose e.g. “our ad partners” or requirement e.g. “law agencies” - (CMQ8)

3. Data recipients cannot be a collective or a group whose identity cannot be represented as a list of its members e.g. “our partners” vs “our partners – A, B, C” - (CMQ9)

4. Identity of the recipients does not need to be associated with the processing record if category of recipients is already documented. However, the identity of recipients within the category at that point of time must be recorded (somewhere). - (CMQ10)

5. Where data is stored, its erasure can depend on a condition or an event e.g. “XX days after your last sign-in”, or “as long as your account is active” - (CMQ12)

6. Processing carried out for a specific purpose adopts the legal basis of the purpose - (CMQ26)

7. Personal data may not have the source information associated with it directly. It must have some link (chain, path) to the information and its source from which it was obtained. - (CMQ28)

8. If there are multiple categories of personal data, consent is granted for all (union) of them - (CMQ36)

9. If a consent is given for multiple purposes, consent is considered given for all (union) of them - (CMQ37)

10. If a consent is given for multiple processing, consent is considered given for all (union) of them - (CMQ38)

11. Valid status of consent are when it is given (explicitly or implicitly) by the data subject, or by delegation - (CMQ39)

12. Invalid status of consent are when it its status is unknown, refused, not offered, withdrawn, invalidated, terminated, or expired. - (CMQ39)

13. The status of consent indicates whether it can be used as a legal basis for processing - (CMQ39)

14. Consent provided by a Person that is not the Data Subject is consent by Delegation - (CMQ41)

15. A delegation can involve another delegation for the provision of consent - (CMQ42)

16. If consent is provided to an actor not the data controller associated with consent, the actor is considered as acting on behalf of the controller - (CMQ46)

17. Specifying location for obtained consent is optional - (CMQ53)

18. Specifying medium for obtained consent is optional - (CMQ54)

19. Consent may not have a tangible expiry - (CMQ56)

20. Consent may have multiple forms of expiry depending on conditions or events - (CMQ56)

21. A purpose or processing may be associated with zero or more third parties - (CMQ57)

22. Processing of data may involve storage of data - (CMQ59)

23. Different personal data, processing, or purpose may have different storage of data - (CMQ60)

24. Storage duration may not be a tangible instance in time, it can depend on conditions or event - (CMQ60)

25. Processing may involve transfer of data to a third country or international organisation - (CMQ63)

26. Personal data associated with consent may belong to a special category - (CMQ65)

27. A data subject may be a minor or a child - (CMQ67)

28. The data subject may have a relationship of relevance with the Data Controller - (CMQ69)

29. If there are multiple categories of personal data, consent is granted for all (union) of them - (CMQ71)

30. If a consent is given for multiple purposes, consent is considered given for all (union) of them - (CMQ72)

31. If a consent is given for multiple processing, consent is considered given for all (union) of them - (CMQ73)

32. Valid status of consent are when it is given (explicitly or implicitly) by the data subject, or by delegation - (CMQ74)

33. Invalid status of consent are when it its status is unknown, refused, not offered, withdrawn, invalidated, terminated, or expired. - (CMQ74)

34. The status of consent indicates whether it can be used as a legal basis for processing - (CMQ74)

35. Consent state/status can be changed by Delegation - (CMQ76)

36. A delegation can involve another delegation for the provision of consent - (CMQ77)

37. Specifying location for changed consent is optional - (CMQ84)

38. Specifying medium for changed consent is optional - (CMQ85)

39. Consent may not have a tangible expiry - (CMQ87)

40. Consent may have multiple forms of expiry depending on conditions or events - (CMQ87)

4.2.3.2 Constraints

1. Processing carried out by a controller must have information on how its records are being maintained - (CMQ1)

2. Records of processing activity under the responsibility of a controller must have the names/identity of all associated controllers - (CMQ2)

3. Each controller associated record of processing activities under the responsibility of (this) controller must have one or more contact details - (CMQ3)

4. Each controller associated with records of processing activities under the responsibility of (this) controller must have the identity and one or more contact details of the DPO - (CMQ4)

5. Processing under the responsibility of a controller must have one or more purposes of processing associated with it - (CMQ3)

6. Processing under the responsibility of a controller must have one or more categories of data subjects associated with it - (CMQ4)

7. Processing under the responsibility of a controller must have one or more categories of personal data associated with it - (CMQ5)

8. Processing under the responsibility of a controller must explicitly state when data is shared - (CMQ6)

9. Processing under the responsibility of a controller where data is shared must have the category of recipients to whom the data is or will be disclosed - (CMQ7)

10. Processing under the responsibility of a controller where data is shared must have the identities of recipients to whom the data is or will be disclosed - (CMQ8)

11. Processing under the responsibility of a controller where the recipients to whom the data is or will be disclosed are based in a Third Country or International Organisation must explicitly specified it as such - (CMQ9)

12. Processing under the responsibility of a controller must specify the identity of the Third Country or International Organisation to whom the data is or will be disclosed - (CMQ10)

13. Processing under the responsibility of a controller where personal data is transferred to a third country or an international organisation must specify the safeguards present for the transfer - (CMQ10)

14. Processing under the responsibility of a controller must explicitly state when data is stored - (CMQ11)

15. Processing under the responsibility of a controller where data is stored must specify the criteria for its erasure - (CMQ12)

16. Each category of data associated with a record of processing must have a time limit or a condition or an event specified for its erasure - (CMQ13)

17. The record of processing must have technical and organisational security measures associated with it - (CMQ14)

18. Every sharing of personal data must specify the purposes of sharing with the recipients - (CMQ15)

19. Every processing must have information on how its records are being maintained - (CMQ16)

20. Each record of processing activity under the responsibility of a processor must have the names/identity of all associated processors under its responsibility - (CMQ17)

21. Each processor associated with a record of processing activity under the responsibility of a processor must have one or more contact details - (CMQ17)

22. Each processor associated with a record of processing activity under the responsibility of a processor must have the identity and one or more contact details of the DPO - (CMQ17)

23. Each record of processing activity under the responsibility of a processor must have the names/identity of the controller(s) it is acting on behalf of - (CMQ18)

24. Each record of processing activity under the responsibility of a processor must have name and contact details of the controller’s representative and DPO - (CMQ18)

25. Each record of processing carried out by a processor on behalf of a controller must specify categories of processing associated with it - (CMQ19)

26. Each record of processing under the responsibility of a processor where data is shared must have the identity of recipients to whom the data is or will be disclosed - (CMQ20)

27. The identities of the recipients to whom data is or will be disclosed must be specified - (CMQ21)

28. If the recipients to whom the data is or will be disclosed are based in a Third Country, or International Organisation, this must be specified as such - (CMQ22)

29. The identity of the Third Country or International Organisation to whom the data is or will be disclosed must be specified - (CMQ22)

30. The transfer of personal data to a third country or an international organisation must specify its safeguards - (CMQ23)

31. The record of processing must have technical and organisational security measures associated with it - (CMQ24)

32. Every sharing of personal data must specify the purposes of sharing with the recipients - (CMQ25)

33. Each processing of data must have an associated legal basis - (CMQ26)

34. Each purpose for processing of data must have an associated legal basis - (CMQ27)

35. Each personal data must have information about its source - (CMQ28)

36. Personal data collected from the data subject must be clearly specified as such - (CMQ29)

37. Every anonymisation of data must specify the techniques used for anonymisation - (CMQ31)

38. Where pseudo-anonymised data can be de-anonymised by the organisation, it must be clearly specified as such - (CMQ32)

39. Every consent must be associated with only one Data Subject - (CMQ35)

40. Every consent must have one or more categories or types of personal data associated with it - (CMQ36)

41. Every consent must have one or more purposes associated with it - (CMQ37)

42. Every consent must have one or more processing associated with it - (CMQ38)

43. Every consent must have one and only one state/status - (CMQ39)

44. Every consent must be associated with one or more Controllers - (CMQ40)

45. Consent is given by exactly one Person - (CMQ41)

46. Consent provided by delegation must be clearly specified as such - (CMQ42)

47. Consent provided by delegation must have a single chain of delegation - (CMQ42)

48. Delegate in a consent has to play one or more roles that are associated with the Data Subject - (CMQ43)

49. Every delegation must have information on how it was executed - (CMQ44)

50. A delegate must be authenticated to act on behalf of the data subject in a delegation - (CMQ45)

51. Every consent must have information on who it was provided to - (CMQ46)

52. An entity collecting consent on behalf of the Data Controller must have information on the relationship - (CMQ47)

53. Every given consent must have information on how it was obtained - (CMQ48)

54. Every consent must have some artefacts associated with how it was given/obtained - (CMQ49)

55. Every consent must have information on what choices were provided to the data subject - (CMQ50)

56. Every consent must have a statement or affirmative action indicating given consent - (CMQ51)

57. Every consent must have information on how the right to withdraw was communicated - (CMQ52)

58. Consent must not have more than one location it was provided at - (CMQ53)

59. Consent must not have more than one medium it was provided in - (CMQ54)

60. Every consent must have a timestamp indicating when it was given/obtained - (CMQ55)

61. Every purpose or processing associated with Third Party must have information on the role played by the Third Party - (CMQ58)

62. If data is being stored, it must have information on how long it will be stored for - (CMQ60)

63. Every storage of data must have information on its storage location - (CMQ61)

64. Processing of personal data which is of automated nature must be clearly indicated as such - (CMQ62)

65. Every processing of data involving transfer to a third country or international organisation must have the identity of the third country or international organisation specified - (CMQ64)

66. Every personal data belonging to a special category must be clearly indicated as such - (CMQ65)

67. Every personal data must have information on one or more identifiers that link it to a particular data subject - (CMQ66)

68. A data subject who is not of legal age to provide their own consent must be clearly indicated as such - (CMQ67)

69. There must be information on the relevant laws that determine the legal age of consent - (CMQ68)

70. Every consent must be associated with only one Data Subject - (CMQ70)

71. Every consent must have one or more categories or types of personal data associated with it - (CMQ71)

72. Every consent must have one or more purposes associated with it - (CMQ72)

73. Every consent must have one or more processing associated with it - (CMQ73)

74. Every consent must have one and only one state/status - (CMQ74)

75. Every consent must be associated with one or more Controllers - (CMQ75)

76. Every change in the state/status of consent must be attributed to one or more agents - (CMQ76)

77. Consent changed by delegation must be clearly specified as such - (CMQ77)

78. Consent provided by delegation must have a single chain of delegation - (CMQ77)

79. Delegate in a consent has to play one or more roles that are associated with the Data Subject - (CMQ78)

80. Every delegation must have information on how it was executed - (CMQ79)

81. A delegate must be authenticated to act on behalf of the data subject in a delegation - (CMQ80)

82. Every change in the state/status of consent must have information on how it was changed - (CMQ81)

83. Every change in state/status of consent must have some artefacts associated with how it was changed - (CMQ82)

84. Every change to consent by the Data Subject must have a statement or affirmative action indicating the change - (CMQ83)

85. Consent must not have more than one location it was changed at - (CMQ84)

86. Consent must not have more than one medium it was changed in - (CMQ85)

87. Every consent must have a timestamp indicating when it was changed - (CMQ86)

88. Information about how the right to be informed was implemented must be specified - (CMQ88)

89. Information part of right to be informed must be concise - (CMQ88)

90. Information part of right to be informed must be transparent - (CMQ88)

91. Information part of right to be informed must be intelligible - (CMQ88)

92. Information part of right to be informed must be easily accessible - (CMQ88)

93. Information part of right to be informed must use clear and plain language - (CMQ88)

94. When the information relevant to the right to be informed was provided to the data subject must be specified - (CMQ89)

95. Information relevant to the right to be informed was provided to the data subject must be provided at most within one month of obtaining the data - (CMQ89)

96. If information relevant to the right to be informed is to be communicated to the data subject, it must be provided at most during the first communication with the data subject - (CMQ89)

97. If data is to be disclosed to someone else, information relevant to the right to be informed must be communicated to the data subject at latest when the data is disclosed - (CMQ89)

98. Information part of right to be informed must contain name and contact details of the controller’s representative - (CMQ90)

99. Information part of right to be informed must contain name and contact details of the DPO - (CMQ91)

100. Information part of right to be informed must contain purposes for processing - (CMQ92)

101. Information part of right to be informed must contain legal basis for processing - (CMQ93)

102. Information part of right to be informed must specify processing whose legal basis is legitimate interest - (CMQ94)

103. Where personal data is not obtained from the data subject, information part of right to be informed must specify categories of personal data obtained - (CMQ95)

104. Where personal data is not obtained from the data subject, information part of right to be informed must specify the sources of such data - (CMQ96)

105. Where personal data is shared, information part of right to be informed must specify the identity of the recipients or categories of recipients - (CMQ97)

106. Where personal data is transferred to a third country or international organisation, information part of right to be informed must specify the identity of the third country or international organisation - (CMQ98)

107. Where personal data is stored, information part of right to be informed must specify the retention period - (CMQ99)

108. Information part of right to be informed must specify the available rights - (CMQ100)

109. Where consent is obtained from the data subject, information part of right to be informed must specify the right to withdraw consent - (CMQ101)

110. Information part of right to be informed must specify right to lodge a complaint with the supervisory authority - (CMQ102)

111. Information part of right to be informed must specify where personal data is obtained under statutory or contractual obligation, - (CMQ103)

112. Information part of right to be informed must specify where personal data is obtained from the data subject under statutory or contractual obligation - (CMQ104)

113. Information part of right to be informed must specify if automated-decision making, including profiling is being used - (CMQ105)

114. Every record of a data breach must have a timestamp indicating when it occurred - (CMQ106)

115. Every record of a data breach must have a timestamp indicating when the controller became aware of the breach - (CMQ107)

116. Every data breach must be notified to the supervisory authority - (CMQ108)

117. Every record of a data breach must have a timestamp indicating when it was notified to the supervisory authority - (CMQ109)

118. Every record of a data breach must specify how the notification was provided to the supervisory authority - (CMQ110)

119. Every record of a data breach must specify the identities of the supervisory authorities it was communicated to - (CMQ110)

120. Every record of a data breach must specify if it is likely to result in a high risk to the rights and freedoms of the natural persons whose data is associated with it - (CMQ111)

121. Every record of a data breach must specify the process used to determine if it is likely to result in a high risk to the rights and freedoms of the natural persons whose data is associated with it - (CMQ111)

122. Every data breach must specify the data subjects affected by the data breach - (CMQ112)

123. Every data breach must be notified to the data subjects whose personal data was associated with the breach - (CMQ113)

124. Every record of a data breach must have a timestamp indicating when it was notified to the data subjects - (CMQ114)

125. Every record of a data breach must specify how the notification was provided to the data subjects - (CMQ115)

126. Every notification of a data breach to the data subject must provide information about the data breach - (CMQ116)

127. Every notification of a data breach to the data subject must provide information about mitigating potential effects of the data breach - (CMQ117)

128. Every record of a data breach must specify the data involved in the breach - (CMQ118)

129. Every record of a data breach must specify the technical measures for the protection of data involved in the data breach - (CMQ119)

130. Every record of a data breach must specify the steps taken to prevent or mitigate the effects of the data breach - (CMQ120)

Summary

Through this chapter, an analyses of information associated with GDPR and its compliance was presented. Section 4.1 presented a model of information interoperability between entities as defined by requirements for GDPR compliance. The model provides an analyses of information requirements and information flows between different entities, and categorisation of information requirements as provenance records, consent information, compliance documentation, data processing agreements, and use of seals/certifications. Its analyses also provides a strong motivation towards adopting a common information model for representation of all activities associated with GDPR compliance.

Following this, Section 4.2 presented ‘compliance questions’ which aim to retrieve information relevant in evaluation of GDPR compliance. The section also provides the methodology used to formulate questions from authoritative sources. The compliance questions are accompanied with identification of assumptions and constraints which are useful towards establishment of information requirements and its validation.

The next chapter presents ontologies developed for addressing research objective RO3, and which utilise compliance questions presented in this chapter as competency questions in their ontology engineering process.

5 Representing Information for GDPR Compliance using Ontologies

This chapter presents OWL2 ontologies developed to fulfil research objective RO3 defined in Section 1.2.2 regarding representation of information. The chapter first presents a more detailed description of the methodology in Section 1.3.3 regarding developing and evaluating ontologies based on summary presented earlier in Section 5.1. It then presents the ontologies of: (i) GDPRtEXT (Section 5.2) which provides a linked data representation of GDPR text and a glossary of GDPR compliance concepts, and which satisfies research objective RO3(a) by providing an ontological representation of concepts and text of GDPR; (ii) GDPRov Section 5.3 which enables representing provenance of activities associated with personal data and consent in ex-ante and ex-post phases, and fulfils research objective RO3(b); and (iii) GConsent (Section 5.4) which enables representing information regarding consent, and fulfils research objective RO3(c).

Each ontology is presented with a summary of its motivation, engineering process, and dissemination. Ontologies are presented with their evaluation based on the extent to which they satisfy the competency questions used in their development and through comparison with analysed approaches in state of the art in Section 3.7.

In addition to these, Data Privacy Vocabulary (DPV), initially presented in Section 1.4.6, is also included as an external contribution of the thesis based on work done by author of this thesis within the W3C Data Protection Vocabularies and Controls Community Group (DPVCG), and overlap of DPV with the research presented. Section 5.5 presents an overview of DPV and compares it with GDPRtEXT, GDPRov, and GConsent - and demonstrates their similarity in representing information while drawing attention to distinguishing features. The section also presents a comparison of DPV with state of the art as identified in Chapter 3.

5.1 Methodology for Ontology Engineering

5.1.1 Utilisation of Existing Ontology Engineering Methodologies

The creation of ontologies followed guidelines and methodologies deemed ‘best practice’ by semantic web community. In this, ‘Ontology development 101: A guide to creating your first ontology’ by Noy and McGuiness (Noy, McGuinness, and others 2001) was utilised as a guiding document for ontology creation. It provided steps for construction of an ontology with attention on avoiding bad design decisions and common pitfalls. It also suggested use of competency questions to determine scope of an ontology and for evaluation after creation. The guide suggested Protégé¹⁰¹ - a popular and widely adopted tool - for ontology development as it supports semantic reasoners to detect logical inconsistencies arising from asserted facts and axioms in ontology. Use of this guide provided a foundational basis for initiating the ontology development process and for using compliance questions from Section 4.2 as competency questions to identify concepts and relationships, testing for inconsistencies using Protégé, and iteratively building an ontology.

The development of ontologies followed a combination of NeOn methodology (Suárez-Figueroa, Gómez-Pérez, and Fernández-López 2012) and UPON Lite methodology (De Nicola and Missikoff 2016). NeOn provides a flexible workflow for ontology development through use of scenarios such a using a specification, reusing and re-engineering existing ontological and non-ontological resources, and utilisation of ontological design patterns. UPON Lite is a lightweight methodology for rapid ontology engineering that was used in combination with NeOn for iteratively developing ontologies in an agile fashion. UPON Lite consists of six steps: identification of domain terminology, construction of domain glossary, creating a taxonomy, predication as properties, meronymy for complex components, and conceptualisation into an ontology. The combination of NeOn and UPON Lite consisted of identifying development scenarios and specifying them as requirements using NeOn, then using UPON Lite to derive actionable tasks and implementing ontology creation.

The methodology used to develop ontologies presented in this chapter explicitly specifies competency questions used to derive its concepts based on compliance questions from previous chapter (Section 4.2). This approach enables tracing lineage of a concept to its role in compliance process and provides transparency in development process. To compare methodology used in this thesis with other methodologies used to develop ontologies within relevant approaches in SotA - some utilise legal experts which act as domain experts to validate developed ontologies and their interpretation - such as in research projects SPECIAL and MIREL (see Section 3.2). Such projects involve commercial partners who provide real-world use-cases and data to inform and evaluate developed research. Others - such as Ujcich et al. (Ujcich, Bates, and Sanders 2018) - interpret GDPR as a set of requirements for compliance in their modelling of information. In either case, approaches within SotA do not provide competency questions that could be used to develop ontologies¹⁰².

5.1.2 Ontology Quality

The quality of an ontology refers to quality of its design of concepts and relationships, and quality as a semantic dataset. While following a suitable ontology engineering methodology provides a structured ontology, it still needs to be inspected for quality in terms of ontology as well as for intended use-cases and scenarios. For this, existing publications (Gurk, Abela, and Debattista 2017; Vrandecic 2010) list various methods of ontology quality detection, evaluation, and suggest solutions to fix identified problems.

OOPS!¹⁰³ (Poveda-Villalón, Gómez-Pérez, and Suárez-Figueroa 2014) is a useful tool for ontology evaluation which detects common pitfalls in design of concepts and relationships and provides a documented output which can be persisted for provenance of ontology development. Each pitfall detected by OOPS! is categorised along structural, functional, and usability-profiling dimensions. The tool also provides an indicative measure of importance regarding pitfalls in terms of critical, important, and minor levels. OOPS! was used for detecting catalogued common pitfalls in evaluation of developed ontologies. Identified pitfalls were corrected by changing underlying relationships to remove them.

Quality was also assessed and maintained by asserting sufficiency of developed ontology to represent and query information based on collected use-cases presented in Section 4.2.2.1. In this process, missing concepts and relationships were added to the ontology, while incorrect ones were removed or rectified.

5.1.3 Ontology Documentation

Ontology documentation was created by using WIDOCO¹⁰⁴ (Garijo 2017) - a tool which uses ontology metadata to create HTML documents listing its classes and properties. Ontology metadata consists of information regarding the ontology as well as its concepts and properties integrated into its serialisation as annotations. WIDOCO provides a document of suggested metadata indicating best practices for ontology documentation. It builds upon LODE¹⁰⁵ which is itself a popular ontology documentation service.

The output of WIDOCO is a HTML document along with various serialisations of ontology for content negotiation that can be published and used as an online resource. Additional information was manually added to HTML documentation to specify aims and methodologies used in development of ontologies as well as examples of use-cases and diagrams intended for human consumption. WIDOCO integrates OOPS! to detect pitfalls and documents the output. It also provides an interactive visualisation of the ontology using WebVOWL¹⁰⁶.

5.1.4 Dissemination

The ontologies were published on internet using a stable IRI through persistent identifiers on servers hosted by ADAPT Research Centre¹⁰⁷ and School of Computer Science & Statistics¹⁰⁸ within Trinity College Dublin. Initially, persistent identifiers were provided using purl¹⁰⁹ which later had issues regarding maintenance and frequent problems with URL resolution. The ontologies were then modified to utilise W3ID¹¹⁰ persistent identifiers maintained by W3C Permanent Identifier Community Group¹¹¹. The ontologies published in this manner followed best practices and principles related to use of Linked Open Data¹¹², Linked Open Vocabularies¹¹³, and FAIR¹¹⁴ principles.

Each ontology was added to Linked Open Vocabularies¹¹⁵ (LOV) - a community listing that catalogues vocabularies in semantic web community. Each ontology was published in Zenodo¹¹⁶ which provides open repositories and assigns a unique DOI to repositories. The ontology and its resources were also added to public hosting repositories such as GitHub¹¹⁷ and an instance of OpenGogs¹¹⁸ hosted on institution servers. Each ontology was published under an open and permissive license (CC-by-4.0¹¹⁹) to promote its use and adoption.

5.1.5 Evaluation

Evaluation was carried out by analysing sufficiency of each ontology to provide concepts for representing information for answering competency questions. This was carried out in an iterative manner where each iteration consisted of developing the ontology, evaluating it, and utilising results of evaluation as feedback to identify areas of improvement such as missing concepts and relationships or incorrect assumptions.

The ontology was also evaluated against common pitfalls using OOPS! as described earlier regarding ontology quality. The OOPS! ontology report is published along with ontology documentation, and can be manually generated by using OOPS! online service. Documentation and publishing standards were evaluated by assessing whether ontologies met existing criteria advocated by the community (such as 5-star principle for linked data¹²⁰ and FAIR principles). Finally, each ontology was published and presented in a peer-reviewed venue and publication, with more information about publications provided in the respective ontology’s section.

Evaluation of work as a research contribution was carried out based on whether it satisfied its research objectives motivating its development and whether it provided novel contributions compared to existing approaches within state of the art. The details of this are presented in evaluation sections of each ontology.

Summary of Methodology

Based on above description of ontology engineering processes, the methodology used for ontology engineering and development is summarised through as:

1. Identification of aims, objectives, scope: The first step was to identify aim and objectives of information to be represented, followed by deciding on scope regarding relation to GDPR compliance. For ontologies presented in this chapter, aims and objectives are listed in Section 1.2.

2. Identify and analyse relevant information: Using identified scope, relevant information was gathered from various sources including authoritative, community, and publications - and analysed to identify terms of importance and requirements regarding GDPR compliance. The information is presented as background of GDPR in Section 2.1 and analysed with regards to compliance in Chapter 4.

3. Create use-cases and competency questions: From the analysed information, different use-cases were identified to better understand application of information in compliance scenarios and requirements of different stakeholders in this process. This was done using information interoperability model presented in Section 4.1. The analysed information was used to create compliance questions, as presented in Section 4.2, which identify relevant information for evaluation of compliance. These compliance questions were utilised as competency questions in development and evaluation of ontologies.

4. Identify concepts and relationships: Relevant concepts and relationships were identified to express information required to answer compliance questions in identified use-cases. This was an iterative and cyclic process where identified concepts and relationships were re-purposed to better suit some design pattern or compliance requirements.

5. Create Ontology: The identified concepts and relationships were formalised as an ontology in OWL2 using the Protégé ontology development environment. In this process, a semantic reasoner (i.e. Pellet¹²¹ and HermiT¹²²) was used to identify logical inconsistencies in ontology. Minor inconsistencies were fixed by changing appropriate relationships between concepts, while major inconsistencies required evaluation of information identified in step 4. Development of ontology utilised best practices advocated by semantic web community in terms of ontology metadata, documentation, design patterns, publication, and dissemination.

6. Evaluate: The ontology was evaluated for sufficiency towards representing information for answering competency questions. The use of a semantic reasoner detected logical inconsistencies in expressed facts and axioms, while OOPS! provided detection of common pitfalls and bad design patterns. The quality of metadata and documentation was evaluated in terms of sufficiency based on community guidelines. Where an ontology was published and/or presented as a resource or as part of a peer-reviewed publication, resulting comments and feedback were used to identify areas of improvement. Citations of ontologies and associated publications were used to identify criticisms (if provided) and to compare them with work presented in citing publication.

7. Dissemination: The ontology and its documentation were published online with a persistent identifier as a FAIR resource with an open and permissive license. This included publication of ontology, datasets, and code in a public repository accompanied by human-readable documentation about its creation and utilisation.

8. Progressive iterations: Within a single iteration of development, an ontology was created and evaluated by following steps 2 to 6. Multiple iterations consisted of repeating these steps as in an development cycle to progressively improve the ontology by adding new concepts or removing existing undesirable ones. Previous versions of ontology were retained with their documentation for provenance where possible to indicate milestones in its development.

5.2 GDPRtEXT - Linked Open Dataset of GDPR text & Glossary of Concepts

This section describes the GDPRtEXT ontology and dataset which provides a linked data version of text of GDPR and a SKOS glossary of concepts associated with its compliance. The section presents the motivation and creation of GDPRtEXT, its publication, dissemination, and comparison with relevant approaches in state of the art. The latest iteration of GDPRtEXT (v0.6) is available online¹²³ with its documentation and code repository¹²⁴.

5.2.1 Motivation

GDPR as a legislation consists of text which is structured into 173 Recitals, 99 Articles (further grouped into Chapters and Sections), and 21 Citations. Each Article may have one or more Paragraphs which itself may have one or more Sub-Paragraphs. As per norms used in legislations, each individual clause - whether an article, paragraph, or sub-paragraph - is identified with an alphanumeric number as provided. These are commonly referenced in textual notation as identifiers, for example Article 8 Paragraph 2 Sub-Paragraph c can be referred to as: A8(2-c), A(8-2c), A8-2(c), Art.8 2(c), Art-8-2-c. As there is no standard or accepted commonality in specifying such references, and because such notations are intended for human readability and interpretation - a strict set or specification of notations does not exist. This presents difficulty when representing such information in machine-readable formats.

The EU Publications Office currently publishes legislation metadata at document level which provides information about GDPR as a legislation using ELI ontology and standard (Thomas et al. 2019) but does not specify granular information about its contents - such as its articles. The EU Publications Office has indicated its intention to provide such granular metadata in future (see footnote in 3.7.2). Currently, concepts arising from legislations as well as those used in context of GDPR compliance have no standardised reference to provide commonality between two representations in different use-cases.

Within the larger scope of legal compliance, information is always associated with clauses and concepts of a law - in this case GDPR. Amongst approaches part of SotA presented in Chapter 3, only two approaches consider association of information with GDPR within scope of their work as presented in 3.7.2. Other approaches, where they reference concepts and clauses of GDPR, do so in an ad-hoc manner using textual notations such as “Article 4-11”. As the analysis in 3.7.2 points out, the two approaches modelling clauses of GDPR have three drawbacks - (a) the representation is incompatible with ELI ontology, (b) none provide a glossary of terms relevant for compliance, and more importantly (c) neither resource can be reused as it is not published in an open and accessible manner. Addressing this gap is required to fulfil research objectives related to linking of information with GDPR.

With this motivation research objective RO3(a) was established in Section 1.2.2 and is fulfilled by GDPRtEXT - which provides an OWL2 ontology for granular representation of GDPR text and a dataset created using this ontology for a linked data representation of GDPR where each clause has a unique IRI. GDPRtEXT also provides a SKOS glossary of terms associated with compliance and links them with their definition and relevance to clauses within GDPR using the developed ontology. It thus enables linking of information with specific clauses and concepts of GDPR.

5.2.2 Ontology Engineering and Creation of Resource

Following the methodology described in Section 5.1, development of competency questions was based on understanding and analysis of how legal articles are referenced in text in relation to compliance. Competency questions presented here are categorised based on whether they concern structure of GDPR or representation of concepts associated with compliance. These competency questions investigate structure and concepts of GDPR as a document and thereby differ from compliance questions presented in Chapter 4 which are concerned with investigating information for compliance. The competency questions for GDPRtEXT are outlined below with identified requirements:

5.2.2.1 Structure of GDPR text

1. How many Recitals are there within GDPR?

2. How many Chapters are there within GDPR?

3. How many Sections are there within GDPR?

4. How many Articles are there within GDPR?

5. How many Paragraphs are there within GDPR?

6. How many Sub-paragraphs are there within GDPR?

7. How many References or Citations are there within GDPR?

8. Article 4 belongs to which Chapter? (generalised to which Chapter does Article X belong?)

9. Which clause contains the definition of ’personal data’? (generalised to definition of concept X)

10. What is the structural hierarchy of the document?

11. What are the ‘Principles’ defined in GDPR? (generalised to conceptA with types conceptB, e.g. ‘Accountability’ as a type of ‘Principle’)

12. Which articles, paragraphs, and sub-paragraphs are relevant to the validity of given consent? (generalised to relevant to concept X)

13. How to associate information regarding given consent to relevant clauses in the GDPR? (generalised to association information regarding concept X)

14. How to associate information regarding compliance to a specific article of the GDPR?

Based on these, following requirements were identified with regards to extending the existing ELI ontology:

• Structure of text must be specified with granularity and a hierarchy of Document, Chapter, Section, Article, Paragraph, Sub-Paragraph along with Recitals and Citations.

• Relations between clauses must be specified e.g. Paragraph belongs to an Article.

• Relations must be transitive e.g. Paragraph in an Article must also be in the Article’s Chapter.

• Each individual clause must have a unique IRI to enable linking of information to it.

5.2.2.2 Concepts associated with GDPR compliance

1. What type of data does the GDPR define?

2. What types of consent does the GDPR define?

3. What are the different entities referred to within GDPR?

4. Which activities are associated with processing of personal data?

5. Which activities are associated with consent?

6. What are the conditions or criteria associated which affect sensitivity of processing?

7. What activities are relevant to a data breach?

8. Which activities are relevant regarding compliance?

9. What are the principles defined in GDPR?

10. What are the rights provided by the GDPR?

11. Which criteria does the GDPR mention for right to data portability?

12. Which criteria does the GDPR mention for right to be informed?

13. What are the obligations mentioned within GDPR?

14. What are the obligations of the Controller?

15. What are the obligations of the Processor?

16. What are the obligations of a DPO?

17. What are the lawful basis for processing of personal data specified in the GDPR?

18. What are the conditions for valid consent under GDPR?

19. Which obligations are mentioned in relation to data collection?

20. Which obligations are mentioned in relation to obtaining consent?

21. Which obligations are mentioned in relation to retaining personal data?

22. Which obligations are mentioned in relation to security of personal data?

23. What concepts are defined regarding seals and certifications?

Based on these, following requirements were identified with regards to representing concepts as a glossary using W3C SKOS standard:

• The glossary should express concepts in a hierarchy of relation as associated with compliance. This hierarchy is based on which additional concepts are relevant to the given concept. For example, all principles are referred to when referring to the concept of ‘Principle’, and - activities and actions associated with compliance are referred to when using the concept of ‘Compliance’.

• The glossary should reference concepts with their definitions within the clauses of the GDPR.

• The glossary should indicate relevant concepts within GDPR for a given concept in the context of compliance.

• The glossary should provide concepts regarding:

  • types of data

  • types of consent

  • types of entities

  • types of activities associated with - consent, data, processing, data breaches

  • actions associated with compliance

  • principles defined in the GDPR

  • rights provided by the GDPR

  • obligations mentioned in the GDPR

  • conditions required for valid consent

  • conditions associated with seals and certifications

5.2.2.3 Extending ELI

The suitability of extending existing ELI ontology for representing hierarchy of clauses in GDPR was evaluated and found to be feasible based on existence of generic extendible concepts. Information models used by ELI - namely FORMEX¹²⁵ and Common Data Model¹²⁶ were also taken into consideration in formulating an extension mechanism for compatibility. Where the GDPR as a document contains metadata regarding its expression in multiple languages, the extension was modelled to be language agnostic with labels in English for the scope of this thesis. Therefore language specifications provided by FRBR model¹²⁷ were not modelled nor included as language labels. The FRBR functionality can be easily integrated in future by extending relevant GDPRtEXT concepts with language tags and expressions.

5.2.2.4 Creation of datasets

Three outputs were decided to be produced under GDPRtEXT based on requirements stated earlier - an OWL2 ontology for representing structure of GDPR text, a dataset of GDPR text using this ontology, and a SKOS glossary of concepts associated with compliance. The OWL2 ontology and SKOS glossary were combined within a single deliverable - namely GDPRtEXT ontology, and representation of GDPR text was provided as a RDF dataset with metadata defined using DCAT¹²⁸ and VoID¹²⁹ standards.

The task of extracting individual clauses and annotating their structure (e.g. chapter, article, paragraph) was automated using a JavaScript script¹³⁰. Three datasets were produced and published through this process. The first provides description of canonical versions of official legislation, i.e. those published by EU Publications Office which specifies GDPR legislation in HTML, PDF, and XML formats. The second provides a copy of GDPR hosted on institution servers and provides identifiers for individual clauses in HTML, JSON, and plain-text documents. The third provides RDF serialisations of GDPR using GDPRtEXT ontology in RDF/XML, N3, Turtle, and JSON-LD.

The glossary published using SKOS utilised IRIs of individual clauses of GDPR in GDPRtEXT to indicate source, definitions, and related concepts. Definitions were declared using rdfs:isDefinedBy property, and a new property called gdprtext:involves was created to indicate associations between concepts.

5.2.2.5 Publication & Dissemination

The ontology and dataset are exposed through a SPARQL endpoint¹³¹ on a triple-store hosted on institution servers. Pubby¹³² was used to provide a front-end for browsing a RDF serialisation of GDPRtEXT as shown in Figure 5.1. The dataset was provided under the CC-by-4.0 license to provide resources in an open and reusable manner and was published in Irish Open Data Portal¹³³ which rated it as a 5-star dataset indicating highest quality in following linked open data principles.

5.2.3 Resource Description & Application

An visual overview of concepts within GDPRtEXT is presented in Figure 5.2 and Figure 5.3.

5.2.3.1 Concepts for description structure of text

GDPRtEXT extends European Legislation Identifier (ELI) (Thomas et al. 2019) ontology published by European Publications Office with granular concepts to represent individual clauses within GDPR. ELI provides the class LegalResource to indicate a legislative document and its sub-class LegalSubResource to indicate a component or part of that resource. GDPRtEXT extends LegalSubResource with sub-classes Chapter, Section, Article, Point (indicating Paragraph), SubPoint (indicating Sub-Paragraph), Recital, and Citation. ELI provides properties has_part and its inverse is_part_of to indicate connections between two legal resources, which GDPRtEXT extends using sub-properties to indicate hierarchical relations between chapters, sections, articles, points, and sub-points.

5.2.3.2 Concepts about Data

GDPR mentions different types of data which determine applicable obligations and requirements of compliance. GDPRtEXT provides Data as a top-level concept to indicate abstract term of ‘data’. GDPR primarily focuses on personal data as defined in Article 4(1) - represented in GDPRtEXT as PersonalData, with special categories of personal data defined in Article 9(1) requiring additional obligations for processing and handling being represented by SpecialCategoryPersonalData. Types of special categories mentioned include criminal data, genetic data, health data, and racial data - which are defined as sub-classes in GDPRtEXT. GDPR also mentions data in context of anonymisation and pseudo-anonymisation processes - represented in GDPRtEXT as AnonymousData and PseudoAnonymousData.

5.2.3.3 Concepts about Consent

The top-level concept of ‘consent’ is represented by Consent in GDPRtEXT with its definitions based in Articles 4(11), 6(1) and Recitals 32, 40. It is sub-classed as GivenConsent - which is a legal basis and therefore is also a sub-class of LegalBasis. GivenConsent is further sub-classed to indicate ‘valid consent’ which carries obligations of ensuring consent is valid and meets requirements of GDPR - and is therefore also defined as sub-class of ObligationForObtainingConsent. Obligations regarding conditions of valid consent are represented by sub-classing the ValidConsent for indicating - freely given, informed, specific, voluntary, and opt-in.

5.2.3.4 Concepts about Entities

Entity represents an ‘entity’ which could be an individual, institution, company, corporation, partnership, or government agency - to name a few. It is sub-classed to indicate entities specifically mentioned in GDPR: Data Subject, Controller, Processor, Sub-Processor, Data Protection Officer (DPO), and Data Protection Authority (DPA). Additionally, relevant concepts associated with entities are also defined: Representative of Controller, Representative of Processor, Certification Body, and Regulatory Authority.

5.2.3.5 Concepts about Activities

‘Activity’ refers to some process or action mentioned, referred, implied, or defined by requirements of GDPR compliance. To represent these, GDPRtEXT defines activities regarding consent and personal data processing, as well as other activities related to functioning of GDPR - such as reporting data breach and demonstrating consent. The top-level concept ‘Activity’ represents abstraction of all activities. ‘ConsentActivity’ and ‘DataActivity’ represent specialised activities involving consent and personal data respectively.

Consent activities defined within GDPRtEXT consist of obtaining consent and withdrawing consent. Data activities include use, archival, collection, cross-border transfer, erasure, copying, rectifying, sharing, and storage of personal data. In these, the activity associated with usage of personal data is equivalent to its common and synonymous usage with term ‘processing’. Activities for indicating context of processing include - automated processing, automated decision making with significant effects, confirming or matching datasets, large scale processing, processing affected or vulnerable individuals, processing sensitive data, processing using untested technologies, and unlawful processing.

GDPRtEXT also provides activities associated with reporting of data breach, which includes obligations and actions such as - report data breach, maintain record of breach, notify data subject of breach, report breach to controller (for processors), and report breach to DPA within 72 hours. Other activities provided are - security of personal data, appointment of processors, demonstrating consent, exercise rights, identification of data subject, impact assessment, marketing, direct marketing, monitor compliance, propagate rights to third parties, and systematic monitoring.

5.2.3.6 Concepts about Compliance

Concepts associated with compliance are provided to indicate actions or terms used in process of maintaining, documenting, evaluating, and demonstrating compliance. The top-level concept Compliance represents an abstract notion of compliance. Other terms derived from this include - Demonstration of Consent, Monitor Compliance, and Report Data Breach.

5.2.3.7 Concepts about Principles

GDPRtEXT represents principles using top-level concept Principle, which is specialised to indicate principles associated with: Accountability; Accuracy; Data Minimisation; Integrity and Confidentiality; Lawfulness, Fairness, and Transparency; Purpose Limitation; and Storage Limitation.

5.2.3.8 Concepts about Rights

To represent rights, GDPRtEXT provides top-level concepts representing each individual right with further concepts associated each right represented as sub-classes. The right of data portability is represented by RightOfDataPortability with related concepts regarding: providing copy of personal data, commonly used data format, machine readable format, structured, and supporting reuse.

The right of erasure is represented by RightOfErasure with related concepts provided regarding obligation to erase data when consent is withdrawn, or when data is no longer needed for original purpose. The right to access personal data is represented by concept RightToAccessPersonalData with related concepts for indicating if and where controller is processing data, whether there is automated processing with significant effects on data subject, categories of data being processed, categories of recipients data is shared with, existence of rights, information about processing, source of data, storage period, and ensuring no charges are levied for provision of rights.

RightToBasicInformationAboutProcessing represents right to basic information about processing and is accompanied with its related concept regarding information about third parties. The concept RightToRestrictProcessing represents right to restrict processing, and is accompanied with conditions such as - accuracy is contested, data no longer needed for original purpose, and processing is unlawful. The right to transparency is represented by RightToTransparency with related concepts regarding conditions of concise, easily accessible, intelligible, and transparent. Other represented rights include: right to not be evaluated through automated processing, right to object to direct marketing, right to object to processing, and right of rectification.

5.2.3.9 Concepts about Obligations

GDPRtEXT defines concepts regarding obligations of controllers, processors, DPOs, consent, and compliant processing of personal data based on a legal basis. Obligations of controllers are represented by ControllerObligation with related concepts provided regarding appointment of processors, accountability, controller responsibility, co-operation with DPA, data protection by design and default, data security, liability of joint controller(s), maintaining records of processing activities, privacy by design, propagate rights to third parties, and reporting data breach.

Rights of processors is represented by ProcessorObligation with related concepts for appointing sub-processors, assisting in complying with rights, compliance with controller’s instructions, co-operating with DPA, data security, imposing confidentiality on personnel, informing controller of conflict with law, maintaining records of processing activities, only acting on documented instructions, propagating rights to third parties, providing controller with information for compliance, reporting data breach to controller, restrictions on cross-border transfers, and to return or destroy personal data at end of term.

The concept DPOObligation represents obligations of a DPO which include the monitoring of compliance represented by MonitoringCompliance . The obligations related to lawful basis for processing are represented by LawfulBasisForProcessing along with related concepts for contract with data subject, exempted by national law, employment law, given consent, historic, statistical, or scientific purposes, legal claims, legal obligation, legitimate interest, made public by data subject, medical or diagnostics use, not for profit organisation, public interest, purpose of new processing, and vital interest.

Obligations regarding valid consent are represented by ValidConsent with related concepts provided to indicate consent should be freely given, informed, specific, voluntary, and opt-in. Obligations for obtaining consent are represented by ObligationForObtainingConsent and include concepts for information about third parties, indicating consent can be withdrawn easily, and conditions regarding information provided for obtaining consent such as - it should be clear, providing explanation of processing, should not be from silence or inactivity, should be demonstrable, should be distinguishable from other matters, and that it should produce valid consent.

Obligations for data collection are represented by ObligationForDataCollection, which is accompanied with related concepts for indicating accurate collection, specification of explicit purpose, ensuring legitimate purpose, ensuring it is not further processed than original purpose, and ensuring it is limited to specified purpose. Obligations for retention of personal data are represented by ObligationForRetentionOfPersonalData and include related concepts about retention of personal data, ensuring it is adequate for processing, ensuring it is identifiable for required processing, obligation to kept it up to date, ensuring it is limited for processing, obligation to rectify inaccuracies, and ensuring it is relevant for processing. The concept ObligationForSecurityOfPersonalData represents obligations regarding security of personal data with related concepts provided regarding accidental loss, damage, destruction, and unlawful processing.

5.2.3.10 Concepts about Seals and Certifications

GDPRtEXT provides concepts of Seal and Certification for representing seals and certifications as provided by GDPR to assist with maintenance and demonstration of compliance. The conditions of these are represented by ConditionsForSealsAndCertifications, which is further expanded to represent conditions for seal/certification such as having a maximum validity of 3 years and having a voluntary system of accreditation.

5.2.3.11 Example Use-Case: Compliance Reporting

This example use-case, taken from documentation of GDPRtEXT (Harshvardhan J. Pandit, Fatema, et al. 2018), shows how references to GDPR can aid in creation of reports which document information regarding compliance.

Consider a system for creation of compliance reports that stores information related to obligations it addresses from GDPR. It uses the EARL¹³⁴ vocabulary for expressing results of conformance checks within the report. GDPRtEXT is used to link resources in EARL reports with articles and points within GDPR and to express and define concepts related to compliance in a suitable and comprehensible manner. Through this, information about compliance checks is linked and associated with specific articles of GDPR.

EARL provides a standardised vocabulary to describe specific resources and relationships that are relevant to test reporting. The core construct of EARL is an Assertion, which describes context and outcome of an individual test execution. It uses following concepts (copied verbatim from EARL specification):

• Assertor - This can include information about who or what ran the test. For example human evaluators, automated accessibility checkers, or combinations of these.

• Test Subject - This can include web content (such as web pages, videos, applets, etc.), software (such as authoring tools, user agents, etc.), or other things being tested.

• Test Criterion - What are we evaluating test subject against? This could be a specification, a set of guidelines, a test from a test suite, or some other testable statement.

• Test Result - What was the outcome of test? A test result could also include contextual information such as error messages or relevant locations.

Taking the example of Right to Data Portability, the EARL report in Listing represents compliance checks for conditions associated with linked articles in GDPR (Article 20). The compliance system has a module _system_dataportability that checks software that handles provision of copy of personal data _org_dataportability through test case _test_provide_data_copy and generates a report showing the test has passed through _result_pass.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix earl: <http://www.w3.org/ns/earl#> .
@prefix dct:  <http://purl.org/dc/terms/> .
@prefix gdprtext: <http://purl.org/adaptcentre/resources/GDPRtEXT#> .
@prefix ex: <http://example.com/phd-thesis#> .

ex:org_dataportability
    a    earl:TestSubject, earl:Software ;
    dct:description "System that handles data portability requests"@en ;
    dct:title "Data Portability Handler"@en .

ex:system_dataportability
    a    earl:Assertor ;
    dct:description "Module checking data portability obligations"@en ;
    dct:hasVersion "1.4" ;
    dct:title "DataPortability Module"@en ;
    earl:asserts [ a earl:Assertion ; 
      rdf:subject ex:org_dataportability ;
      rdf:predicate ex:result_pass ;
      rdf:object ex:test_provide_data_copy  ] .

ex:result_pass
    a    earl:ResultProperty ;
    earl:date "2018-01-01" ;
    earl:validity earl:Pass ;
    earl:confidence earl:High .

ex:test_provide_data_copy
    a    earl:TestCase ;
    earl:testMode earl:automatic ;
    dct:title "Test provision of data copy"@en ;
    dct:description "Tests data portability"@en ;
    dct:subject gdprtext:article20 .

To gather related resources together, a SPARQL query (simplified) would focus on link between TestCase and its result using earl:validity, as shown in Listing. These tests can be further combined into test suites to group compliance checks related to each article or a particular concept and structure documentation around this form of logical grouping of concepts. In this manner, use of GDPRtEXT to link tests and results with documentation enables automation of information retrieval and management. A similar use-case of GDPRtEXT in linking constraints and their outcomes with GDPR is demonstrated in Chapter 6.

SELECT ?gdpr ?result ?confidence ?mode WHERE {
    ?assertor a earl:Assertor .
    ?assertor earl:asserts ?assertion .

    ?testcase rdf:predicate ?assertion .
    ?testcase a earl:TestCase .
    ?testcase dct:subject ?gdpr .
    ?testcase ear:testMode ?mode .

    ?testresult rdf:object ?assertion .
    ?testresult a earl:ResultProperty .
    ?testresult earl:validity ?result .
    ?testresult earl:confidence ?confidence .
}

| gdpr          | result     | confidence     | mode          |
---------------------------------------------------------------
| article16     | pass       | low            | automatic     |
| article17     | pass       | high           | automatic     |
| article18     | fail       | high           | manual        |
| article19     | pass       | high           | automatic     |

5.2.3.12 Example Use-Case: Mapping between DPD and GDPR obligations

The second application of GDPRtEXT, taken from its publication (Harshvardhan J. Pandit, Fatema, et al. 2018), demonstrates linking of obligations between GDPR and its predecessor - Data Protection Directive (DPD. Given that DPD was adopted in 1995, and was superseded by GDPR in 2016, there are a large number of solutions and approaches regarding compliance with DPD that already exist and are used in practice. By linking obligations between DPD and GDPR it is possible to investigate reuse of these existing solutions for GDPR compliance. To that end, a mapping from DPD obligations to GDPR obligations containing annotations that describe nature of changes is constructed by linking articles of DPD and GDPR.

To model annotations as a RDF resource, a linked data version of DPD was created similar to GDPRtEXT by assigning URIs for every clause in legislation. This enabled referring to each individual clause in DPD and linking it with relevant clauses in GDPR. The annotations (available online¹³⁵) consist of references from a clause in DPD to its corresponding clause in GDPR with an expression of change between the two. The nature of change is represented by values: same - indicating no change; reduced - indicating reduction of obligation; slightly changed - indicating minor change; completely changed - indicating major change; and extended - indicating addition of obligations.

Its example demonstration consisted of using XACML¹³⁶ rules for controlling access to data and modelled after DPD obligations. For each link between DPD and GDPR obligations, a record was created indicating whether the corresponding XACML rules for DPD compliance needed to be changed to be applicable for GDPR. The notation N/A was used to denote cases where no XACML rules existed for a particular DPD obligation and where corresponding obligations in GDPR had changed or had additional requirements.

@prefix gdpr: https://w3id.org/GDPRtEXT/gdpr# .
@prefix dpd: https://w3id.org/GDPRtEXT/dpd# .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .

dpd:mappingrule6
    a dpd:DPDToGDPR_Annotation ;
    dpd:hasChange dpd:ChangeExtended ;
    dpd:hasXACMLChange dpd:XACMLNoChange ;
    dpd:resourceInDPD dpd:Article7 - a ;
    dpd:resourceInGDPR gdpr:Article6-1-a ;
    rdfs:comment "added consent given to ..." .

The class DPDToGDPR_Annotation represents annotations between DPD and GDPR, with an example instance depicted in Listing. The property resourceInDPD is used to refer to a specific clause within DPD using its IRI. Similarly, the property resourceInGDPR is used to refer to a corresponding clause in GDPR. The nature of change is defined using property hasChange whose value is an instance of class ChangeInObligation, with instances defined for Extended, Same, Reduced, CompletelyChanged, and SlightlyChanged. Similarly, a change in XACML rules is defined using class ChangeInXACMLRule with instances Yes, No, and N/A.

5.2.4 Evaluation

In terms of ontology assessment, the methodology outlined in Section 5.1 provides criterion for evaluation of ontology quality and documentation. GDPRtEXT fulfils these based on using OOPS! tool¹³⁷ to identify and rectify bad design patterns and by following best practices and community guidelines for ontology documentation. GDPRtEXT and the work described in this section was published (Harshvardhan J. Pandit, Fatema, et al. 2018) at Extended Semantic Web Conference (ESWC) - Resource Track. The publication described creation of resource, summarised its contents, and described mapping of DPD obligations with GDPR using a linked data approach and XACML to denote which obligations from DPD could be re-used towards GDPR compliance. ESWC is a premier and top-tier conference within semantic web domain, and has a rigorous review process with an open review policy. The acceptance of GDPRtEXT in this venue demonstrates its value as a semantic web resource.

To date, the publication has received 19 citations from peer-reviewed publications (excluding self-citations) on Google Scholar¹³⁸. In addition to these, a 5 star rating given to GDPRtEXT as a dataset in Irish open data portal indicates its adherence to linked data principles. A survey of legal approaches within state of the art (Leone, Di Caro, and Villata 2019) undertaken by MIREL project analysed GDPRtEXT amongst other legal ontologies and found that GDPRtEXT is singular in its use of ELI and provision of GDPR as a glossary of concepts - a finding shared with the analyses of SotA in Section 3.7.

5.2.4.1 Fulfilment of Competency Questions

The assessment of GDPRtEXT consists of evaluating the extent to which it answers competency questions outlined in Section 5.2.2. For this, Table shows concepts and relationships of GDPRtEXT relevant towards answering competency questions.

The table demonstrates that GDPRtEXT provides concepts to answer all competency questions. GDPRtEXT thus meets requirements of representing and linking information with text and concepts of GDPR in a granular manner and fulfils RO3(a).

5.2.4.2 Comparison with SotA

The SotA in representing text of GDPR in machine-readable formats presented in 3.7.2 compared three approaches: ELI (Thomas et al. 2019), Agarwal et al (Agarwal et al. 2018), and PrOnto (Palmirani, Martoni, et al. 2018b, 2018a). Their comparison and analysis, summarised in Table 3.2, depicts relevance of each approach in representing the GDPR as a glossary of concepts, providing a permanent identifier for resources, modelling of GDPR’s text, and whether resources are open and accessible. The conclusion drawn from these is the lack of an approach fulfilling all criteria along with a lack of open and reusable resources concerning GDPR. The additional resource of ELI+ mentioned in analysis shows intention of EU Publications Office to remedy this gap through an update to the ELI ontology at some time in future.

A comparison of GDPRtEXT with these approaches, depicted in Table, shows that GDPRtEXT provides a glossary of concepts, uses permanent identifiers, provides linked data version of text of GDPR, and is available under an open and permissive license (CC-BY-4.0). This matches the intended contributions of ELI+ (update to ELI) planned by EU Publications Office, and therefore enables GDPRtEXT to fill this gap in this time.

A survey of legal ontologies by Leone et al. (Leone, Di Caro, and Villata 2019) includes GDPRtEXT as an ontology relevant for data protection. The survey also includes ELI and PrOnto within the scope of data protection ontologies - which provides external comparison between these and GDPRtEXT. The survey outlines the role of GDPRtEXT in acting as a glossary of concepts rather than a prescriptive set of norms and rules for specification of compliance - such as made available through PrOnto. In this role, GDPRtEXT is novel within state of the art given a lack of other similar resources.

Based on this, GDPRtEXT is argued to provide novel contribution to state of the art and addresses gaps associated with representation of concepts and GDPR text at a granular level, and whose open availability enables usage and adoption.

Summary

The GDPRtEXT resource represents the first major contribution of this thesis. It provides a linked data version of text of GDPR and a glossary of its concepts, fulfils research objective RO3(a), and assists with research objective RO5(b) - as outlined in Section 1.2. It enables representing each article or point within GDPR as a unique resource through IRIs defined using RDF and semantic web. GDPRtEXT thus enables machine-readable links to be established between information and clauses of GDPR as well as concepts pertaining to its compliance.

The use of GDPRtEXT makes it possible to create approaches that automate generation and querying of information associated with GDPR - such as for compliance, management of business processes, or generation of privacy policies. The compatibility provided through extension of ELI ontology ensures alignment with official documents produced by European Publications Office. Finally, GDPRtEXT fills an important gap in the state of the art regarding machine-readable approaches for linking information with legal text. GDPRtEXT has been released as an open resource, has been published in Zenodo and Datahub, and has been incorporated into Ireland’s open data portal as a 5-star linked open dataset.

5.3 GDPRov - Ontology for GDPR activities associated with Personal Data and Consent

This section describes the GDPRov ontology for representing activities in ex-ante and ex-post phases associated with processing of personal data and consent for GDPR compliance. GDPRov stands for GDPR Provenance - a reference to the requirement of maintaining provenance information of processes in both ex-ante and ex-post phases for demonstrating GDPR compliance. This section presents motivation, overview, dissemination, and evaluation of GDPRov ontology. It also presents comparisons with relevant approaches in state of the art.

The ontology satisfies the research objectives RO3(b) presented in Section 1.2. It uses the compliance questions presented in Section 4.2 as competency questions to identify requirements and for evaluation. GDPRtEXT is used to define and associate the source of concepts within the text of GDPR. An earlier version (v0.4) of GDPRov was described in a peer-reviewed publication (Pandit and Lewis 2017). Subsequent revisions included addition of new concepts associated with real-world implementation and interpretation of GDPR compliance requirements (see Section 6.1) and for representing information about consent mechanisms on the internet (see Section 6.2). The latest version of GDPRov (v0.7) is available online¹³⁹ with its documentation and code repository¹⁴⁰.

5.3.1 Identification of requirements from competency questions

The compliance questions presented in Section 4.2 were selected based on relevance to information regarding activities and provided competency questions for deriving concepts and relationships regarding processes associated with personal data and consent based on GDPR compliance requirements. These concepts and relationships were collected, combined, and analysed to ensure their cohesion as an ontology and evaluated using compliance questions to ensure they satisfied requirements regarding GDPR compliance and documentation of associated processes. In this, ex-ante and ex-post representation provide repetition of some information as most processes have counterparts in both phases. The linking of information between phases enables them to be documented in a manner so as to demonstrate prior planning of processes to ensure compliance and later their execution which also needs to be documented for compliance. Therefore, while GDPR requirements and compliance questions do no explicitly mention or refer to ex-ante and ex-post phases for each activity, GDPRov implicitly considers each activity to have representations in both phases.

The sub-sections below present concepts to answer competency questions derived from compliance questions. This is followed by an analysis of discovered concepts in ex-ante and ex-post phases. The analysis is used to derive requirements for construction of GDPRov ontology, and is presented to describe motivations for the ontology design and implementation.

5.3.1.1 Actors and Agents involved in activities

• CMQ2 - Provides concept of Controller as an agent controlling processes and its representative Data Protection Officer (DPO).

• CMQ17 - Describes Processor as an executor of processes and its representative DPO. In this relationship, Controller provides processes to be executed as instructions to Processor through a Data Processing Agreement (DPA).

• CMQ35 - Describes Data Subject as an agent who is associated with provision of personal data, consent, and who is related to exercising of rights.

5.3.1.2 Details of processing

• CMQ3 and CMQ37 provide concept of Purpose which describes purpose of personal data processing. Each purpose can incorporate multiple processing operations, and each processing operation taking place can be associated with multiple purposes.

• CMQ4 describe necessity to specify data subject categories whose personal data is being processed.

• CMQ36 describes personal data, while CMQ5 describes categories of personal data being processed. CMQ34 specifies special categories of personal data as a sub-category of personal data that needs to be explicitly stated as being processed.

• CMQ38 defines processing of personal data as defined by Article 4-2 of GDPR. The GDPR definition of processing provides types of operations as specified by “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;”.

• CMQ6 defines sharing of data as a type of processing. Additional information associated with sharing of data is provided by - CMQ7 and CMQ20 for categories of recipients; CMQ8,CMQ21 for identifies of recipients, CMQ9 and CMQ22 for location where data is being sharing to; CMQ10 and CMQ23 for safeguards associated with data transfer; CMQ15 and CMQ25 for purposes of sharing - which is the same concept as purpose of processing except applied for sharing of personal data.

• CMQ11 defines data storage, with additional concepts provided by CMQ12 for existence of time limits or conditions for erasure and CMQ13 for specification of time limits or conditions for erasure for categories of data.

• CMQ26 defines legal basis for justifying processing of personal data, and CMQ27 specifies legal basis associated with a particular purpose. Each purpose can have one or more legal basis associated with it.

5.3.1.3 Life-cycle of data

• CMQ28 and CMQ30 describe source of personal data which in turn implies an activity that collects data and specifies actors or agents as source of data.

• CMQ29 specifically refers to personal data collected from data subject.

5.3.1.4 Anonymisation

• CMQ31 specifies anonymisation of personal data with CMQ32 inquiring about different ‘levels’ of anonymisation which affect the application of obligations and requirements of compliance.

• Levels of anonymisation are specified based on their relevance to investigation of compliance, and are defined as data which is: completely anonymised, pseudo-anonymised, not anonymised. In this, data that is pseudo-anonymised can be considered and used as anonymous data when an organisation does not have additional information to de-anonymise it.

• Processing activities associated with anonymisation and de-anonymisation of personal data are defined to produce anonymised data.

5.3.1.5 Activities associated with Consent

• Regarding consent, CMQ48 inquires about activities associated with provision and collection of consent. This includes information about how consent is requested and collected, used within processes as a legal basis, and is archived for future demonstration of compliance.

• CMQ49 and CMQ50 inquire about artefacts associated with collection of consent for determination of consent validity under GDPR, which requires investigation of how choices for consent were offered. This also includes forms through which consent is provided or collected from data subjects. Artefacts such as forms or dialogues are associated with processes where consent choices are offered or requested and whose result is collection of consent or given consent.

5.3.1.6 Provision of Rights

• The rights associated with GDPR need processes to internally (in perspective of an organisation) handle their execution as well as for interactions with data subjects. Therefore, such processes need to be defined and documented for compliance purposes.

• For right to be informed, CMQ88 - CMQ105 provide competency questions regarding how the right is provided and how it is executed or implemented.

• This includes activities associated with provision of information to data subject, artefacts associated with information provision, inclusion of details such as controller and DPO, purposes, processing, legal basis, and personal data categories.

• It also includes information about sources of personal data (where not obtained directly from data subject), and whether legal basis used is legitimate interest.

• Regarding data sharing, information to be specified includes categories of recipients and their location.

• Right to be informed also includes provision of information regarding existence and application of rights.

• Information associated with right to be informed is common to other information documented in due course of processing of personal data, and therefore does not require a separate notation or representation of this information in order to execute the right. Existing information or concepts for representation of processing activities can be reused for specifying required information. However, activities associated with executing rights need to be defined to demonstrate existence of processes for handling rights.

5.3.1.7 Compliance procedures such as Reporting of Data Breach

• Reporting of data breach requires information about data breach to be maintained as specified by CMQ106 - CMQ120.

• This includes information about the data breach consisting of: timestamp of when breach occurred (CMQ106), timestamp of when controller became aware of it (CMQ107), timestamp and method of it being notified to supervisory authority (CMQ108).

• Information about contents of breach include information about its affected personal data and categories of data subject (CMQ112).

• Information also needs to be provided to supervisory authorities and in some cases to data subjects based on extent of breach (CMQ113). It therefore requires prior planning of processes for handling data breaches and sending information to data subjects along with any remedial measures (CMQ116).

5.3.1.8 Specifying requirements for ex-ante and ex-post phases

Process logs are a convenient and demonstrable form of information to store and document compliant processing of personal data. By verifying logs, it is possible to document, evaluate, and demonstrate that executed processes were compliant with requirements of GDPR. This constitutes as ex-post phase of compliance and consists of evaluating information after processing has been carried out. It also fulfils Article 30 of GDPR concerning processing records to be maintained. Along with ex-post records, it is also essential to demonstrate that executed processes were based on a preconceived plan or template that was ensured to be compliant before execution. Storing such plans is essential to demonstrate prior planning and maintenance of a compliant processing system. This constitutes as ex-ante phase of compliance, and consists of evaluating compliance on plans of processing yet to be carried out. This is necessary for Article 35 of GDPR concerning carrying out a DPIA.

Associating executed processes with their plans allows demonstration of compliance throughout the life-cycle of processes, i.e. from planning of processes to their eventual execution. It also enables documenting changes in plans and their effects on execution of processes - i.e. demonstrating that when a plan changes it also brings about corresponding changes in executed processes. In context of GDPR compliance, requirements of compliance require documentation, maintenance, and demonstration of processes across both ex-ante (planning) and ex-post (execution) phases. Ex-ante plans of processes are described as an organisational measure and their compliance is associated with ensuring processes meet legal requirements before they are actually carried out. In some instances, such as for a Data Protection Impact Assessment (DPIA), existence of ex-ante information about processes is essential in evaluation of compliance.

While compliance questions provide a basis for identifying information to be modelled, requirements of expressing this information in ex-ante and ex-post phase require specification of their intended usage in planning and processing stages respectively which further determines whether compliance evaluation consists of verification of a plan or analysis of processing logs. The argument and motivation for representing processes in ex-ante and ex-post phases represents a design decision based on separating representation of information across phases of compliance rather than being a compliance requirement itself. Approaches within state of the art that also follow a similar representation of ex-ante and ex-post information include SPECIAL (Section) which uses PROV-O to log information in both phases, and MIREL (Section) which uses a workflow model to represent a plan and its executions.

Information requirements for modelling information about activities is summarised through following points:

1. Represent process in ex-post phase as a log or record.

2. Represent process in ex-ante phase as plan or template.

3. Link ex-ante plan with its instantiations or executions in ex-post phase.

4. Track provenance of ex-ante plans i.e. changes in plans of processes.

5. Enable tracking changes in ex-post logs based on corresponding changes in ex-ante plans.

6. Associate information used/generated in activities as artefacts in both ex-ante and ex-post phases.

7. Associate actors/agents with processes.

8. Link processes based on:

   1. dependency - where one process is dependant on another through use of generated artefact,

   2. order of execution - where one process is or will be executed before or after another, and

   3. composition - where one process is constituted by several sub-processes.

5.3.2 Extending PROV-O and P-Plan

Based on above stated requirements for representing activities or processes in ex-ante and ex-post phases, existing semantic web ontologies of PROV-O (Lebo et al. 2013) and P-Plan (Garijo and Gil 2014) were extended with relevant GDPR concepts and relationships to create the GDPRov ontology. The necessity of this process and a brief overview of PROV-O and P-Plan ontologies is presented below along with the process of extending ontologies.

5.3.2.1 PROV - W3C standard for representing provenance information

Provenance is information about entities, activities, and people (or software) involved in producing data or a component which can be used to form an assessment about its quality, reliability, or trustworthiness. The PROV-O ontology (Lebo et al. 2013) along with PROV family¹⁴¹ of schemas and documents is the W3C recommendation for representing provenance information since 30^th April 2013 and has seen significant adoption by semantic web and industrial communities. It provides definitions for interchange of provenance information by representing entities and relations between them such as generated by, derived from, and attributions.

The core concepts of PROV-O are summarised in Figure 5.4 and consist of interactions between Activities, Entities, and Agents. An Entity in PROV-O is defined as being physical, digital, conceptual, or other kind of ‘thing’ with some fixed aspects. PROV-O defines an Activity as something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.

PROV-O is a generic and domain independent ontology for representing provenance information. In order for it to be applied in domain of GDPR compliance, it needs to incorporate relevant terminology and enable distinction between different types of activities and entities. Furthermore, PROV-O as a provenance ontology is intended to represent information about activities that have been executed in the past, and is therefore suitable to represent information only in the ex-post aspects.

While PROV-O does provide the concept of Plan¹⁴² to represent ex-ante information, it does not provide further concepts or relationships to associate a plan with activities and entities¹⁴³. In order to adopt PROV-O and use Plan for representing ex-ante information for GDPR compliance, it needs to be extended with additional concepts and relationships.

5.3.2.2 P-Plan - extending PROV-O Plans as Workflows

P-Plan (Garijo and Gil 2014) extends the concept of Plan in PROV-O towards representing scientific workflows which enable creating a template of a ‘step’ and linking it to executions of activities. A p-plan:Plan is a subclass of prov:Plan and is composed of smaller activities or steps (p-plan:Step) that use and generate (as inputs or outputs) variables (p-plan:Variable). An overview of relationship between PROV-O and P-Plan is described in Figure 5.5. P-Plan enables representation of provenance information associated with both ex-ante and ex-post processes by representing them as scientific workflows. It also enables associating plans with their executions, thereby providing a link between ex-ante and ex-post provenance information.

A p-plan:Plan represents information of ‘how’ something should happen or a ‘template’ for executions. A p-plan:Activity is a subclass of prov:Activity and represents execution of process described in a p-plan:Step. A p-plan:Entity is a subclass of prov:Entity that corresponds to a p-plan:Variable in p-plan:Plan. Therefore, a p-plan:Step may describe the template including inputs and outputs which can then be instantiated into multiple instances of p-plan:Activity that can have distinct inputs to produce different outputs. As p-plan:Plan extends prov:Plan, which itself extends prov:Entity, it can be used to treat p-plan:Plan as an object whose provenance can be tracked using PROV-O or P-Plan. This makes it possible to express ‘provenance of provenance’ - thereby creating a record of how plans were formulated and executed over time.

5.3.2.3 Extending ontologies for GDPR

The PROV-O and P-Plan ontologies were extended to represent concepts and relationships of ex-ante and ex-post activities associated with personal data and consent based on requirements of GDPR compliance. The decision to extend PROV-O and P-Plan with GDPR concepts was made as both ontologies contain generic concepts associated with activities and workflows which can be used for representing information about GDPR compliance, but doing so would be not be intuitive due to difference in terminology and structuring of information as expected for GDPR compliance.

Extending existing ontologies of PROV-O and P-Plan enables expressing a ‘template’ or ‘plan’ using p-plan:Plan describing ex-ante activities (as p-plan:Step) that can take place. This template can then be used to denote execution of activities in ex-post phase using p-plan:Activity. This provides a machine-readable and documented information model for both ex-ante and ex-post activities whose provenance itself can be expressed (using PROV-O and P-Plan) to record how they were created and how they change over time. This is beneficial in documenting state of a system at a given time through a set of activities that deal with consent and personal data, and can be helpful in determining changes to be made based on changes in processing of personal data over time.

The extended ontology derived from PROV-O and P-Plan incorporates concepts and relationships associated with GDPR in order to normalise terminology for representing information associated with GDPR compliance. Concepts and relationships are derived from competency questions and linked with relevant clauses within GDPR through using GDPRtEXT concepts using rdfs:isDefinedBy and rdfs:seeAlso. This provides documentation regarding origin of concepts and their use in representation of information associated with specific clauses of GDPR. It also provides a machine-readable link from the ontology to GDPR which can be used to compare, analyse, and align relevant ontologies.

The extension consists of sub-classing existing concepts in PROV-O and P-Plan to represent specific activities associated with GDPR compliance. The use of subclass mechanism preserves existing concepts and relationships of PROV-O and P-Plan to provide compatibility and reuse. This is particularly important for PROV-O as it is a W3C standard and therefore is more likely to have existing uses. The compatibility with PROV-O also enables information defined using the ontology to be bundled as an artefact to record its provenance and planning as a form of meta-documentation regarding planning and maintenance of compliance activities This is particularly useful to maintain periodic snapshots of organisational processes associated with compliance and provides opportunities to automate querying and validation of information within a use-case - as demonstrated in Chapter 6.

5.3.3 Ontology Description & Application

The ontology engineering is named GDPRov (GDPR Provenance Ontology) and is published online along with its documentation at https://w3id.org/GDPRov/ under an open and permissive CC-by-4.0 license. The ontology was created, documented, and published using the methodology presented in Section 5.1. The aim of GDPRov is to provide representations of ex-ante and ex-post activities regarding personal data and consent for GDPR compliance. It uses GDPRtEXT concepts to define origin and relevance of its concepts to GDPR.

5.3.3.1 Overview of GDPRov concepts

GDPRov extends concepts from PROV-O and P-Plan using the sub-class and sub-property mechanisms to represent activities associated with GDPR compliance, with a visual overview provided in Figure 5.6.

GDPRov extends p-plan:Plan as Process to represent ex-ante plans of activities that will take place. The terminology is based on common use of term in expressions such as ‘business processes’ and ‘compliance processes’. Each Process can contain steps (represented by p-plan:Step) to represent activities that interact with data and agents. To associate steps with a process, the property p-plan:isStepOfPlan is extended as isPartOfProcess. Another additional property - refersToProcess is also used to enable referring to a process without being a part of it. Similarly, to associate data (defined in P-Plan as p-plan:Variable) the properties p-plan:hasInputVar and p-plan:isOutputVarOf are extended for activities using inputs and producing outputs respectively.

Ex-post activities in P-Plan are represented by p-plan:Activity. Data interactions with these activities is represented by p-plan:Entity and the properties prov:used and prov:wasGeneratedBy are used to indicate inputs and outputs respectively. GDPRov defines steps to indicate automated execution and user interactions regarding collecting data from user (input) and providing data (output). To indicate a legal basis associated with a process or a step, the property hasLegalBasis is provided.

5.3.3.2 Depicting Data Life-cycle

Activities associated with life-cycle of personal data constitute of collecting, processing or using it, storing, sharing, deleting, transferring, transforming, anonymise, and rectifying data. GDPR defines several more categories of actions in Article 4-2 in its definition of ‘processing’. GDPRov provides broad and abstract processes to represent data access, data archival, data erasure, and data rectification given the need to execute these using one or more steps. GDPRov provides representations of actions in ex-ante phase as DataStep which extends p-plan:Step and in ex-post phase as DataActivity which extends p-plan:Activity. These are further extended to distinguish between data collection, data deletion, data sharing, data storage, data archival, data transfer, data transformation, data usage, and rectification of data. A visual overview of steps describing a data life-cycle using GDPRov is provided in Figure 5.7.

Anonymisation of data is defined as a sub-class of data transformation to indicate transformation of data that takes place when anonymising it. As GDPR obligations are based on level of anonymity and capability of de-anonymising it from an organisation’s point of view, GDPRov provides the concept of anonymisation level to indicate state of anonymity of data. GDPRov defines four levels of anonymisation based on existing work in representing anonymous data (Hintze and LaFever 2017), which constitute of data that is: (i) completely anonymised, (ii) completely de-anonymised, (iii)pseudo-anonymised, and (iv) pseudo-organisational-anonymised where an organisation does not have additional data required to de-anonymise it and can thus utilise it internally as if it were completely anonymous data. Sharing of data consists of interactions with actors or agents, which are represented by prov:Agent and associated with respective steps and activities using extended properties.

Personal data used within activities is represented by PersonalData which is sub-classed from p-plan:Variable for ex-ante representation and by PersonalDataEntity which is sub-classed from prov:Entity for ex-post representation. Further categorisation of personal data into anonymised, sensitive, and representing user identifier is provided through sub-classes.

5.3.3.3 Depicting Consent Life-cycle

Activities associated with the life-cycle of consent are represented in ex-ante phase by sub-classing p-plan:Step as ConsentStep and similarly in ex-post phase by sub-classing p-plan:Activity as ConsentActivity. These are further sub-classed to represent acquisition, archival, modification, and withdrawal of consent. Amongst these, withdrawal of consent is defined as sub-class of modification since it modifies state of consent. A visual summary of steps in a consent life-cycle is provided in Figure 5.8.

Artefacts associated with consent and used in activities include choices or offer provided to request consent and subsequent consent given by an individual. To represent these in ex-ante phase, GDPRov provides concepts of ConsentAgreementTemplate to represent template offered to collect consent, ConsentAgreement to indicate given consent, and TermsAndConditions to indicate applicable policies or terms and conditions. Corresponding concepts in ex-post phase are GivenConsentTemplate, GivenConsent, and TermsAndConditionsEntity.

5.3.3.4 Depicting Compliance-related processes

In addition to representing activities associated with personal data and consent, GDPRov also provides representations for compliance-related processes. These include actions such as appointing processor (by a controller), carrying out an impact assessment, marketing and its special case of direct marketing, and monitoring compliance. Processes are also provided for handling data breaches which include notifying controller (by a processor), notifying data subject, and notifying data protection authority. The handling of rights required by GDPR is represented through sub-classes of Process for data portability, erasure, access personal data, basic info about processing, no automated processing, object to direct marketing, object processing, rectification, restrict processing, transparency, SAR (subject access request).

5.3.3.5 Example Use-Case: Querying anonymised sharing of data

The applicability and usefulness of GDPRov is demonstrated through its use for querying and validation of information for GDPR compliance in Chapter 6. A simplified example demonstrating a similar application through use of a SPARQL query was published along in a peer-reviewed publication (Pandit and Lewis 2017). It is presented in Listing to demonstrate how GDPRov can assist in answering of compliance questions for GDPR.

The query uses GDPRov concepts to retrieve data being shared, specific steps that share it, anonymisation level of shared data, and steps used to anonymise it. The query is meant to retrieve information relevant in investigation of data being shared and its anonymity.

PREFIX gdprov: <https://w3id.org/GDPRov#>
SELECT ?data ?sharestep ?isAnonymised ?anonymisationStep
WHERE {
    ?data a gdprov:Data .
    ?sharestep a gdprov:DataSharingStep .
    ?sharestep gdprov:sharesData ?data. 
    BIND (
        EXISTS { ?data a gdprov:AnonymisedData . }
        as ?isAnonymised ) .
    OPTIONAL {
        ?anonymisationStep
        gdprov:generatesAnonymisedData ?data .
    }
}

5.3.3.6 Example Use-Case: Detecting changes in activities for updates to consent

As an use-case, consider the case where a data controller updates a plan of processing activities - such as when a purpose changes or a new processing operation is added to an existing purpose, and where legal basis for such processing is consent. In such cases, a data controller is required to evaluate whether updating an individual’s consent is required based on changes between given consent and new purposes or processing activities. By storing plans of processing operations using GDPRov, it is possible to compare the old and new versions of a plan, detect changes, and identify whether corresponding updates to consent are needed.

An exploration of above as change detection was published in Managing the Evolution and Preservation of the Data Web workshop co-located with ESWC 2018 (Harshvardhan J Pandit, O’Sullivan, and Lewis 2018). It described comparison of plans represented using P-Plan to identify changes based on the above obligation.

The change detection, visualised in Figure 5.9, is based on identifying differences between two plans in terms of steps and variables and whether they have been added, removed, or modified. In the figure, the change reflects removal of a step - which by itself does not require any changes to given consent since no new purposes have been added to an existing given consent. Using this approach, the detected change can be analysed - manually for complex and legal interpretations and automatically for simpler or simplified graphs - and used to identify whether corresponding changes are necessary based on compliance obligations.

5.3.4 Evaluation

The ontology assessment was based on the methodology outlined in Section 5.1 regarding criterion for ontology quality and documentation. The ontology was used in two applications developed to demonstrate use of SPARQL to query information (see Section 6.1) and SHACL to validate information for GDPR compliance (see Section 6.2). The experience demonstrates suitability of GDPRov in representing the required information, and led to addition of ConsentAgreementTemplateBundle (in v0.7) as a concept for convenience in representing ‘bundled’ consent requests and provisions based on consent workflows on a website where a single dialogue is used to collect consent involving multiple distinct purposes and third parties.

GDPRov was published (Pandit and Lewis 2017) as a peer-reviewed publication in Workshop on Society, Privacy and the Semantic Web - Policy and Technology (PrivOn) co-located with the 16th International Semantic Web Conference (ISWC). The workshop provided reviews from domain experts in privacy, legal, and semantic web domains; with ISWC being a top-tier conference in semantic web domain. As of February 2020, this publication has received 18 citations to (excluding self-citations) on Google Scholar¹⁴⁴ of which 2 are deliverables of CitySPIN research project (see Section 3.2). A publication describing an approach for annotating DFDs (data flow diagrams) with information for analysing compliance (Debruyne et al. 2019) utilised GDPRov to represent personal data as an entity used in activities within its ontology for representing DFDs to abstract processing operations as data flows.

5.3.4.1 Fulfilment of Competency Questions

An assessment of the extent to which GDPRov satisfies competency questions by providing concepts and relationships is presented here as part of its evaluation. The competency questions, summarised in Section 5.3.1, were used to guide development of ontology and therefore are used to evaluate the extent to which the developed ontology meets requirements of representing this information. Table lists concepts and properties for answering competency question (with N/S used to indicate not in scope).

Questions not in scope (marked as N/S either require clarity from authoritative sources regarding interpretation of information to provide a concrete design pattern or have multiple possible representations of which it cannot be determined which is more useful from a legal compliance point of view. Examples include location of recipients - which can be expressed either through an property/annotation associated with a data sharing activity or attached with a particular third party; and specifying time limits or duration or conditional events associated with data storage and deletion periods. These have been identified as future work regarding further development of the ontology based on differing interpretations of representation, complexity of specifying values such as “EU membership” and “as long as required”, and pending expert opinion of legal authorities on these issues through courts or executive decisions. These are considered minor issues regarding representation of information as they do not have a major impact on design and use of GDPRov. Approaches and ontologies in SotA provide alternative design patterns which can be used as non-authoritative approaches for short-term mitigation of this issue.

The presented evaluation demonstrates GDPRov satisfies requirements of answering competency questions regarding representation of activities and identifies those that are needed to be resolved as future work based on availability of legal opinion and decisions. GDPRov thus fulfils research objective RO3(b) by providing representations of activities associated with personal data and consent in ex-ante and ex-post phases.

Comparison with SotA

The representation of process flows and activities associated with GDPR compliance in existing approaches was presented and analysed as part of state of the art in Table. The attributes for this analysis involved features or concepts that could be represented using the specified approach and basis for representation in existing vocabularies and standards. The analysis demonstrated existence of a variety of approaches that utilised existing standards of PROV-O and BPMN to model GDPR-specific information regarding process flows and activities in both ex-ante and ex-post phase. It found that approaches modelling both ex-post and ex-ante phases exist and utilise PROV-O as their basis for representation of information.

A comparison of GDPRov with SotA is provided in using the same attributes used for analysis. The table lists features supported by each approach using a check mark (✓) with a blank indicating no information regarding the feature was found. Column headings corresponding with expression of information supported by an approach, and use following abbreviations - (Repr): method used for representation of process flow; (EA): whether it permits Ex-ante modelling; (EP): whether it permits Ex-post modelling; (Pu): whether Purpose can be specified; (Pr): whether Processing can be specified; (DS): if Data Sharing can be modelled; (Rp): if Recipients are associated with data sharing; (St): whether Data Storage occurs; (Rg): if provision of Rights can be modelled; and (LB): if Legal Basis can be associated with a process flow.

The table demonstrates that GDPRov supports all of analysed features and is the only one currently providing all of them. However, this analysis only takes into consideration abstract existence or provision of features and does not take into consideration context of an approach or its granularity. For example, while an approach may provide representation of data storage concepts, there are additional features such as storage duration, condition, form or medium, security, and policy which are also relevant in evaluation of GDPR compliance. These are highly dependant on individual use-cases and domains, and contain existing work which can be used to represent them such as Time ontology for temporal annotations and ODRL ontology for conditions and events as policies. Since the scope of GDPRov is limited to expression of information regarding activities in ex-ante and ex-post phases, representation of such granular attributes is relevant but not the primary focus within its scope and is therefore not considered in its evaluation or comparison with SotA.

Regarding expression of information as being in either ex-ante or ex-post phase - GDPRov is the only approach to do so using existing ontologies of PROV-O and P-Plan based on a scientific workflow model which is useful in investigation of executions based on a plan and association of information between ex-ante and ex-post phases. The use of PWO in MIREL project also follows a similar rationale though it does not provide the same extent of concepts and representations as GDPRov. In addition, utilisation of PROV-O as its base ontology enables information represented using GDPRov to be captured and recorded as provenance information using PROV-O or GDPRov itself. This provides capabilities for documenting evolution of a system as well as representing state of compliance at a given moment in time. This feature is shared by all approaches that utilise a provenance based ontology at their core, and especially the ones that utilise PROV-O as it is a well-recognised and adopted standard. The combination of PROV-O and P-Plan enables a flexible representation of activities by specifying their constituent steps and involved artefacts at an arbitrary level of granularity while providing annotations and classes to link these with GDPR. In this, GDPRov is unique and novel within SotA.

Based on this, GDPRov’s novelty within SotA is based on it being one of few approaches using PROV-O to represent activities for GDPR compliance in both ex-ante and ex-post phases. GDPRov is also novel in its provision of concepts associated with GDPR and granularity afforded by use of PROV-O and P-Plan to link information in ex-ante and ex-post phases. Furthermore, GDPRov is one of few approaches to be available under an open and permissive license (CC-by-4.0) thereby enabling its use, adoption, and further evolution.

Application to external use-case from SPECIAL project

The SPECIAL project uses a scenario¹ to motivate their work and demonstrate use of developed technologies in their deliverables (D1.7 ) and peer-reviewed publications (). In this section, the scenario is adapted as an external use-case to evaluate GDPRov’s suitability to express required concepts.

The use-case is summarised as follows with GDPR concepts added in parenthesis for relevance: Sue (Data Subject) buys a wearable appliance for fitness tracking from BeFit (Data Controller), and is presented with an informed consent request that describes collection of biomedical parameters such as heart rate (Personal Data) and how they will be processed, which are stored in BeFit’s cloud and transmitted for purposes of: giving Sue feedback on her activity, such as calories consumption; and creating an activity profile that will be shared with other companies for targeted ads related to fitness - an optional purpose to which Sue opts-in. After two years, Sue starts receiving annoying SMS messages from a local gym that advertise its activities. Sue discovers following facts: (i) the gym has an activity profile referring to Sue, that, due to appliance’s malfunctioning, reports that she is not doing any physical exercise; (ii) the gym received Sue’s profile from BeFit, associated with a policy that allows the gym to send targeted ads to Sue based on the profile; (iii) BeFit built Sue’s profile by mining data collected by appliance; and (iv) all these operations are permitted by consent agreement previously signed by Sue and BeFit. Using this information BeFit and the gym prove that they used Sue’s data in accordance with Sue’s given consent. Sue now asks both BeFit and the gym to delete all of her data.

The use-case is accompanied with information on its interpretation in terms of GDPR terminology and its representation using SPECIAL vocabularies . To represent the use-case using GDPRov, concepts used by SPECIAL are mapped or aligned to their closest relative concepts within GDPRov (see Table.) with its RDF/Turtle representation provided in Listing. The SPARQL queries used to retrieve information depicted by statements (i) to (iv) in the scenario are provided in Listing. The RDF representation and SPARQL query utilised a simplified representation of the scenario to present only the essential fact for answering of questions.

# Entities
:Sue a gdprov:DataSubject .
:BeFit a gdprov:DataController .
:Gym a gdprov:ThirdParty .
# Personal Data
:Biomedical_Parameters a gdprov:PersonalData .
:Activity_Profile a gdprov:PersonalData .

# Register with BeFit, given consent, and generate activity profile
:Registration a gdprov:Process .
:Sue_consent a gdprov:GivenConsent, gdprtext:LawfulBasisForProcessing .
:Collect_consent a gdprov:AcquireConsentActivity ;
    gdprov:isPartOfProcess :Registration .
    gdprov:collectedConsentFromAgent :Sue ;
    gdprov:generatedConsent :Sue_consent .
:Collect_data a gdprov:DataCollectionActivity ;
    gdprov:isPartOfProcess :Registration ;
    prov-o:wasInformedBy :Collect_consent ;
    gdprov:collectedDataFromAgent :Sue ;  # from Sue's device
    gdprov:generatedData :Activity_Profile .

# Share activity profile with Gym
:Targeted_ads_related_to_fitness a gdprov:Process ;
    gdprov:hasLegalBasis :Sue_consent .
:Share_data a gdprov:DataSharingActivity ;
    :sharedData :Activity_Profile ;
    :hasSharedDataWith :Gym .
# Gym receives Sue's activity profile from BeFit
:Collect_data_from_BeFit a :DataCollectionActivity ;
    gdprov:collectedDataFromAgent :BeFit ;
    gdprov:involvesAgent :Sue ;
    gdprov:refersToProcess :Targeted_ads_related_to_fitness ;
    gdprov:generatedData :Activity_Profile . # Gym copy of data

# Sue withdraws consent
:Withdraw_consent a gdprov:WithdrawConsentActivity ;
    prov:invalidated :Sue_consent .
# BeFit and Gym deleted the activity profile
:Delete_data a gdprov:DataDeletionActivity ;
    prov:invalidated :Activity_Profile ;
    prov:wasInformedBy :Withdraw_consent .

# Query (i)
# retrieves :Activity_Profile as personal data shared with Gym
# queried over Gym's records
SELECT ?personal_data 
WHERE {
    ?personal_data a gdprov:PersonalData .
    ?activity gdprov:generatedData .
    ?activity (gdprov:collectedDataFromAgent|gdprov:involvesAgent) :Sue .
}

# Query (ii)
# retrieves :BeFit as data source
# retrieves :Targeted_ads_related_to_fitness as purpose
# queried over Gym's records
SELECT ?party, ?purpose 
WHERE {
    ?activity gdprov:generatedData :Activity_Profile .
    ?activity gdprov:collectedDataFrom ?party .
    ?activity gdprov:refersToProcess ?purpose .
}

# Query (iii)
# retrieves :Sue as data source (as Sue's device)
# queried over BeFit's records
SELECT ?data_source 
WHERE {
    ?activity_profile gdprov:generatedData :Activity_Profile .
    ?activity_profile gdprov:collectedDataFromAgent ?data_source .   
}

# Query (iv)
# retrieves :Sue_consent as the legal basis for data collection and mining
# queried over BeFit's records
SELECT ?legal_basis 
WHERE {
    {
        ?activity gdprov:generatedData :Activity_Profile .
    } UNION {
        ?activity gdprov:sharedData :Activity_Profile .
        ?activity gdprov:hasSharedDataWith :Gym .
    }
    ?activity (
            gdprov:hasLegalBasis|
            (gdprov:isPartOfProcess/gdprov:hasLegalBasis))
        ?legal_basis .
}

Through the representation of concepts within the scenario and use of SPARQL, GDPRov is shown to support representation and answering of questions within the scenario. While the scenario relies on use of SPECIAL’s policy-based vocabulary and immutable distributed ledger to store and retrieve information regarding given consent and processing activities carried out by BeFit and the Gym, these have not been replicated as storage mechanisms are not relevant within the use-case as adapted for this work.

One important conclusion from the above exercise is regarding representation of given consent where SPECIAL vocabularies represent given consent as a policy using OWL2 (Kirrane, Fernández, et al. 2018). In comparison, GDPRov does not represent information provided within consent requests and given consent, but instead records its activities and associates generated consent as an artefact representing a legal basis with purposes (specified using gdprov:Process) that rely on it. This is the consequence of GDPRov focusing on representation of activities which does not concern representation of consent. A consent-centric representation of this same scenario is presented in Section which uses GConsent to represent the scenario as interactions between consent states.

Summary

GDPRov is part of the second major contribution of this thesis. It provides an ontological representation of ex-ante and ex-post activities associated with personal data and consent for GDPR compliance. It thus fulfils research objective RO3(b) as outlined in Section 1.2. The use of GDPRov makes it possible to indicate plans associated with how personal data and consent is collected, used, stored, shared, and erased. It also enables representation of logs for activities that act over personal data and consent.

When GDPRov was first being developed (in 2016-2017), no other vocabulary was found that represented information about activities associated with GDPR compliance. The work presented as state of the art in Chapter 3 and demonstrating existence of approaches for representing information about GDPR processes were published after development and publication of GDPRov (Pandit and Lewis 2017). Of these approaches, some also utilise PROV-O to represent provenance of activities as found as presented in 3.7.3. The differentiating factor of GDPRov is in use of PROV-O and P-Plan as distinct ontologies representing ex-ante and ex-post phases of activities based on a scientific workflow model - which is novel within state of the art. Another differentiating factor is use of GDPRtEXT to define origin and relevance of concepts to their basis in GDPR.

Approaches within state of the art, such as SPECIAL (Section), demonstrate applicability of provenance vocabularies in maintaining, querying, and assessing provenance logs represented using PROV-O for GDPR compliance. While SPECIAL also provides ex-ante compliance assessment by using the same data model and logs it as a consent request instead of processing or execution (Dullaert et al. 2019), GDPRov expands further on use of provenance to include representation of plans or templates to indicate association between activities in ex-ante and ex-post phases of compliance.

5.4 GConsent - Ontology of Consent Information for GDPR Compliance

GConsent is a semantic web ontology for representing contextual information about consent based on requirements of GDPR compliance. GConsent aims to model context, state, and provenance of consent as an entity. Its scope is limited to consent as defined in GDPR and is intended towards assisting in modelling and management of information associated with compliance. It uses GDPRtEXT to denote origin and relevance of its concepts within GDPR.

GConsent is the outcome of applying the methodology presented in Section 5.1 to identify and represent information about consent and its life-cycle as required to determine compliance with GDPR. For this, information presented in Chapter 2 was used to identify validity of consent with requirements and compliance questions presented in Chapter 4 used as competency questions. The latest iteration of GConsent (v0.5) is published online¹⁴⁵ with its documentation under an open and permissive license of CC-by-4.0 and its code repository¹⁴⁶.

The design of GConsent was influenced by a real-world use-case for managing consent information based on GDPR compliance requirements, as mentioned earlier in Section 4.2.1. The design of ontology underwent several iterations based on whether it should model an association or dependency between purposes and processing operations associated with consent. The outcome, representing a decision and which is presented here, models separation between purpose and processing operations similar to other representations of consent within SotA.

5.4.1 Distinction with existing work in state of the art

Information about consent needs to be maintained and shared by multiple parties which includes data subjects who give consent, controllers who use it as legal basis, and authorities who evaluate its validity. GDPR requires information about consent across its life-cycle to be maintained, with an representation that is interoperable assisting all stakeholders in the compliance process - as outlined earlier in Section 4.1.

From existing work analysed in Chapter 3, the focus of approaches for consent is mostly on concept of ‘given’ consent i.e. consent provided by a data subject and used as legal basis by a controller. There is a lack of work regarding representing other ‘states’ of consent within its life-cycle as an entity or representation of agreement which are relevant to its use as legal basis in determination of processing of personal data and its compliance under GDPR. Examples of such states are ‘not given’, ‘refused’, ‘withdrawn’ which cannot be modelled in the same manner as ‘given consent’ as they do not reflect the same information as given consent, but are still relevant when associated with a particular instance of processing. The state of a consent reflects its status for use as legal basis and is also relevant in management of consent information from an organisation’s perspective.

Apart from the notion of states, existing approaches also lack modelling representations for events such as delegation, and associations with third parties regarding consent which have an effect on its validity regarding compliance. GConsent aims to fill this gap, and therefore to provide novelty and contribution by representing a more cohesive and complete representation of information associated with consent for GDPR.

5.4.2 Relationship with GDPRov

GConsent builds upon and is complimentary to the representation of consent in GDPRov. The definition of consent as an entity involved in activities is sufficient to express its life-cycle and provenance by using GDPRov. This includes ex-ante representation of information provided to collect consent and its subsequent agreement by an individual to produce given consent - which is then used within activities as a legal basis and may be modified, withdrawn, or revoked - signalling its effective end of life-cycle. While GDPRov is sufficient to represent these states of consent as an entity along with information about activities acting on it, the primary focus of GDPRov is for expressing information regarding its association with activities. Managing consent as a legal basis involves consideration of information such as purpose of processing, recipients, and contextual information such as medium of provision and collection, and situations such as delegation - which are not modelled in GDPRov.

GConsent aims to provide a consent-centric representation of these information categories by providing concepts relevant to resolution of valid consent as defined by requirements of GDPR compliance. In this, use of provenance concepts show an overlap with GDPRov. This is resolved through differing scopes of the two ontologies, where concepts defined within GDPRov can also be defined using corresponding concepts in GConsent and vice-versa. An example of such cohesive usage is demonstrated through application of both GDPRov and GConsent for querying and validation of information in Chapter 6. By having separation between GDPRov and GConsent, the ontologies are modular in their scope and concepts, and provide an adopter with choice regarding inclusion of semantics represented by each ontology.

5.4.3 Requirements Gathering and Establishment of Competency Questions

The scope of consent as represented within GConsent is limited to definition of consent as provided by Article 4-11¹⁴⁷ of GDPR. Other special cases of consent not included within GConsent consist of consent defined by Article 9 regarding use of special categories of personal data, Recital 33 regarding use of personal data for scientific research, and Article 8 along with Recital 38 regarding use of children’s personal data. These were not included within the scope due to their additional requirements and complexity regarding interpretation and representation using semantic web. Additionally, current lack of real-world use-cases reflecting how these types of consent would function and legal guidance on their compliance requirements is noticeably absent in context of GDPR.

GConsent is primarily based on notion of consent as a legal basis under Article 6 of the GDPR. The conditions defined in Article 7, Recital 42, and Recital 43 provide requirements for consent to be considered or determined valid as per requirements of GDPR. The Data Controller bears burden of demonstrating proof and satisfaction of requirements for consent to be considered valid as per Recital 42. This requires demonstrable proof that data subject provided consent and that it was valid as per obligations specified in GDPR.

For consent to be informed it is necessary to provide information to data subjects which includes specific purposes of processing the personal data. GDPR also provides data subjects with right to modify or withdraw consent as defined in Article 7-3. When consent is withdrawn, processing carried out done prior to withdrawal is considered valid under given consent in effect as legal basis during that period of time.

Through this, a rudimentary summary of information or attributes associated with ‘consent’ as defined by GDPR is expressed as:

• Data Subject the consent is about

• Personal Data associated with consent

• Processing operations or categories the consent is about, with data storage and data sharing having additional information requirements

• Purposes the consent is about

• Entity/Agent/Actor the consent is provided to

• Recipients of data or categories of recipients if any

These attributes are sufficient to provide a simplified representation of consent, and are used in existing approaches within state of the art - such as model of consent in SPECIAL vocabularies (Piero A Bonatti, Kirrane, et al. 2018b). However, these attributes are not sufficient by themselves to determine validity of consent as they lack information about context the consent was given in as well as changes to its state.

Therefore, further attributes associated with consent are identified and expressed as:

• Entity/Agent/Actor that provided consent - relevant in case of delegation

• Entity/Agent/Actor that revoked, withdrew, or invalidated consent - relevant in case of delegation, and authoritative actions such as by regulators or courts

• Status of consent at a given period in time

• Contextual information regarding request and giving of consent such as - location, medium, timestamp, expiry

• Contextual information regarding revocation, withdrawal, and invalidation of consent such as - location, medium, timestamp, expiry

In addition to these, provenance information regarding how consent was requested and obtained is also important. Specifically, information about specific processes and artefacts used in provision of request for consent should be recorded as they must satisfy GDPR qualitative requirements - such as request being clearly stated and being unambiguous.

To derive required concepts, competency questions were identified from compliance questions presented in Section 4.2 pertaining to given consent (CMQ35-CMQ69) and change in consent state (CMQ70-CMQ87). These refer to information regarding consent (e.g. CMQ35-CMQ40), how consent was created/given/changed/invalidated (e.g. CMQ41-CMQ52), context of how consent was created/given/invalidated (e.g. CMQ53-CMQ56), and third parties associated with consent (e.g. CMQ57-CMQ58).

5.4.4 Ontology Description & Application

5.4.4.1 Core Concepts

Core concepts and relationships in GConsent describe common and primary attributes associated with consent. In this case, ‘consent’ by itself does not refer only to state of ‘given consent’ but also stands as a representation of ‘consent’ as an entity whose state is unknown or is refused, withdrawn, or invalidated by Data Subject, Controller, or an authority such as courts. This definition of consent is based on managing consent as a data entity rather than as a semantic concept pertaining to an agreement by an individual. Core concepts are associated with consent in all its states and refer to information necessary to express what the consent is about. This comprises of the 5 attributes visualised in Figure 5.10 - Data Subject, Personal Data, Purpose, Processing, and Status.

DataSubject is natural individual consent is associated with as an agreement of their choices. This individual may or may not be the same entity that gave consent - as in case of parent or guardian giving consent for a child or as an act of delegation. DataSubject class is defined as a subclass of prov:Person, and with subclass MinorDataSubject to denote a data subject that is legally a minor or a child. Each instance of Consent must be associated with one and only one DataSubject, and any further changes or modifications to a state of consent will continue to be associated with the same DataSubject. PersonalData is a set of personal data associated with consent. Where multiple personal data are associated with a single instance of consent, it is interpreted to mean union of these sets of personal data. Similarly, multiple Purpose and Processing associated with a consent are also to be interpreted as union rather than intersection. The ‘status’ or ‘state’ of consent indicates suitability of using that specific instance of consent as a legal basis for processing of personal data as defined by associated attributes.

Purpose and Processing are concepts that have semantic meaning based on their use within GDPR. ‘Processing’ is defined by Article 4-2, while ‘Purpose’ has no specific definition provided but can be summarised as intent or aim of why the set of personal data is needed or to be used for. In practice, purpose is generally defined at a higher abstract level, and often encompasses several types or categories of data. An example of this is a privacy policy specifying ‘account information’ and ‘location of service use’ - which are data categories, that are ‘collected’ and ‘used’ - which are processing operations on personal data, ‘to ensure security of the account’ - which is the purpose personal data will be processed for. The relation between a purpose and its associated processing operations is quite opaque when considered for purposes involving one or more processing operations. Based only on the description, it is difficult to determine which processing operations a purpose entails and vice versa, and their usage may not always be implied or commonly understood. Therefore, GConsent provides purpose and processing as self-declarative high-level concepts which can be extended with additional information for granularity and transparency.

5.4.4.2 Context of Consent

The context of consent refers to attributes such as location or time when instance of consent was created, invalidated, generated, changed, modified, given, or recorded. GConsent provides concepts for expressing location, medium, and timestamp to indicate instant of creation or invalidation along with capturing ‘expiry’ of consent as either an instant of time or a duration using Time vocabulary (Cox and Little 2017). The context also represents how consent was ‘provided’ by a Person or Data Subject or Delegation. The provided contexts in GConsent are visualised in Figure 5.11.

Context is associated with an instance of consent using generic property hasContext, with specialised properties extending it to indicate provision, expiry, location, time, and medium. Additional contexts can be represented and associated by extending hasContext in a similar manner.

5.4.4.3 Consent States

The state of consent determines suitability of its usage as a legal basis in processing of personal data. From a compliance perspective, there are only two categories of states - one which permits legal processing of personal data, and other being insufficient or prohibitive for processing. GConsent represents these concepts by sub-classing Status as StatusValidForProcessing and StatusInvalidForProcessing to indicate use of a consent instance as valid or invalid legal basis as depicted in Figure 5.12. Instances provided to represent states of valid consent to indicate legal processing include - explicitly given, implicitly given, and given by delegation. Instances provided that represent invalid states of consent to indicate processing should not be carried out include - unknown, not given, withdrawn, expired, invalidated, refused, and requested.

The use of state refers to tracking consent of a data subject from a legal perspective, and is aimed to aid in management of consent as an entity. For example, ‘unknown’ reflects a situation where status of consent is not known - which can occur when importing consent information from another source. This is distinct from ‘not given’ which indicates an offer has been made for obtaining consent but a data subject has not yet provided any actionable response that could indicate acceptance or refusal - which are themselves represented by states ‘given’ and ‘refused’ respectively. For meeting obligations and requirements of GDPR compliance, it is not necessary to represent consent instances with states such as unknown or refused. GConsent provides them for practical management of consent information where a controller may wish to track consent status of its processing operations throughout its life-cycle.

GDPR requires keeping track of state change for consent - for example when status changes from given to withdrawn or when consent is invalidated because by a controller or legal authority. Whenever a consent status changes, this results in a new consent instance being created, which also assists in capturing context of the consent (such as time instant). This leads to a chain of consent instances, where ‘latest’ consent is at ‘end’ of this chain and indicates most recent operation regarding consent states. It is vital to record such provenance to demonstrate past processing was in compliance with state of consent at that point in time and to show changes to consent as part of its life-cycle.

5.4.4.4 Example Use-Case

The documentation of GConsent provides example applications in four use-cases to demonstrate how information can be represented, which are - (i) change in consent state, (ii) capturing given consent, (iii) capturing consent given via delegation, and (iv) capturing consent when data is shared with a third party. The fourth use-case is presented here to demonstrate application of GConsent and use of its concepts to represent information towards GDPR compliance.

The example, visually represented in Figure 5.13, shows association of a third party in role of a data processor¹⁴⁸ with whom data is shared for purposes of advertising. The association is captured by instance ex:AdvertisingArrangement of type prov:Association, and has ex:AdPartner defined as a gdprov:Processor defined with role as gdprtext:Processor. It is also possible to list out specific arrangement for this association using prov:hadPlan property and a gdprov:Process instance to list specific steps and entities involved in data sharing arrangement.

The example serves to demonstrate practical use of GConsent in representing information about consent, where PROV-O is used to specify relationships with a Processor. GConsent can be combined or supplemented with other ontologies to define such associations and practical reflections of data sharing agreements between parties. The defined instance of consent in example enables a Controller to track state of consent as the data subject is provided with choice of whether to agree to this arrangement or to refuse it, where upon agreement the option to exercise right to modify and withdraw consent is also provided.

5.4.5 Evaluation

GConsent as an ontology was evaluated regarding its capability to express information about consent using the methodology outlined in Section 5.1. This was an iterative process where the ontology was tested and modified to accommodate the requirements of the competency questions. Changes were made to the ontology where information was found to be missing or incorrectly modelled. In particular, the iterations consisted of the degree and design of representing a dependency between purposes and processing operations associated with consent. These were ultimately rejected with the final iteration modelling purpose and processing independent of each other to provide greater granularity and reuse of these concepts. An application of GConsent towards representation of consent information for a real-world website in the application of SHACL to validate information for GDPR compliance is presented in Section 6.2.

GConsent was published as a peer-reviewed publication (Harshvardhan J. Pandit, Debruyne, et al. 2019) in Extended Semantic Web Conference (ESWC) Ontologies and Reasoning Track. As ESWC is a top-tier semantic web conference with a rigorous review process, acceptance of GConsent demonstrates its contribution as a semantic web resource. Along with this, the documentation of GConsent, available online, also provides extensive information about the ontology and its potential applications. It also provides a brief comparison of the ontology with relevant approaches within state of the art. GConsent, along with Consent Receipt standard (Lizar and Turner 2017), had a direct impact on design and development of consent information within DPV. In particular, GConsent provided concepts for expression of consent based on the GDPR and competency questions for integrating those with rest of DPV. As of February 2020, GConsent does not currently have any citations (excluding self-citations) given recency of its publication.

5.4.5.1 Fulfilment of Competency Questions

Assessment of the extent to which GConsent provides concepts and relationships to answer competency questions is presented in Table. In these, the PROV-O and Time ontologies are used in conjunction with GConsent to represent provenance and temporal information about consent and changes to it. PROV-O is also used to capture association and roles of entities in activities associated with consent. Based on these, GConsent satisfies requirements of providing information for answering compliance questions regarding consent and thus fulfils research objective RO3(c).

Comparison with SotA

Existing approaches regarding consent were presented and analysed in Table, with an observation about lack of approaches modelling consent as required for GDPR compliance. demonstrates a comparison of GConsent with SotA based on attributes used in this analysis. Column headings indicate representation of information within an approach and are abbreviated to indicate - Personal Data (PD), Purpose (Pu), Processing (Pr), Data Sharing (Sh), Data Storage (St), Recipients (Rp), Data Source (S), Withdrawal of consent (W), Delegation (D), Visualisation (V), Significant effects of processing (SE), (Ct): Context (Ct), Types or States (T). A check mark () indicates the approach provides or models that information category, and a blank cell indicates that the approach does not provide representation for that information or that there is no open and public information available regarding its provision.

The table demonstrates contributions of GConsent to state of the art. Compared to SotA, GConsent provides novel contributions for representation of consent for GDPR compliance and thus extends state of the art. In particular, depiction of delegation is more detailed and provides representation of information based on compliance requirements of GDPR. As the table depicts, GConsent is currently the only approach that models delegation based on its potential relevancy to evaluation of GDPR compliance. GConsent is also novel in provision of consent states which enable documenting of information from a controller’s perspective regarding evolution of consent throughout its life-cycle. This is useful for management of consent as an entity in an information management system such as a database. The SotA usually limits consent state to given or withdrawn without consideration to its other states within its life-cycle as an entity.

Application to external use-case from SPECIAL project

The use-case described earlier in Section is used here to demonstrate use and sufficiency of GConsent in management of consent information. The use-case concerns the scenario where a data subject named Sue gives consent to BeFit company for sharing her activity profile with other companies for receiving targeted ads. She later receives ads from a local Gym and investigates to find that the Gym is using her activity profile shared by BeFit - and that this activity is consistent with her previously given consent. She then withdraws her consent and asks both companies to delete her data.

The representation of this use-case using GConsent consists of using its concepts to represent information, and then utilise SPARQL to answer queries - similar to the exercise in Section for GDPRov. Table presents concepts for representing use-case using GConsent, GDPRov, and SPECIAL vocabularies. The corresponding RDF representation using GConsent is provided in Listing with queries for deriving answers to questions (i) - (iv) in use-case provided in Listing.

# Entities
:Sue a gc:DataSubject .
:BeFit a gc:DataController .
:Gym a gc:ThirdParty .
# Personal Data
:Activity_Profile a gc:PersonalData .
# Purpose
:Targeted_ads_related_to_fitness a gc:Purpose .

# Sue gives consent to BeFit
:Consent1_registration a gc:Consent ;
    gc:isConsentForDataSubject :Sue ;
    gc:isProvidedToController :BeFit ;
    gc:forPurpose :Targeted_ads_related_to_fitness ;
    gc:forProcessing gc:CollectionOfPersonalData, 
        gc:ShareDataForTargetedAds ;
    gc:forPersonalData :Activity_Profile ;
    gc:hasStatus gc:ConsentStatusExplicitlyGiven .

# BeFit shares data with Gym 
# assumed similar 'policy' structure as SPECIAL
:ShareDataForTargetedAds a gc:DataSharing ;
    gc:involvesThirdParty :Gym .
    gc:sharesDataWithThirdParty :Gym .

:Consent_info_shared_by_BeFit_with_Gym a gc:Consent ;
    gc:isConsentForDataSubject :Sue ;
    gc:isProvidedTo :BeFit ;
    gc:forPurpose :Targeted_ads_related_to_fitness ;
    gc:forProcessing gc:UseOfPersonalData ;
    gc:forPersonalData :Activity_Profile ;
    gc:hasStatus gc:ConsentStatusExplicitlyGiven .  

# Sue withdraws consent
:Consent2_withdraw a gc:Consent ;
    gc:isUpdatedConsentFor :Consent1_registration ;
    gc:forPurpose :Targeted_ads_related_to_fitness ;
    gc:forProcessing gc:CollectionOfPersonalData, 
        gc:ShareDataForTargetedAds ;
    gc:forPersonalData :Activity_Profile ;
    gc:hasStatus gc:ConsentStatusWithdrawn .

# Query (i)
# retrieves :Activity_Profile as data shared for Sue
# queried over Gym's records
SELECT ?personal_data
WHERE {
    ?_ gc:isConsentForDataSubject :Sue .
    ?_ gc:forPersonalData ?personalData .
}

# Query (ii)
# retrieves :BeFit as data source
# retrieves :Targeted_ads_related_to_fitness as purpose
# queried over Gym's records
SELECT ?party, ?purpose {
    ?_ gc:isConsentForDataSubject :Sue .
    ?_ gc:forPersonalData :Activity_Profile .
    ?_ gc:isProvidedTo ?party .
    ?_ gc:forPurpose ?purpose .
}

# Query (iii)
# retrieves :CollectionOfPersonalData as the processing operation
# from which it needs to be inferred that data is collected from Sue
# queried over BeFit's records
SELECT ?data_processing {
    ?_ gc:forPersonalData :Activity_Profile .
    ?_ gc:forProcessing ?data_processing .
}

# Query (iv)
# retrieves :Consent1_registration as satisfying
# conditions for data sharing with Gym
# queried over BeFit's records
SELECT ?consent
WHERE {
    ?consent a gc:Consent .
    ?consent gc:isConsentForDataSubject :Sue .
    ?consent gc:forPersonalData :Activity_Profile .
    ?consent (gc:forProcessing/gc:sharesDataWithThirdParty) :Gym .
}

From the above representation and queries, GConsent demonstrates use of terms (purpose, sharing, etc.) closer to those of SPECIAL as compared to GDPRov’s representation in Section. At the same time, an inability to represent information about activities such as how data was collected or shared is also evident since GConsent does not represent them while GDPRov does. From a consent perspective, consent ‘records’ represented using GConsent are more clear and concise in terms of what consent is related to, and how it was withdrawn. The above representation therefore demonstrates GConsent’s use in managing consent information, with SPARQL queries used to retrieve answers to questions pertaining to use of Sue’s personal data within the use-case.

Summary

GConsent is an ontology for representation of consent and its associated information for GDPR compliance. It fulfils research objective RO3(c) and along with GDPRov forms the second major contribution of this thesis. GConsent has been published in a peer-reviewed publication and is available online as an open and reusable resource along with an extensive and descriptive documentation.

GConsent is currently the only approach within state of the art to provide representations of attributes of consent and its states based on requirements of the GDPR. GConsent thus represents a novel representation of consent based on GDPR and provides concept of states for practical management of consent information from a controller’s perspective. It also provide detailed information representation regarding context of consent which enables documenting information required for evaluating the validity of consent under GDPR compliance requirements.

5.5 Data Privacy Vocabulary (DPV)

The Data Protection Vocabulary (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019) is a semantic web ontology for representing information about personal data handling based on legal requirements such as those for GDPR compliance. It is the outcome of work done by W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) which consists of collaboration between a community of academics, researchers, industry stakeholders, and legal experts as initially described in Section 1.4.6. DPVCG aims to work towards establishment of interoperable standards regarding representing information about personal data processing for which there are currently no existing standards.

The DPVCG was initiated as part of SPECIAL project (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernandez, et al. 2019), and therefore bears close association and alignment with SPECIAL vocabularies. In particular, SPECIAL core vocabulary was used as the basis to create the DPV core vocabulary, which provides compatibility between DPV and SPECIAL vocabularies and frameworks.

DPV reflects a community consensus in its representation of information regarding data protection and personal data processing. While being a generic vocabulary, much of its design is based on and reflected by requirements of GDPR. DPV, and by extension DPVCG, reflect an ongoing effort to provide practical and useful semantic representations of information in an open, interoperable, and machine-readable form.

5.5.1 Relevance of DPV to this thesis

The ontologies presented in this thesis as research contributions - GDPRtEXT, GDPRov, and GConsent - were part of state of the art analysed by DPVCG in its methodology (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019). In addition, by being an active member of DPVCG and a contributor in creation of DPV, the author of this thesis has applied the experience of developing research presented in this thesis and influenced design and modelling of information within DPV.

A peer-reviewed publication of DPV (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019) presents its creation methodology and concepts where the author of this thesis was a co-first author. In addition to these, the vocabulary specification published online lists the author of this thesis as an co-editor and author of the ontology. The deliverable D6.5 (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernandez, et al. 2019) of SPECIAL project presents work of DPVCG and describes DPV based on its peer-reviewed publication (Harshvardhan J. Pandit, Polleres, Bos, Brennan, Bruegger, Ekaputra, Fernández, et al. 2019) - where the author of this thesis was also a co-lead author for the deliverable.

Owing to involvement of the author and overlap between DPV and the research question and developed ontologies in this thesis, the DPV is presented here as an external research contribution influenced by research presented in this thesis. This section describes DPV and compares it with ontologies presented in this thesis to provide an extent of their similarity and overlap. It demonstrates differences in representation of information, scope, and methodology and their complimentary nature in representing information for GDPR compliance.

5.5.2 Overview of DPV

5.5.2.1 Description of Data Privacy Vocabulary

The DPV ontology is published in the W3C namespace http://w3.org/ns/dpv with its documentation and uses the namespace prefix dpv. Its current iteration (v0.1 28 November 2019) provides classes and properties to annotate and categorise information about legally compliant personal data handling. In this context, personal data handling refers to all operations associated with processing of personal data and its management - including organisational measures which indirectly affect processing.

The DPV is a pseudo-modular ontology with a set of core concepts referred to as ‘Base Ontology’ and modular extensions further expanding each concept within the base ontology as a taxonomy. The base ontology represents top-level classes for defining a policy of legal personal data handling. The core concepts defining the base ontology are visualised in Figure 5.14 and consist of personal data category, processing, purpose, legal basis, data controller, recipient, data subject, technical and organisational measures, with the top-level concept of personal data handling which ties them together.

5.5.2.2 Personal Data Categories

DPV uses the taxonomy provided by EnterPrivacy¹⁴⁹ to define a broad hierarchy of personal data categories based on nature of information (financial, social, tracking) and to its inherent source (internal, external). In addition to these, the class dpv:SpecialCategoryOfPersonalData represents categories that are ‘special’ or ‘sensitive’ based on GDPR’s Article 9.

These personal data categories can be further extended using the sub-class mechanism to depict specialised concepts such as ‘likes regarding movies’. Sub-classing also enables representation of specific contexts such as derivation of personal data as represented by class dpv:DerivedPersonalData. This is useful to represent practical representation of personal data categories such as inference of opinions from social media. Similar classes can be additionally added to specify contexts such as use of machine learning, accuracy, and source. The aim of providing such high-level concepts is to provide a sufficient coverage of abstract categories of personal data which can be extended using subclass mechanism to represent concepts used in real-world.

5.5.2.3 Purposes

Purposes in DPV are organised hierarchically using the sub-class mechanism to represent high-level and generic purposes of data handling. Purposes provided in DPV include service provision, R&D, commercial interest, security, service optimisation, and service personalisation. These are further extended to provide a total of 31 generic purposes. These may be extended by further sub-classing to create more specific purposes as applicable to a scenario. As GDPR requires a specific purpose to be declared in an understandable manner, additional purposes can be created as sub-classes of one or several dpv:Purpose categories to make them as specific in a use-case as possible. Purposes can be restricted to specific contexts using the class dpv:Context and property dpv:hasContext. Purposes can also be restricted to a specific business sector using the class dpv:Sector and property dpv:hasSector.

5.5.2.4 Processing Categories

DPV provides a hierarchy of processing categories based on requirements of regulations such as GDPR. DPV defines top-level classes to represent following broad categories of processing - Disclose, Copy, Obtain, Remove, Store, Transfer, Transform, and Use. Each of these are further expanded using sub-classes to provide 33 processing categories, which includes terms defined in definition of processing in GDPR (Article 4-2). DPV provides properties with a boolean range to indicate nature of processing regarding Systematic Monitoring, Evaluation or Scoring, Automated Decision-Making, Matching or Combining, Large Scale processing, and Innovative use of new solutions - as these affect assessment of legal data processing under GDPR.

5.5.2.5 Technical and Organisational Measures

GDPR Article 32 requires implementing appropriate measures by taking into account state of the art, costs of implementation and - nature, scope, context, and purposes of processing - as well as risks, rights and freedoms. These are represented as technical and organisational measures in DPV. Examples include pseudo-anonymisation and encryption of personal data, ability to restore availability and access to personal data in a timely manner in event of a physical or technical incident, and a process for regularly testing, assessing and evaluating effectiveness of technical and organisational measures for ensuring security of processing. The generic property dpv:measureImplementedBy enables referencing implementation measures as comments or IRIs. The class StorageRestriction provides expression of measures used for storage of data with two specific properties provided for storage location and duration restrictions.

5.5.2.6 Consent and Legal Bases

DPV provides dpv:LegalBasis as a top-level concept to represent various legal bases that can be used for justifying processing of personal data. The definition of a ‘legal basis’ is based on justification for processing which has a provision in law. The concept itself is not based on any specific jurisdiction, but needs to be interpreted in terms of legal bases defined and provided by laws applicable within a jurisdiction.

For GDPR, which is a EU specific law and therefore is not binding in interpretation of legal bases across other jurisdiction, DPV provides legal bases specific to GDPR as a separate aligned vocabulary under https://www.w3.org/ns/dpv-gdpr and namespace (prefix: dpv-gdpr). This vocabulary defines legal bases provided by Articles 6 and 9 of GDPR to represent legal justification for processing personal data.

Consent as a special case of legal basis provided by GDPR is provided with additional properties and classes within the core DPV vocabulary to reflect information requirements associated with its validity as a legal basis. The concepts associated with consent provide terms to describe consent provision, withdrawal, and expiry. The structure of these was adapted from an analysis of existing work regarding Consent Receipt (Lizar and Turner 2017) and GConsent (Harshvardhan J. Pandit, Debruyne, et al. 2019) with the intention to enable documenting attributes associated with consent which can demonstrate and evaluate its validity based on requirements of GDPR.

5.5.3 Comparing DPV with GDPRtEXT, GDPRov, and GConsent

DPV has several commonalities with ontologies presented in this thesis arising from a common aim of representing information for legal compliance with laws such as GDPR. However, the aim and granularity of representing information about all attributes relevant to processing of personal data differentiates DPV from the scope of ontologies presented in this thesis. Given the high-level and abstract nature of DPV in its concepts and more granular and representative focus of developed ontologies, there is a possibility of aligning or combining the two based on identifying commonality of concepts. While there have been no efforts to carry out an exercise to combine or align the developed ontologies with DPV, their comparison as presented here demonstrates the possibility and applicability of such an approach.

5.5.3.1 Representing information about GDPR concepts

GDPRtEXT provides a linked data version of GDPR and a SKOS glossary of concepts associated with GDPR compliance, which can be used to link information to clauses and concepts of GDPR. This has been used by GDPRov and GConsent to define the source of its concepts within GDPR.

DPV, whose concepts represent generic legal terms, does not link its concepts to GDPR except in cases where a defined concept was directly taken from a definition provided by GDPR. In such cases, it uses the URI format prescribed by EU Publications Office to indicate specific clause of GDPR. The URI format¹⁵⁰ is similar in its structuring of contents with GDPRtEXT and is based on an upcoming iteration¹⁵¹ of ELI vocabulary which will be used in all EU published legislations to offer granular linking to their clauses. Since the format prescribed by EU Publications Office is authoritative in its nature, the links provided by GDPRtEXT need to be aligned or replaced with those defined using the newer ELI format.

One of the aims of DPVCG is to provide a glossary of concepts associated with legal personal data handling. For this, concepts of DPV itself are considered a glossary of terms, though not explicitly defined as such within the ontology. This use of ‘glossary’ refers to providing concepts to an adopter in order to represent required information in an interoperable manner. Since these terms do not necessarily arise from a particular legislation, their sources are based on their use as a commonly understood concept or notion within legal domain.

In terms of coverage, GDPRtEXT focuses on terms directly obtained from text of GDPR while DPV focuses on modelling of concepts based on their relevance to defining personal data handling in the legal domain. Therefore, while there is a small overlap in concepts directly associated with GDPR, the two vocabularies differ in provision and definition of terms. For example, GDPRtEXT defines DataSecurity based on Article 28 and 32 of GDPR as obligations for Controllers and Processors, while DPV defines Security as a purpose. To further exemplify this distinction, DPV aims to offer terms that reflect real-world practices while GDPRtEXT focuses on legal text of GDPR. This is evident from hierarchical taxonomy of concepts in DPV such as for personal data categories and purposes so as to enable modelling of practices across a broader spectrum of use-cases.

5.5.3.2 Representing information about activities

DPV does not provide representation of activities through which it can be compared with GDPRov. Instead, DPV provides concepts to represent ‘processes’ taking place within an organisation, such as those for ensuring technical and organisational measures, purposes, and processing. The modelling of an instance of personal data handling, which consists of specifying purpose, processing, and technical & organisational measures - can be compared with modelling of plans in GDPRov where a purpose represents a plan and its steps represent processing activities - which can be further annotated with measures and legal bases. Through this, it can be summarised that the focus of GDPRov is on representing activities with granularity in terms of their composition and dependency, and that of DPV is on providing metadata as an overview of processing and data handling practices. With this, it is possible to define an instance of personal data handling using DPV to indicate a high-level summary and expand it using GDPRov to represent details of processes and capture their provenance in ex-ante/ex-post phases.

5.5.3.3 Representing information about consent

The DPV and GConsent both provide concepts to represent information about consent based on requirements specified by GDPR. In this, both share an aim to document context of consent with a view towards establishing its validity and compliance. The difference between the two is based on granularity and use of existing vocabularies to represent this information.

The DPV utilises the model provided by its core or base vocabulary to represent information by specifying consent as a legal basis used to justify processing of personal data. In addition to this, it provides properties to indicate the specific notice displayed to obtain consent, its expiry, obtaining or provision of consent, and its withdrawal. In this, attributes such as timestamp and method used to carry out provision and withdrawal are used to indicate information regarding how consent was obtained. This is based on updating concept from Consent Receipt with requirements of GDPR.

The DPV does not prescribe or utilise any existing vocabulary to specify information. In contrast, GConsent provides similar concepts as DPV base vocabulary and uses vocabularies of PROV-O and GDPRov to represent information about activities. Given that GConsent was an input to DPV and by extension influential in its modelling of consent, there is a degree of compatibility between the two based on similarity of concepts. In this, GConsent provides a more detailed vocabulary for consent while DPV provides a minimal set of concepts regarding consent but is more expressive in representing information through its taxonomies.

5.5.4 Comparing DPV with SotA

This sections compares the DPV with approaches presented in the SotA in Chapter 3. The aim of this exercise to demonstrate extent of DPV’s contributions and present its comparison with approaches in SotA. Since DPV is not presented as a direct contribution of this thesis, its formal evaluation is not within scope of this thesis.

The aim of DPV as established by DPVCG is providing a vocabulary for personal data handling which concerns representation of information relevant for legal compliance - in this case associated with GDPR. Based on this, DPV is a vocabulary useful towards representing information about processing of personal data rather than a framework or methodology that can be used to evaluate compliance. Currently, DPV is not accompanied by any documentation demonstrating its use or application in use-cases, though such activities are planned in near future.

Comparing DPV with other vocabularies in SotA as presented in Chapter 3, DPV provides a large amount of concepts in its top-down taxonomies which can be expanded with additional concepts. This enables it to be adapted and expanded for use-cases. This aspect of the DPV is novel within SotA as no other approach aims to provide a similar taxonomy of concepts, and does not incorporate requirements of extending it for a given use-case such as through sub-classing mechanism.

The DPV base vocabulary provides a compact structure representing personal data handling which aims to represent all relevant information required to evaluate and demonstrate compliance. In this, it bears resemblance to SPECIAL core vocabulary (Piero A Bonatti, Kirrane, et al. 2018a) which is self-explanatory given that DPVCG was an extension of SPECIAL’s work on its vocabularies. This approach is more suitable for representation or documentation of information from a compliance perspective, and is not intended to be specific to any particular law - though the GDPR clearly has a significant influence on its vocabulary. This is again in contrast to approaches in SotA which are often intended to be applied to a particular legislation and a specific use-case.

The representation of technical and organisational measures is the most distinctive feature of DPV, as currently no other approach within SotA provides a comparable representation of these. While there have been efforts to establish vocabularies regarding specification and representation of privacy policies, these tend to focus on use of concepts such as purpose, processing, data storage, data sharing, third parties - which have been utilised quite commonly in SotA.

Summary

This chapter presented the ontologies created to fulfil research objective RO3 along with the methodology used for their development and evaluation. It also provides a comparison of ontologies with related approaches in SotA as presented in Chapter 3.

The ontology engineering process presented in Section 1.3.3 described the methodology used for creating ontologies based on best-practices and guidelines advocated by semantic web community. This included ensuring ontology quality, documentation, and releasing developed resources under an open and permissive license. It also described utilisation of compliance questions presented in Section 4.2 as competency questions.

The presented ontologies consisted of GDPRtEXT, GDPRov, and GConsent. GDPRtEXT, presented in Section 5.2, provides a linked data version of text of GDPR created by extending the official ELI (“Council Conclusions Inviting the Introduction of the European Legislation Identifier (ELI)” 2012) ontology to represent GDPR in a granular manner. It also presents a SKOS glossary of concepts associated with GDPR compliance derived from its text. GDPRtEXT enables association and linking of information with concepts and clauses of GDPR through use of persistent IRIs. It thus fulfils research objective RO3(a). GDPRtEXT extends state of the art by providing an ELI-compatible extension capable of representing GDPR clauses at a granular level. It is also novel in providing a glossary of concepts associated with GDPR compliance.

GDPRov provides an OWL2 ontology for representing activities associated with personal data and consent in ex-ante and ex-post phases. It is presented in Section 5.3. The ontology is based on extending existing ontologies of PROV-O (Lebo et al. 2013) and P-Plan (Garijo and Gil 2014) with GDPR terminology to represent activities in context of compliance requirements. GDPRov is novel in use of PROV-O and P-Plan together based on a scientific workflow model to represent processes for GDPR compliance. It provides an extensible model that can be used for representing processes related to compliance which can be extended for representing related processes such as compliance activities and organisational processes. Use of GDPRov enables capturing provenance of plans or snapshots of a system at a given time and document them as evidence of planned and maintained compliance. Use of P-Plan with PROV-O enables associating execution of activities with their intended planning and thereby provides systematic linking of ex-ante and ex-post compliance information. GDPRov thus fulfils research objective RO3(b).

The representation of consent is provided by GConsent - an OWL2 ontology presented in Section 5.4 that fulfils research objective RO3(c). GConsent provides representation of information relevant for evaluation of consent under GDPR obligations and requirements. It extends representation of consent as an artefact in GDPRov and models life-cycle of consent based on the concept of states. State or status of consent reflects its suitability for use as a legal basis for processing and is modelled based on management of consent information from an organisation’s perspective. In this GConsent is novel within SotA. GConsent is also novel in provision of concepts related to consent for GDPR as it provides a more detailed and comprehensive vocabulary for representing information regarding consent.

The chapter also presented the DPV vocabulary published by W3C Data Privacy and Vocabularies Community Group (DPVCG). The author of the thesis was an active contributor to DPV, and subsequently DPV shares its aim and bears similarity to research presented in this thesis. Section 5.5 provides a summary of DPV and compares it with ontologies presented as contributions in this thesis - namely GDPRtEXT, GDPRov, and GConsent. A comparison of DPV with SotA is also provided. DPV is intended to provide a vocabulary for representing information about personal data handling and is not limited to GDPR though it is influenced by it. It reflects a community consensus and is intended to be standardised, thereby providing a strong basis for its adoption.

Through these developed ontologies and the significance of DPV, the primary motivation guiding this research as outlined at the beginning of this thesis (Section 1.1) regarding representing information and associating it with GDPR has been addressed. In the next chapter, use of semantic web technologies to query this information to answer compliance questions, such as those presented in Section 4.2, is presented. The next chapter also presents use of semantic web technologies in validating information to ensure its correctness for assessing GDPR compliance based on constraints presented in Section 4.2.3. The querying and validation of information are minor contributions of this thesis, and satisfy research objectives RO4 and RO5 respectively. For this, the next chapter utilises real-world use-cases to demonstrate application of developed ontologies of GDPRtEXT, GDPRov, and GConsent to represent, query, and validate information for GDPR compliance.

6 Querying and Validating Information for GDPR Compliance

This chapter presents an application of semantic web technologies to query and validate information for GDPR compliance. In this, information is represented using developed vocabularies of GDPRtEXT, GDPRov, and GConsent - as presented in Chapter 5. The queries are represented using SPARQL - a W3C standard for querying RDF - and are based on compliance questions presented in Section 4.2. Validation is carried out based on identified assumptions and constraints presented in Section 4.2.3 and is expressed using SHACL - a W3C standard for representing constraints. The presented work represents minor contributions of this thesis, and fulfils research objective RO4 regarding querying of information and RO5 regarding validation of information for GDPR compliance.

Section 6.1 presents use of SPARQL to query information for answering compliance questions. Use of SHACL to validate information for GDPR compliance is presented in Section 6.2. The chapter ends with conclusions drawn from this research in Table regarding novelty of contributions.

6.1 Querying Information using SPARQL

This section presents creation and utilisation of SPARQL queries to retrieve information relevant for GDPR compliance. Creation of queries is dependant on ontological representation of information being retrieved, which in this case includes use of GDPRov and GDPRtEXT ontologies. As no consent instances needed to be represented, GConsent was not used. This is further explained in Section 6.1.1.

A GDPR preparation guide published by Irish Data Protection Commission was used as source of questions for which corresponding the SPARQL queries were created. The methodology used for this is presented in Section 6.1.2 with a demonstration of developed queries presented in Section 6.1.3. A note on evaluation of this work is presented in Section 6.1.4.

6.1.1 SPARQL queries and ontological representation of information

The research regarding querying presented here is based on the task of retrieving information for answering questions relevant to assessment of compliance. It represents utilisation of technical solutions to automate information retrieval and requires machine-readable data (or metadata). For this, developed ontologies provide concepts and relationships necessary to express information using GDPR terminology and enable association of information with clauses and concepts of GDPR.

The compliance questions, as presented in Section 4.2, do not use a specific ontology or vocabulary but instead are based in natural language and use legal terminology. In order to utilise technological solutions for answering them, it is necessary to first convert these questions into queries using ontological concepts. As research presented in this thesis derives motivation for use of semantic web technologies which use RDF for representing information, querying this utilises SPARQL to retrieve this information.

Ontologies used in SPARQL queries must match ontologies used in representation of information it aims to retrieve. Differences in ontologies hamper effective execution of queries with potential returning of invalid or empty results. Creation of these SPARQL queries is therefore specific to ontologies of GDPRov and GDPRtEXT used for information representation.

6.1.2 Methodology

The methodology used for creation of SPARQL queries is based on utilisation of GDPRov to represent concepts and GDPRtEXT to link information to GDPR. SPARQL queries thus created aim to retrieve information relevant to answering a question rather than show evaluation or assessment of compliance. While compliance questions presented in Section 4.2 provide a basis for construction of semantic queries using SPARQL, presented application of SPARQL utilises a real-world use-case of questions to provide an demonstration of this research.

6.1.2.1 Utilising compliance questions from GDPR readiness guide published by DPC

The application of SPARQL utilised the guide titled “Preparing Your Organisation for the GDPR – A Guide for SMEs” published by Data Protection Commission of Ireland (DPC) as basis for (compliance related) questions which were represented using SPARQL as semantic queries. The guide was published by DPC in 2017 to help organisations in assessing their readiness towards GDPR compliance requirements. It is accessible online¹⁵² and consists of a ‘table’ (see Figure [fig:sparql:guide]) containing questions regarding information about an organisations processing activities. The guide was chosen based on its simplicity in terms of questions, its intended use in evaluating information associated with compliance, and locality of Irish DPC with respect to the author.

The guide divides questions into contextual sections based on addressing specific GDPR articles and obligations.

6.1.2.2 Steps of the methodology

The steps followed in utilising questions in the guide to create SPARQL queries and demonstrate their application were as follows:

1. Analyse questions within the document to identify corresponding concepts and relationships in GDPRov and GDPRtEXT (see below). The questions largely concerned details of processing activities and organisational practices and therefore did not require use of GConsent.

2. Represent questions as SPARQL queries using GDPRov and GDPRtEXT (see below)

3. Create a synthetic use-case based on processing of personal data with GDPRov and GDPRtEXT used to represent information (see Section 6.1.3)

4. Execute SPARQL queries over use-case to retrieve answers for compliance questions (see Section 6.1.3)

5. Evaluate queries based on subjective criteria of - a) Extent of answering compliance questions b) Suitability of retrieved results in answering compliance questions (see Section 6.1.4)

6.1.2.3 Analysis of GDPR Readiness Guide

The guide contains 63 questions across 13 pages that are presented in 9 sections. Its analysis consisted of categorising questions based on requirements of information, relation to phases of compliance, and whether they were suitable to be implemented as SPARQL queries. The analysis was recorded and published online¹⁵³ as a spreadsheet with comments describing interpretation of each question’s information requirements.

The first set of questions on page 1 concern consent and personal data and are structurally different than other sets in that they are more abstract and generic and concern overall practices concerning processing of personal data by an organisation. These questions are described under ‘general’ category with other groups of questions having their category mentioned explicitly within the document. Questions in general category require information and practices associated with consent and personal data. Other categories contain questions which enquire explicitly about activities and mechanisms regarding compliance to specific obligations.

The questions were analysed and categorised based on their intended requirements towards information required for compliance. The three categories identified through this exercise were - demonstrative, evaluative, and assistive - based on requirements of information associated with them. Demonstrative questions require answers that satisfy the question and do not need further actions or processing based on information. Assistive questions provide information that needs to be directly evaluated for compliance, with ‘assistive’ indicating information that assists evaluation of compliance. Evaluative questions retrieve information whose evaluation requires further information retrieved through additional questions based on provided information. The primary difference assistive and evaluative questions is whether they retrieve information which can be evaluated as is for compliance or whether it requires additional questions to retrieve further information. These terms used for categorisation do not relate to any specific methodology used in legal compliance, but are useful to analyse questions from an information management perspective.

Questions were also analysed based on whether they relate to or require information regarding activities in ex-ante and ex-post phases. The questions do not explicitly provide an indication of whether they enquire about a model of processing (ex-ante) or logs (ex-post). The distinction was made based on whether a question concerned information about practices, plans, or intentions regarding processing of personal data - in which case it was deemed to enquire about ex-ante information. Similarly, if a question concerned past execution of activities or records of activities - it was specified to enquire about ex-post information. In some cases, questions were specified to enquire about both ex-ante and ex-post information based on potential application in both phases.

An overview of the questions is provided in Table. It assigns an ID for each question to enable associating it with corresponding SPARQL queries and for linking related questions in analysis. The column ‘Category’ reflects category of question mentioned within the guide, with ‘general’ used for initial generic questions. ‘Title’ refers to title of text within the guide, and column ‘GDPR’ refers to an explicit mention of a GDPR clause within the question or its description.

Table presents a summarised view of analysis of questions presented in Table. The complete information along with additional comments and fields is available in an online version of analysis. In the table, column ‘Type’ indicates type of query based on categorisation as demonstrative, assistive, evaluative based on description in previous sections. Column ‘Data’ provides information on information required for the question, including results of other queries. Relation of question to ex-ante phase of compliance is reflected by column ‘E/A’ and ex-post phase by column ’E/P’ using boolean Y/N values. Column ‘SPARQL’ indicates whether a SPARQL query was constructed for the corresponding question, with N indicating that a query was not constructed. Column ‘GDPRov’ indicates whether the latest iteration (v0.7) of GDPRov provides concepts and relationships to answer the question, with a value of Y indicating that it does, N indicating it does not provide concept, and S indicating information to be out of scope. Where a query was not constructed, the reason can be inferred by combining values in SPARQL and GDPRov columns - for example, where concepts were out of scope for GDPRov query was not constructed due to lack of concepts.