Primer

The Data Privacy Vocabulary [[DPV]] enables expressing machine-readable metadata about the use and processing of personal data based on legislative requirements such as the General Data Protection Regulation [[GDPR]]. This document acts as a ‘Primer’ for the DPV by introducing its fundamental concepts and providing examples of use-cases and applications. It is intended to be a starting point for those wishing to use the DPV and an orientation for people from all disciplines. The canonical URL for DPV is https://w3id.org/dpv# which contains its specification.

This primer document aims to ease adoption of DPV by providing:

A high-level conceptual explanation of the DPV and its modelling of concepts;
Self-contained examples that illustrate how the concepts and data models provided by DPV can represent information associated with personal data handling (for the concept, see Section); and
Guidance towards application of DPV in use-cases and technologies.

DPV v1.0 - beta The current release is a beta/test version intended to be published as a v1. Feedback can be provided via GitHub or [email protected] (mailing list).

DPV Family of Documents

[[[DPV-Primer]]]: (this document) An introductory document for DPV's concepts and taxonomies.
Newcomers to the DPV are strongly recommended to first read through the Primer to familiarise themselves with the semantics and concepts of DPV.
[[[DPV]]]: The formal and normative description of DPV and its concepts, with serialisations in RDFS & SKOS [[DPV-SKOS]] and OWL2 [[DPV-OWL]]
Extensions to Concepts:
- [[[DPV-GDPR]]]: serialisations: [[DPV-SKOS-GDPR]], [[DPV-OWL-GDPR]]
- [[[DPV-PD]]] serialisations: [[DPV-SKOS-PD]], [[DPV-OWL-PD]]
- [[[DPV-LEGAL]]] serialisations: [[DPV-SKOS-LEGAL]], [[DPV-OWL-LEGAL]]
- [[[DPV-TECH]]] serialisations: [[DPV-SKOS-TECH]], [[DPV-OWL-TECH]]
- [[[RISK]]] serialisations: [[RISK-SKOS]], [[RISK-OWL]]
[[[DPV-GUIDES]]]:
- [[[DPV-GUIDE-OWL2]]]
Other Resources:
- [[[DPV-NACE]]]
- [[[RIGHTS-EU]]] serialisations: [[RIGHTS-EU-SKOS]], [[RIGHTS-EU-OWL]]

Related Links

Releases are published on GitHub
For a general overview of the Data Protection Vocabularies and Controls Community Group [[DPVCG]], its history, deliverables, and activities - refer to DPVCG Website.
The peer-reviewed article “Creating A Vocabulary for Data Privacy” presents a historical overview of the DPVCG, and describes the methodology and structure of the DPV along with describing its creation. An open-access version can be accessed here, here, and here.

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).

Contributing to the DPV and its extensions The DPVCG welcomes participation regarding the DPV, including expansion or refinement of its terms, addressing open issues, and welcomes suggestions on their resolution or mitigation.

For contributions to the DPV, please see the section on GitHub. The current list of open issues and their discussions to date can be found at GitHub issues.

Concept	[[DPV]]	[[DPV-SKOS]]	[[DPV-OWL]]
Concept	`dpv:Concept`	`skos:Concept`	`owl:Class`
is subtype of	`dpv:isSubTypeOf`	`skos:broader`	`owl:subClassOf`
is instance of	`dpv:isInstanceOf`	`rdf:type`	`rdf:type`
has concept	`dpv:Relation`	`rdf:Property`	`owl:ObjectProperty`
relationship domain	`dpv:domain`	`rdfs:domain`	`rdfs:domain`
relationship range	`dpv:range`	`rdfs:range`	`rdfs:range`

Core Concepts

Structure of DPV

DPV can be viewed as a hierarchical taxonomy of concepts where each core concept represents the top-most abstract concept in a tree and each of its children provide a lesser abstract or more concrete concept. For example, consider the concept of PersonalData which is the abstract representation of personal data. It can be further refined or extended as SensitivePersonalData, and further as SpecialCategoryPersonalData and then as GeneticData and so on.

From this perspective, the top-most abstract concepts are collectively referred to as the core vocabulary within DPV. The goal of the DPV is to provide a rich collection of concepts for each of the top concepts so as to enable their application within real-world use-cases. The identification of what constitutes a core concept is based on the need to represent information about it in a modular and independent form, such as that required for legal compliance.

Each core concept is intended to be independent from other core concepts. For example, the Purpose (e.g. Optimisation) refers only to the purpose of why personal data is processed and is independent as a concept from the PersonalData (e.g. Location) or the Processing activities (e.g. collect, store) involved to carry out that purpose. Such separation is necessary in order to represent and answer questions such as:

Q: What data is being processed?
Ans: dpv:PersonalData → dpv:Email
Q: Why is the data being processed?
Ans: dpv:Purpose → dpv:Marketing
Q: What operations are done with the data?
Ans: dpv:Processing → dpv:Collect, dpv:Store
Q: What justification is used to do the processing?
Ans: dpv:LegalBasis → dpv:Consent, dpv:Contract
Q: How is the data directly or indirectly being protected?
Ans: dpv:TechnicalOrganisationalMeasure → dpv:AccessControlMethod, dpv:PrivacyByDesign
Q: What rights are associated with the processing of data?
Ans: dpv:Right → dpv:ActiveRight, dpv:PassiveRight
Q: What are the risks associated with processing of data?
Ans: dpv:Risk → dpv:RiskLevel, dpv:Severity
Q: What is the contextual information associated with processing?
Ans: dpv:Context → dpv:Duration, dpv:Scale

The separation of concepts creates a modular structure for concept hierarchies within DPV, which in turn allows an adopter to use one particular concept taxonomy or module (e.g. list of purposes) independently without reusing the others, or to select only those concepts which are needed for their particular use-case. The separation also permits greater flexibility of representation and usage - such as using different combinations of core concepts as needed in use-cases. For example, a use-case can specify a single concept representing both Purpose and Processing by combining their respective concepts from DPV. The modular design of DPV also makes it possible to define domain and jurisdiction specific concepts in a separate namespace - such as the [[[DPV-NACE]]] purpose taxonomy providing a way for Purpose to indicate sectors using NACE taxonomy, and the [[[DPV-GDPR]]] for using LegalBasis to represent the legal bases provided by GDPR.

Overview of Core Concepts

PersonalData

‘Personal data’ refers to any data about a natural person that can be used to identify them directly or, in combination with other information, indirectly. ‘Personal data’ is also commonly referred to as ‘personally identifiable information (PII)’. However the terms should not be interchangeably used as based on definitions (e.g. those in GDPR), ‘personal data’ can be interpreted as a broader term than PII, and where PII may refer to only to information that can directly identify a person. DPV’s definition of personal data is based on the broadest possible definition (i.e. from GDPR) as it covers a wider range of information considered ‘personal data’. Personal data can be declared as a category, such as ‘Email’, or an instance, such as ‘[email protected]’. PersonalData is associated with using the relation hasPersonalData.

Purpose

Representing the purpose for which personal data is processed, for e.g. ‘Personalisation’ as a broad category of purpose. Information about the purpose can be further specified by denoting information about its interpretation within a particular Sector, such as from standardised authoritative lists e.g. [[NACE]], to indicate domain-specific applications and interpretations, or to indicate applicability of sectorial laws.

Processing

Representing processing as in the actions or operations over personal data, for e.g. collect, use, share, store. To indicate the origin or source of data, the concept DataSource along with relation hasDataSource is provided. For additional contextual information regarding operations or processing, such as whether it include humans or automation, the concept ProcessingContext is provided which can be associated using the relation hasContext (description of Context is provided later in the document). Examples of ProcessingContext include conditions such as profiling, automated decision making, human involvement.

LegalBasis

A legal basis is a law or a clause in a law that justifies or permits the processing of personal data in the specified manner. It is a jurisdictional concept given the scoping of laws to specified countries or regions, as well as a domain-specific concept given the specific laws enacted scoped to particular domains. A law, such as the GDPR, that regulates the use of personal data requires that every processing of personal data must be justified with some legal basis to ensure it is lawful, and to further assess its correctness, accountability, and impact based on the obligations applicable. However, what is considered a legal basis varies greatly across cultures, domains, use-cases, and laws themselves. The aim of DPV is therefore to provide an upper-level abstract taxonomy of categories of legal bases that can be customised and applied as needed.

Entities

Representing the ‘entities’ or ‘actors’ involved in the processing of personal data. DPV provides a broad categorisation of entities based on their relevance in jurisprudence (i.e. legal roles) as well as categorisation in real-world (e.g. organisation types).

DataController

Representing the organisation(s) responsible for processing the personal data.

DataSubject

Representing the categories or groups (e.g. Users of a Service), or instances (e.g. Jane Doe) of individual(s) whose personal data is being processed.

Recipient

Represents the entities that receive personal data, e.g. when it is shared.

TechnicalOrganisationalMeasure

DPV provides a taxonomy of technical and organisational measures for representing information about how the processing of personal data is technically and organisationally protected, safeguarded, secured, or otherwise managed. This is distinct from what technology is used for carrying out processing, and instead refers to what measures are in place (i.e. what the technology intends to provide in terms of features).

