This document lists the examples for concepts in DPV and aligned vocabularies. The examples are available in DPVCG GitHub repo under ./examples path.
Release Candidate for DPV v1.0 The current release is the final point/minor version before the scheduled release of v1 approx. around 15-NOV-2022. Feedback can be provided via GitHub or [email protected] (mailing list).
Newcomers to the DPV are strongly recommended to first read through the Primer to familiarise themselves with the semantics and concepts of DPV.
Related Links
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.
The namespaces used in this document are as follows:
: | <<https://w3id.org/dpv/examples/vocab#> |
dpv: | <https://w3id.org/dpv#> |
dct: | <http://purl.org/dc/terms/> |
rdfs: | <http://www.w3.org/2000/01/rdf-schema#> |
skos: | <http://www.w3.org/2004/02/skos/core#> |
owl: | <http://www.w3.org/2002/07/owl#> |
vann: | <http://purl.org/vocab/vann/> |
xsd: | <http://www.w3.org/2001/XMLSchema#> |
sh: | <http://www.w3.org/ns/shacl#> |
| IRI | https://w3id.org/dpv/use-cases/vocab# |
skos:definition | An Example provides a description where information within the scope of DPVCG is expected to be relevant or applied, and acts as the basis for identifying requirements (including but not limited to creation of concepts). Use cases can contain descriptions of systems, their operations, actors and entities involved, restrictions or constraints, or any other pertinent detail. They can be a simple textual paragraph or elaborative structured documents (in which case we prefer to reference them here as an URL). |
dct:title)dct:description)dct:identifier)dct:contributor)dct:date)dct:source)dct:subject)dct:references)Dummy Example description
Relevant Concepts: dpv:Concept, dpv:Relation
source: https://w3id.org/dpv/examples/E0001.ttl
dpv:PersonalData a dpv:Concept ;
rdfs:label "Personal Data"@en .
dpv:hasPersonalData a dpv:Relation ;
rdfs:label "has personal data"@en .Dummy Example 2 description
Relevant Concepts: dpv:Concept
DPV defines the (broad) concept Marketing in its Purpose hierarchy to represent information about (purposes related to) marketing activities and topics. For a use-case which requires representing purposes (note: plural) related to marketing of new products, the broad Marketing concept is extended as a child or subclass concept for representing the intended purpose as, e.g. MarketingNewProducts.
Relevant Concepts: dpvs:Purpose
source: https://w3id.org/dpv/examples/E0003.ttl
# Case1: Where further categories are required to 'group' related purposes
# creating a new subclass or category of Marketing for use-case
ex:MarketingOfNewProducts a dpv:Purpose ;
skos:broader dpv:Marketing ;
rdfs:label “Marketing of New Products” .
# more specific purposes under group ‘Marketing of New Products’
ex:NewslettersOffers a dpv:Purpose ;
skos:broader ex:MarketingOfNewProducts ;
rdfs:label “Newsletters about Offers” .
ex:EmailsSeasonalOffers a dpv:Purpose ;
skos:broader ex:MarketingOfNewProducts ;
rdfs:label “Emails about Seasonal Offers” .
# Case2: A single final and definite purpose within EmailSeasonalOffers
ex:MarketingSeasonalOffer2021 a dpv:Purpose ;
skos:broader dpv:Marketing ;
rdfs:label "Sending Email Newsletters with Seasonal Offers" .
DPV defines the (broad) concept Marketing in its Purpose hierarchy to represent information about (purposes related to) marketing activities and topics. For a use-case which requires representing purposes (note: plural) related to marketing of new products, the broad Marketing concept is extended as a child or subclass concept for representing the intended purpose as, e.g. MarketingNewProducts.
Relevant Concepts: dpvo:Purpose
source: https://w3id.org/dpv/examples/E0004.ttl
# Case1: Where further categories are required to 'group' related purposes
# creating a new subclass or category of Marketing for use-case
ex:MarketingOfNewProducts rdfs:subClassOf dpv:Marketing ;
rdfs:label “Marketing of New Products” .
# more specific categories of group ‘Marketing of New Products’
ex:NewslettersOffers rdfs:subClassOf ex:MarketingOfNewProducts ;
rdfs:label “Newsletters about Offers” .
ex:EmailsSeasonalOffers rdfs:subClassOf ex:MarketingOfNewProducts ;
rdfs:label “Emails about Seasonal Offers” .
# Case2: A single final and definite purpose within EmailSeasonalOffers
ex:MarketingSeasonalOffer rdf:type dpv:Marketing ;
rdfs:label "Sending Email Newsletters with Seasonal Offers" .
Consider the use-case where an activity simultaneously uses the data while collecting it. The first representation (ActivityA) models them separately - which is not accurate as it is ambiguous in terms of collection and usage taking place independently. By extending the collect and use concepts to create a new concept called CollectAndUse, it is possible to accurately declare that they both occur as a concurrent operation. Such combinations of concepts are also useful to collectively represent or annotate additional information such as: technologies involved, implementation details, or agents involved
Relevant Concepts: dpv:Concept, dpv:Processing
source: https://w3id.org/dpv/examples/E0005.ttl
# Method 1: Ambiguous regarding independence of Collect and Use
ex:ActivityA a dpv:PersonalDataHandling ;
dpv:hasProcessing ex:Collect, ex:Use .
# Method 2: Accuracy regarding combination of Collect and Use
ex:CollectAndUse skos:broader ex:Collect, ex:Use ;
rdfs:label “Collect and Use data using User Device” .
ex:Activity a dpv:PersonalDataHandling ;
dpv:hasProcessing ex:CollectAndUse .
For example, two TV companies (AliceCo and BobCo) extend the concept Optimisation to reflect their respective purposes. When exchanging information about their use-cases with each other (or with a third party), by following the chain of use-case specific concepts it is possible to deduce that both AliceCo and BobCo are doing optimisations for consumers. Thus a common language or interface can be developed based on using DPV as a point of interoperability and commonality which can be used by adopters to define the specifics of their use-case. For example, in the above use-case, a common notice generation algorithm could be created and used to inform users of both services the purposes each company is using data for.
Relevant Concepts: dpv:Concept, dpv:Purpose
source: https://w3id.org/dpv/examples/E0006.ttl
# AliceCo’s optimisation related to better services for users’ infrastructure
exA:TVServiceOptimisaion skos:broader dpv:OptimisationForConsumer ;
rdfs:label “Optimise Service for Users’ Infrastructure” .
# BobCo’s optimisation related to more efficient signals for users’ TV sets
exB:TVSignalOptimisation skos:broader dpv:OptimisationForConsumer ;
rdfs:label “Optimise Signal for Consumer TV Set” .<F24><F25> .
# analysing respective graphs, a common ancestor is found as:
# dpv:OptimisationForConsumer ; Using this as context to compare:
# (either manually, or based on data used, etc.)
# 1: BobCo's optimisations are found to be broader than AliceCo's
exA:TVServiceOptimisation skos:broader exB:TVServiceOptimisation .
# 2: BobCo's optimisations are found to be the same as AliceCo's
exA:TVServiceOptimisation skos:exactMatch exB:TVServiceOptimisation .
# 3: BobCo's optimisations are found to be similar to AliceCo's
exA:TVServiceOptimisation skos:closeMatch exB:TVServiceOptimisation .
For an example of how PersonalDataHandling brings together the core concepts, consider the example where Acme is a DataController that Collect(s) and Use(s) Email for ServiceProvision.
Relevant Concepts: dpv:PersonalDataHandling
source: https://w3id.org/dpv/examples/E0007.ttl
ex:Acme rdf:type dpv:DataController .
ex:AcmeMarketing rdf:type dpv:PersonalDataHandling ;
dpv:hasDataController ex:Acme .
dpv:hasPersonalDataCategory dpv:EmailAddress ;
dpv:hasProcessing dpv:Collect, dpv:Use ;
dpv:hasPurpose dpv:ServiceProvision ;
onsider the example where Acme, as a DataController, maintains records of its processing activities using PersonalDataHandling to represent one of its services. In this, it collects email, uses it for internal analyses based on LegitimateInterests, and also sends marketing information by using a processor based on the data subject's consent. Using nesting of personal data handling, the information can be expressed at granular level representing service, individual purposes, and so on.
Relevant Concepts: dpv:PersonalDataHandling
source: https://w3id.org/dpv/examples/E0008.ttl
ex:Acme rdf:type dpv:DataController .
ex:AcmeMarketing rdf:type dpv:PersonalDataHandling ;
dpv:hasPersonalDataHandling ex:InternalAnalytics ;
dpv:hasPersonalDataHandling ex:SendingNewsletters .
ex:InternalAnalytics rdf:type dpv:PersonalDataHandling ;
dpv:hasPersonalData dpv:Email ;
dpv:hasProcessing dpv:Collect, dpv:Store ;
dpv:hasPurpose dpv:InternalResourceOptimisation ;
dpv:hasLegalBasis dpv:LegitimateInterestOfController .
ex:FooTech rdf:type dpv:DataProcessor .
ex:SendingNewsletters rdf:type dpv:PersonalDataHandling ;
dpv:hasPersonalData dpv:Email ;
dpv:hasProcessing dpv:Share ;
dpv:hasPurpose dpv:Marketing ;
dpv:hasDataProcessor ex:FooTech ;
dpv:hasLegalBasis dpv:Consent .
In this example, a new purpose is created by extending dpv:FraudPreventionAndDetection and annotated with human-readable information. The interpretation of this purpose is thus more clear in relation to how it is applied or used within that use-case, and also serves to compare it with other purposes within the same category.
Relevant Concepts: dpv:Concept, dpv:Purpose
source: https://w3id.org/dpv/examples/E0009.ttl
ex:PreventTransactionFraud a dpv:Purpose ;
skos:broader dpv:FraudPreventionAndDetection ;
skos:prefLabel "Prevent Transaction and Payment Frauds" ;
For example, the following purpose concerns implementing access control with the domain specified as scientific research using its corresponding NACE code M72 to indicate sectorial implications for what "access control" and "enforce security" are expected to imply.
Relevant Concepts: dpv:Purpose, dpv:Sector
source: https://w3id.org/dpv/examples/E0010.ttl
:RestrictPersonnelAccess a dpv:Purpose ;
skos:broader dpv:EnforceSecurity ;
skos:prefLabel “Limit access to lab by checking personnel identity" ;
dpv:hasSector dpv-nace:M72 .
Acme is a Data Processor that stores data within servers located in Ireland for a period of one year.
Relevant Concepts: dpv:DataProcessor, dpv:Duration, dpv:Location, dpv:Processing, dpv:StorageCondition
source: https://w3id.org/dpv/examples/E0011.ttl
ex:ServerInfo a dpv:PersonalDataHandling ;
dpv:hasDataProcessor ex:Acme ;
dpv:hasProcessing dpv:Store ;
dpv:hasStorageCondition ex:DataStoragePolicy .
ex:DataStoragePolicy a dpv:StorageCondition ;
dpv:hasLocation ex:IE ;
dpv:hasDuration [
rdf:type time:Duration, dpv:Duration ;
time:numericDuration "1"^^xsd:decimal ;
time:unitType time:unitYear ;
] .
Data sources can be the data subject (direct or indirect), the data controller or processor (itself), or another entity (third party). The below example provides an overview of these with distinctions between source and method of generation.
Relevant Concepts: dpv:DataSource
source: https://w3id.org/dpv/examples/E0012.ttl
ex:S01 dpv:hasDataSource dpv:DataSubject .
ex:S01 dpv:hasProcessing dpv:Collect .
ex:S02 dpv:hasDataSource dpv:DataSubject .
ex:S02 dpv:hasProcessing dpv:Derive, dpv:Observe .
ex:S03 dpv:hasDataSource dpv:DataController .
ex:S03 dpv:hasProcessing dpv:Infer .
ex:S04 dpv:hasDataSource ex:Acme .
ex:Acme a dpv:ThirdProcessor .
ex:S05 dpv:hasDataSource dpv:DataPublishedByDataSubject .
ex:S05 dpv:hasProcessing dpv:Collect .
Consider the use of a spam filter that is based on automated processing operations where humans provide inputs, have oversight of the operation, and results in automated decision making for whether communications should be propogated. A new separate filter is developed that utilises a novel spam detection criteria that also takes into account communications other than emails for the sender and makes automated decisions whether to permit communication to proceed. Such explicit annotation of several high-risk operations assists in performing impact assessments for this technology, as well as understanding the extent and effectiveness of human involvement to mitigate risks and issues.
Relevant Concepts: dpv:HumanInput, dpv:ProcessingAutomation
source: https://w3id.org/dpv/examples/E0013.ttl
ex:SpamFilter rdf:type dpv:Processing ;
skos:broader dpv:Analyse ;
dpv:hasProcessingAutomation dpv:FullyAutomatedProcessing ;
dpv:hasHumanInvolvement dpv:HumanInput, dpv:HumanOversight ;
dpv:hasAlgorithmicLogic ex:SpamDetection .
ex:SpamDetection rdf:type dpv:AlgorithmicLogic ;
skos:broader dpv:InnovativeUseOfNewTechnologies ;
dpv:hasProcessingContext dpv:AutomatedDecisionMaking,
dpv:SystemicMonitoring,
dpv:EvaluationScoring ;
dpv:hasPersonalData dpv-pd:Communication ;
dpv:hasDataSource ex:EmailSender .
This use-case collects browser fingerprint and IP Address to identify the country one is visiting from, and to infer language to be used for personalisation. Note that this example uses [[DPV-PD]] for personal data concepts.
Relevant Concepts: dpv:Derive, dpv:Infer, dpv:PersonalDataHandling, dpv:Processing, dpv:Purpose
source: https://w3id.org/dpv/examples/E0014.ttl
ex:PersonaliseWebsiteForVisitors rdf:type dpv:PersonalDataHandling ;
dpv:hasPurpose dpv:Personalisation ;
dpv:hasPersonalData dpv-pd:BrowserFingerprint,
dpv-pd:IPAddress ;
dpv:hasProcessing dpv:Collect, dpv:Use ;
dpv:hasPersonalDataHandling ex:DeriveVisitorCountry ;
dpv:hasPersonalDataHandling ex:InferVisitorLanguage .
ex:DeriveVisitorCountry rdf:type dpv:PersonalDataHandling ;
dpv:hasProcessing dpv:Derive ;
dpv:hasPersonalData ex:VisitorCountry .
ex:VisitorCountry rdf:type dpv:DerivedPersonalData ;
skos:broader dpv-pd:Country .
ex:InferVisitorLanguage rdf:type dpv:PersonalDataHandling ;
dpv:hasProcessing dpv:Infer ;
dpv:hasPersonalData ex:VisitorLanguage .
ex:VisitorLanguage rdf:type dpv:InferredPersonalData ;
skos:broader dpv-pd:Language .
In this example, the knowledge that blood samples are of type 'special category' can be inferred from the fact that they are a form of Medical Health which is a 'special category'. However, the example considers best practices that suggest explicitly identifying and denoting that blood samples are also of type 'special category'.
Relevant Concepts: dpv:SensitivePersonalData, dpv:SpecialCategoryPersonalData
source: https://w3id.org/dpv/examples/E0015.ttl
ex:PatientStudy rdf:type dpv:PersonalDataHandling ;
dpv:hasPersonalData ex:BloodSamples, ex:PatientIdentifier .
ex:BloodSamples rdf:type dpv:SpecialCategoryPersonalData ;
skos:broader dpv-pd:MedicalHealth ;
skos:narrower dpv-pd:BloodType .
ex:PatientIdentifier rdf:type dpv:SensitivePersonalData ;
skos:broader dpv-pd:Identifying .
To indicate data is encrypted using the Rivest-Shamir-Adleman (RSA) method, one would extend the Encryption concept within DPV to represent RSA, and then instantiate it with the specific implementation used (e.g. to indicate key size). Access to this data is further restricted by requiring a password or credential.
Relevant Concepts: dpv:AccessControlMethod, dpv:Encryption, dpv:TechnicalMeasure
source: https://w3id.org/dpv/examples/E0016.ttl
ex:RSAEncryption rdf:type dpv:TechnicalMeasure ;
skos:broader dpv:Encryption ;
skos:scopeNote "Key size: 2048, Custom Implementation"@en .
ex:RBACCredential rdf:type dpv:TechnicalMeasure ;
skos:broader dpv:AccessControlMethod .
To indicate staff are trained in the use of credentials, and that a policy exists regarding this, the use of OrganisationalMeasure concepts can be combined in several ways. Note that the interpretations for how staff training is associated with credentials, or contains training regarding credentials is arbitrary in notation. It is intended to demonstrate how different perspectives can be represented so as to be suitable to the organisation's documentation practices.
Relevant Concepts: dpv:OrganisationalMeasure, dpv:Policy, dpv:StaffTraining
source: https://w3id.org/dpv/examples/E0017.ttl
# 1: directly associating staff training with credentials used
ex:StaffCredentialsTraining rdf:type dpv:OrganistionalMeasure ;
skos:broader dpv:StaffTraining .
ex:RBACCredential dpv:hasOrganisationalMeasure ex:StaffCredentialTraining .
# 2: security policy containing staff training and access control
ex:SecurityPolicy rdf:type dpv:OrganisationalMeasure ;
skos:broader dpv:Policy ;
dpv:hasOrganisationalMeasure dpv:StaffTraining ;
dpv:hasTechnicalMeasure dpv:AccessControlMethod .
# 3: indicating staff training contains access control methods
ex:StaffCredentialsTraining rdf:type dpv:OrganistionalMeasure ;
skos:broader dpv:StaffTraining ;
dpv:hasTechnicalMeasure ex:RBACCredential .
This example first specifies a privacy notice as a document is being used in the context of a service as represented using a personal data handling instance. Then it provides an alternative representation where the contents of a notice are described using DPV.
Relevant Concepts: dpv:Collect, dpv:PersonalDataHandling, dpv:PrivacyNotice, dpv:ServiceProvision
source: https://w3id.org/dpv/examples/E0018.ttl
# Associating a Notice with DPV metadata
ex:Service rdf:type dpv:PersonalDataHandling ;
dpv:hasNotice ex:AcmePrivacyPolicy .
ex:AcmePrivayPolicy rdf:type dpv:PrivacyNotice ;
dct:title "Acme's Privacy Policy"@en ;
foaf:page "https://example.com/"^^xsd:anyURI .
# Describing a Notice using DPV metadata
ex:AcmePrivacyPolicy rdf:type dpv:PrivacyNotice ;
# Approach 1: delegate contents to a PDH instance
dpv:hasPersonalDataHandling ex:Service ;
# Approach 2: declare specifics directly
dpv:hasPurpose dpv:ServiceProvision ;
dpv:hasPersonalData dpv-pd:Email ;
dpv:hasProcessing dpv:Collect ;
# Specifying location of notice
# In this case, as a website, or could be a domain
dpv:hasLocation "https://example.com"^^xsd:anyURI .
This example shows a consent record containing the topic of consent (i.e. which processing activities it was about), its current status, and when it was given by the data subject. The structure of a record is highly dependant on the requirements of the use-case, and can vary across implementations. In this case, it is based on a draft of the ISO/IEC AWI TS 27560 Privacy technologies - Consent record information structure.
Relevant Concepts: dpv:Consent, dpv:ConsentRecord, dpv:ConsentStatus, dpv:ConsentType, dpv:DataController, dpv:Duration, dpv:Jurisdiction, dpv:PersonalDataHandling, dpv:Recipient
source: https://w3id.org/dpv/examples/E0019.ttl
:63ded36f-4acd-4f3c-991e-6cb636698523 a dpv:ConsentRecord ;
dct:hasVersion "27560-WD5" ;
dpv:hasIdentifier "63ded36f-4acd-4f3c-991e-6cb636698523" ;
dpv:hasDataSubject "96121fde-199f-4848-8942-4436e270513a" ;
dpv:hasNotice <https://example.com/notice/WD5> ;
dpv:hasPersonalDataHandling [
a dpv:PersonalDataHandling ;
dct:title "Send Newsletters with Seasonal Offers"@en ;
dpv:hasPurpose dpv:Marketing ;
dpv:hasLegalBasis dpv:Consent ;
dpv:hasPersonalData dpv-pd:Email ;
dpv:hasDataController ex:Acme ;
dpv:hasProcessing dpv:Collect, dpv:Store ;
dpv:hasStorageCondition [
dpv:hasLocation dpv-legal:IE ;
dpv:hasDuration 63115200 ;
] ;
dpv:hasJurisdiction dpv-legal:EU ;
dpv:hasRecipient ex:Beta, ex:Epsilon ;
] ;
dpv:hasConsentStatus dpv:ConsentGiven ;
dct:hasPart [
a dpv:ConsentGiven, dpv:ExplicitlyExpressedConsent ;
dpv:isIndicatedAtTime "2021-05-28T12:24:00"^^xsd:dateTime ;
dpv:hasDuration 63115200 ;
dpv:hasEntity "96121fde-199f-4848-8942-4436e270513a"
] .
Acme is the Data Controller, that contracts BetaInc as a Data Processor to analyse raw call logs and provide statistical patterns.
Relevant Concepts: dpv:Controller, dpv:ControllerProcessorAgreement, dpv:DataSource, dpv:PersonalDataHandling, dpv:Processor, dpv:Transfer
source: https://w3id.org/dpv/examples/E0020.ttl
ex:Acme rdf:type dpv:DataController .
ex:BetaInc rdf:type dpv:DataProcessor .
ex:AcmeBetaContract rdf:type dpv:ControllerProcessorAgreement ;
dpv:hasDataController ex:Acme ;
dpv:hasDataProcessor ex:Beta ;
# part1: acme sends data to beta
dpv:hasPersonalDataHandling ex:AcmeProvision ;
# part2: beta sends data to acme
dpv:hasPersonalDataHandling ex:BetaProvision .
ex:AcmeProvision rdf:type dpv:PersonalDataHandling ;
skos:note "Acme transfers call logs to Beta"@en ;
dpv:hasPersonalData ex:CallLogs ;
dpv:hasProcessing ex:TransferCallLogs ;
dpv:hasDataController ex:Acme ;
dpv:hasDataProcessor ex:BetaInc .
ex:BetaProvision rdf:type dpv:PersonalDataHandling ;
skos:note "Beta analyses and transfers call statistics to Acme"@en ;
dpv:hasPersonalData ex:CallStatistics ;
dpv:hasProcessing ex:AnalyseCalls, dpv:TransferStatistics ;
dpv:hasDataProcessor ex:BetaInc ;
dpv:hasRecipientDataController ex:Acme ;
# alternative way to explicitly indicate who is implementing this
dpv:isImplementedByEntity ex:BetaInc .
ex:CallLogs rdf:type dpv:PersonalData ;
skos:broader dpv-pd:CallLog ;
# denoting source of data as part of agreement
dpv:hasDataSource ex:Acme .
ex:CallStatistics rdf:type dpv:DerivedData ;
skos:broader ex:CallLogs ;
dpv:hasDataSource ex:BetaInc .
ex:TransferCallLogs rdf:type dpv:Processing ;
skos:broader dpv:Transfer ;
dpv:hasPersonalData ex:CallLogs ;
# alternative 1 - based on implementation and recipient
dpv:isImplementedByEntity ex:Acme ;
dpv:hasRecipient ex:BetaInc ;
# alternative 2 - based on data exporter/importer roles
dpv:hasDataExporter ex:Acme ;
dpv:hasDataImporter ex:BetaInc .
ex:AnalyseCalls rdf:type dpv:Processing ;
skos:broader dpv:Analyse ;
# no recipients, data is analysed by BetaInc
dpv:isImplementedByEntity ex:BetaInc .
ex:TransferStatistics rdf:type dpv:Processing ;
skos:broader dpv:Transfer ;
dpv:hasPersonalData ex:CallStatistics ;
# using alternative 2 from above
dpv:hasDataExporter ex:BetaInc ;
dpv:hasDataImporter ex:Acme .
This example represents a contractual agreement between a controller and a processor indicating the use of encryption and EU commission approved Standard Contractual Clauses as specific measures to safeguard data transfers between them.
Relevant Concepts: dpv:ControllerProcessorAgreement, dpv:DataTransferSafeguard, dpv-gdpr:SCCsByCommission
source: https://w3id.org/dpv/examples/E0021.ttl
ex:TransferPolicy a dpv:ControllerProcessorAgreement,
dpv:DataTransferSafeguard ;
dpv:hasTechnicalMeasured dpv:Encryption ;
dpv:hasOrganisationalMeasure dpv-gdpr:SCCsByCommission ;
dpv:hasDataExporter ex:Acme ;
dpv:hasDataImporter ex:Beta .
The LegalBasis can be associated with any concept using the relation hasLegalBasis. Such associations are of three types: (1) where the legal basis refers to an instance, such as the consent or contract associated with a particular data subject; (2) where the legal basis refers to the category that will be used to justify processing, such as the concept consent to denote consent will be the basis for indicated processing; and lastly (3) where the legal basis is the denoted with context, such as consent of service consumers.
Relevant Concepts: dpv:Consent, dpv:LegalBasis, dpv:PersonalDataHandling
source: https://w3id.org/dpv/examples/E0022.ttl
# 1: instance of legal basis
# interpretation: consent of user #00145667 is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
dpv:hasDataController ex:Acme ;
dpv:hasDataSubject ex:ServiceConsumers ;
dpv:hasLegalBasis ex:ConsentUserN00145667 .
ex:ConsentUserN00145667 rdf:type dpv:Consent ;
dpv:hasDataSubject ex:UserN00145667 .
# 2: category of legal basis
# interpretation: consent is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
dpv:hasDataController ex:Acme ;
dpv:hasDataSubject ex:ServiceConsumers ;
dpv:hasLegalBasis dpv:Consent .
# 3: category of legal basis with contextual information
# interpretation: consent of service consumers is the legal basis
ex:PDH1 rdf:type dpv:PersonalDataHandling ;
dpv:hasDataController ex:Acme ;
dpv:hasDataSubject ex:ServiceConsumers ;
dpv:hasLegalBasis ex:UserConsent .
ex:UserConsent rdf:type dpv:LegalBasis ;
skos:broader dpv:Consent ;
dpv:hasDataSubject ex:ServiceConsumers .
Here, a personal data handling instance represents some context (e.g. a service, or a product, or some opreation), and the example specifies that the legal basis for these is the use of consent.
Relevant Concepts: dpv:Consent, dpv:LegalBasis
source: https://w3id.org/dpv/examples/E0023.ttl
ex:PDH rdf:type dpv:PersonalDataHandling ;
dpv:hasDataController ex:Acme ;
dpv:hasDataSubject ex:ServiceConsumers ;
dpv:hasPersonalData dpv:Email ;
dpv:hasLegalBasis dpv:Consent .
In this example, an individual's consent is recorded with abstraction in the form of linking to a common personal data handling instance from the previous example. This 'common' personal data handling represents processing taking place for all data subjects, whereas the consent instance refers only to the individual with a link to this common information. This is to present an alternative method for storing information as compared to extensive consent records.
Relevant Concepts: dpv:Consent, dpv:ConsentStatus, dpv:ConsentType
source: https://w3id.org/dpv/examples/E0024.ttl
ex:UserConsent rdf:type dpv:Consent ;
dpv:hasConsentStatus dpv:ConsentGiven ;
dpv:hasDataSubject ex:User12345 ;
dpv:isIndicatedAtTime "2022-09-06T15:36:07"^^xsd:dateTime .
Representing notice, provision, expiry, and withdrawal information for consent
Relevant Concepts: dpv:Consent, dpv:ConsentStatus, dpv:ConsentType, dpv:Notice, dpv:PrivacyNotice
source: https://w3id.org/dpv/examples/E0025.ttl
# Approach 1: specify notice for an instance of consent
ex:UserConsent rdf:type dpv:Consent ;
dpv:hasDataSubject ex:User12345 ;
# notice can be references in different forms, e.g. URL, string
dpv:hasNotice ex:AcmeConsentNotice ; # RDF
dpv:hasNotice "https://example.com/AcmeConsentNotice" ; # URL
dpv:hasNotice "Notice-v3.456" . # identifier
# Approach 2: specify notice for a group of activities
ex:PDH rdf:type dpv:PersonalDataHandling ;
dpv:hasPurpose ... ;
dpv:hasProcessing ... ;
dpv:hasPersonalData ... ;
dpv:hasLegalBasis dpv:Consent ;
dpv:hasNotice ex:AcmeConsentNotice .
ex:UserConsent rdf:type dpv:Consent ;
dpv:hasDataSubject ex:User12345 ;
# notice is part of PDH, not declared for each consent instance
dpv:hasPersonalDataHandling ex:PDH .
Expressing consent type is required as legal basis and as instances
Relevant Concepts: dpv:Consent, dpv:ConsentStatus, dpv:ConsentType
source: https://w3id.org/dpv/examples/E0026.ttl
# Approach 1: specifying a specific consent type is required as legal basis
ex:PDH a dpv:PersonalDataHandling ;
dpv:hasLegalBasis dpv:ExplicitlyExpressedConsent .
# Approach 2: creating instances of consent
ex:UserConsent a dpv:ExpressedConsent .
Indicating Entity Information, including DPO and Representatives
Relevant Concepts: dpv:Entity
source: https://w3id.org/dpv/examples/E0027.ttl
ex:Acme rdf:type dpv:LegalEntity ;
dpv:hasName "Acme"@en ;
dpv:hasAddress "Dublin, Ireland"@en ;
dpv:hasContact "[email protected]" ;
dpv:hasRepresentative ex:AcmeDPO, # internal DPO
ex:AcmeEUOrg ; # EU Representative
dpv:hasLocation iso:IE, # if an ISO vocabulary for country-codes is used
dpv-juris:Ireland, # dpv-juris proposed vocabulary
"Ireland"@en . # plain strings
ex:AcmeDPO rdf:type dpv:Representative ;
dpv:hasEntity ex:Acme .
ex:AcmeEUOrg rdf:type dpv:LegalEntity, dpv:DataProtectionOfficer ;
dpv:hasEntity ex:Acme ;
dpv:hasLocation "EU"@en .
In this example, a PersonalDataHandling instance is comprised of two nested PersonalDataHandling instances for each of the optional and required parts. The personal data category 'Account Identifier' is indicated as being required for 'Communication for Customer Care', while the use of 'Email' is optional for the same purpose.
Relevant Concepts: dpv:Context, dpv:Necessity, dpv:PersonalDataHandling
source: https://w3id.org/dpv/examples/E0028.ttl
:PDH1 a dpv:PersonalDataHandling ;
# optionally also declare data and purpose for PDH1
dpv:hasPersonalData dpv:Email, dpv:AccountIdentifier ;
dpv:hasPurpose dpv:CommunicationForCustomerCare ;
dpv:hasPersonalDataHandling :PDH2, :PDH3 .
:PDH2 a dpv:PersonalDataHandling ;
dpv:hasContext dpv:Optional ;
dpv:hasPersonalData :Email ;
dpv:hasPurpose dpv:CommunicationForCustomerCare .
:PDH3 a dpv:PersonalDataHandling ;
dpv:hasContext dpv:Required ;
dpv:hasPersonalData dpv:AccountIdentifier ;
dpv:hasPurpose dpv:CommunicationForCustomerCare .
In this example, we consider Risk can be associated with any concept given its broad existence and applicability, and that its mitigation is a technical and organisational measure. Using this, the implemented or adopted technical and organisational measures within an use-case are annotated with the risks they address or mitigate, along with specific impacts that may occur if the risk were to occur. For example, the storage of personal data within a database has an implementation of access control that mitigates the consequence of unauthorised access and its impact to cause harm.
Relevant Concepts: dpv:Consequence, dpv:Harm, dpv:Impact, dpv:Riskl, dpv:RiskMitigationMeasure
source: https://w3id.org/dpv/examples/E0029.ttl
# 1: annotating implementations with risks involved
ex:DataStore rdf:type dpv:Technology ;
dpv:hasTechnicalMeasure ex:RBACCredential ;
dpv:hasRisk ex:UnAuthorisedAccess .
# 2: risk registry denoting risks and mitigations
ex:UnAuthorisedAccess rdf:type dpv:Risk ;
dpv:hasConsequence "Unauthorised Access to Data Store"@en ;
dpv:hasImpact dpv:Harm ;
dpv:isMitigatedByMeasure ex:RBACCredential .
# 3: annotating measures with risks mitigated
ex:RBACCredential rdf:type dpv:TechnicalMeasure, dpv:RiskMitigationMeasure ;
skos:broader dpv:AccessControlMethod ;
dpv:mitigatesRisk ex:UnAuthorisedAccess .
# 4: policies and training as risk mitigations
ex:SecurityPolicy rdf:type dpv:OrganisationalMeasure ;
skos:broader dpv:Policy ;
dpv:hasOrganisationalMeasure dpv:StaffTraining ;
dpv:mitigatesRisk ex:UnAuthorisedAccess .