{{term}}
+{{term.skos_prefLabel}}
| Term: | -{{term.iri|fragment_this}} |
+ {% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
|||
| Description: | -{{term.dct_description}} | +Definition: | +{{term.skos_definition}} | ||
| Subclass Of: | +SubType of: | - {% if term.rdfs_subClassOf is sequence and not term.rdfs_subClassOf is string %}{% for parent in term.rdfs_subClassOf|sort %} + {% if term.dpv_isSubTypeOf is sequence and not term.dpv_isSubTypeOf is string %}{% for parent in term.dpv_isSubTypeOf|sort %} {{parent|prefix_this}}{{", " if not loop.last}} {% endfor %}{% else %} - {{term.rdfs_subClassOf|prefix_this}} + {{term.dpv_isSubTypeOf|prefix_this}} {% endif %} | |||
| Superclass Of: | +SuperType Of: | {% for child in children|sort %} {{child|prefix_this}}{{", " if not loop.last}} @@ -42,26 +42,20 @@ | |||
| Status: | -{{term.sw_term_status}} | -||||
| Comment: | -{{term.rdfs_comment}} | +Note: | +{{term.skos_note}} | ||
| Source: | - {% if term.rdfs_isDefinedBy is sequence and not term.rdfs_isDefinedBy is string %}{% for parent in term.rdfs_isDefinedBy|sort %} + {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} {{parent|saved_label}}{{', ' if not loop.last }} {% endfor %}{% else %} - {{term.rdfs_isDefinedBy|saved_label}} + {{term.dct_source|saved_label}} {% endif %} | ||||
| See Also: | - {% if term.rdfs_seeAlso is sequence and not term.rdfs_seeAlso is string %}{% for link in term.rdfs_seeAlso %} + {% if term.skos_related is sequence and not term.skos_related is string %}{% for link in term.skos_related %} {{link|prefix_this}}{{", " if not loop.last}} {% endfor %}{% else %} - {{term.rdfs_seeAlso|prefix_this}} + {{term.skos_related|prefix_this}} {% endif %} |
| Term: | -{{term.iri|fragment_this}} |
+ {% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
|||
| Description: | -{{term.dct_description}} | +{{term.skos_definition}} | |||
| Status: | -{{term.sw_term_status}} | -||||
| Source: | - {% if term.rdfs_isDefinedBy is sequence and not term.rdfs_isDefinedBy is string %}{% for parent in term.rdfs_isDefinedBy|sort %} + {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} {{parent|saved_label}}{{', ' if not loop.last }} {% endfor %}{% else %} - {{term.rdfs_isDefinedBy|saved_label}} + {{term.dct_source|saved_label}} {% endif %} | ||||
| Domain: | +{{term.rdfs_domain|prefix_this}} |
+ ||||
| Range: | +{{term.rdfs_range|prefix_this}} |
+ ||||
| Created: | @@ -177,14 +179,14 @@ | ||||
| See Also: | - {% if term.rdfs_seeAlso is sequence and not term.rdfs_seeAlso is string %}{% for link in term.rdfs_seeAlso %} + {% if term.skos_related is sequence and not term.skos_related is string %}{% for link in term.skos_related %} {{link|prefix_this}}{{", " if not loop.last}} {% endfor %}{% else %} - {{term.rdfs_seeAlso|prefix_this}} + {{term.skos_related|prefix_this}} {% endif %} |
| Term: | +{% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
+
| Definition: | +{{term.dct_description}} | +
| SubClass of: | ++ {% if term.rdfs_subClassOf is sequence and not term.rdfs_subClassOf is string %}{% for parent in term.rdfs_subClassOf|sort %} + {{parent|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_subClassOf|prefix_this}} + {% endif %} + | +
| SuperClass Of: | ++ {% for child in children|sort %} + {{child|prefix_this}}{{", " if not loop.last}} + {% endfor %} + | +
| Note: | +{{term.rdfs_comment}} | +
| Source: | ++ {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} + {{parent|saved_label}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_source|saved_label}} + {% endif %} + | +
| Created: | ++ |
| Modified: | ++ |
| Contributor(s): | ++ {% if term.dct_creator is sequence and not term.dct_creator is string %}{% for person in term.dct_creator|sort %} + {{person}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_creator}} + {% endif %} + | +
| See Also: | ++ {% if term.rdfs_seeAlso is sequence and not term.rdfs_seeAlso is string %}{% for link in term.rdfs_seeAlso %} + {{link|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_seeAlso|prefix_this}} + {% endif %} + | +
Properties
+
+ {% for term in term_list | sort(attribute='iri') %}
+ {{term.rdfs_label}} |
+ {% endfor %}
+
{{term.rdfs_label}}
+| Term: | +{% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
+
| Description: | +{{term.dct_description}} | +
| Sub-Property Of: | ++ {% if term.rdfs_subPropertyOf is sequence and not term.rdfs_subPropertyOf is string %}{% for parent in term.rdfs_subPropertyOf|sort %} + {{parent|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_subPropertyOf|prefix_this}} + {% endif %} + | +
| Source: | ++ {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} + {{parent|saved_label}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_source|saved_label}} + {% endif %} + | +
| Domain: | +{{term.rdfs_domain|prefix_this}} |
+
| Range: | +{{term.rdfs_range|prefix_this}} |
+
| Created: | ++ |
| Approved: | ++ |
| Contributor(s): | ++ {% if term.dct_creator is sequence and not term.dct_creator is string %}{% for person in term.dct_creator|sort %} + {{person}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_creator}} + {% endif %} + | +
| See Also: | ++ {% if term.rdfs_seeAlso is sequence and not term.rdfs_seeAlso is string %}{% for link in term.rdfs_seeAlso %} + {{link|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_seeAlso|prefix_this}} + {% endif %} + | +
Classes
+
+ {% for term in term_list | sort(attribute='iri') %}
+ {{term.skos_prefLabel}}{{" |" if not loop.last }}
+ {% endfor %}
+
{{term.skos_prefLabel}}
+| Term: | +{% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
+
| Definition: | +{{term.skos_definition}} | +
| SubClass of: | ++ {% if term.rdfs_subClassOf is sequence and not term.rdfs_subClassOf is string %}{% for parent in term.rdfs_subClassOf|sort %} + {{parent|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_subClassOf|prefix_this}} + {% endif %} + | +
| Instance of: | +{% for cls in term.rdf_type %}{% if 'dpv' in cls.iri %}{{cls|prefix_this}}{% endif %}{% endfor %} | +
| Narrower than: | ++ {% if term.skos_broaderTransitive is sequence and not term.skos_broaderTransitive is string %}{% for parent in term.skos_broaderTransitive|sort %} + {{parent|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.skos_broaderTransitive|prefix_this}} + {% endif %} + | +
| SuperType Of: | ++ {% for child in children|sort %} + {{child|prefix_this}}{{", " if not loop.last}} + {% endfor %} + | +
| Note: | +{{term.skos_note}} | +
| Source: | ++ {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} + {{parent|saved_label}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_source|saved_label}} + {% endif %} + | +
| Created: | ++ |
| Modified: | ++ |
| Contributor(s): | ++ {% if term.dct_creator is sequence and not term.dct_creator is string %}{% for person in term.dct_creator|sort %} + {{person}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_creator}} + {% endif %} + | +
| See Also: | ++ {% if term.skos_related is sequence and not term.skos_related is string %}{% for link in term.skos_related %} + {{link|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.skos_related|prefix_this}} + {% endif %} + | +
Properties
+
+ {% for term in term_list | sort(attribute='iri') %}
+ {{term.skos_prefLabel}} |
+ {% endfor %}
+
{{term.skos_prefLabel}}
+| Term: | +{% if not prefix %}{{term.iri|fragment_this}}{% else %}{{term.iri|fragment_this}}{% endif %} |
+
| Description: | +{{term.skos_definition}} | +
| Sub-Property Of: | ++ {% if term.rdfs_subPropertyOf is sequence and not term.rdfs_subPropertyOf is string %}{% for parent in term.rdfs_subPropertyOf|sort %} + {{parent|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.rdfs_subPropertyOf|prefix_this}} + {% endif %} + | +
| Source: | ++ {% if term.dct_source is sequence and not term.dct_source is string %}{% for parent in term.dct_source|sort %} + {{parent|saved_label}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_source|saved_label}} + {% endif %} + | +
| Domain: | +{{term.rdfs_domain|prefix_this}} |
+
| Range: | +{{term.rdfs_range|prefix_this}} |
+
| Created: | ++ |
| Approved: | ++ |
| Contributor(s): | ++ {% if term.dct_creator is sequence and not term.dct_creator is string %}{% for person in term.dct_creator|sort %} + {{person}}{{', ' if not loop.last }} + {% endfor %}{% else %} + {{term.dct_creator}} + {% endif %} + | +
| See Also: | ++ {% if term.skos_related is sequence and not term.skos_related is string %}{% for link in term.skos_related %} + {{link|prefix_this}}{{", " if not loop.last}} + {% endfor %}{% else %} + {{term.skos_related|prefix_this}} + {% endif %} + | +
The Data Privacy Vocabulary (DPV) provides terms (classes and properties) to describe and represent information related to processing of personal data based on established requirements such as for the EU General Data Protection Regulation (GDPR). The DPV is structured as a top-down hierarchical vocabulary with the core or base concepts of personal data categories, purposes of processing and types of processing, data controller(s) associated, recipients of personal data, legal bases or justifications used, technical and organisational measures and restrictions (e.g. storage locations and storage durations), applicable rights, and the risks involved.
-
- The namespace for DPV terms is http://www.w3.org/ns/dpv#
- The suggested prefix for the DPV namespace is dpv
- The DPV and its documentation is available on GitHub.
This document is published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a deliverable and report of its work in creating and maintaining the Data Privacy Vocabulary (DPV).
-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:
+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 describes the DPV specification along with its data model.
+The canonical URL for DPV is https://w3id.org/dpv# which contains (this) specification. The namespace for DPV terms is https://w3id.org/dpv#, the suggested prefix for is dpv, and this document along with its various serializations are available on GitHub.
+
Newcomers to the DPV are strongly recommended to first read through the [[[DPV-Primer]]] to familiarise themselves with the semantics, concepts, their place within DPV.
+ +DPV Family of Documents
-
-
- Personal Data Categories -
- Purposes -
- Processing Categories -
- Technical and Organisational Measures -
- Legal Basis such as Consent -
- Entities such as Recipients, Data Controllers, Data Subjects -
- Rights -
- Risks +
- [[DPV-Primer]]: The Primer serves as an introductory document to DPV and provides an overview of its concepts. +
- [[DPV]]: (This document) The DPV Specification is the formal and normative description of DPV and its concepts. It provides a serialisation of the concepts as a taxonomy using SKOS. +
- Extensions to Concepts:
-
+
- [[DPV-GDPR]]: Extension to the DPV providing concepts relevant to [[GDPR]]. +
- [[DPV-PD]]: Extension to the DPV providing a taxonomy of personal data categories.
+ - Serialisations of DPV:
-
+
- [[DPV-SKOS]]: A serialisation of the DPV using [[RDFS]] and [[SKOS]] to enable its use as a schema or ontology. +
- [[DPV-OWL]]: is a serialisation of the DPV using [[OWL]] to enable its use as an ontology.
+ - [[DPV-NACE]]: [[NACE]] taxonomy serialised in RDFS
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.
The table provides an overview of the expression of concepts across the three DPV serialisations.
| Prefix | -Namespace | -Concept | +[[DPV]] | +[[DPV-SKOS]] | +[[DPV-OWL]] |
|---|---|---|---|---|---|
- 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#
- |
+ Concept | +dpv:Concept
+ | skos:Concept |
+ owl:Class |
- svl
- |
-
- http://www.specialprivacy.eu/vocabs/locations#
- |
+ is subtype of | +dpv:isSubTypeOf
+ | skos:broaderTransitive |
+ owl:subClassOf |
- svpu
- |
-
- http://www.specialprivacy.eu/vocabs/purposes#
- |
+ is instance of | +dpv:isInstanceOf
+ | rdf:type |
+ rdf:type |
- svpr
- |
-
- http://www.specialprivacy.eu/vocabs/processing#
- |
+ has concept | +dpv:Relation
+ | rdf:Property |
+ owl:ObjectProperty |
- svr
- |
-
- http://www.specialprivacy.eu/vocabs/recipients
- |
+ relationship domain | +dpv:domain
+ | rdfs:domain |
+ rdfs:domain |
- xsd
- |
-
- http://www.w3.org/2001/XMLSchema#
- |
+ relationship range | +dpv:range
+ | rdfs:range |
+ rdfs:range |
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.
-Related Links
+-
+
- 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.
+Serialisations of DPV and its modules are available on GitHub.
+Base Vocabulary
-Concepts in the Base vocabulary are available as an individual module here.
The 'Base' or 'Core' vocabulary describes the top-level classes required for defining a 'policy' for personal data handling. Classes and properties for each top-level class are further elaborated using sub-vocabularies, for example a taxonomy of personal data categories. While all concepts within the vocabulary share a single namespace, the modular approach makes it possible to use only the specific taxonomies or sub-vocabularies, for example to refer only to purposes. The DPV provides the following as top-level concepts and generic properties to associate them with other concepts:
+The 'Base' or 'Core' concepts in DPV represent the most relevant concepts for representing information regarding the what, how, where, who, why of personal data and its processing. Each of these concepts is further elaborated as a taxonomy of concepts in a hierarchical fashion. The DPV provides the following as 'top-level' concepts and relations to associate them with other concepts:
| [=PersonalDataCategory=] | -[=hasPersonalDataCategory=] | +[=PersonalData=] | +[=hasPersonalData=] | Personal data categories |
| Legal bases or justifications for processing | ||||
| [=Right=] and [=DataSubjectRight=] | +[=Right=] | [=hasRight=] | Rights applicable or provided | [=hasRisk=] | Risks applicable or probable regarding processing | +
| [=PersonalDataHandling=] | +[=hasPersonalDataHandling=] | +A concept for associating the other core concepts as a 'group, 'policy', or 'set' - so as to express different use-cases and combinations | +
DPV provides taxonomies for all core concepts except the ones specified below:
-
-
+
- PersonalDataHandling: DPV defines the concept of for representing a 'policy' or 'grouping' that associates the top-level concepts with one another. The relation hasPersonalDataHandling provides a relation to associate a
PersonalDataHandlingwith other concepts, including like itself.
+ - Right: The concept
Rightrepresents a generic rights provided or recognised by some law or convention. The relation hasRight provides the relation to associate aRightwith concepts.. In addition, DataSubjectRight refers to rights specifically available to applicable for Data Subjects.
+ - Risk represents the generic concept of Risk that can be associated with other concepts using [=hasRisk=].
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.
+ {% if core_classes %}Personal Data Categories
-Concepts related to Personal Data Categories are available as an individual module here.
-DPV provides broad top-level personal data categories adapted from the taxonomy contributed by R. Jason Cronk [[EnterPrivacy]]. The top-level concepts in this taxonomy refer to the nature of information (financial, social, tracking) and to its inherent source (internal, external). Each top-level concept is represented in the DPV vocabulary as a Class, and is further elaborated by subclasses for referring to specific categories of information - such as preferences or demographics.
-
- While this taxonomy is by no means exhaustive, the aim is to provide a sufficient coverage of abstract categories of personal data which can be extended using the subclass mechanism to represent concepts used in the real-world.
-Regulations such as the GDPR define personal data at an abstract level as information (directly or indirectly) associated with an individual or a category of individuals. DPV defines classes representing categories that are inclusive of information associated with them (e.g. name consisting of first name, last name), with their instances representing specific elements of 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 | -
Entities
+ {% if entities_classes %} +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.
-
- 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 | -
| [=Context=] | -[=hasContext=] | -Indicate context or restrict purpose to context | -
Purposes
+ {% if purpose_classes %} +Processing Categories
-Concepts related to Processing are available as an individual module here.
-DPV provides a hierarchy of classes to specify the operations associated with the processing of personal data. Declaring the processing or processing categories associated with personal data is required by regulations such as the GDPR. Processing operations (e.g. collect, share, and use) can have specific constraints or obligations which makes it necessary to accurately represent them. While the term ‘use’ is liberally used to refer to a broad range of processing categories in privacy notices, we suggest to select and use appropriate terms to accurately reflect the nature of processing where applicable.
-
- There are a variety of terms used for describing processing operations depending on specific interpretations within the technological, legal, or sociological domain. We consolidate these terms and define the 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 | -
Processing
+ {% if processing_classes %}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 -
- 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 | -
| - | [=measureImplementedBy=] | -Specifies the implementation details of measure | -
| [=RiskMitigationMeasure=] | -[=mitigatesRisk=] | -Specifies use of measure to mitigate risks | -
| [=StorageRestriction=] | -- | Specifies restriction on storage of personal data | -
| [=StorageDuration=] | -- | Specifies restriction on duration of storage | -
| [=StorageLocation=] | -- | Specifies restriction on location of storage | -
| [=StorageDeletion=] | -- | Specifies restriction on deletion of storage | -
| - | [=hasStorage=] | -Specifies information about storage | -
| - | [=hasLocation=] | -Specifies information about location | -
| - | [=hasDuration=] | -Specifies information about duration | -
Personal Data
+ {% if personaldata_classes %} +Tech/Org Measures
+ {% if technical_organisational_measures_classes %} +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.
-
- 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.
- {% if entities_classes %} -Contextual Info
+ {% if context_classes %} +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.
+Location & Jurisdictions
+ {% if jurisdictions_classes %} +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.
-Legal Bases
+ {% if legal_basis_classes %}Consent
-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.
- {% if consent_classes %} +