Technical and Organisational measures consist of activities, processes, or procedures used in connection with ensuring data protection, carrying out processing in a secure manner, and complying with legal obligations. Such measures are required by regulations depending on the context of processing involving personal data. For example, GDPR (Article 32) states implementing appropriate measures by taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as risks, rights and freedoms.

The broad concept TechnicalOrganisationalMeasure represents all technical and organisational measures, which are associated through the relation hasTechnicalOrganisationalMeasure. The concept TechnicalMeasure, associated using the relation hasTechnicalMeasure, concerns measures primarily achieved using some technology. Similarly, OrganisationalMeasure and the relation hasOrganisationalMeasure represent measures carried out through activities and processes at the management and organisational levels, which may or may not be assisted by technology.

Specific examples of measures in the article include:

the pseudo-anonymisation and encryption of personal data;
the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

Right

Representing the rights available, applicable, or afforded by a law or regulation, either to data subjects or data controllers, or other entities.

Risk

Representing risk(s) associated with a concept, for e.g. risk of unauthorised data disclosure related to processing, technical measure, or vulnerability of data subjects

Technology

Representing the technologies used to implement the processing, or associated with the processing. For example, such as specific software products, algorithms, or approaches. This also involves specifying who is doing the implementing i.e. a technology and its implementer.

Temporal and Geo-Spatial Information for Storage

Indicating applicable or relevant temporal and geo-spatial information

Indicating information about storage of personal data, such as its location, duration, deletion (e.g. erasure mechanisms), or restoration (e.g. backup availability). Storage information can be part of the processing information (e.g. logs) or technical and organisational measure (e.g. indicating policies or plans in place) depending on context.

Location and Jurisdiction

Indicating applicable or relevant `Jurisdiction`

Representing the locations associated with entities, processing, data, and other information that is important to consider jurisdictions and from that understand the applicability of laws, involvement of authorities, and discover rights.

Rules

Personal Data Handling

In legal terminology, it is common to refer to all information about how personal data is being processed using the colloquial term processing. This results in confusion between the use of processing as a concept referring to all information (i.e. purposes, personal data, collection, storage, etc.), and processing as a concept referring to (only) the specific actions or operations (e.g. collect, use).

To avoid this ambiguity and enable clarity of information, DPV defines a new concept called PersonalDataHandling for representing how the core concepts are related or apply to each other for a particular use-case. The association of a concept to PersonalDataHandling is made using the relationships or properties provided for each concept. For example, to indicate a PersonalDataHandling includes personal data, the relationship hasPersonalData is used along with the concept PersonalData. The following figure provides an overview of how the PersonalDataHandling concept provides a way to associate relevant concepts with one another through it.

`PersonalDataHandling` as a central concept

Note that PersonalDataHandling is intended to provide a convenient concept for tying the core concepts together, and DPV does not make its use binding, nor does it constrain the relationships to only be defined between PersonalDataHandling and the other core concepts. This is so as to permit using DPV in alternate or differing models. For example, where a central concept already exists, such as when describing relevant information for a smartphone app, the concept for App can be a replacement for PersonalDataHandling based on statements such as <App> hasPurpose <SomePurpose>. Even in such cases, PersonalDataHandling can provide granular expression thereby enabling description of different contexts within which the app uses personal data, such as for registration or complaint resolution.

Nesting `PersonalDataHandling` to express granular models

The use of PersonalDataHandling can be nested, which means one instance can contain other instances, much like a box with several smaller boxes inside. This permits breaking down complex or dense use-cases into more granular ones and representing them in a more precise and granular fashion. In the above example, consider the following situation containing a single PersonalDataHandling instance consisting of two additional instances representing: (i) data is stored using a data processor, (ii) data is used for Marketing. While it is certainly possible to represent all of this information within one single instance of PersonalDataHandling, the adopter may decide to create separate instances of PersonalDataHandling based on requirements such as reflecting similar separations for legal documentation or accountability purposes.

Consider the example where Acme, as a DataController, maintains records of its processing activities using PersonalDataHandling to represent one of its services. In this, it collects email, uses it for internal analyses based on LegitimateInterests, and also sends marketing information by using a processor based on the data subject's consent. Using nesting of personal data handling, the information can be expressed at a granular level representing service, individual purposes, and so on.

ex:Acme rdf:type dpv:DataController .
ex:AcmeMarketing rdf:type dpv:PersonalDataHandling ;
    dpv:hasPersonalDataHandling ex:InternalAnalytics ;
    dpv:hasPersonalDataHandling ex:SendingNewsletters .

ex:InternalAnalytics rdf:type dpv:PersonalDataHandling ;
    dpv:hasPersonalData dpv:Email ;
    dpv:hasProcessing dpv:Collect, dpv:Store ;
    dpv:hasPurpose dpv:InternalResourceOptimisation ;
    dpv:hasLegalBasis dpv:LegitimateInterestOfController .

ex:FooTech rdf:type dpv:DataProcessor .
ex:SendingNewsletters rdf:type dpv:PersonalDataHandling ;
    dpv:hasPersonalData dpv:Email ;
    dpv:hasProcessing dpv:Share ;
    dpv:hasPurpose dpv:Marketing ;
    dpv:hasDataProcessor ex:FooTech ;
    dpv:hasLegalBasis dpv:Consent .

Alternate Models to PersonalDataHandling

An instance where one may not wish to utilise PersonalDataHandling is where the adopter or use-case wants to indicate a different method for relating concepts together. For example, instead of expressing the relationship between personal data and purpose through a PersonalDataHandling instance, an alternate model could be one where the purpose directly specifies what personal data it uses as: <SomePurpose hasPersonalData SomePersonalData>. Similarly, another instance for such alternate use of concepts is to associate a legal basis directly with the purpose by using the hasLegalBasis relationship. To support such uses, DPV does not explicitly declare restrictions on the properties in terms of what concepts they can be used with (e.g it does not provide domain assertions). In case an adopter needs such explicit declarations, they can utilise or import the separate file declaring them.

The following figure indicates an alternate model which does not use PersonalDataHandling as a central concept, but instead uses the core concepts and relationships to structure information related to a Service.

Alternate model to `PersonalDataHandling` using core concepts and relationships

When using custom-defined restrictions and data models, it is important to note the consequences such models have on interpretation and interoperability of data defined using DPV. For example, consider a compliance assessment tool that takes DPV data as input. If the tool expects a PersonalDataHandling with links to relevant information, using other alternate models and relationships can produce invalid or incorrect results. To avoid this, we recommend:

Documenting alternate models to clearly indicate their interpretation and use of DPV semantics;
Where possible, ensuring and providing mappings between the alternate models and the PersonalDataHandling or equivalent concepts within DPV so that the data can be transformed for interoperability;
Consider contributing your idea or implementation of an alternate model to DPVCG to create a ‘library of models’, which can act as documentation for adopters and provide better understanding of the model's impacts on requirements and interpretation of information specified using DPV. This exercise can also assist in selecting a common model as the 'default' and to provide mechanisms for conversion/interoperability between it and other models.

Taxonomies of Key Concepts

The following sections provide an overview of the taxonomies (i.e. hierarchies of concepts) provided by DPV for its core concepts.

Purpose

DPV’s taxonomy of purposes is used to represent the reason or justification for processing of personal data. For this, purposes are organised within DPV based on how they relate to the processing of personal data in terms of several factors, such as: management functions related to information (e.g. records, account, finance), fulfilment of objectives (e.g. delivery of goods), providing goods and services (e.g. service provision), intended benefits (e.g. optimisations for service provider or consumer), and legal compliance.

It is important to note the following for real-world implications of Purpose:

There is no universal definition for what constitutes a ’purpose’ or what attributes are associated with it.
There are several distinct ways to model purposes, e.g. as a ‘goal’ such as ‘Delivery of Ordered Goods’; or as a statement explaining the processing of personal data, e.g. ‘Sending newsletters to Email’.
DPV does not define requirements for what is a ‘valid purpose’ as these are defined externally, e.g. in laws such as [[GDPR]] Article.5-1b where purposes are required to be ‘explicit and legitimate’.
Purposes have contextual interpretations within their application and domains i.e. depending on how they are used in an use-case). For example, ServiceProvision is interpreted distinctly across the use-cases of an online website, a goods delivery outlet, and a medical centre - even if they use the same term or wording.

Following from the above, most use-cases would need to extend one of the concepts within DPV’s purpose taxonomy to ensure its purpose descriptions are specific and understandable within the context of that use-case. We therefore suggest, where possible and appropriate, to create a customised purpose as required within the use-cases by extending or subtyping one or several purposes from the DPV taxonomy and to provide a human readable description to assist in its accurate interpretation (e.g. for RDF, using rdfs:label and rdfs:comment).

Sector of Purpose Application

DPV provides Sector that can be used to indicate the relevant information to further clarify or indicate how a purpose should be interpreted. Sector, used with the hasSector relation, denotes the sector or domain of application, such as Manufacturing. This can be used alongside existing official sector taxonomies such as [[NACE]] (EU), [[NAICS]] (USA), or [[ISIC]] (UN), as well as commercial industry taxonomies such as [[GICS]] maintained by organisations MSCI and S&P. Multiple classifications can be used through mappings between sector codes such as the [[[NACE-NAICS]]] provided by EU.

DPVCG provides an interpretation of the NACE revision 2 codes which uses rdfs:subClassOf to specify the hierarchy between sector concepts. It is available as [[DPV-NACE]]. The NACE codes within this extension have the namespace dpv-nace and are represented as dpv-nace:NACE-CODE.

