The Data Privacy Vocabulary (DPV) provides terms (classes and properties) to describe and represent information related to processing of personal data based on established requirements such as for the EU General Data Protection Regulation (GDPR). The DPV is structured as a top-down hierarchical vocabulary with the core or base concepts of personal data categories, purposes of processing and types of processing, data controller(s) associated, recipients of personal data, legal bases or justifications used, technical and organisational measures and restrictions (e.g. storage locations and storage durations), applicable rights, and the risks involved.

The namespace for DPV terms is http://www.w3.org/ns/dpv#
The suggested prefix for the DPV namespace is dpv
The DPV and its documentation is available on GitHub.

This document is published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a deliverable and report of its work in creating and maintaining the Data Privacy Vocabulary (DPV).

Introduction

The Data Privacy Vocabulary provides terms (classes and properties) to describe and represent information about personal data handling. In particular, the vocabulary provides extensible taxonomies of terms to describe the following components:

• Personal Data Categories
• Purposes
• Processing Categories
• Technical and Organisational Measures
• Legal Basis such as Consent
• Entities such as Recipients, Data Controllers, Data Subjects
• Rights
• Risks

These terms are intended to repersent personal data handling as machine-readable information by specifying personal data categories undergoing processing, its purpose(s), the data controller(s) involved, recipient(s) of this data, the legal bases or justifications used (e.g. consent or legitimate interest), involving technical and organisational measures and restrictions (e.g. storage location and storage duration), the applicable rights, and possibility of risks.

As the Legal Bases are dependant on legal jurisdictions, we provide the legal bases defined by GDPR as a separate 'extension' of the DPV called DPV-GDPR. The DPV is intended to be a 'general vocabulary', with extensions used to extend any apply it in jurisdiction, domain, and use-case specific requirements.

Examples of applications where the concepts provided by the DPV can be used are:

1. represent policies for personal data handling
2. represent information about consent e.g. provenance of consent
3. log/document personal data handling actions e.g. by a data controller
4. support automated checking of legal compliances of data handling ex ante (prior to processing), or ex post (i.e. check compliance after processing)

Namespaces

The namespace for DPV vocabulary is http://www.w3.org/ns/dpv#. The table below indicates the full list of namespaces and prefixes used in this document.

The DPV, as it is provided, does not recommend any specific way to use its concepts. Adopters are free to utilise their preferred models (e.g. RDFS-style, OWL2-style, or simply as a list of terms), though we strongly recommend being aware of the implications of using a specific model regarding interpretation, reasoning, and interoperability.

Base Vocabulary

Concepts in the Base vocabulary are available as an individual module here.

The 'Base' or 'Core' vocabulary describes the top-level classes required for defining a 'policy' for personal data handling. Classes and properties for each top-level class are further elaborated using sub-vocabularies, for example a taxonomy of personal data categories. While all concepts within the vocabulary share a single namespace, the modular approach makes it possible to use only the specific taxonomies or sub-vocabularies, for example to refer only to purposes. The DPV provides the following as top-level concepts and generic properties to associate them with other concepts:

Along with these, the DPV defines the concept of [=PersonalDataHandling=] for representing a 'policy' associating the top-level concepts with one another. For example, using [=PersonalDataHandling=] it is possible to indicate the application of a specific purpose and processing to categories of personal data relating to data subjects (or individual), along with the data controller responsible, the recipients of data, legal basis used, the technical and organisational measures involved, rights provided, and the possibility of risks.

The DPV does not mandate the use of [=PersonalDataHandling=]. Adopters can define their own interpretation of what concepts personal data handling involves, or define a separate concept similar to [=PersonalDataHandling=]. For example, one may specify that a [=PersonalDataHandling=] is only associated with [=Purpose=], [=Processing=], [=PersonalDataCategory=], and [=Recipient=] where the legal basis and technical and organisational measures are either assumed or defined externally. In continuation of this, the DPV also does not provide any constraints on the inclusion or exclusion of concepts used to define an instance of [=PersonalDataHandling=]. Possibilities for specifying such constraints include use of OWL2 semantics and SHACL to specify mandatory concepts. For example, requiring every instance of [=PersonalDataHandling=] must have at least one Personal Data Category, Controller, Purpose, and Legal Basis.

Personal Data Categories

Concepts related to Personal Data Categories are available as an individual module here.

DPV provides broad top-level personal data categories adapted from the taxonomy contributed by R. Jason Cronk [[EnterPrivacy]]. The top-level concepts in this taxonomy refer to the nature of information (financial, social, tracking) and to its inherent source (internal, external). Each top-level concept is represented in the DPV vocabulary as a Class, and is further elaborated by subclasses for referring to specific categories of information - such as preferences or demographics.

While this taxonomy is by no means exhaustive, the aim is to provide a sufficient coverage of abstract categories of personal data which can be extended using the subclass mechanism to represent concepts used in the real-world.

