Data Privacy Vocabulary Version 0.1
Editor:
Axel Polleres, Vienna University of Economics and Business
Contributors:
(In alphabetical order)
Bert Bos, W3C/ERCIM
Rob Brennan, Trinity College Dublin
Bud Bruegger, Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein
Fajar J. Ekaputra, Vienna University of Technology
Javier D. Fernández, Vienna University of Economics and Business
Ramisa Gachpaz Hamed, Trinity College Dublin
Elmar Kiesling, Vienna University of Technology
Mark Lizar, OpenConsent/Kantara Initiative
Harshvardhan Pandit, Trinity College Dublin
Eva Schlehan, Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein
Simon Steyskal, Siemens
Rigo Wenning, W3C/ERCIM
The Data Privacy Vocabulary provides terms and attributes[a] to annotate and categorize instances of legally compliant personal data handling according to the EU General Data Protection. This scope could be extended by later versions to other data and privacy protection regulations. The vocabulary provides terms to describe which personal data Categories are undergoing a specified kind of processing by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal ground (e.g. consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g. storage locations and storage durations) in place.
This document was published by the Data Privacy Vocabularies and Controls Community Group (DPVCG) as a first public working draft. If you wish to make comments regarding this document, please send them to public-dpvcg@w3.org (archives). All comments are welcome.
Specifically, the DPVCG kindly requests proposals to extend its initial taxonomies by additional terms, where these are missing or need refinements in order to describe specific use cases of personal data handling. In order to propose/approve new terms, please include the following in your email:
Technical and Organisational Measures
Recipients, Data Controllers, Data Subjects
The Data Privacy Vocabulary provides terms and attributes[b] to annotate and categorize instances of legally compliant personal data handling. In particular, the vocabulary provides extensible taxonomies of terms to describe these components, namely:
These concepts and terms should be usable to annontate Legal Personal data Handling in a machine-readable fashion, in terms of which personal data Categories are undergoing a specified kind of processing by a specific data controller and/or transferred to some recipient for a particular purpose, based on a specific legal ground (e.g. consent, or other legal grounds such as legitimate interest, etc.), with specified technical and organisational measures and restrictions (e.g. storage locations and storage durations) in place.
Descriptions and respective annotations of Legal Personal data Handling could be used for instance to:
ISSUE-2 should we do something like SPECIAL
We use the following RDF namespace for all terms defined in the DPVCG community group:
dpv: http://www.w3.org/ns/dpv#
Besides that, the present specification occasionally refers to the following external namespaces:
rdf |
The normative W3C RDF vocabulary |
|
rdfs |
The normative W3C RDFS vocabulary |
|
owl |
The normative W3C OWL vocabulary |
|
skos |
The normative W3C SKOS vocabulary |
|
dct |
Dublin core terms |
|
odrl |
Namespace of the Open Digital Rights Language |
|
spl |
||
svd |
Namespace for SPECIAL data categories |
|
svpu |
Namespace for SPECIAL purposes |
|
svpr |
Namespace for SPECIAL processing |
|
svr |
Namespace for SPECIAL recipients |
|
svl |
Namespace for SPECIAL locations |
|
svdu |
Namespace for SPECIAL durations |
|
dpv-nace |
Auxiliary namespace for casting NACE codes as an RDFS hierarchy |
|
dpv-gdpr |
Auxiliary namespace for referring explicitly to particular Articles and paragraphs in GDPR, e.g. the URI dpv-gdpr:A6-1-b refers to GDPR Article 6, paragraph 1(b). |
The base vocabulary to describe Legal Personal data Handling provides terms to connect the terms defined in the other sub-taxonomies.
Classes: |
---|
dpv:PersonalDataHandling |
dpv:PersonalDataCategory |
dpv:Processing |
dpv:Purpose |
dpv:Recipient |
dpv:TechnicalOrganisationalMeasure |
dpv:LegalBasis |
dpv:DataSubject |
dpv:DataController |
Properties: |
---|
dpv:hasPersonalDataCategory |
dpv:hasProcessing |
dpv:hasPurpose |
dpv:hasRecipient |
dpv:hasTechnicalOrganisationalMeasure |
dpv:hasLegalBasis |
dpv:hasDataSubject |
dpv:hasDataController |
dpv:PersonalDataHandling a rdfs:Class ; dct:description "Top Class to describe a concrete instance of legal personal Data Handling of a defined class of Data Subjects, meaning that a personal Data Category is undergoing specified processing by a specific data controller and/or
transferred to some recipient for a particular purpose, based on a specific legal ground, with specified security measures and restrictions (e.g. storage locations and storage durations)." .
dpv:PersonalDataHandling dct:created "04.04.2019"^^xsd:date .
dpv:PersonalDataHandling dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:PersonalDataCategory a rdfs:Class ; dct:description "A category of personal data (as defined by GDPR article 4.1) from the personal data categories taxonomy, i.e. for instance denoting the category of an object/field or data item that is used for processing" .
dpv:PersonalDataCategory dct:created "04.04.2019"^^xsd:date .
dpv:PersonalDataCategory dct:date-accepted "04.04.2019"^^xsd:date .
dpv:PersonalDataCategory dct:creator "Harshvardhan Pandit, Axel Polleres" .
dpv:Processing a rdfs:Class ; dct:description "A type of processing from one of the processing categories in the processing Taxonomy" .
dpv:Processing dct:created "04.04.2019"^^xsd:date .
dpv:Processing dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:Purpose a rdfs:Class ; dct:description "The purpose of Data Handling, from the purposes Taxonomy" .
dpv:Purpose dct:created "04.04.2019"^^xsd:date .
dpv:Purpose dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:Recipient a rdfs:Class ; dct:description "The entities that can access the result of a data handling action/processing, any legal entity that is defined by article 4.9 of GDPR." .
dpv:Recipient dct:created "04.04.2019"^^xsd:date .
dpv:Recipient dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:TechnicalOrganisationalMeasure a rdfs:Class ; dct:description "Technical and organisational measures, for instance security measure, storage restrictions etc. required/followed when processing data of the declared category" .
dpv:TechnicalOrganisationalMeasure dct:created "04.04.2019"^^xsd:date .
dpv:TechnicalOrganisationalMeasure dct:creator "Bud Bruegger" .
dpv:LegalBasis a rdfs:Class ; dct:description "A particular legal Basis, which permits personal Data handling (e.g. Consent, etc.)" .
dpv:LegalBasis dct:created "04.04.2019"^^xsd:date .
dpv:DataSubject a rdfs:Class ; dct:description "The class of Data Subject that this particular data handling applies to, any legal entity that is defined by article 4.1 of GDPR." .
dpv:DataSubject dct:created "04.04.2019"^^xsd:date .
dpv:DataSubject dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:DataController a rdfs:Class ; dct:description "The class of Data Controllers that control this particular data handling, any legal entity that is defined by article 4.7 of GDPR." .
dpv:DataController dct:created "04.04.2019"^^xsd:date .
dpv:DataController dct:creator "Axel Polleres, Javier Ferenandez" .
dpv:hasPersonalDataCategory a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its affected personal data categories " .
dpv:hasPersonalDataCategory rdfs:domain dpv:PersonalDataHandling .
dpv:hasPersonalDataCategory rdfs:range dpv:PersonalDataCategory .
dpv:hasProcessing a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its involved data processing categories. " .
dpv:hasProcessing rdfs:domain dpv:PersonalDataHandling .
dpv:hasProcessing rdfs:range dpv:Processing .
dpv:hasPurpose a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its purpose" .
dpv:hasPurpose rdfs:domain dpv:PersonalDataHandling .
dpv:hasPurpose rdfs:range dpv:Purpose .
dpv:hasRecipient a rdfs:Property ; dct:description "This property associates an instance of legal data handling with potential recipients" .
dpv:hasRecipient rdfs:domain dpv:PersonalDataHandling .
dpv:hasRecipient rdfs:range dpv:Recipient .
dpv:hasTechnicalOrganisationalMeasure a rdfs:Property ; dct:description "This property associates an instance of legal data handling with required/followed technical and organisational measures" .
dpv:hasTechnicalOrganisationalMeasure rdfs:domain dpv:PersonalDataHandling .
dpv:hasTechnicalOrganisationalMeasure rdfs:range dpv:SecurityMeasure .
dpv:hasLegalBasis a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its underlying legal basis" .
dpv:hasLegalBasis rdfs:domain dpv:PersonalDataHandling .
dpv:hasLegalBasis rdfs:range dpv:LegalGround .
dpv:hasDataSubject a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its affected data subject(s)" .
dpv:hasDataSubject rdfs:domain dpv:PersonalDataHandling .
dpv:hasDataSubject rdfs:range dpv:DataSubject .
dpv:hasDataController a rdfs:Property ; dct:description "This property associates an instance of legal data handling with its involved data controller(s)" .
dpv:hasDataController rdfs:domain dpv:PersonalDataHandling .
dpv:hasDataController rdfs:range dpv:Datacontroller .
#import PersonalDataCategory.html
DPVCG at the moment defines a hierarchically organized set of generic categories of data handling purposes. Typical regulations such as GDPR require though that a specific purpose is declared in an understandable manner. We therefore suggest to declare the specific context as an instance of one or several DPV-Purpose categories and always declare the specific purpose in a human readable descriptrion (rdfs:comment).
dpv:Purpose rdfs:subClassOf [ onProperty rdfs:comment owl:someValuesFrom … ] [c][d]
Moreover, purposes can be further restricted to a specific context, for instance a specific business sector. At the moment, we recommend to specify this sector in terms of the EU NACE hierarchy, using the following URI-scheme.
dpv-nace:NACE-CODE
For instance, … add example
Alternative hierarchies for defining business sectors include NAICS (US) and ISIC (UN)[e][f].
#import Purpose.html
We understand the nature of processing as the "processing operation to likely result in a high risk”.
Start with the basic categories of https://github.com/dpvcg/processing (second diagram) and consider feedback of Bud regarding the high risk of Article 22:
Nature of Processing/Decision Making
monitoringDrivingBehaviour :hasProcessingType [
:typeProcessing ;erasure;
:isAutomatedDecM true;
:isSystematicMonitoring true
]
:Nature
Procedure: fully-automated
Transp: machine-learning
:Context driving behavior
]
As for “derive” processing, we can have what we derive or just store in a different policy (that is, with data public life and processing derive, and in another policy we say collect sexual behavioral)
#import Processing.html
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. These include:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
For any of the declared Technical and organisational measures defined below, we provide an ObjectProperty, and for the values of these attributes (with the exception of Storage), we either allow a blank node with a single rdfs:comment[h][i][j] to describe the measure, or a URI to a standard or best practice followed, i.e. a well-known identifier for that standard ot a URL where the respective document can describing the standard. In the future, we plan to provide a collection of URIs for identifying recommended standards and best practices.
In particular, in future versions of this document we might extend the vocabulary by an approved taxonomy of identifiers for such standards and best practices.
#import TechnicalOrganisationalMeasure.html
TODO: this needs to be moved to the spreadsheet:
TODO: add rationale
#import LegalBasis.html
TODO: add rationale
#import Consent.html
TODO: add rationale
#import RecipientsDataControllersDataSubjects.html
[a]classes and properties?
[b]classes and properties?
[c]Not really expressible in OWL alone, SHACL?
[d]sure :D
[e]add references
[f]NAICS https://www.census.gov/eos/www/naics/2017NAICS/2017_NAICS_Manual.pdf
ISIC https://unstats.un.org/unsd/publication/SeriesM/seriesm_4rev4e.pdf
[g]with legal or similar significant effect [Bud: financial effects??]
[h]Why not create a property to specify this? Could be sub-property of rdfs:comment if semantics matter.
[i]I agree but I think it is not appropriate to subclass rdfs:comment as that is outside the logical model
[j]agreed, subclassing reserved vocabularies is evil :)
[k]Can be combined with Access Control as Securing Access to Data. PseudoAnonymisation and Encryption should be in separate categories.
[l]Is this distinct from pseudo-anonymisation?
[m]Difference between Standards and Design Standards?
[n]feel free to add references, Mark, Harsh?