We are working on further alignments between the NACE codes and DPV's purpose taxonomy, and welcome contributions for the same.

While the use of Sector for restricting (personal data processing) purposes is an uncommon and undocumented practice in terms of legal enforcement, we provide this feature as the use of sector code can assist with identification and interpretation of information as well as legal or organisational obligations and policies. For example, indicating some purpose is to be implemented within manufacturing or scientific research facilities (e.g. medical centres) can assist in ensuring specific types of access control and policies are defined and implemented.

Processing Operations

Overview of top-concepts in `Processing` taxonomy

DPV’s taxonomy of processing concepts reflects the variety of terms used to denote processing activities or operations involving personal data, such as those from [[GDPR]] Article.4-2 definition of processing. Real-world use of terms associated with processing rarely uses this same wording or terms, except in cases of specific domains and in legal documentation. On the other hand, common terms associated with processing are generally restricted to: collect, use, store, share, and delete.

DPV provides a taxonomy that aligns both the legal terminologies such as those defined by GDPR with those commonly used. For this, concepts are organised based on whether they subsume other concepts, e.g. Use is a broad concept indicating data is used, which DPV extends to define specific processing concepts for Analyse, Consult, Profiling, and Retrieving. Through this mechanism, whenever an use-case indicates it consults some data, it can be inferred that it also uses that data.

The definitions for describing and interpreting each processing concept is based on the following sources: language dictionaries (predominantly Oxford English), use of the term within legal documents (e.g. GDPR case law), and technology-specific interpretations such as for IT systems. Despite these, there may be distinct interpretations for what a term represents based on differences in practices, culture, language, and domains. In case an adopter or a use-case foresees such ambiguity or confusion, it is advisable to extend the relevant concepts and define them as needed, or create a separate extension.

Data Storage

Indicating Storage and Data Source for Processing

The processing taxonomy uses the concept Store to indicate data is being stored. To specify additional information such as its location, erasure or deletion, the generic concepts and relations associated with processing (i.e. location and duration) can be used. However, to emphasise that information about storage - such as policies, conditions, rules, or documentation - are critical on considerations of data protection and privacy as well as legal compliance, DPV provides specific concepts related to these.

The concept StorageCondition and the relation hasStorageCondition represent the general or abstract conditions associated with storage of data. This is specialised to indicate StorageDuration, StorageDeletion, StorageRestoration, and StorageLocation. This enables a document to directly specify information such as: "storage duration is 6 months" or "storage restoration uses 3 geo-distinct backup servers".

This example is similar to the previous one, where Acme is a Data Processor that stores data within servers located in Ireland for a period of one year.

        ex:ServerInfo a dpv:PersonalDataHandling ;
            dpv:hasDataProcessor ex:Acme ;
            dpv:hasProcessing dpv:Store ;
            dpv:hasStorageCondition ex:DataStoragePolicy .

        ex:DataStoragePolicy a dpv:StorageCondition ;
            dpv:hasLocation ex:IE ;
            dpv:hasDuration [
                rdf:type time:Duration, dpv:Duration ;
                time:numericDuration "1"^^xsd:decimal ;
                time:unitType time:unitYear ;
              ] .

In this example, the StorageCondition is expressed as a separate policy applicable. It is also possible to directly express it over other concepts such as a service, technology, or a processing operation, e.g. to say ex:AcmeStore dpv:hasStorageCondition ....

Data Source

For declaring the source of data, the DataSource concept along with hasDataSource relationship is provided to indicate where the data is collected or acquired from. For example, data can be obtained from the data subject directly (e.g. given via forms) or indirectly (e.g observed from activity, or inferred from existing data), or from another entity such as a third party.

It is important to understand the distinction between a data source and data origin. The source of data refers to the direct or indirect place, entity, or other concept from which the data was collected (in any manner). The origin of data refers to the specific entity or artefact which produced or created the data. For example, consider a company that collects data from a public database that is populated by government bodies who themselves collect that data from people. In this case, the origin of that data is ultimately the people, but the sources of this information are the people, the government bodies, and the public database.

Using such two synonymous terms (source and origin) can lead to ambiguity and confusion. Therefore, we suggest using data source to indicate information as contextually required within a use-case. In most cases, this would be the direct source of data (i.e. public database in above example). In other cases, it would be relevant to indicating whether data originated from the data subject.

Data can be sourced from a public or a non-public source. The distinction is important given that a public source has different implications (and justifications) for the availability of that data as well as how it can be used. To represent these, DPV uses sub-types of data source as PublicDataSource and NonPublicDataSource. Public data sources can be datasets published by authoritative bodies, or census reports, or (public) websites. Non-public data sources are anything that is not publicly available - so data subjects, third parties, etc.

Data sources can be the data subject (direct or indirect), the data controller or processor (itself), or another entity (third party). The below example provides an overview of these with distinctions between source and method of generation.

        ex:S01 dpv:hasDataSource dpv:DataSubject .
        ex:S01 dpv:hasProcessing dpv:Collect .

        ex:S02 dpv:hasDataSource dpv:DataSubject .
        ex:S02 dpv:hasProcessing dpv:Derive, dpv:Observe .

        ex:S03 dpv:hasDataSource dpv:DataController .
        ex:S03 dpv:hasProcessing dpv:Infer .

        ex:S04 dpv:hasDataSource ex:Acme .
        ex:Acme a dpv:ThirdParty .

        ex:S05 dpv:hasDataSource dpv:DataPublishedByDataSubject .
        ex:S05 dpv:hasProcessing dpv:Collect .

In this example, ex:S01 represents direct collection of data from the data subject, while ex:S02 represents indirect collection where data is derived or observed - or undergoes any operation that still points to the data subject as the source. ex:S03 infers data, which means the inferring entity (the Controller in this case) is the source of this data - even if the inferred data is based on data collected from the Data Subject. ex:S04 has data sourced from another entity - such as a Third Party, but could also refer to a Data Processor. ex:S05 represents collection of data from a public dataset that has been published by the data subject themselves.

Note that the above example is illustrative - it may be pertinent to provide documentation about each data source to ensure sufficient information is recorded for intended purposes. For example, the method of collection (e.g. forms), or inference (e.g. algorithm), or public dataset (e.g. link, license).

Automation in Processing

Automation is a broad concept that refers to automated or reduced human involvement in a process. Most (if not all) processing operations can be considered to be automated given that they are operated by machines and utilise digital information and mediums. However, even within this, specific forms and descriptions of automation are more important than others. For example, if the processing operations are intended to produce an output that will result in prosecution - then information about the automation utilised in this process is needed to understand if the decisions are fair, correct, unbiased, or to understand whether there has been some human oversight or involvement at various stages.

DPV's concepts intentionally refer to "automation" rather than "artificial intelligence", where the former is considered a broader and more inclusive term than the latter. It also avoids delving into investigations of what is and how to define "AI". Given that AI is a form of automation, whether directly or indirectly applied, these terms within the DPV are also intended to supplement use-cases where AI is used, and to represent information regarding the degree of automation and involvement of humans within its processes.

DPV provides AutomationOfProcessing to represent the degree of automation, and the relation hasProcessingAutomation to associate it with contextual concepts. The degrees of automation are represented by FullyAutomatedProcessing, PartiallyAutomatedProcessing, and CompletelyManualProcessing.

To represent how humans are involved, the concept HumanInvolvement and relation hasHumanInvolvement are provided. Specific types of human involvement include: HumanInput, HumanOversight, and HumanVerification.

To indicate more specific applications: DecisionMaking and AutomatedDecisionMaking refer to use of processing to make decisions, AlgorithmicLogic for explaining the use of algorithms and specifics of processing logic, EvaluationScoring to indicate the processing evaluates or assigns scores (or metrics), InnovativeUseOfNewTechnologies to indicate there are innovative uses of novel technologies, and SystematicMonitoring to indicate the processing performs a systematic (or systemic) monitoring. These additional concepts are intended to model areas or topics that are considered sensitive or high-risk or require caution.

Consider the use of a spam filter that is based on automated processing operations where humans provide inputs, have oversight of the operation, and results in automated decision making for whether communications should be propagated. A new separate filter is developed that utilises a novel spam detection criteria that also takes into account communications other than emails for the sender and makes automated decisions whether to permit communication to proceed. Such explicit annotation of several high-risk operations assists in performing impact assessments for this technology, as well as understanding the extent and effectiveness of human involvement to mitigate risks and issues.

  ex:SpamFilter rdf:type dpv:Processing ;
    skos:broader dpv:Analyse ;
    dpv:hasProcessingAutomation dpv:FullyAutomatedProcessing ;
    dpv:hasHumanInvolvement dpv:HumanInput, dpv:HumanOversight ;
    dpv:hasAlgorithmicLogic ex:SpamDetection .

  ex:SpamDetection rdf:type dpv:AlgorithmicLogic ;
      skos:broader dpv:InnovativeUseOfNewTechnologies ;
      dpv:hasProcessingContext dpv:AutomatedDecisionMaking, 
                               dpv:SystemicMonitoring, 
                               dpv:EvaluationScoring  ;
      dpv:hasPersonalData dpv-pd:Communication ;
      dpv:hasDataSource ex:EmailSender .

Personal Data