Regulations such as the GDPR define personal data at an abstract level as information (directly or indirectly) associated with an individual or a category of individuals. DPV defines classes representing categories that are inclusive of information associated with them (e.g. name consisting of first name, last name), with their instances representing specific elements of persona data (e.g. “John Doe” as name).

The categories defined in the personal data categories taxonomy can be used directly or further extended by subclassing the respective classes to depict specialised concepts, such as “likes regarding movies” or combined with classes to indicate specific contexts. The class [=DerivedPersonalData=] provides one such context to indicate information has been derived from existing information, e.g. inference of opinions from social media. Additional classes can be defined to specify contexts such as use of machine learning, accuracy, and source. Similarly, the class [=SpecialCategoryPersonalData=] represents categories that are ‘special’ or ‘sensitive’ and require additional conditions, e.g. as per GDPR’s Article 9.

The following is an overview of the concepts provided for personal data within the DPV:

Purposes

Concepts related to Purposes are available as an individual module here.

DPV at the moment defines a hierarchically organized taxonomy of generic categories of purposes (for processing of personal data). Regulations, such as GDPR, require the purpose to be declared in a specific and understandable manner. We therefore suggest to declare the purpose being used as an instance of one or several dpv:Purpose categories and to always declare the specific purpose with a human readable description (e.g. by using rdfs:label and rdfs:comment).

DPV provides a way to indicate purposes are restricted or fall within a specific business sector using the class [=Sector=] and the property [=hasSector=]. Hierarchies for defining business sectors include NACE maintained by EU [[NACE]], NAICS maintained by USA [[NAICS]], ISIC maintained by UN [[ISIC]], and GICS maintained by commercial organisations MSCI and S&P [[GICS]]. Multiple classifications can be used through mappings between sector codes such as the NACE to NAICS alignment provided by EU [[NACE-NAICS]].

We provide an interpretation of the NACE revision 2 codes which uses rdfs:subClassOf to specify the hierarchy, available here. The NACE codes have the namespace dpv-nace and are represented as dpv-nace:NACE-CODE.

Purposes can be further restricted to specific contexts using the [=Context=] and the property [=hasContext=]. In this case, 'context' refers to a generic context which can be expanded as applicable within a use-case or domain.

For using purposes, we suggest selecting the most appropriate or applicable purpose over more abstract ones by selecting or extending the relevant classes in the purpose taxonomy. For example, the purpose [=ServiceOptimization=] is further sub-classed to indicate optimisation for consumer as [=OptimisationForConsumer=] and for controller as [=OptimisationForController=].

The following is an overview of the concepts within the purpose taxonomy:

Processing Categories

Concepts related to Processing are available as an individual module here.

DPV provides a hierarchy of classes to specify the operations associated with the processing of personal data. Declaring the processing or processing categories associated with personal data is required by regulations such as the GDPR. Processing operations (e.g. collect, share, and use) can have specific constraints or obligations which makes it necessary to accurately represent them. While the term ‘use’ is liberally used to refer to a broad range of processing categories in privacy notices, we suggest to select and use appropriate terms to accurately reflect the nature of processing where applicable.

There are a variety of terms used for describing processing operations depending on specific interpretations within the technological, legal, or sociological domain. We consolidate these terms and define the follow 'top-level' concepts to create a hierarchical taxonomy for categories of processing: [=Disclose=], [=Copy=], [=Obtain=], [=Remove=], [=Store=], [=Transfer=], [=Transform=], and [=Use=]. Each of these are then further expanded using subclasses within the taxonomy.

Although the DPV taxonomy of processing categories includes terms mentioned in the definition of processing in GDPR (Article 4-2), their interpretation is based on common understanding (i.e. dictionary definition) and legal interpretation. Where the interpretation of a term differs significantly within a jurisdiction, it is advisable to declare it in a separate vocabulary as an extension to the DPV, similar to DPV-GDPR. An example of where terms differ between common understanding and jurisdiction-dependent definitions is the term 'sell' mentioned within the California Consumer Protection Act (2018) 1798.140(t), which includes "selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating".

Along with information about the processing 'operation', regulations (e.g. GDPR) also require additional information such as scale of processing, extent of automation and human involvement, source of data, consequences, and algorithmic logic. DPV declares such concepts as top-level classes which can be used in combination with the processing (or other concepts such as purposes) to indicate their application.

Terms such as evaluation or scoring are defined within the processing categories because they relate to the specific operations or activities taking place over personal data. This is not to be confused as indicating a purpose, since they still need to be applied or defined towards a specific 'purpose' for the processing. For example, consider an use-case for scoring an individual for rankings in an online competition - here the 'scoring' is indicative of the processing operations while 'rankings' is the purpose.

The following is an overview of the concepts provided within the DPV processing taxonomy: