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.
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.
While we welcome participation via any and all mediums - e.g., via Github pull requests or issues, emails, papers, or reports - the formal resolution of contributions takes place only through the DPVCG meeting calls and mailing lists. We therefore suggest joining the group to participate in these discussions for formal approval.
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.
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:
Entities such as Recipients, Data Controllers, Data Subjects
Rights
Risks
These terms are intended to represent 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 some concepts, e.g. Legal Bases, are defined and dependant on legal jurisdictions - these are provide as a separate 'extension' of the DPV. The scope of DPV is intended to be as a 'general vocabulary', and the extensions expand it to required jurisdictions, domains, and use-case specific requirements. The DPV-GDPR extension models concepts such as legal bases and rights provided by the GDPR.
Examples of applications where the concepts provided by the DPV can be used are:
represent policies for personal data handling
represent information about consent i.e. what it is about
log/document personal data handling actions e.g. activities of data controller
represent input data for automated checking of legal compliance
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.
Prefix
Namespace
dct
http://purl.org/dc/terms/
dpv
http://www.w3.org/ns/dpv#
dpv-gdpr
http://www.w3.org/ns/dpv-gdpr#
dpv-nace
http://www.w3.org/ns/dpv-nace#
odrl
http://www.w3.org/ns/odrl/2/
owl
http://www.w3.org/2002/07/owl#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
skos
http://www.w3.org/2004/02/skos/core#
spl
http://www.specialprivacy.eu/langs/usage-policy#
svd
http://www.specialprivacy.eu/vocabs/data#
svdu
http://www.specialprivacy.eu/vocabs/duration#
svl
http://www.specialprivacy.eu/vocabs/locations#
svpu
http://www.specialprivacy.eu/vocabs/purposes#
svpr
http://www.specialprivacy.eu/vocabs/processing#
svr
http://www.specialprivacy.eu/vocabs/recipients
xsd
http://www.w3.org/2001/XMLSchema#
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. There is ongoing work to document 'flavours' for using DPV as a RDFS, OWL2, or SKOS vocabulary.
Base Vocabulary
Concepts in the Base vocabulary are available as an individual module here.
Base Vocabulary
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:
Class
Property
Description
[=PersonalDataCategory=]
[=hasPersonalDataCategory=]
Personal data categories
[=Purpose=]
[=hasPurpose=]
Purpose of Processing
[=Processing=]
[=hasProcessing=]
Category or type of processing of personal data
[=DataController=]
[=hasDataController=]
Data Controller responsible for processing
[=DataSubject=]
[=hasDataSubject=]
Data Subject or Individual whose data is being processing
[=Recipient=]
[=hasRecipient=]
Recipient of personal data
[=TechnicalOrganisationalMeasure=]
[=hasTechnicalOrganisationalMeasure=]
Technical and/or Organisational measures associated with processing
[=LegalBasis=]
[=hasLegalBasis=]
Legal bases or justifications for processing
[=Right=] and [=DataSubjectRight=]
[=hasRight=]
Rights applicable or provided
[=Risk=]
[=hasRisk=]
Risks applicable or probable regarding processing
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.
For a formal legal definition of personal data, see GDPR Art.4-1. An informal definition consists of any data directly or indirectly associated or related to an individual. This definition is equivalent to ISO/IEC definition of Personally Identifiable Information (PII).
A high-level Class to describe 'data handling'. This can consist of personal data being processed for a purpose, involving entities, using technical and organisational measures, applicable risks, rights, and legal basis.
A recipient of personal data can be used to indicate any entity that receives personal data. This can be a Third Party, Processor (GDPR), or even a Controller.
A 'right' is a legal, social, or ethical principle of freedom or entitlement which dictate the norms regarding what is allowed or owed.. Rights as a concept encompass a broad area of norms and entities, and are not specific to Individuals or Data Protection / Privacy. For individual specific rights, see dpv:DataSubjectRight
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J Pandit
Risk
Term:
Risk
Description:
A risk or possibility or uncertainty of negative effects, impacts, or consequences.
Comment:
Risks can be associated with one or more different concepts such as purpose, processing, personal data, technical or organisational measure.
Axel Polleres,
Bud Bruegger,
Harshvardhan J. Pandit,
Javier Fernández,
Mark Lizar
has right
Term:
hasRight
Description:
Indicates applicability of a Right.
Status:
accepted
Created:
Contributor(s):
Harshvardhan J. Pandit
has risk
Term:
hasRisk
Description:
Indicates applicability of a Risk.
Status:
accepted
Created:
Contributor(s):
Harshvardhan J. Pandit
has technical and organisational measure
Term:
hasTechnicalOrganisationalMeasure
Description:
Indicates use of a Technical or Organisational measure.
Status:
accepted
Created:
Contributor(s):
Axel Polleres,
Bud Bruegger,
Harshvardhan J. Pandit,
Javier Fernández,
Mark Lizar
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.
Concepts for Personal Data Categories in DPV
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 personal 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:
Concept
Description
[=PersonalDataCategory=]
Category of Personal Data
[=SpecialCategoryPersonalData=]
Indicates that personal data is sensitive or belongs to a special category
[=DerivedPersonalData=]
Indicates that personal data is derived or inferred
Information about web browsing referrer or referral, which can be based on location, targeted referrals, direct, organic search, social media or actions, campaigns.
Elmar Kiesling; Harshvardhan J. Pandit,
Fajar Ekaputra
Life History
Term:
LifeHistory
Description:
Information about personal history regarding events or activities - including their occurrences that might be directly related or have had an influence (e.g. World War, 9/11)
Elmar Kiesling; Harshvardhan J. Pandit,
Fajar Ekaputra
PIN Code
Term:
PINCode
Description:
Information about Personal identification number (PIN), which is usually used in the process of authenticating the individual as an user accessing a system.
Elmar Kiesling; Harshvardhan J. Pandit,
Fajar Ekaputra
Secret Text
Term:
SecretText
Description:
Information about secret text used in the process of authenticating the individual as an user accessing a system, e.g., when recovering a lost password.
Elmar Kiesling; Harshvardhan J. Pandit,
Fajar Ekaputra
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 an use-case or domain.
Concepts for Purposes in DPV
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=].
Depending on specific jurisdictions, certain purposes within the DPV may not satisfy the requirements to be specific, umabigious, or clear. For example, in the above example, [=OptimisationForController=] may still be considered to be too broad, and thus should be further clarified either through use of one of its sub-classes or by creating dedicated instances for a given use-case.
Also depending on jurisdictions, there may be correlations between purposes and legal bases that indicate which specific legal bases may or may not be used for what purpose categories.
We welcome ways to indicate guidelines for use of purposes, relations with legal basis, and assisting adopters with choices to utilise in their use-cases.
The following is an overview of the concepts within the purpose taxonomy:
Class
Property
Description
[=Purpose=]
[=hasPurpose=]
Indicate purpose
[=Sector=]
[=hasSector=]
Indicate sector of organisation or restrict purpose to sector
Conduct advertising i.e. process or artefact used to call attention to a product, service, etc. through announcements, notices, or other forms of communication
This purpose by itself does not sufficiently and clearly indicate what the communication is about. As such, it is recommended to combine it with another purpose to indicate the application. For example, Communication of Payment.
Created:
Contributor(s):
David Hickey,
Georg P Krog,
Harshvardhan J. Pandit,
Paul Ryan
Context
Term:
Context
Description:
Contextually relevant information about purpose not possible to represent through other concepts
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Create Event Recommendations
Term:
CreateEventRecommendations
Description:
Create and provide personalised recommendations for events
HR is a broad concept. Its management includes, amongst others - recruiting employees and intermediaries e.g. brokers, independent representatives; payroll administration, remunerations, commissions, and wages; and application of social legislation.
This term is a blanket purpose category for indicating personalisation of some other purpose, e.g. by creating a subclass of the other concept and Personalisation
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sector
Term:
Sector
Description:
Indicate or restrict scope for interpretation and application of purpose in a domain e.g. Agriculture, Banking
Comment:
There are various sector codes used commonly to indicate the domain of an organisation or business. Examples include NACE (EU), ISIC (UN), SIC and NAICS (USA).
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sell here means exchange, submit, or provide in return for direct or indirect compensation. Was subclass of commercial interest, changed to reflect selling something
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Sell Insights from Data
Term:
SellInsightsFromData
Description:
Sell data or information relevant to insights obtained from analysis of data
Sell here means exchange, submit, or provide in return for direct or indirect compensation. Was subclass of commercial interest, changed to reflect selling something
Created:
Contributor(s):
Axel Polleres,
Elmar Kiesling,
Fajar Ekaputra,
Harshvardhan J. Pandit,
Javier Fernandez,
Simon Steyskal
Indicates a purpose is restricted to the specified context(s)
Status:
accepted
Created:
has sector
Term:
hasSector
Description:
Indicates the purpose is associated with activities in the indicated (Economic) Sector(s)
Status:
accepted
Created:
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.
Concepts for Processing in DPV
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 following '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:
Class
Property
Description
[=Processing=]
[=hasProcessing=]
Specifies the processing operations over personal data
[=DataSource=]
[=hasDataSource=]
Indicates source of personal data used in processing
[=SystematicMonitoring=]
Specifies processing involves systematic monitoring (of data subjects)
[=EvaluationScoring=]
Specifies processing involves evaluating or scoring (of data subjects)
[=MatchingCombining=]
Specifies processing involves matching or combining of data
[=AutomatedDecisionMaking=]
Specifies processing produces automated decisions (regarding data subjects)
[=LargeScaleProcessing=]
Specifies processing takes place at 'large scales'
[=InnovativeUseOfNewTechnologies=]
Specifies processing involves use of innovative and new technologies
[=hasAlgorithmicLogic=]
Specifies the algorithmic logic for processing
[=hasConsequences=]
Specifies consequences arising from processing
[=hasHumanInvolvement=]
Specifies the extent of human involvement regarding processing
to irreversibly alter personal data in such a way that an unique data subject can no longer be identified directly or indirectly or in combination with other data
Indicates the logic used in processing such as for automated decision making
Status:
accepted
Created:
Contributor(s):
Georg P. Krog,
Harshvardhan J. Pandit,
Paul Ryan
has consequence
Term:
hasConsequence
Description:
Indicates consequences of processing such as those for Data Subjects in relation to automated decision making
Status:
changed
Created:
Contributor(s):
Georg P. Krog,
Harshvardhan J. Pandit,
Paul Ryan
has data source
Term:
hasDataSource
Description:
Indicates the source or origin of data being processed
Status:
accepted
Created:
Contributor(s):
Georg P. Krog,
Harshvardhan J. Pandit,
Paul Ryan
has human involvement
Term:
hasHumanInvolvement
Description:
Indicates Involvement of humans in processing such as within automated decision making process
Status:
accepted
Created:
Contributor(s):
Georg P. Krog,
Harshvardhan J. Pandit,
Paul Ryan
Technical and Organisational Measures
Concepts related to Technical and Organisational Measures are available as an individual module here.
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. Specific examples of measures in the article include:
the pseudonymisation 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
Concepts for Technical and Organisational Measures in DPV
To represent these requirements, the DPV defines a hierarchical taxonomy of technical and organisational measures through the top-level concept of [=TechnicalOrganisationalMeasure=], which is further distinguished as [=TechnicalMeasure=] and [=OrganisationalMeasure=]. A technical measure is an implementation detail or technology used to achieve a specific goal or objective, such as an authentication protocol used to validate identity. In contrast, an organisational measure is a process or procedure used by the organisation, for example an authorisation procedure to decide who should be granted access within an organisation.
Measures can be associated using the generic property [=measureImplementedBy=]. The value or object of this property can be an IRI (or URL) representing a specific measure or standard used to implement it, or a String representing relevant information.
In the future, we plan to provide a collection of terms and URIs for specifying standards (e.g. ISO) and best practices (e.g. certifications, seals). Whether this should be provided within the DPV itself or as a separate extension similar to DPV-GDPR is to be decided. We welcome participation and contributions for this work.
DPV provides specific measures for storage of personal data in the form of [=StorageRestriction=], with specialised variants for duration as [=StorageDuration=], location as [=StorageLocation=], deletion as [=StorageDeletion=], and restoration as [=StorageRestoration=].
The generic properties [=hasStorage=], [=hasLocation=], and [=hasDuration=] enable representing information about storage, location, and duration respectively. These can be used to specify restrictions or conditions, such as for storage of personal data, its processing, or information about recipients.
For indicating the mitigation of [=Risk=], DPV provides [=RiskMitigationMeasure=] as a top-level concept within the Technical and Organisational measures taxonomy. The property [=mitigatesRisk=] is used to indicate the relationship between risk and its mitigation.
The following provides an overview of the important top-level concepts within the Technical and Organisational measures taxonomy:
Class
Property
Description
[=TechnicalOrganisationalMeasure=]
[=hasTechnicalOrganisationalMeasure=]
Specifies the technical and organisational measures utilised or applicable
Axel Polleres,
Harshvardhan J. Pandit,
Mark Lizar,
Rob Brennan
Anonymization
Term:
Anonymization
Description:
Altering personal data irreversibly such that a data subject can no longer be identified directly or indirectly, either by the data controller alone or in collaboration with any other party
David Hickey,
Georg P Krog,
Harshvardhan J. Pandit,
Paul Ryan
Pseudo-Anonymization
Term:
PseudoAnonymization
Description:
PseudoAnonmyization or 'pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;
Axel Polleres,
Harshvardhan J. Pandit,
Mark Lizar,
Rob Brennan
Risk Management Procedure
Term:
RiskManagementProcedure
Description:
Risk management refers to a coordinated set of activities and methods that is used to direct an organization and to control the many risks that can affect its ability to achieve objectives. The term risk management also refers to the programme that is used to manage risk. This programme includes risk management principles, a risk management framework, and a risk management process.
Data Protection Impact Assessments as per GDPR art 35, other Privacy Impact Assessments, threat severity assessment https://www.cnil.fr/en/privacy-impact-assessment-pia
Axel Polleres,
Harshvardhan J. Pandit,
Mark Lizar,
Rob Brennan
measure implemented by
Term:
measureImplementedBy
Description:
a generic Property to describe how the measure is implemented
Status:
accepted
Created:
Contributor(s):
Axel Polleres
mitigates risk
Term:
mitigatesRisk
Description:
Indicates mitigation of risk(s)
Status:
accepted
Created:
Contributor(s):
Harshvardhan J. Pandit
Entities
Concepts related to Entities are available as an individual module here.
Entities refer to individuals, organisations, institutions, authorities, agencies, or any similar 'actor'. Defining and representing them is important given their rights and responsibilities under legal obligations. To represent such entities, DPV defines the [=LegalEntity=] class as a generic concept which if further extended to represent the different categories of entities.
Concepts for Entities in DPV
The DPV core vocabulary includes the concepts of [=DataSubject=], [=DataController=], and [=Recipient=] which are subclasses of [=LegalEntity=]. Consequently, they are not described in this section to avoid duplicity.
To describe the entities that act as recipients regarding personal data and its processing, the concepts of [=DataProcessor=], [=DataSubProcessor=], and [=ThirdParty=] are defined. Defining recipients is important in the context of data protection and privacy as it allows tracking the entities personal data is shared/transfered with. The concepts of [=Child=] and [=VulnerableDataSubject=] represent specific categories of data subjects based on relevance in legal requirements. The concept [=Authority=] represents an entity with legal authority, and is extended to represent [=DataProtectionAuthority=] for a specific authority concerned with data protection and privacy. To represent an 'agent' of an organisation, the concept [=Representative=] is provided. Similarly, [=DataProtectionOfficer=] refers to a specific entity associated with monitoring data protection and privacy within (or on behalf of) an organisation.
The concept 'child' can be legally distinct from 'minor', although they are also used as synonyms in several cases. DPV uses 'child' as the commonly used term to signify an individual below a certain legally defined age. This is influenced from the use of the term 'child' within the GDPR and by CJEU in its judgements. It is important to note that the relevant age for determining a child (or a minor child) varies by jurisdiction.
To represent information about entities, DPV provides the following properties: [=hasName=] to indicate name, [=hasAddress=] to indicate address, [=hasContact=] to indicate contact or communication channels, [=hasIdentifier=] to indicate an identifier associated with the entity, and [=hasRepresentative=] to indicate an 'agent' or representative of the entity.
The legality of age defining a child varies by jurisdiction. In addition, 'child' is distinct from a 'minor'. For example, the legal age drinking alcohol can be 21, which makes a person of age 20 a 'minor' in this context. In other cases, 'minor' and 'child' are used interchangeably to refer to a person below some legally defined age.
Created:
Contributor(s):
Harshvardhan J. Pandit
Data Exporter
Term:
DataExporter
Description:
An entity that 'exports' data where exporting is considered a form of data transfer
The EU, in particular the EDPB, uses data exporter the context of cross-border data transfers/flows. These concepts are not bound by jurisdictional or geopolitical scopes within DPV and can thus be used for any notion of exporting
The EU, in particular the EDPB, uses data importing the context of cross-border data transfers/flows. These concepts are not bound by jurisdictional or geopolitical scopes within DPV and can thus be used for any notion of importing
An entity within or authorised by an organisation to monitor internal compliance, inform and advise on data protection obligations and act as a contact point for data subjects and the supervisory authority.
Beatriz Esteves,
Georg Krog,
Harshvardhan J. Pandit,
Paul Ryan
Third Party
Term:
ThirdParty
Description:
A ‘third party’ means a natural or legal person, public authority, agency or body other than the data subject, controller, processor and people who, under the direct authority of the controller or processor, are authorised to process personal data.
Specifies address of a legal entity such as street address or pin code
Status:
accepted
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J.Pandit,
Paul Ryan
has contact
Term:
hasContact
Description:
Specifies contact details of a legal entity such as phone or email
Status:
accepted
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J.Pandit,
Paul Ryan
has identifier
Term:
hasIdentifier
Description:
Specifies an identifier for the entity such as registeration number or official ID
Status:
accepted
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J.Pandit,
Paul Ryan
has name
Term:
hasName
Description:
Specifies name of a legal entity
Status:
accepted
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J.Pandit,
Paul Ryan
has representative
Term:
hasRepresentative
Description:
Specifies representative of the legal entity
Status:
accepted
Created:
Contributor(s):
Beatriz Esteves,
Georg P Krog,
Harshvardhan J.Pandit,
Paul Ryan
Legal Basis
The concepts related to Legal Basis are available as an individual module here.
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.
Every processing of personal data must be justified with a legal basis to ensure it is lawful, and to further assess its correctness, accountability, and impact based on the laws it aims to follow. 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.
The legal bases defined by GDPR are provided as a separate extension of DPV concepts within the DPV-GDPR vocabulary. This modular approach ensures legal bases in DPV provide a general interoperable framework which can be customised to specific requirements through extensions. For other jurisdictions and domains, we welcome similar representation through extensions.
The concepts related to Consent are available as an individual module here.
Consent is one of the legal bases or legal justifications for the processing of personal data, whose legal validity is associated with requirements and obligations based on jurisdictional laws. DPV provides concepts to describe consent and its attributes to represent a 'record' of consent from a compliance perspective.
[=Consent=] represents the concept of 'consent', with the DPV classes and properties used to associate the relevant information it is about. If using [=PersonalDataHandling=], the use of consent can be indicated through the [=hasLegalBasis=] property, and the relevant information associated using properties, such as [=hasPurpose=] and [=Purpose=]. Conversely, one can also create alternate forms of 'consent as a policy' where the purpose and other information is directly associated with [=Consent=] using the generic properties.
To specify additional information, DPV specifies provenance properties of [=hasProvisionTime=] and [=hasProvisionMethod=] for how consent was given, and [=hasWithdrawalTime=] and [=hasWithdrawalMethod=] to indicate how consent was withdrawn. The expiry of consent can be specified using the property [=hasExpiry=], with sub-properties provided to define expiry as a temporal entity using [=hasExpiryTime=] or as a condition/event using [=hasExpiryCondition=].
Requirements for 'informed' consent require provision of information before the consent is obtained so as to inform the individual. This information is typically provided through a 'notice', which can be specified using the property [=hasConsentNotice=]. Similarly, 'explicit' consent is a specific form of consent where the action of giving consent carries additional obligations of being explicitly performed by the individual. To represent this, the boolean property [=isExplicit=] is provided.
The specific conditions under which consent can be considered valid, or informed, or explicit as defined under jurisdictional law. The terms provided within the DPV are generic concepts for representing these 'types' of consent. For using specific jurisdictional requirements and use of consent as a legal basis, it is advisable to declare such jurisdictional concepts in a separate extension to the DPV. For specific use of consent as a legal basis defined within GDPR, we provide DPV-GDPR.
To specify consent provided by delegation, such as in the case of a parent or guardian providing consent for a child, the properties [=hasProvisionByJustification=] and [=hasWithdrawalByJustification=] can be used to capture the nature of such ‘delegation’, with the fields [=hasProvisionBy=] and [=hasWithdrawalBy=] representing the legal entity who provided the consent. By default, the consent can be assumed to be provided by the associated Data Subject.