DPV provides the concept PersonalData and the relation hasPersonalData to indicate what categories or instances of personal data are being processed. As described earlier, common use of personal data concepts in the real-world consists of specifying as concepts both categories (e.g. Location) and instances (e.g. your exact location right now).

The DPV main or core specification only provides a structure for describing personal data, e.g. as being sensitive. For specific categories of personal data for use-cases, [[[DPV-PD]]] provides additional concepts that extend the DPV's personal data taxonomy. This separation is to enable adopters to decide whether the extension's concepts are useful to them, or to use other external vocabularies, or define their own.

Real-world and common usage of personal data is at both an abstract level as well as specific level. For example, consider the sentence "We use your Email information...", which uses "Email" to represent a reference to what personal data is involved. Here, one may interpret Email as representing only the email address, or as a broad set of possible information related to emails, such as email address, email senders and recipients list, email service provider, email usage statistics and so on.

For ensuring clarity and resolving any potential ambiguity, DPV recommends being as specific as possible. This means where there is ambiguity as to what the information may be associated with or within a concept, it is advisable to resolve that ambiguity - either by choosing a more accurate concept from the taxonomy and/or by creating one through extension of an existing concept.

In addition to above, it is also challenging to accurately represent how concepts function within real-world use in terms of their encapsulation within one another. For example, when establishing the DPV, we discussed the modelling of personal data categories based on the scenario where a picture of passport is initially collected, and from it various categories are extracted, such as - name, address, and photo. For representing this, merely stating the personal data as ‘passport photograph’ would not be entirely accurate as there is additional information within the photograph.

A solution was established whereby the use-case is expected to declare what information it intends to collect or use through the mechanism of expression relation between its personal data categories. For the passport photograph scenario, the use-case would declare the class PassportPhoto with subtypes representing Name, Age, and so on. This is necessary to ensure the interpretation that using PassportPhoto means having access to and using all of its subsequent personal data categories.

While this is one possible solution, other methods exist, such as explicitly declaring the data categories and their encapsulation within one another, such as by reusing hasPersonalData or creating additional properties (e.g. containsData) to indicate a personal data concept, i.e. the passport photo, contains information associated through the relation, i.e. name, age, etc. We welcome discussions regarding both these methods.

Non-Personal and Synthetic Data

While the focus of DPV is on Personal Data, there may be a need to represent Non-Personal Data within the same contextual use-cases. For example, if the personal data has been fully, completely, and irreversibly anonymised, then it can no longer be said to be personal data. To enable this, and other representations, DPV provides the concept Data to represent any data, with subtypes PersonalData and NonPersonalData. Using these as annotations can assist in clearly indicating which data should be protected, or protected with more severe measures, or to determine the scope of regulations which only apply over operations involving personal data.

Data is further subtyped as SyntheticData - a new concept that represents generated data intended to mimic personal data within a system so as to aid in development and testing without using actual or real personal data. Since such synthetic data may be used in systems that assume it is personal data, it has not been declared as a specific category of personal or non-personal data to permit its use as either.

Categorisation based on Source

The concept DataSource refers to information associated with processing contexts for indicating how the data is sourced or obtained. In some cases, it may be desirable to directly express this information over the data itself, such as indicating a dataset is "collected personal data", or that a storage policy only applies over "inferred data". To enable such uses, DPV provides the following subtypes of personal data: CollectedPersonalData, DerivedPersonalData, InferredPersonalData, GeneratedPersonalData, and ObservedPersonalData. Here the terms derive and infer relate to creation of additional data based on existing data, whereas generate refers to creation of new data that is not derived or inferred.

This use-case collects browser fingerprint and IP Address to identify the country one is visiting from, and to infer language to be used for personalisation. Note that this example uses [[DPV-PD]] for personal data concepts.

  ex:PersonaliseWebsiteForVisitors rdf:type dpv:PersonalDataHandling ;
      dpv:hasPurpose dpv:Personalisation ;
      dpv:hasPersonalData dpv-pd:BrowserFingerprint,
                          dpv-pd:IPAddress ;
      dpv:hasProcessing dpv:Collect, dpv:Use ;
      dpv:hasPersonalDataHandling ex:DeriveVisitorCountry ;
      dpv:hasPersonalDataHandling ex:InferVisitorLanguage .

  ex:DeriveVisitorCountry rdf:type dpv:PersonalDataHandling ;
      dpv:hasProcessing dpv:Derive ;
      dpv:hasPersonalData ex:VisitorCountry .
  ex:VisitorCountry rdf:type dpv:DerivedPersonalData ;
      skos:broader dpv-pd:Country .

  ex:InferVisitorLanguage rdf:type dpv:PersonalDataHandling ;
      dpv:hasProcessing dpv:Infer ;
      dpv:hasPersonalData ex:VisitorLanguage .
  ex:VisitorLanguage rdf:type dpv:InferredPersonalData ;
      skos:broader dpv-pd:Language .

Sensitive and Special Categories

For indicating personal data which is sensitive, the concept SensitivePersonalData is provided. For indicating special categories of data, the concept SpecialCategoryPersonalData is provided. In this, the concept sensitive indicates that the data needs additional considerations (and perhaps caution) when processing, such as by increasing its security, reducing usage, or performing impact assessments. Special categories, by contrast, are a 'special' type of sensitive personal data requiring additional considerations or obligations defined in laws (or through other forms) that regulate how they should be used or prohibit their use until specific obligations are met.

DPV currently categorises personal data as sensitive based on existing research and literature, and as special categories based on [[GDPR]] Article 9. Both are subject to expansion in the future based on requirements and technological progress, and we welcome well-formed proposals for the same.

The sensitivity of personal data can be universal, where that data is always sensitive, or contextual, which means a use-case needs to declare it as such. For indicating personal data is sensitive (or special), it is sub-typed or declared as an instance of SensitivePersonalData, as shown in the example below.

In using these concepts, it is important to note that DPV's modelling of sensitive and special categories is non-exhaustive and as such should not be taken as an authoritative fact or a 'source of truth'. To assist with better identifying sensitive concepts, work is ongoing within DPV to identify and provide a reference list of (potentially) sensitive and special categories, and we welcome contributions for the same.

In a medical study involving genetic data, the person's collected blood samples are considered to be 'special category' personal data under the GDPR. In addition to this, the person's identifier associated with that dataset to enable monitoring future appointments is considered sensitive within the medical centre. Note that the examples use the [[DPV-PD]] extension to represent some concepts.

In this example, the knowledge that blood samples are of type 'special category' can be inferred from the fact that they are a form of Medical Health which is a 'special category'. However, the example considers best practices that suggest explicitly identifying and denoting that blood samples are also of type 'special category'.

  ex:PatientStudy rdf:type dpv:PersonalDataHandling ;
      dpv:hasPersonalData ex:BloodSamples, ex:PatientIdentifier .

  ex:BloodSamples rdf:type dpv:SpecialCategoryPersonalData ;
      skos:broader dpv-pd:MedicalHealth ;
      skos:narrower dpv-pd:BloodType .

  ex:PatientIdentifier rdf:type dpv:SensitivePersonalData ;
      skos:broader dpv-pd:Identifying .

Anonymised Data

To specify data is anonymised, DPV provides two concepts. AnonymisedData for when data is completely anonymised and cannot be de-anonymised, which is a subtype of NonPersonalData. And, PseudonymisedData for when data has only been partially anonymised or de-anonymisation is possible, which is a subtype of PersonalData.

It is important to note that these definitions can be contextually difficult to apply or interpret. For example, consider the case where some data is indicated as being anonymised by itself without any available information to de-anonymise it. Though this can be considered as anonymised data, if there were to exist an external method or dataset that when combined with the anonymised dataset provides de-anonymised information - then this does not fit the definition of anonymised data.

Therefore, when indicating AnonymisedData, the understanding is that it is completely anonymised. Otherwise, given that regulations targeting PersonalData do not apply over anonymised data, the labelling of pseudo-anonymised or contextually anonymised data may lead to misleading representation and violating obligations.

We are exploring the provision of the concept ContextuallyAnonymisedData as a subtype of PseudonymisedData to indicate situations where data is locally or contextually considered anonymised without any guarantees of its anonymity outside of that context.

Technical and Organisational Measures

Overview of Technical and Organisational Measure concepts in DPV

DPV's taxonomy of tech/org measures are structured into two groups representing TechnicalMeasure and OrganisationalMeasure along with specific properties for each. Each term has a dedicated taxonomy that expands upon the core idea to provide a rich list of technical and organisational measures that are intended to protect personal data (and its associated entities and consequences).

DPV is looking to enrich its taxonomy of technical and organisational measures through adoption of existing standards, best practices, and widely relevant practices. For this, we welcome contributions of concepts from sources such as ISO/IEC standards, ENISA, NIST, IETF, and others.

Technical Measures

Technical Measures are implemented through technological means, such as machine-processing or automation or tools and services that are primarily technological in nature. To distinguish these with organisational measures, consider whether the measure is for human organisation and management (which makes it organisational) or an implementation detail (which makes it technical).

Examples of technical measures include use of specific access control methods, encryption, anonymisation, security protocols, and other similar concepts.

Organisational Measures

Organisational measures are a corresponding counterpart to technical measures, and are intended to be implemented or realised through human action, whether directly by an individual, teams, or through an organisation's management (hence the term organisational). Implementing such measures may include use of technology or a tool, for example - a security training exercise that is carried out using some software, or to use information systems such as dashboards to keep track of information. However, the concepts themselves are structured as organisational based on who or what has to decide or implement the action. If it is to be performed through a technological means, then it is a technical measure. If it is to be performed through human or organisation management, then it is an organisational measure.

Examples of organisational measures include staff training, policies, notices, and other such concepts - which indicate that reflect organisational decisions and actions (e.g. privacy notices, policy for how to train new recruits).

To indicate staff are trained in the use of credentials, and that a policy exists regarding this, the use of OrganisationalMeasure concepts can be combined in several ways. Note that the interpretations for how staff training is associated with credentials, or contains training regarding credentials is arbitrary in notation. It is intended to demonstrate how different perspectives can be represented so as to be suitable to the organisation's documentation practices.

# 1: directly associating staff training with credentials used
ex:StaffCredentialsTraining rdf:type dpv:OrganistionalMeasure ;
    skos:broader dpv:StaffTraining .
ex:RBACCredential dpv:hasOrganisationalMeasure ex:StaffCredentialTraining .

# 2: security policy containing staff training and access control
ex:SecurityPolicy rdf:type dpv:OrganisationalMeasure ;
    skos:broader dpv:Policy ;
    dpv:hasOrganisationalMeasure dpv:StaffTraining ;
    dpv:hasTechnicalMeasure dpv:AccessControlMethod .

# 3: indicating staff training contains access control methods
ex:StaffCredentialsTraining rdf:type dpv:OrganistionalMeasure ;
    skos:broader dpv:StaffTraining ;
    dpv:hasTechnicalMeasure ex:RBACCredential .

Policies

A Policy is an organisational measure (given that it is decided and enabled by humans) that can be used to describe procedures or encode actions. It may be implemented manually (e.g. by employees) or technologically (e.g. by software or agents). Policies are an important aspect of personal data processing, and can be associated with a wide variety of concepts - such as processing operations, purposes, specific data categories, or legal bases. To enable such uses, DPV provides the relation hasPolicy and isPolicyFor to link or associate policies with their respective subjects or topics.

DPV does not provide the concept PrivacyPolicy, but instead suggests to use the better expressed and less ambiguous term - PrivacyNotice. This is to explicitly denote that the role of what is considered common as a "privacy policy" is actually a "notice" intended for end users and other individuals, instead of being an internal policy document for how the company should approach 'privacy'. More information about notices is provided in the next section.

Common policies provided by DPV include: InformationSecurityPolicy for how information is secured or safeguarded, and RiskManagementPolicy for how risks should be managed. In the future, we expect there to be more concepts added for dedicated policies as regulations and the general culture of privacy and data protection progresses.

Notices

A Notice is an artefact intended to provide information, most commonly to individuals who are viewing, visiting, or otherwise using a service. Legally, a 'notice' is provision of information with the intention of imparting knowledge. DPV represents notices through the concept Notice as a form of Organisational Measure, with the relation hasNotice enabling use or association of notice within some context.

Notices may contain only information, or also have interactive components intended to make decisions, offer choices and controls, or otherwise carry out processes that go beyond mere provision of information. Currently, PrivacyNotice and ConsentNotice are provided as specific forms of notices.

This example first specifies a privacy notice as a document is being used in the context of a service as represented using a personal data handling instance. Then it provides an alternative representation where the contents of a notice are described using DPV.

# Associating a Notice with DPV metadata
ex:Service rdf:type dpv:PersonalDataHandling ;
    dpv:hasNotice ex:AcmePrivacyPolicy .
ex:AcmePrivayPolicy rdf:type dpv:PrivacyNotice ;
    dct:title "Acme's Privacy Policy"@en ;
    foaf:page "https://example.com/"^^xsd:anyURI .

# Describing a Notice using DPV metadata
ex:AcmePrivacyPolicy rdf:type dpv:PrivacyNotice ;
    # Approach 1: delegate contents to a PDH instance
    dpv:hasPersonalDataHandling ex:Service ;
    # Approach 2: declare specifics directly
    dpv:hasPurpose dpv:ServiceProvision ;
    dpv:hasPersonalData dpv-pd:Email ;
    dpv:hasProcessing dpv:Collect ;
    # Specifying location of notice
    # In this case, as a website, or could be a domain
    dpv:hasLocation "https://example.com"^^xsd:anyURI .

Records

Records, or storing of information with the intention to use it in the future, are an important obligation for several legal as well as other obligations related to data protection and privacy. To represent these, DPV provides the RecordsOfActivities concept for records in general, and DataProcessingRecords for records that relate to the processing of personal data. The concept RegisterOfProcessingActivities, based on [[GDPR]] Art.30, refers to a register or index of data processing activities, and is a specific type of data processing records. Where consent is used as the legal basis, the concept ConsentRecord relates to records related to such consent and its collection / use for processing of personal data.

DPV also contains the Record concept as a type of Processing operation, and RecordManagement as a type of Purpose. The former refers to recording of personal data as a means to obtain it (e.g. record a conversation), while the latter relates to the use of personal data towards creating records and managing them as a purpose (e.g. record consent was given). These are distinct, though relevant to the organisational measures related to record keeping.

Record keeping may require further vocabularies to represent details such as various temporal annotations, provenance, statuses, or other contextual information that is not possible or provided for by DPV's concepts. In such cases, we suggest utilising other standardised vocabularies where applicable.

This example shows a consent record containing the topic of consent (i.e. which processing activities it was about), its current status, and when it was given by the data subject. The structure of a record is highly dependent on the requirements of the use-case, and can vary across implementations. In this case, it is based on a draft of the ISO/IEC AWI TS 27560 Privacy technologies — Consent record information structure.

:63ded36f-4acd-4f3c-991e-6cb636698523 a dpv:ConsentRecord ;
    dct:hasVersion "27560-WD5" ;
    dpv:hasIdentifier "63ded36f-4acd-4f3c-991e-6cb636698523" ;
    dpv:hasDataSubject "96121fde-199f-4848-8942-4436e270513a" ;
    dpv:hasNotice  ;
    dpv:hasPersonalDataHandling [
      a dpv:PersonalDataHandling ;
      dct:title "Send Newsletters with Seasonal Offers"@en ;
      dpv:hasPurpose dpv:Marketing ;
      dpv:hasLegalBasis dpv:Consent ;
      dpv:hasPersonalData dpv-pd:Email ;
      dpv:hasDataController ex:Acme ;
      dpv:hasProcessing dpv:Collect, dpv:Store ;
      dpv:hasStorageCondition [ 
          dpv:hasLocation dpv-legal:IE ;
          dpv:hasDuration 63115200 ;
          ] ;
      dpv:hasJurisdiction dpv-legal:EU ;
      dpv:hasRecipient ex:Beta, ex:Epsilon ;
    ] ;
    dpv:hasConsentStatus dpv:ConsentGiven ;
    dct:hasPart [
        a dpv:ConsentGiven, dpv:ExplicitlyExpressedConsent ;
        dpv:isIndicatedAtTime "2021-05-28T12:24:00"^^xsd:dateTime ;
        dpv:hasDuration 63115200 ;
        dpv:hasEntity "96121fde-199f-4848-8942-4436e270513a"
    ] .

The example uses the DCMI Metadata Terms (dct) vocabulary to indicate metadata such as title and timestamps. Other vocabularies such as PROV-O can be used to also indicate provenance information such as when it was generated and how it was produced.

Security

All technical and organisational measures are intended, by definition, to provide better security and handling of personal data and its associated processing and other activities. In DPV's taxonomy, some measures directly and specifically relate to security as their topic, whilst others provide their intended benefit indirectly. For example, the concept SecurityAssessments is an organisational measure relating to how security is assessed (and thus ultimately improved) - and is directly associated with security as a topic. Whereas a concept such as ProfessionalTraining relates to measures that are not directly tied to security, but can be associated in cases where the training is related to security or specific security measures or risks (e.g. cybersecurity data breach mitigations). The purpose EnforceSecurity provides a common umbrella term for personal data that is utilised for enacting and enforcing security measures, such as for authorisation and authentication.

Technical measures that relate specifically to security include SecurityMethod for providing security, and its subtypes for DocumentSecurity, FileSystemSecurity, HardwareSecurityProtocols, IntrusionDetectionSystem, MobilePlatformSecurity, NetworkSecurityProtocols, OperatingSystemSecurity, WebBrowserSecurity, WebSecurityProtocols, and more. Organisational measures that relate specifically to security include SecurityProcedure, and its subtypes for BackgroundChecks, CybersecurityAssessments, CybersecurityTraining, SecurityAssessments, and more.

Data Processing Agreements

The term Data Processing Agreement refers to a broad concept related to contracts or agreements between entities representing conditions regarding the processing of (personal-)data. This can include ad-hoc 'data handling' policies such as NDAs, embargoes, and enforcement of practices, as well as more formal and legal binding contractual obligations such as those between a Controller and a Processor.

To represent such concepts, DPV provides LegalAgreement, along with subtypes for NDA (Non-disclosure agreements), ContractualTerms, and DataProcessingAgreement. In these, it is important to remember that while contract can also be as a form of legal basis, the concept represented here is not necessarily the same contract as that is used to justify the processing of personal data with a data subject. Instead, contracts are a broad category representing contractual terms governing data handling within or with an entity.

For representing specific agreements between entities (other than those with data subjects - which are covered in Legal Basis taxonomy), DPV provides the following types of agreements:

ControllerProcessorAgreement: An agreement between a Controller and a Processor, where the Controller instructs the Processor(s) to carry out processing on its behalf.
JointControllersAgreement: An agreement between two or more Controllers to act as a 'Joint Controller'.
SubProcessorAgreement: An agreement between two or more Processors where one Processor instructs another to carry out processing on its behalf.
ThirdPartyAgreement: An agreement between a Data Controller or a Data Processor, and a Third Party. Note that this is a loosely defined concept, as depending on the jurisdiction, this relationship may result in the Third Party being a Data Controller or a Joint Data Controller.

To indicate the entities involved in an agreement, the relation hasEntity can be used, or relations associated with specific roles to indicate contextuality. For example, using hasDataController with a ControllerProcessorAgreement denotes the Data Controller for that agreement.

Acme is the Data Controller that contracts BetaInc as a Data Processor to analyse raw call logs and provide statistical patterns.

ex:Acme rdf:type dpv:DataController .
ex:BetaInc rdf:type dpv:DataProcessor .

ex:AcmeBetaContract rdf:type dpv:ControllerProcessorAgreement ;
    dpv:hasDataController ex:Acme ;
    dpv:hasDataProcessor ex:Beta ;
    # part1: acme sends data to beta
    dpv:hasPersonalDataHandling ex:AcmeProvision ;
    # part2: beta sends data to acme
    dpv:hasPersonalDataHandling ex:BetaProvision .

ex:AcmeProvision rdf:type dpv:PersonalDataHandling ;
    skos:note "Acme transfers call logs to Beta"@en ;
    dpv:hasPersonalData ex:CallLogs ;
    dpv:hasProcessing ex:TransferCallLogs ;
    dpv:hasDataController ex:Acme ;
    dpv:hasDataProcessor ex:BetaInc .

ex:BetaProvision rdf:type dpv:PersonalDataHandling ;
    skos:note "Beta analyses and transfers call statistics to Acme"@en ;
    dpv:hasPersonalData ex:CallStatistics ;
    dpv:hasProcessing ex:AnalyseCalls, dpv:TransferStatistics ;
    dpv:hasDataProcessor ex:BetaInc ;
    dpv:hasRecipientDataController ex:Acme ;
    # alternative way to explicitly indicate who is implementing this
    dpv:isImplementedByEntity ex:BetaInc .

ex:CallLogs rdf:type dpv:PersonalData ;
    skos:broader dpv-pd:CallLog ;
    # denoting source of data as part of agreement
    dpv:hasDataSource ex:Acme .
ex:CallStatistics rdf:type dpv:DerivedData ;
    skos:broader ex:CallLogs ;
    dpv:hasDataSource ex:BetaInc .

ex:TransferCallLogs rdf:type dpv:Processing ;
    skos:broader dpv:Transfer ;
    dpv:hasPersonalData ex:CallLogs ;
    # alternative 1 - based on implementation and recipient
    dpv:isImplementedByEntity ex:Acme ;
    dpv:hasRecipient ex:BetaInc ; 
    # alternative 2 - based on data exporter/importer roles
    dpv:hasDataExporter ex:Acme ;
    dpv:hasDataImporter ex:BetaInc .

ex:AnalyseCalls rdf:type dpv:Processing ;
    skos:broader dpv:Analyse ;
    # no recipients, data is analysed by BetaInc
    dpv:isImplementedByEntity ex:BetaInc .

ex:TransferStatistics rdf:type dpv:Processing ;
    skos:broader dpv:Transfer ;
    dpv:hasPersonalData ex:CallStatistics ;
    # using alternative 2 from above
    dpv:hasDataExporter ex:BetaInc ;
    dpv:hasDataImporter ex:Acme .

Data Transfer Safeguards

While all technical and organisational measures are intended to safeguard personal data and its associated activities, there may be contextual or use-case requirements to explicitly indicate safeguards against or for specific criteria. To enable such use, DPV provides the concept Safeguard and its subtype SafeguardForDataTransfer for indicating application when data is being transferred. Through these, it is possible to represent aspects such as policies for data transfers, specific measures such as encryption being applied, and other pertinent information in combination with DPV's concepts from technical and organisational measures.

[[GDPR]] and its various guidelines utilise the term "data transfer tools" to refer to specific measures that aid in safeguarding data transfers. Given this jurisdiction-specific nomenclature and its applicability being restricted to GDPR, DPVCG provides the concept DataTransferTool and its implementations (such as the SCCs above) within the [[DPV-GDPR]] extension.

Impact Assessments

DPV provides the concept Assessment to represent various assessments and related procedures and processes that an organisation or entity may undertake. An important subtype of such assessments is the ImpactAssessment which refers to calculating or determining the likelihood of impact of an existing or proposed process and its involved risks or detriments. This could be inward facing - such as impact to the organisation, or outward facing - regarding impact to stakeholders such as individuals.

To represent privacy related impact assessments, the concept PIA (Privacy Impact Assessment) is provided. Similarly, the concept DPIA is provided for Data Protection Impact Assessment. Without getting into specifics of jurisdictional nomenclature (more specifically GDPR), DPVCG considers PIA and DPIA to be distinct terms based on their topic of focus. The PIA process is based on privacy as its focal point whereas the DPIA process considers the processing of personal data. Both refer to impacts (e.g. individuals affected), and may contain overlapping processes and outcomes. DPVCG suggests using the concept most suitable or applicable for a given use-case, or which matches the terminology of an obligation. For example, the concept DPIA would be more suitable for systems based on GDPR's requirements. It is also possible to utilise both terms to refer to the same process, for example to specify that an assessment satisfies both PIA and DPIA criteria (as suggested by CNIL - the French DPA).

Other assessments represented within DPV include: DataTransferImpactAssessment for impacts arising from data transfers, LegitimateInterestAssessment for determining the suitability of legitimate interest as a lawful basis, and SecurityAssessments to identify gaps, vulnerabilities, risks, and effectiveness of controls.

Legal Basis

DPV provides the following categories of legal bases based on [[GDPR]] Article 6: consent of the data subject, contract, compliance with legal obligation, protecting vital interests of individuals, legitimate interests, public interest, and official authorities. Though derived from GDPR, these concepts can be applied for other jurisdictions and general use-cases. The legal bases are represented by the concept LegalBasis and associated using the relation hasLegalBasis.

When declaring a legal basis, it is important to denote under what law or jurisdiction that legal basis applies. For instance, using Consent as a legal basis has different obligations and requirements in EU (i.e. [[GDPR]]) as compared to other jurisdictions. Therefore, unless the information is to be implicitly interpreted through some specific legal lens or jurisdictional law, DPV recommends indicating the specific law or legal clause associated with the legal basis so as to scope its interpretation. This can be done using the relation hasJurisdiction or hasLaw.

For GDPR, DPVCG provides the [[[DPV-GDPR]]] which defines the legal bases within [[GDPR]] by extending them from relevant concepts within the DPV. We welcome similar contributions for extending the GDPR extension as well as creating extensions for other laws and domains.

The LegalBasis can be associated with any concept using the relation hasLegalBasis. Such associations are of three types: (1) where the legal basis refers to an instance, such as the consent or contract associated with a particular data subject; (2) where the legal basis refers to the category that will be used to justify processing, such as the concept consent to denote consent will be the basis for indicated processing; and lastly (3) where the legal basis is the denoted with context, such as consent of service consumers.

# 1: instance of legal basis
# interpretation: consent of user #00145667 is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
    dpv:hasDataController ex:Acme ;
    dpv:hasDataSubject ex:ServiceConsumers ;
    dpv:hasLegalBasis ex:ConsentUserN00145667 .
ex:ConsentUserN00145667 rdf:type dpv:Consent ;
    dpv:hasDataSubject ex:UserN00145667 .

# 2: category of legal basis
# interpretation: consent is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
    dpv:hasDataController ex:Acme ;
    dpv:hasDataSubject ex:ServiceConsumers ;
    dpv:hasLegalBasis dpv:Consent .

# 3: category of legal basis with contextual information
# interpretation: consent of service consumers is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
    dpv:hasDataController ex:Acme ;
    dpv:hasDataSubject ex:ServiceConsumers ;
    dpv:hasLegalBasis ex:UserConsent .
ex:UserConsent rdf:type dpv:LegalBasis ;
    skos:broader dpv:Consent ;
    dpv:hasDataSubject ex:ServiceConsumers .

When using legal bases, we advise careful consideration whether the information to be represented is regarding a specific instance (e.g. consent of an individual) or a general category (e.g. contract of service consumer/users), and to utilise DPV concepts accordingly.

Entities

A ‘legal entity’ is an entity whose role is defined legally or within legal norms. DPV provides a taxonomy of entities based on their application within laws and use-cases. Alongside DataController and DataSubject, the DPV also defines other types of entities involved in the processing of personal data such as DataProcessor, ThirdParty, or terms associated with data transfers such as DataImporter and DataExporter. In addition to these, various kinds of Authority, including DataProtectionAuthority are also provided.

Entity Descriptions

Legal Roles

To specify the roles organisations can take in the context of data processing, DPV defines the following concepts based on terminology from ISO 29100 and GDPR. In these, an entity can take on one or more roles as necessary or specified within an use-case.

DataController - An entity responsible for deciding the purposes and means of processing.
DataProcessor - An entity contracted by a Controller to carry out the processing.
DataSubProcessor - An entity contracted by a Processor to carry out the processing.
Recipient - An entity that is recipient of personal data
ThirdParty - An entity other than a Controller or a Processor who also processes personal data
DataExporter - An entity that exports data across a jurisdiction or context.
DataImporter - An entity that imports data into a jurisdiction or context.
JointDataControllers - Multiple Controllers that together are responsible as Controller(s) for the processing of personal data.
DataProtectionOfficer - An agent affiliated or part of another entity and represents it regarding overseeing processing of personal data and its relevant obligations.

Organisation Categories

Organisation is a specified type of entity, representing common concepts such as Company or Business, as well as non-commercial entities such as NGO or University. To assist with expressing such common types of organisations, DPV provides concepts covering Industry, Governmental bodies, NGOs, For and Not-For Profits, and Academic or Scientific Organisations.

We are looking to provide a rich collection of organisation types to accurately reflect the contextual differences between specific organisation types based on domain (e.g. education and school) and roles (e.g. vendor, procurer). Suggestions and proposals for these are invited.

Authorities

The concept Authority is a specific Governmental Organisation authorised to enforce a law or regulation. Authorities can be associated with a specific domain, topic, or jurisdiction. DPV currently defines regional authorities for NationalAuthority, RegionalAuthority, and SupraNationalAuthority, and DataProtectionAuthority represents authorities associated with data protection and privacy. To associate authorities with concepts, the relations hasAuthority and isAuthorityFor are provided.

Data Subjects

DPV provides a taxonomy of data subject types to assist with describing what kind of individuals or groups are associated with an use-case. Some examples of such types are age-based roles: Adult and Child, ParentOfDataSubject, GuardianOfDataSubject; vulnerability: VulnerableDataSubject, ElderlyDataSubject, AsylumSeeker; domain-specific roles such as Patient, Employee, Student, jurisdictional roles such as Citizen, NonCitizen, Immigrant; and general roles such as User, Member, Participant, and Client.

Location and Jurisdiction

To represent location, the concept Location along with relations hasLocation is provided. For geo-political locations, the concepts such as Country and SupraNationalUnion are subtyped, with hasCountry and ThirdCountry with hasThirdCountry provided for convenience in common uses (e.g. data storage, transfers).

To define contextual location concepts, such as there being several locations, or that the location is 'local' to an event, DPV provides two concepts. LocationFixture specifies whether the location is 'fixed' or 'deterministic', with subtypes for fixed single, fixed multiple, and variable locations. LocationLocality specifies whether the location is 'local' within the context, with subtypes for local, remote, within a device, or in cloud.

To represent locations as jurisdictions, the relation hasJurisdiction is provided. The concept Law represents an official or authoritative law or regulation created by a government or an authority. To indicate applicability of laws within a jurisdiction, the relation hasApplicableLaw is provided.

The [[[DPV-LEGAL]]] provides taxonomies extending these concepts, such as to represent specific countries, their laws, authorities, memberships, adequacy decisions, and other information.

Contextual Information

For indicating additional information regarding how the expressed information should be interpreted, or how it applies within a particular context, the Context concept along with the hasContext relationship can be used. Context refers to a generic collection of concepts that assist in indicating information such as the necessity, importance, environment - which aid in the interpretation or application of other core concepts.

Importance and Necessity

DPV provides two subtypes of concepts to denote contextual Importance and Necessity, which can be applied to specific contexts such as PersonalDataHandling, Purpose, PersonalData.

Importance is similar in application to Necessity, and provides a way to indicate how central or significant the indicated operation(s) are to the context (e.g. to the Controller). Subtypes of importance are PrimaryImportance to indicate 'main' or 'central' or 'primary' importance, and SecondaryImportance to indicate 'auxiliary' or 'peripheral' or 'secondary' importance.

Necessity enables specifying whether the contextual information is Required, is Optional, or is NotRequired. These can be used to indicate, for example, which parts of processing operations (e.g. purposes, personal data) are optional, and whether a particular processing operation is required to be carried out.

In this example, a PersonalDataHandling instance consists of two nested PersonalDataHandling instances for each of the optional and required parts. The personal data category 'Account Identifier' is indicated as being required for 'Communication for Customer Care', while the use of 'Email' is optional for the same purpose.

Example using [[DPV-SKOS]]

:PDH1 a dpv:PersonalDataHandling ;
  # optionally also declare data and purpose for PDH1
  dpv:hasPersonalData dpv:Email, dpv:AccountIdentifier ;
  dpv:hasPurpose dpv:CommunicationForCustomerCare ;
  dpv:hasPersonalDataHandling :PDH2, :PDH3 .

:PDH2 a dpv:PersonalDataHandling ;
  dpv:hasContext dpv:Optional ;
  dpv:hasPersonalData :Email ;
  dpv:hasPurpose dpv:CommunicationForCustomerCare .

:PDH3 a dpv:PersonalDataHandling ;
  dpv:hasContext dpv:Required ;
  dpv:hasPersonalData dpv:AccountIdentifier ;
  dpv:hasPurpose dpv:CommunicationForCustomerCare .

remove identifier

Duration and Frequency

To express the duration of events or operations, such as how long processing will take or the validity of consent, the concept Duration can be used. Duration is indicated using the relation hasDuration, and has the following subtypes:

TemporalDuration - indicating a relative temporal duration, e.g. 6 months.
UntilTimeDuration - indicating duration that occurs until the end of specified time, e.g. until 31 DEC 2022.
UntilEventDuration - indicating duration that occurs until the end of specified event, e.g. until account is closed.
FixedOccurencesDuration - a duration that is based on number of occurrences, e.g. until you view it 3 times
EndlessDuration - indicating a duration without an end condition or temporal notation.

Frequency indicates how frequently something occurs. Statistically, this can be expressed as the combination of number of occurrences and a time period, which can further be expressed as a probabilistic value or a percentage. For example, for something occurring once every year, the frequency is: 1 or 100% for 1 year. While such quantified representations are important for determining metrics and performing operations, DPV focuses on the qualitative labelling of such representations within a specific context.

The relation hasFrequency associates a frequency with a context, and can be expressed using the following subtypes:

ContinousFrequency - indicates things occurring continuously, e.g. location collection happens continuously.
SporadicFrequency - indicates things occurring sporadically or rarely or not often, e.g. collecting system usage logs every month.
OftenFrequency - indicates things happen often or regularly or commonly, e.g. online status is reported every 5 mins.
SingularFrequency - indicates things happen only once.

Scope and Justification

Scope, associated using the relation hasScope, indicates the extent or range or boundaries associated with(in) a context. For example, where processing only takes place for a specific service or within a jurisdictional framework.

Justification, associated using hasJustification, is another generic concept representing the argument or justification or reason provided to explain or document information within the specific context. For example, where an audit was rejected the justification for this rejection can be associated. Or, if processing was decided to be continued despite an assessment showing high-risk criteria, the outcome can express a justification.

Data and Processing Scales

Scale, associated using hasScale, refers to a measurement along some dimension. DPV provides (qualitative) scales for expressing Data Volume, Data subjects, and Geographical Coverage of processing. Along with these, DPV also provides a Processing Scale to express combinations of these. NOTE: The actual meaning or quantified amounts for each concept are not defined due to their interpretation based on contextual factors such as legislations, guidelines, domains, and variations across industries.

DataVolume refers to the volume or amount of data in the form of a scale with the following subtypes: HugeDataVolume, LargeDataVolume, MediumDataVolume, SmallDataVolume, SporadicDataVolume, SingularDataVolume, and is associated using hasDataVolume.

DataSubjectScale refers to the volume or amount of data subjects in the form of a scale with the following subtypes: HugeScaleOfDataSubjects, LargeScaleOfDataSubjects, MediumScaleOfDataSubjects, SmallScaleOfDataSubjects, SporadicScaleOfDataSubjects, SingularScaleOfDataSubjects, and is associated using hasDataSubjectScale.

GeographicCoverage refers to the volume or amount of geographical area covered by the processing in the form of a scale with the following subtypes: GlobalScale, NearlyGlobalScale, MultiNationalScale, NationalScale, RegionalScale, LocalityScale, LocalEnvironmentScale, and is associated using hasGeographicScale.

ProcessingScale, also associated using hasScale, represents an interpretation of the other scales to express whether the combination entails a specific threshold for qualifying as 'large scale'. Specific subtypes defined for these are: LargeScaleProcessing, MediumScaleProcessing, SmallScaleProcessing.

Statuses

To assist with expressing the state or status associated with various activities, DPV provides the Status concept that can be associated contextually using the hasStatus relation. Specific subtypes are provided as ActivityStatus, ComplianceStatus, and AuditStatus.

The Activity statuses are further subtyped to refer to the activity being: Proposed, Ongoing, Halted, and Completed. These can be used to refer to any activity, for example, processing operations, or audits, or impact assessments.

The Compliance statuses are subtyped to indicate: Compliant, NonCompliant, PartiallyCompliant, Compliance Violation, and Unknown. These can be used to refer to any compliance assessments, for example for specific laws, or requirements, or certifications, or internal guidelines.

Audits are important categories of activities that need to be carried out and documented, such as compliance and impact assessments. The outcome of such activities represents an assessment that is recorded to indicate satisfaction or fulfilment of some criteria. For example, a compliance audit is undertaken to investigate the fulfilment of obligations. The activity information is represented using ActivityStatus, with ComplianceStatus indicating what was found. To indicate the state of the audit itself, such as whether it has been requested or approved, the AuditStatus is subtyped as: Approved, Conditionally Approved, Rejected, Requested, Required, and NotRequired.

Risk Management

Provide overview of core concepts. Describe how the risk extension extends the core concepts.

For risk management, DPV's provides a lightweight risk ontology based on commonly utilised concepts regarding risk mitigation and risk management. While these concepts permit rudimentary association of risks and mitigations within a use-case, it is important to note that DPV (currently) does not provide comprehensive concepts for risk management.

For more developed representations of risk assessment, mitigation, and management vocabularies, we suggest the adoption of relevant standards, such as the ISO/IEC 31000 series, and welcome contribution for their representation within DPV through [[[RISK]]].

Risk and Mitigation

Will also describe risk matrix

Should contain everything in risk extension not covered in other subsections

The central concepts within DPV's risk management vocabulary are Risk (associated using hasRisk) and its mitigation through RiskMitigationMeasure (associated using mitigatesRisk and conversely isMitigatedByRisk). Through these, risk can be associated with specific concepts (e.g. data categories) or contexts (e.g. personal data handling).

To express quantified and qualified attributes associated with risk, such as levels and severity, DPV provides the following concepts: RiskLevel (associated using hasRiskLevel) to indicate the 'level' or 'magnitude' of risk; Severity (associated using hasSeverity) to indicate the magnitude of being unwanted or causing unwanted impacts, and Likelihood (associated using hasLikelihood) to indicate the probability of it taking place.

To express remaining risk after mitigation, the concept ResidualRisk (associated using hasResidualRisk and conversely isResidualRiskOf) is provided. To represent the management of risk and the procedures and methods associated with it, the concept RiskManagementProcess is defined as part of the Technical and Organisational Measures.

Consequences and Impacts

To represent the consequences and impacts of a risk event taking place, DPV provides the following concepts: Consequence arising from the context (e.g. data breach or unauthorised access to data) and the Impact caused (e.g. identity theft).

Consequences are associated using hasConsequence, and subtyped to indicate whether the consequence was due to the event successfully taking place (ConsequenceOfSuccess) or due to its failure in successfully completing or not taking place (ConsequenceOfFailure) or as side-effects (ConsequenceAsSideEffect).

Impacts are associated using hasImpact, with the specific entity being impacted indicated using hasImpactOn. Impacts are subtyped to represent: Benefit, Detriment, Damage (MaterialDamage, NonMaterialDamage), and Harm

In this example, we consider Risk can be associated with any concept given its broad existence and applicability, and that its mitigation is a technical and organisational measure. Using this, the implemented or adopted technical and organisational measures within an use-case are annotated with the risks they address or mitigate, along with specific impacts that may occur if the risk were to occur. For example, the storage of personal data within a database has an implementation of access control that mitigates the consequence of unauthorised access and its impact to cause harm.

  # 1: annotating implementations with risks involved
  ex:DataStore rdf:type dpv:Technology ;
      dpv:hasTechnicalMeasure ex:RBACCredential ;
      dpv:hasRisk ex:UnAuthorisedAccess . 

  # 2: risk registry denoting risks and mitigations
  ex:UnAuthorisedAccess rdf:type dpv:Risk ;
      dpv:hasConsequence "Unauthorised Access to Data Store"@en ;
      dpv:hasImpact dpv:Harm ;
      dpv:isMitigatedByMeasure ex:RBACCredential .

  # 3: annotating measures with risks mitigated
  ex:RBACCredential rdf:type dpv:TechnicalMeasure, dpv:RiskMitigationMeasure ;
      skos:broader dpv:AccessControlMethod ;
      dpv:mitigatesRisk ex:UnAuthorisedAccess .

  # 4: policies and training as risk mitigations
  ex:SecurityPolicy rdf:type dpv:OrganisationalMeasure ;
      skos:broader dpv:Policy ;
      dpv:hasOrganisationalMeasure dpv:StaffTraining ;
      dpv:mitigatesRisk ex:UnAuthorisedAccess .

Exercising Rights

Rules

check content; add hyperlinks

DPV provides the concept Rule [1] to specify requirements, constraints, and other forms of 'rules' that are associated with specific contexts (e.g., processing activities) using the relation hasRule [2]. DPV provides three forms of Rules to represent Permission [3], Prohibition [4] and Obligation [5], and their corresponding relations hasPermission [6], hasProhibition [7] and hasObligation [8], to indicate a Rule that specifies whether something is permitted, prohibited or an obligation, respectively. DPV does not define additional semantics for rules and limits its scope and focus to provide a simple way to specify permissions, prohibitions, and obligations as common rules associated with personal data and its processing activities. For a more extensive and richer set of semantics and concepts to represent rules, DPVCG suggests looking towards other languages, such as ODRL [], SHACL [], RuleML [] that have been developed with the specific goal of representing and applying rules. We welcome contributions for aligning DPV with these, and for providing guidance on how to complement DPV's rule-based concepts with external languages.

In representing Rules, DPV only provides the concept and does not express any inherent semantics on what those rules mean in relation to each other. For example, DPV does not express Permission to be non-compatible or disjoint from Prohibition. This is to separate the interpretation and application of rules based on the necessities of a use-case. For example, in a legal investigation it may be prudent to specify permission and prohibition can never occur together, but this may not be true if there are different legal requirements that allow a prohibition to be resolved or deferred, such as through another permission that overrides the prohibition.

DPV does not specify 'default' in relation to rules, i.e. it does not provide an interpretation of whether some rules apply automatically unless otherwise declared. For example, in declaring an instance of Personal Data Handling, the assumption is that the activities are modelled for what is happening or what is intended/planned to happen. The explicit annotation using a Permission rule adds information about whether some activity is permitted (and its associated information). Instead, if the use-case is using DPV to only document activities that are permitted, there is no need to explicitly specify the permissions. Similarly, just because something is happening or planned to happen, it cannot be assumed to be permitted (e.g., from evaluation of legal requirements).

To associate a rule with a specific context, which can be a PersonalDataHandling or PersonalData or Purposes, the relations hasPermission, hasProhibition and hasObligation are provided. Additional types of rules can be added to DPV by extending the Rule Concept (e.g., :MyRule rdfs:isSubClassOf dpv:Rule).

In this example, a PersonalDataHandling which consists of using an email address for service provision using the legal basis as Consent is permitted

ex:PDH a dpv:PersonalDataHandling ;
    dpv:hasRule dpv:Permission ;
    dpv:hasPurpose dpv:ServiceProvision ;
    dpv:hasPersonalData dpv-pd:EmailAddress ;
    dpv:hasLegalBasis dpv:Consent .

In this example, the hasProhibition relation is directly used to assert a prohibition to handle Health data within a PersonalDataHandling:

ex:PDH a dpv:PersonalDataHandling ;
    dpv:hasProhibition dpv-pd:Health .

In this example, DPV is complemented with ODRL, following the ODRL implementation best practices, to assert an obligation to Anonymise data in order to use it:

ex:Policy a dpv:Obligation, odrl:Policy ;
    odrl:profile new-profile: ;
    odrl:uid <https://example.com/policy:1> ;
      odrl:obligation [
        odrl:action new-profile:Use ;
        odrl:duty [
          odrl:action new-profile:Anonymise
        ]
    ] .

DPV Family of Documents

Introduction

Using DPV

DPV Serialisations

Areas of Application

Semantics of DPV

Concepts and Relationships

DPV as an Ontology

Extending Concepts for Use-Cases

Maintaining Interoperability

Core Concepts

Structure of DPV

Overview of Core Concepts

PersonalData

Purpose

Processing

LegalBasis

Entities

DataController

DataSubject

Recipient

TechnicalOrganisationalMeasure

Right

Risk

Technology

Temporal and Geo-Spatial Information for Storage

Location and Jurisdiction

Rules

Personal Data Handling

Nesting PersonalDataHandling to express granular models

Alternate Models to PersonalDataHandling

Taxonomies of Key Concepts

Purpose

Sector of Purpose Application

Processing Operations

Data Storage

Data Source

Automation in Processing

Personal Data

Non-Personal and Synthetic Data

Categorisation based on Source

Sensitive and Special Categories

Anonymised Data

Technical and Organisational Measures

Technical Measures

Organisational Measures

Policies

Notices

Records

Security

Data Processing Agreements

Data Transfer Safeguards

Impact Assessments

Legal Basis

Consent

Consent Notice

Consent Types

Consent Status

Consent Indication

Duration of Consent

Entities

Entity Descriptions

Legal Roles

Organisation Categories

Authorities

Data Subjects

Location and Jurisdiction

Contextual Information

Importance and Necessity

Duration and Frequency

Scope and Justification

Data and Processing Scales

Statuses

Risk Management

Risk and Mitigation

Consequences and Impacts

Exercising Rights

Rules

Extensions

DPV-PD (Personal Data)

Nesting `PersonalDataHandling` to express granular models