This document lists the examples for concepts in DPV and aligned vocabularies. The examples are available in DPVCG GitHub repo under ./examples path.
Contributing: The DPVCG welcomes participation to improve the DPV and associated resources, including expansion or refinement of concepts, requesting information and applications, and addressing open issues. See contributing guide for further information.
DPV and Related Resources
[[[DPV]]]: is the base/core specification for the 'Data Privacy Vocabulary', which is extended for Personal Data [[PD]], Locations [[LOC]], Risk Management [[RISK]], Technology [[TECH]], and [[AI]]. Specific [[LEGAL]] extensions are also provided which model jurisdiction specific regulations and concepts - see the complete list of extensions . To support understanding and applications of [[DPV]], various guides and resources [[GUIDES]] are provided, including a [[PRIMER]]. A Search Index of all concepts from DPV and extensions is available.
[[DPV]] and related resources are published on GitHub . For a general overview of the Data Protection Vocabularies and Controls Community Group [[DPVCG]], its history, deliverables, and activities - refer to DPVCG Website DPVCG calendar .
The peer-reviewed article “Creating A Vocabulary for Data Privacy here here here Data Privacy Vocabulary (DPV) - Version 2 , accepted for presentation at the 23rd International Semantic Web Conference (ISWC 2024), describes the changes made in DPV v2.
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#>
Vocabulary
Example
IRI https://w3id.org/dpv/use-cases/vocab#skos:definitionAn 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).
An Example MUST have a title (provided using dct:title)
An Example MUST have a description (provided using dct:description)
An Example MUST have an identifier with prefix 'U' (provided using dct:identifier)
An Example MAY have one or more contributors (specified using dct:contributor)
An Example MAY have a date (e.g. creation or modification) (specified using dct:date)
An Example MAY specify the source of its information (using dct:source)
An Example MAY specify its primary subject or concept (using dct:subject)
An Example MAY specify relevant requirements derived from it (using dct:references)
Examples
E0001 :
This example highlights the implications of using DPV with RDFS+SKOS and OWL semantics. The RDFS+SKOS model is suitable for when DPV concepts have to be used 'directly' e.g. an use-case wants to use 'Encryption' from DPV as a technical measure without creating a specific 'instance' representing their implementation of the encryption. RDFS+SKOS model is also suitable for when an use-case wants to further create an hierarchical taxonomy of the different 'Encryption' concepts they are using. Such use of DPV concepts covers both T-box and A-box, and does not restrict or require the underlying ontology/schema to be constantly changed as new concepts are identified in an use-case.
In comparison, the OWL2 model defines concepts as classes and instances with a clear separation between the two i.e. the Tbox and Abox are separate. This means the concept 'Encryption' cannot be directly used with OWL2 semantics and an instance of it must first be created. If instead DPV had provided 'Encryption' as an instance (of Technical Measure) then the further expansion and creation of a hierarchy of encryption concepts described earlier is not feasible in OWL2 as it results in a complex graph which is not efficient for reasoning. Further, making changes such as promoting 'Encryption' from instance to class requires changing the ontology/schema - which may not always be possible or feasible in use-cases.
Thus, the relative strengths and weaknesses of RDFS+SKOS and OWL2 serialisations dictate which should be used. RDFS+SKOS is 'lightweight' and better if the use-case only requires rudimentary or simple reasoning. OWL2 is better suited for semantic reasoners that can perform complex discovery and validation processes but require more strict and restricted use of concepts. By providing both serialisations, DPV enables the adopters to choose the most suitable serialisation that supports their use-case and/or existing implementations, and retains semantic interoperability based on converting between SKOS and OWL2 (see Using OWL and SKOS (2008) ).
# Example: A Company is running 'Direct Marketing' campaigns for
# a purpose (CampaignA), within which it runs another special
# campaign (CampaignB). This may envolve into another campaign C.
# RDFS+SKOS modelling
dpv :Marketing a rdfs :Class , dpv :Purpose .
dpv :DirectMarketing a dpv :Purpose ; skos :broader dpv :Marketing .
ex :CampaignA a dpv :Purpose ; skos :broader dpv :DirectMarketing .
ex :CampaignB a dpv :Purpose ; skos :broader ex :CampaignA .
# valid statements as all objects are instances of dpv:Purpose
ex :Documentation a dpv :Process ; dpv :hasPurpose dpv :DirectMarketing .
# OWL2 modelling
dpv :Marketing a owl :Class ; rdfs :subClassOf dpv :Purpose .
dpv :DirectMarketing a owl :Class ; rdfs :subClassOf dpv :Marketing .
ex :CampaignA a dpv :DirectMarketing .
# problem: instance of instance
ex :CampaignB a ex :CampaignA .
# solution: change CampaignA to subclass
ex :CampaignA rdfs :subClassOf dpv :DirectMarketing .
# problem: DirectMarketing is not an instance of dpv:Purpose
ex :Documentation a dpv :Process ; dpv :hasPurpose dpv :DirectMarketing .
# solution: blank nodes, but not a good solution
ex :Documentation a dpv :Process ; dpv :hasPurpose [ a dpv :DirectMarketing ] .
# solution: use the instances rather than the class
ex :Documentation a dpv :Process ; dpv :hasPurpose ex :CampaignA .
# problem: does not reflect the terminology used by Company/Law
(META
Example ID: E0001source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0002 :
DPV defines the (broad) concept of MarketingPurpose 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.
Note: Here the prefix ex: represents http://example.com# - which is a convention for representing additional examples or concepts, such as those created as part of the use-case. The rest of the document follows this nomenclature and convention.
# Example using DPV (RDFS+SKOS)
# 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 ;
skos :prefLabel "Marketing of New Products" .
# more specific purposes under group ‘Marketing of New Products’
ex :NewslettersOffers a dpv :Purpose ;
skos :broader ex :MarketingOfNewProducts ;
skos :prefLabel "Newsletters about Offers" .
ex :EmailsSeasonalOffers a dpv :Purpose ;
skos :broader ex :MarketingOfNewProducts ;
skos :prefLabel "Emails about Seasonal Offers" .
# Case2: A single final and definite purpose within EmailSeasonalOffers
ex :MarketingSeasonalOffer2021 a dpv :Purpose ;
skos :broader dpv :Marketing ;
skos :prefLabel "Sending Email Newsletters with Seasonal Offers" .
# Example using DPV-OWL (OWL2)
# 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 ;
skos :prefLabel "Marketing of New Products" .
# more specific categories of group ‘Marketing of New Products’
ex :NewslettersOffers rdfs :subClassOf ex :MarketingOfNewProducts ;
skos :prefLabel "Newsletters about Offers" .
ex :EmailsSeasonalOffers rdfs :subClassOf ex :MarketingOfNewProducts ;
skos :prefLabel "Emails about Seasonal Offers" .
# Case2: A single final and definite purpose within EmailSeasonalOffers
ex :MarketingSeasonalOffer rdf :type dpv :Marketing ;
skos :prefLabel "Sending Email Newsletters with Seasonal Offers" .
(META
Example ID: E0002source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0003 :
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.
# Example in DPV (RDFS+SKOS)
# Method 1: Ambiguous regarding independence of Collect and Use
ex :ActivityA a dpv :Process ;
dpv :hasProcessing ex :Collect , ex :Use .
# Method 2: Accuracy regarding combination of Collect and Use
ex :CollectAndUse a dpv :Processing
# rdfs:subClassOf dpv:Collect, dpv:Use ; # -- RDFS+SKOS permits this
skos :broader ex :Collect , ex :Use ;
skos :prefLabel "Collect and Use data using User Device" .
ex :Activity a dpv :Process ;
dpv :hasProcessing ex :CollectAndUse . # -- property range is correct
# Example in DPV-OWL
ex :CollectAndUse rdfs :subClassOf dpv :Collect , dpv :Use ;
skos :prefLabel "Collect and Use data using User Device" .
ex :Activity a dpv :Process ;
# dpv:hasProcessing ex:CollectAndUse # -- property range is incorrect
dpv :hasProcessing ex :CU1 . # hence, an instance is needed for OWL2
ex :CU1 a ex :CollectAndUse .
(META
Example ID: E0003source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0004 :
For example, two TV companies (AliceCo and BobCo) extend the concept Optimisation to reflect their respective purposes as follows:
# Example in DPV (RDFS+SKOS)
# AliceCo’s optimisation related to better services for users’ infrastructure
exA :TVServiceOptimisaion a dpv :Purpose ;
skos :broader dpv :OptimisationForConsumer ;
skos :prefLabel "Optimise Service for Users’ Infrastructure" .
# BobCo’s optimisation related to more efficient signals for users’ TV sets
exB :TVSignalOptimisation a dpv :Purpose ;
skos :broader dpv :OptimisationForConsumer ;
skos :prefLabel "Optimise Signal for Consumer TV Set" .
# Example in DPV-OWL
# the common ancestor is: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 .<F25>
(META
Example ID: E0004source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0005 :
An example of how Process brings together the core concepts, consider the example where Acme is a DataController that Collect(s) and Use(s) Email for ServiceProvision. Note that the pd:EmailAddress is a concept from the [[[PD]]] extension.
ex :Acme rdf :type dpv :DataController .
ex :AcmeMarketing rdf :type dpv :Process ;
dpv :hasDataController ex :Acme ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Collect , dpv :Use ;
dpv :hasPurpose dpv :ServiceProvision ;
(META
Example ID: E0005source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0006 :
Consider the example where Acme , as a DataController , maintains records of its processing activities using Process to represent one of its services. In this, it collects email, uses it for internal analyses based on Legitimate Interests , and also sends marketing information by using a processor based on the data subject's consent. Using nesting of processes, the information can be expressed at a granular level representing service, individual purposes, and so on.
ex :Acme rdf :type dpv :DataController .
ex :AcmeMarketing rdf :type dpv :Process ;
dpv :hasProcess ex :InternalAnalytics ;
dpv :hasProcess ex :SendingNewsletters .
ex :InternalAnalytics rdf :type dpv :Process ;
dpv :hasPersonalData pd :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 :Process ;
dpv :hasPersonalData pd :Email ;
dpv :hasProcessing dpv :Share ;
dpv :hasPurpose dpv :Marketing ;
dpv :hasDataProcessor ex :FooTech ;
dpv :hasLegalBasis dpv :Consent .
(META
Example ID: E0006source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0007 :
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.
ex :PreventTransactionFraud a dpv :Purpose ;
skos :broader dpv :FraudPreventionAndDetection ;
skos :prefLabel "Prevent Transaction and Payment Frauds" .
(META
Example ID: E0007source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0008 :
For example, the following purpose concerns implementing access control with the domain specified as scientific research using its corresponding NACE code <code>M72</code> to indicate sectorial implications for what "access control" and "enforce security" are expected to imply.
RestrictPersonnelAccess a dpv :Purpose ;
skos :broader dpv :EnforceSecurity ;
skos :prefLabel "Limit access to lab by checking personnel identity" ;
dpv :hasSector nace :M72 .
(META
Example ID: E0008source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0009 :
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 [[PD]] for personal data concepts.
ex :PersonaliseWebsiteForVisitors rdf :type dpv :Process ;
dpv :hasPurpose dpv :Personalisation ;
dpv :hasPersonalData pd :BrowserFingerprint ,
pd :IPAddress ;
dpv :hasProcessing dpv :Collect , dpv :Use ;
dpv :hasProcess ex :DeriveVisitorCountry ;
dpv :hasProcess ex :InferVisitorLanguage .
ex :DeriveVisitorCountry rdf :type dpv :Process ;
dpv :hasProcessing dpv :Derive ;
dpv :hasPersonalData ex :VisitorCountry .
ex :VisitorCountry rdf :type dpv :DerivedPersonalData ;
skos :broader pd :Country .
ex :InferVisitorLanguage rdf :type dpv :Process ;
dpv :hasProcessing dpv :Infer ;
dpv :hasPersonalData ex :VisitorLanguage .
ex :VisitorLanguage rdf :type dpv :InferredPersonalData ;
skos :broader pd :Language .
(META
Example ID: E0009source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0010 :
In a medical study involving genetic data, the person's collected blood samples are considered to be 'special category' personal data under the GDPR. In addition to this, the person's identifier associated with that dataset to enable monitoring future appointments is considered sensitive within the medical centre. Note that the examples use the [[PD]] extension to represent some concepts.
In this example, the knowledge that blood samples are of type 'special category' can be inferred from the fact that they are a form of Medical Health which is a 'special category'. However, the example considers best practices that suggest explicitly identifying and denoting that blood samples are also of type 'special category'.
ex :PatientStudy rdf :type dpv :Process ;
dpv :hasPersonalData ex :BloodSamples , ex :PatientIdentifier .
ex :BloodSamples rdf :type dpv :SpecialCategoryPersonalData ;
skos :broader pd :MedicalHealth ;
skos :narrower pd :BloodType .
ex :PatientIdentifier rdf :type dpv :SensitivePersonalData ;
skos :broader pd :Identifying .
(META
Example ID: E0010source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0011 :
This example includes Acme as a Data Processor that stores data within servers located in Ireland for a period of one year. The temporal information is represented using [[[TIME]]], and the location is specified using [[[LOC]]].
In this example, the StorageCondition is expressed as a separate policy applicable. It is also possible to directly express it over other concepts such as a service, technology, or a processing operation, e.g. to say ex:AcmeStore dpv:hasStorageCondition ....
ex :ServerInfo a dpv :Process ;
dpv :hasDataProcessor ex :Acme ;
dpv :hasProcessing dpv :Store ;
dpv :hasStorageCondition ex :DataStoragePolicy .
ex :DataStoragePolicy a dpv :StorageCondition ;
dpv :hasLocation loc :IE ;
dpv :hasDuration [
rdf :type time :Duration , dpv :Duration ;
time :numericDuration "1" ^^xsd :decimal ;
time :unitType time :unitYear ;
] .
(META
Example ID: E0011source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0012 :
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.
In this example, ex:S01 represents direct collection of data from the data subject, while ex:S02 represents indirect collection where data is derived or observed - or undergoes any operation that still points to the data subject as the source. ex:S03 infers data, which means the inferring entity (the Controller in this case) is the source of this data - even if the inferred data is based on data collected from the Data Subject. ex:S04 has data sourced from another entity - such as a Third Party, but could also refer to a Data Processor. ex:S05 represents collection of data from a public dataset that has been published by the data subject themselves.
Note that the above example is illustrative - it may be pertinent to provide documentation about each data source to ensure sufficient information is recorded for intended purposes. For example, the method of collection (e.g. forms), or inference (e.g. algorithm), or public dataset (e.g. link, license).
ex :S01 dpv :hasDataSource dpv :DataSubject .
ex :S01 dpv :hasProcessing dpv :Collect .
ex :S02 dpv :hasDataSource dpv :DataSubject .
ex :S02 dpv :hasProcessing dpv :Derive , dpv :Observe .
ex :S03 dpv :hasDataSource dpv :DataController .
ex :S03 dpv :hasProcessing dpv :Infer .
ex :S04 dpv :hasDataSource ex :Acme .
ex :Acme a dpv :ThirdParty .
ex :S05 dpv :hasDataSource dpv :DataPublishedByDataSubject .
ex :S05 dpv :hasProcessing dpv :Collect .
(META
Example ID: E0012source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0013 :
Consider the use of a spam filter that is based on automated processing operations where humans provide inputs, have oversight of the operation, and results in automated decision making for whether communications should be propagated. A new separate filter is developed that utilises a novel spam detection criteria that also takes into account communications other than emails for the sender and makes automated decisions whether to permit communication to proceed. Such explicit annotation of several high-risk operations assists in performing impact assessments for this technology, as well as understanding the extent and effectiveness of human involvement to mitigate risks and issues.
In this example, the Spam Filter process allows the users to reverse the effects (i.e. emails marked as spam) but does not allow opting out from the process (i.e. stop spam filtering). The spam detection algorithm performs automated decision making (by deciding which emails to accept), systemic monitoring (of communications), and evaluation and scoring (by scoring contents of emails and senders/recipients). The spam detection algorithm also indicates what human involvement is expected - to provide input (e.g. mark emails as spam) and intervention (e.g. change spam criterias).
ex :SpamFilter rdf :type dpv :Process ;
dpv :hasProcessing dpv :Analyse ;
dpv :hasAutomationLevel dpv :FullAutomation ;
dpv :hasEntityInvolvement [
a dpv :EntityInvolvement ;
dpv :isImplementedByEntity dpv :User ;
dpv :ReversingProcessEffects ,
dpv :CannotOptOutFromProcess ;
] ;
dpv :hasAlgorithmicLogic ex :SpamDetection .
ex :SpamDetection rdf :type dpv :AlgorithmicLogic ;
skos :broader dpv :InnovativeUseOfNewTechnologies ;
dpv :hasProcessingContext dpv :AutomatedDecisionMaking ,
dpv :SystemicMonitoring ,
dpv :EvaluationScoring ;
dpv :hasHumanInvolvement dpv :HumanInvolvementForInput ,
dpv :HumanInvolvementForIntervention ;
dpv :hasPersonalData pd :Communication ;
dpv :hasDataSource ex :EmailSender .
(META
Example ID: E0013source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0014 :
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 defined with a context, such as consent of service consumers .
# 1: instance of legal basis
# interpretation: consent of user #00145667 is the legal basis
ex :PDH1 rdf :type dpv :Process ;
dpv :hasDataController ex :Acme ;
dpv :hasDataSubject ex :ServiceConsumers ;
dpv :hasLegalBasis ex :ConsentUserN00145667 .
ex :ConsentUserN00145667 rdf :type dpv :LegalBasis , dpv :Consent ;
dpv :hasDataSubject ex :UserN00145667 .
# 2: category of legal basis
# interpretation: consent is the legal basis
ex :PDH1 rdf :type dpv :Process ;
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 :Process ;
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 .
(META
Example ID: E0014source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0015 :
Here, a process instance represents some context (e.g. a service, or a product, or some operation), and the example specifies that the legal basis for these is the use of consent.
ex :PDH rdf :type dpv :Process ;
dpv :hasDataController ex :Acme ;
dpv :hasDataSubject ex :ServiceConsumers ;
dpv :hasPersonalData dpv :Email ;
dpv :hasLegalBasis dpv :Consent .
(META
Example ID: E0015source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0016 :
In this example, an individual's consent is recorded with abstraction in the form of linking to a common process instance from the previous example. This 'common' process 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.
ex :UserConsent rdf :type dpv :Consent ;
dpv :hasConsentStatus dpv :ConsentGiven ;
dpv :hasDataSubject ex :User12345 ;
dpv :isIndicatedAtTime "2022-09-06T15:36:07" ^^xsd :dateTime .
(META
Example ID: E0016source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0017 :
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.
# 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 :Process ;
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 :hasProcess ex :PDH .
(META
Example ID: E0017source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0018 :
This example shows use of DPV consent types to distinguish between 'expressed' and 'explicitly expressed' consent
# Approach 1: specifying a specific consent type is required as legal basis
ex :PDH a dpv :Process ;
dpv :hasLegalBasis dpv :ExplicitlyExpressedConsent .
# Approach 2: creating instances of consent
ex :UserConsent a dpv :ExpressedConsent .
(META
Example ID: E0018source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0019 :
This example shows how information about representatives can be associated with an entity
ex :Acme rdf :type dpv :LegalEntity ;
dpv :hasName "Acme" @ en ;
dpv :hasAddress "Dublin, Ireland" @ en ;
dpv :hasContact "acme@example.com" ;
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 .
(META
Example ID: E0019source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0020 :
To indicate data is encrypted using the Rivest-Shamir-Adleman (RSA) method , one would extend the EncryptionRSA, 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.
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 .
(META
Example ID: E0020source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0021 :
To indicate staff are trained in the use of credentials, and that a policy exists regarding this, the use of OrganisationalMeasure concepts can be combined in several ways. Note that the interpretations for how staff training is associated with credentials, or contains training regarding credentials is arbitrary in notation. It is intended to demonstrate how different perspectives can be represented so as to be suitable to the organisation's documentation practices.
# 1: directly associating staff training with credentials used
ex :StaffCredentialsTraining rdf :type dpv :OrganistionalMeasure ;
skos :broader dpv :StaffTraining .
ex :RBACCredential dpv :hasOrganisationalMeasure ex :StaffCredentialTraining .
# 2: security policy containing staff training and access control
ex :SecurityPolicy rdf :type dpv :OrganisationalMeasure ;
skos :broader dpv :Policy ;
dpv :hasOrganisationalMeasure dpv :StaffTraining ;
dpv :hasTechnicalMeasure dpv :AccessControlMethod .
# 3: indicating staff training contains access control methods
ex :StaffCredentialsTraining rdf :type dpv :OrganistionalMeasure ;
skos :broader dpv :StaffTraining ;
dpv :hasTechnicalMeasure ex :RBACCredential .
(META
Example ID: E0021source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0022 :
This example first specifies a privacy notice as a document is being used in the context of a service as represented using a process instance. Then it provides an alternative representation where the contents of a notice are described using DPV.
# Associating a Notice with DPV metadata
ex :Service rdf :type dpv :Process ;
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 :hasProcess ex :Service ;
# Approach 2: declare specifics directly
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasPersonalData 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 .
(META
Example ID: E0022source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0023 :
This (simplified) example shows a consent record containing the topic of consent (i.e. which processing activities it was about), its current status, and when it was given by the data subject. The structure of a record is highly dependent on the requirements of the use-case, and can vary across implementations. In this case, it is based on the ISO/IEC TS 27560:2023 Privacy technologies — Consent record information structure, for which we provide the implementation guide [[[GUIDE-Consent-27560]]].
The example uses the DCMI Metadata Terms (dct) vocabulary to indicate metadata such as title and timestamps. Other vocabularies such as PROV-O can be used to also indicate provenance information such as when it was generated and how it was produced.
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 :hasProcess [
a dpv :Process ;
dct :title "Send Newsletters with Seasonal Offers" @ en ;
dpv :hasPurpose dpv :Marketing ;
dpv :hasLegalBasis dpv :Consent ;
dpv :hasPersonalData pd :Email ;
dpv :hasDataController ex :Acme ;
dpv :hasProcessing dpv :Collect , dpv :Store ;
dpv :hasStorageCondition [
dpv :hasLocation loc :IE ;
dpv :hasDuration 63115200 ;
] ;
dpv :hasJurisdiction loc :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"
] .
(META
Example ID: E0023source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0024 :
Acme is the Data Controller that contracts BetaInc as a Data Processor to analyse raw call logs and provide statistical patterns.
ex :Acme rdf :type dpv :DataController .
ex :BetaInc rdf :type dpv :DataProcessor .
ex :AcmeBetaContract rdf :type dpv :ControllerProcessorAgreement ;
dpv :hasDataController ex :Acme ;
dpv :hasDataProcessor ex :Beta ;
# part1: acme sends data to beta
dpv :hasProcess ex :AcmeProvision ;
# part2: beta sends data to acme
dpv :hasProcess ex :BetaProvision .
ex :AcmeProvision rdf :type dpv :Process ;
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 :Process ;
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 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 .
(META
Example ID: E0024source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0025 :
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.
ex :TransferPolicy a dpv :ControllerProcessorAgreement ,
dpv :DataTransferSafeguard ;
dpv :hasTechnicalMeasure dpv :Encryption ;
dpv :hasOrganisationalMeasure dpv-gdpr :SCCsByCommission ;
dpv :hasDataExporter ex :Acme ;
dpv :hasDataImporter ex :Beta .
(META
Example ID: E0025source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0026 :
In this example, a Process instance consists of two nested Process 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.
PDH1 a dpv :Process ;
# optionally also declare data and purpose for PDH1
dpv :hasPersonalData pd :Email , pd :AccountIdentifier ;
dpv :hasPurpose dpv :CommunicationForCustomerCare ;
dpv :hasProcess :PDH2 , :PDH3 .
:PDH2 a dpv :Process ;
dpv :hasContext dpv :Optional ;
dpv :hasPersonalData pd :Email ;
dpv :hasPurpose dpv :CommunicationForCustomerCare .
:PDH3 a dpv :Process ;
dpv :hasContext dpv :Required ;
dpv :hasPersonalData pd :AccountIdentifier ;
dpv :hasPurpose dpv :CommunicationForCustomerCare .
(META
Example ID: E0026source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0027 :
In this example, we consider Risk can be associated with any concept given its broad existence and applicability, and that its mitigation is a technical and organisational measure. Using this, the implemented or adopted technical and organisational measures within an use-case are annotated with the risks they address or mitigate, along with specific impacts that may occur if the risk were to occur. For example, the storage of personal data within a database has an implementation of access control that mitigates the consequence of unauthorised access and its impact to cause harm.
# 1: annotating implementations with risks involved
ex :DataStore rdf :type dpv :Technology ;
dpv :hasTechnicalMeasure ex :RBACCredential ;
dpv :hasRisk ex :UnAuthorisedAccess .
# 2: risk registry denoting risks and mitigations
ex :UnAuthorisedAccess rdf :type dpv :Risk ;
dpv :hasConsequence "Unauthorised Access to Data Store" @ en ;
dpv :hasImpact dpv :Harm ;
dpv :isMitigatedByMeasure ex :RBACCredential .
# 3: annotating measures with risks mitigated
ex :RBACCredential rdf :type dpv :TechnicalMeasure , dpv :RiskMitigationMeasure ;
skos :broader dpv :AccessControlMethod ;
dpv :mitigatesRisk ex :UnAuthorisedAccess .
# 4: policies and training as risk mitigations
ex :SecurityPolicy rdf :type dpv :OrganisationalMeasure ;
skos :broader dpv :Policy ;
dpv :hasOrganisationalMeasure dpv :StaffTraining ;
dpv :mitigatesRisk ex :UnAuthorisedAccess .
(META
Example ID: E0027source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0028 :
In this example, a Process which consists of using an email address for service provision using the legal basis as Consent is permitted
ex :PDH a dpv :Process ;
dpv :hasRule dpv :Permission ;
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasLegalBasis dpv :Consent .
(META
Example ID: E0028source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0029 :
In this example, the hasProhibition relation is directly used to assert a prohibition to handle Health data within a Process:
ex :PDH a dpv :Process ;
dpv :hasProhibition pd :Health .
(META
Example ID: E0029source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0030 :
In this example, DPV is complemented with ODRL, following the ODRL implementation best practices, to assert an obligation to Anonymise data in order to use it:
ex :Policy a dpv :Obligation , odrl :Policy ;
odrl :profile new-profile : ;
odrl :uid <https://example.com/policy:1> ;
odrl :obligation [
odrl :action new-profile :Use ;
odrl :duty [
odrl :action new-profile :Anonymise
]
] .
(META
Example ID: E0030source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0031 :
This example shows the use of Service concept to represent a 'service' provided by an organisation, which includes two processes for data collection and service provision
# Service
ex :StreamingService a dpv :Service ;
dpv :hasProcess ex :SS1 , ex :SS2 ;
dpv :hasLegalBasis dpv :Contract ; # covering service
dpv :hasServiceProvider ex :CompanyA ;
dpv :hasDataController ex :CompanyA ;
dpv :hasServiceConsumer ex :Consumers .
ex :SS1 a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Collect , dpv :Store , dpv :Use ;
dpv :hasPurpose dpv :ServiceProvision , dpv :ServiceRegistration .
ex :SS2 a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Use ;
dpv :hasPurpose dpv :FraudPreventionDetection .
(META
Example ID: E0031source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0032 :
This example describes a controller with details for name, address, and contact, and its representatives for EU and US jurisdictions
ex :Alpha a dpv :Controller ;
dpv :hasName "Alpha" ;
dpv :hasAddress "Somewhere, somewhere, somewhere" ;
dpv :hasContact "email@example.com" ;
dpv :hasRepresentative ex :RepA , ex :RepB .
ex :RepA a dpv :Representative , dpv :Organisation ;
dpv :hasName "CompanyA Inc." ;
dpv :isRepresentativeFor ex :Alpha ;
dpv :hasJurisdiction loc :EU .
ex :RepB a dpv :Representative , dpv :Organisation ;
dpv :hasName "CompanyB Inc." ;
dpv :isRepresentativeFor ex :Alpha ;
dpv :hasJurisdiction loc :US .
ex :PDH a dpv :Process ;
dpv :hasDataController ex :Alpha .
(META
Example ID: E0032source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0033 :
This example shows a process with its controller and processor, and the explicit statement for the processor doing the collection and storing of personal data
ex :PDH a dpv :Process ;
dpv :hasProcessing dpv :Collect , dpv :Store ;
dpv :hasDataController ex :Alpha ;
dpv :hasDataProcessor ex :Beta ;
# explicitly specifying which entity is implementing
dpv :isImplementedByEntity ex :Beta .
(META
Example ID: E0033source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0034 :
This example first shows a process where the processor is denoted as the data recipient, and then another process where a third party is denoted as the recipient. A joint controller agreement is then shown which specifies that only one of the controllers involved is a data recipient.
ex :PDH1 a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Collect ;
dpv :hasPurpose dpv :ServiceRegistration ;
dpv :hasDataController ex :CompanyA ;
dpv :hasDataProcessor ex :CompanyB ;
# explicitly indicating entity receiving data
dpv :hasRecipient ex :CompanyB .
ex :PDH2 a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Share ;
dpv :hasPurpose dpv :FraudPreventionDetection ;
dpv :hasThirdPartyRecipient ex :CompanyC .
ex :JC a dpv :JointControllerAgreement ;
dpv :hasDataController ex :Company1 , ex :Company2 ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Share ;
dpv :hasRecipientDataController ex :Company1 .
(META
Example ID: E0034source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0035 :
This example shows how data exporters and importers for a transfer can be indicated using DPV. It also shows how the locations associated with exporters and importers are relevant to determine cross-border transfers.
ex :PDH a dpv :Process ;
dpv :hasProcessing dpv :Transfer ;
dpv :hasDataExporter dpv :CompanyA ;
dpv :hasDataImporter dpv :CompanyB .
ex :CompanyA a dpv :DataExporter ;
dpv :hasLocation loc :IE .
ex :CompanyB a dpv :DataImporter ;
dpv :hasLocation loc :US .
# cross-border IE -> US inference:
ex :PDH dpv :hasProcessing dpv :CrossBorderTransfer
# Transfers can also be specified with only recipients
# If the exporter is known in existing context
# since the importer is always a recipient
# e.g. CompanyA is the controller and the sender/exporter
ex :PDH dpv :hasRecipient dpv :CompanyB .
(META
Example ID: E0035source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0036 :
This example shows how a DPA can be associated with processing, and the use of LEGAL extensions to obtain DPA information. It also shows how DPAs can be 'discovered' by using the location (jurisdiction) and applicable law concepts.
ex :PDH a dpv :Process ;
dpv :hasAuthority legal-ie :DPA-IE .
# in LEGAL-IE extension:
legal-ie :DPA-IE a dpv :DataProtectionAuthority ;
skos :prefLabel "Data Protection Commission (DPC)" @ en ;
foaf :homepage "https://www.dataprotection.ie/" ^^xsd :anyURI ;
dpv :hasApplicableLaw legal-eu :law-GDPR ,
legal-ie :law-DPA ;
dpv :hasJurisdiction loc :IE .
# Authorities can also be 'discovered' using location or law
ex :PDH a dpv :Process ;
dpv :hasApplicableLaw legal-eu :GDPR ;
dpv :hasLocation loc :IE . # Get GDPR authority for IE
ex :PDH a dpv :Process ;
dpv :hasJurisdiction loc :IE . # Get authority for IE
(META
Example ID: E0036source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0037 :
This example involves an organisation that is a NGO, and that it has Marketing, HR, and IT departments. The HR and IT departments are responsible for specific processes.
ex :CompanyA rdf :type dpv :NonGovernmentalOrganisation ;
dpv :hasOrganisationalUnit ex :Marketing , ex :HR , ex :IT .
ex :Marketing a dpv :OrganisationalUnit ;
dpv :hasName "Marketing Department" @ en ;
dpv :isOrganisationalUnitOf ex :CompanyA .
ex :HR a dpv :OrganisationalUnit ;
dpv :hasName "HR Department" @ en ;
dpv :isOrganisationalUnitOf ex :CompanyA .
ex :IT a dpv :OrganisationalUnit ;
dpv :hasName "IT Department" @ en ;
dpv :isOrganisationalUnitOf ex :CompanyA .
ex :PDH1 a dpv :Process ;
dpv :hasPurpose dpv :IdentityAuthentication ;
dpv :isImplementedByEntity ex :IT .
ex :PDH2 a dpv :Process ;
dpv :hasPurpose dpv :HumanResourceManagement ;
dpv :isImplementedByEntity ex :HR .
(META
Example ID: E0037source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0038 :
This example shows the existence of two subsidiaries associated with an organisation and their locations
ex :CompanyA a dpv :Organisation ;
dpv :hasSubsidiary ex :CompanyM , ex :CompanyN .
ex :CompanyM a dpv :Organisation , dpv :Subsidiary ;
dpv :isSubsidiaryOf ex :CompanyA ;
dpv :hasLocation loc :IE .
ex :CompanyN a dpv :Organisation , dpv :Subsidiary ;
dpv :isSubsidiaryOf ex :CompanyA ;
dpv :hasLocation loc :NL .
(META
Example ID: E0038source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0039 :
This example shows the different ways in which data subjects can be indicated in a process. It also shows how the DPV taxonomy of data subjects can be used to combine concepts to accurately represent the data subject involved. And it also shows how information associated with specific data subjects such as identifiers can be indicated.
ex :PDH a dpv :Process ;
dpv :hasDataSubject dpv :Consumer ; # consumer as subjects
dpv :hasDataSubject dpv :AsylumSeeker ; # vulnerable subject
dpv :hasDataSubject dpv :Child ; # minor or children
dpv :hasDataSubject [
a dpv :DataSubject ;
skos :broader dpv :Customer , dpv :Student ;
skos :description "Customers that are Students" @ en ;
] ;
dpv :hasDataSubject [
a dpv :DataSubject , dpv :Patient ;
dpv :hasIdentifier "X1n31123knf3" ;
] .
(META
Example ID: E0039source file ; contributed by Harshvardhan J. Pandit on 2024-06-10)
E0040 :
This example describes how a purpose can be made clearer and accurate by two methods: (1) providing a human-readable description - which is always recommended; and (2) by extending a DPV concept
ex :PDH a dpv :Process ;
# issue: lack of details for what kind of Personalisation
dpv :hasPurpose dpv :Personalisation ;
# choose concept as specific as possible
dpv :hasPurpose dpv :ProvidePersonalisedRecommendations .
# human-readable information is not provided here,
# which can be okay if it is sufficient to simply state the purpose
# and further descriptions are not necessary for the use-case.
ex :PDH a dpv :Process ;
dpv :hasPurpose ex :HolidayCampaign .
ex :HolidayCampaign a dpv :Purpose ;
# align purpose with DPV taxonomy
skos :broader dpv :DirectMarketing ;
# provide human readable information
dct :title "Holiday Campaign 2024" @ en ;
dct :description "Marketing associated with holiday season" @ en ;
dct :identifier "MH2024-A" . # internal campaign identifier
(META
Example ID: E0040source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0041 :
This example describes how the different purposes and information associated with a service can be expressed in a modular and clear manner
ex :MyProduct a dpv :Service ;
dct :title "My Product Streaming Service" @ en ;
dpv :hasProcess ex :Register , ex :Service , ex :FraudManagement .
ex :Register a dpv :Process ;
dpv :hasPurpose dpv :ServiceRegistration ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Collect , dpv :Store , dpv :Use ;
dpv :hasLegalBasis dpv :EnterIntoContract .
ex :Service a dpv :Process ;
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasProcessing dpv :Use ;
dpv :hasPurpose dpv :IdentityVerification ;
];
dpv :hasLegalBasis dpv :ContractPerformance .
ex :FraudManagement a dpv :Process ;
dpv :hasPurpose dpv :FraudPreventionDetection ;
dpv :hasLegalBasis dpv :LegitimateInterest .
(META
Example ID: E0041source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0042 :
This example describes a purpose for performing 'KYC' identity verification as part of legal compliance with anti-money laundering laws
ex :PDH a dpv :Process ;
dpv :hasPurpose [
a dpv :Purpose ;
skos :broader dpv :IdentityVerification ,
dpv :LegalCompliance ;
skos :prefLabel "KYC: Know Your Customer" @ en ;
] ;
dpv :hasLegalBasis [
a dpv :LegalObligation ;
dpv :hasApplicableLaw ex :CJA2010 ;
] .
ex :CJA2010 a dpv :Law ;
dct :title "Money Laundering and Terrorist Financing Act 2010" ;
dpv :hasJuridiction loc :IE .
(META
Example ID: E0042source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0043 :
This example uses the NACE taxonomy to indicate the domain or sectorial relevance of the purpose
ex :PDH a dpv :Process ;
# expressing Sector using NACE
dpv :hasPurpose [
a dpv :Purpose ;
skos :broader dpv :NonCommercialResearch ;
# Sector defined as R&D on social sciences and humanities
# using NACE Rev 2.1 concept 72.20
dpv :hasSector <http://data.europa.eu/ux2/nace2.1/7220> ;
] ;
# expressing Sector as a 'domain' or 'sector' label and IRI
dpv :hasPurpose [
a dpv :Purpose ;
skos :broader dpv :AcademicResearch ;
dpv :hasSector "Education in University" @ en ; # OR link to existin codes
# NACE Rev 2.1 concept 85 Education
dpv :hasSector [
skos :prefLabel "Education in University" @ en ;
skos :broader <http://data.europa.eu/ux2/nace2.1/85.4.2> ;
] ;
] .
(META
Example ID: E0043source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0044 :
This example shows how personal data can be specified by for a work email address in four methods: (1) by using the PD taxonomy, (2) extending a concept from PD taxonomy,(3) specifying the exact value of email address, and (4) using external vocabularies such as schema.org. In all of these, it is strongly recommended to include a DPV concept (i.e. declare it as Personal Data) for interoperability, and to align it with the DPV and PD taxonomies where relevant (e.g. to mention it is an email address, or to specify it is identifier, or that it is sensitive - which it is not in this case)
ex :PDH a dpv :Process ;
# method 1: directly use concept from PD
dpv :hasPersonalData pd :EmailAddress ;
# method 2: extend concept from PD
dpv :hasPersonalData [
a dpv :PersonalData ;
skos :broader pd :EmailAddress ;
skos :prefLabel "Work Email" @ en ;
] ;
# method 3: specify an exact value i.e. an instance
dpv :hasPersonalData [
a dpv :PersonalData , pd :EmailAddress ;
rdf :value "work@example.com" ;
] ;
# method 4: use another appropriate vocabulary e.g. schema.org
dpv :hasPersonalData [
a schema :ContactPoint ;
a dpv :PersonalData ; # strongly recommended for interop
a pd :EmailAddress ; # strongly recommended for interop
schema :email "work@example.com" ;
] ;
# Note: Email Address can be an identifier
# So good practice is to also declare it when used as an identifier
dpv :hasPersonalData [
a dpv :PersonalData ;
skos :broader pd :EmailAddress , pd :Identifier ;
] ;
dpv :hasPersonalData [
a dpv :PersonalData , pd :EmailAddress , dpv :Identifier ;
rdf :value "work@example.com" ;
] .
(META
Example ID: E0044source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0045 :
This example shows how data can be indicated as being sensitive or belonging to special category. It also shows the use of PD extension which provides a taxonomy of special categories.
ex :PDH a dpv :Process ;
# to denote location being used is sensitive
dpv :hasPersonalData [
a dpv :SensitivePersonalData , pd :Location ;
];
# to express biometrics being used are special category
# note: PD extension already defines Biometric as special category
dpv :hasPersonalData [
a dpv :SpecialCategoryPersonalData ;
skos :broader pd :Biometric ;
] ;
# to use PD extension to infer use of FacialPrint is special category
# i.e. pd:FacialPrint rdf:type dpv:SpecialCategoryPersonalData is
# defined in PD extension
dpv :hasPersonalData pd :FacialPrint .
# The PD extension can also be used to determine what biometric data
# is being used within the use-case as it contains:
# pd:FacialPrint skos:broader pd:Biometric
(META
Example ID: E0045source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0046 :
This example shows a process which first collects email address from the data subject, and then uses it to derive an account identifier. The seeming duplication in information across processing, personal data category, and data source actually represents three distinct concepts - which can be used in various ways for data governance, or legal compliance e.g. to retrieve all data which is collected or to ensure all collected data has a source.
ex :PDH a dpv :Process ;
dpv :hasProcess [
a dpv :Process ;
# Collects email addresses from data subjects
# The statements about processing, data category, and data source
# are aligned but represent different concepts
dpv :hasProcessing dpv :Collect ;
dpv :hasPersonalData [
a dpv :PersonalData ;
a dpv :ProvidedPersonalData ;
skos :broader pd :EmailAddress ;
] ;
dpv :hasDataSource dpv :DataSubjectDataSource ;
] ;
dpv :hasProcess [
a dpv :Process ;
# The existing email address is used to derive an account id
# (not mentioned here, but occurs in the same broader process)
# e.g. by using a MD5 hash technique (not mentioned here)
dpv :hasProcessing dpv :Derive ;
dpv :hasPersonalData [
a dpv :PersonalData ;
a dpv :DerivedPersonalData ;
skos :broader pd :AccountIdentifier ;
] ;
] .
(META
Example ID: E0046source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0047 :
This example shows processing conditions where the use (of data or technology) takes place over 6 months and in Ireland (IE) and Netherlands (NL)
ex :PDH a dpv :Process ;
dpv :hasProcessing dpv :Use ;
dpv :hasProcessingCondition [
a dpv :ProcessingDuration ;
dpv :hasDuration "P6M" ;
] ;
dpv :hasProcessingCondition [
a dpv :ProcessingLocation ;
dpv :hasLocation loc :IE , loc :NL ;
] .
(META
Example ID: E0047source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0048 :
This example shows storage conditions for a 'store' processing operation. It has a duration valid until the event 'account closure' occurs. It has a storage location situated in Ireland (IE) and Netherlands (NL). The deletion occurs 6 months after the event 'account closure'. And restoration is implemented by using (stored) data located in backup systems in Ireland (IE).
ex :PDH a dpv :Process ;
dpv :hasProcessing dpv :Store ;
dpv :hasStorageCondition [
a dpv :StorageDuration ;
dpv :hasDuration [
a dpv :UntilEventDuration ;
dct :description "account closure" @ en ;
] ;
] ;
dpv :hasStorageCondition [
a dpv :StorageLocation ;
dpv :hasLocation loc :IE , loc :NL ;
] ;
dpv :hasStorageCondition [
a dpv :StorageDeletion ;
dpv :hasDuration [
a dpv :UntilEventDuration ;
dpv :hasDuration "P6M" ;
dct :description "6 months from acount closure" @ en ;
] ;
] ;
dpv :hasStorageCondition [
a dpv :StorageRestoration ;
dpv :isImplementedUsingTechnology [
a dpv :Technology ;
dct :description "backup systems" ;
dpv :hasLocation loc :IE ;
] ;
] .
(META
Example ID: E0048source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0049 :
This example shows how data volume, data subject scale, and geographic scale can be indicated along with optional information about the exact values involved. It also shows how a qualified scale can be provided as 'processing scale' based on some criteria (not described here).
ex :PDH a dpv :Process ;
dpv :hasProcessing dpv :Use ;
# Geographic Scale
dpv :hasGeographicCoverage dpv :NationalScale ; # which nation???
dpv :hasGeographicCoverage [
a dpv :NationalScale ;
dpv :hasLocation dpv :IE ; # expresses which nation
] ;
# Data Volume
dpv :hasDataVolume dpv :LargeDataVolume ; # how much is large?
dpv :hasDataVolume [
a dpv :DataVolume ;
rdf :value "2147483647" ^^xsd :int ; # number of records
] ;
# Data Subject Scale
dpv :hasDataSubject dpv :SmallScaleOfDataSubjects ; # how many people?
dpv :hasDataSubject [
a dpv :SmallScaleOfDataSubjects ;
rdf :value "5000" ^^xsd :int ; # number of people
] ;
# Processing Scale - aggretating above as a qualified label
dpv :hasProcessingScale dpv :SmallScaleProcessing .
(META
Example ID: E0049source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0050 :
This example shows the various ways in which duration can be expressed - as a period of time (6 months), as an end date, or as a fixed number of occurrences, or until an event occurs. The example also show some 'bad practices' where the information is expressed directly as strings - and instead shows the benefits of providing semantic information to explicitly indicate what kind of a duration it is which is necessary for unambiguous interpretations.
ex :PDH1 a dpv :Process ;
dpv :hasProcessing dpv :Collect ;
dpv :hasPersonalData pd :Location ;
dpv :hasDuration "P6M" ; # 6 months
dpv :hasDuration [
a dpv :TemporalDuration ;
rdf :value "P6M" ^^xsd :duration ; # 6 months - same as above,
# but more explicit that this is a duration
] ;
dpv :hasDuration "2023-12-31" ;
dpv :hasDuration [
a dpv :UntilTimeDurationdt ;
rdf :value "2023-12-31" ^^xsd :date ; # same as above,
# but more explicit that this is an end date
] ;
dpv :hasDuration "1 time" @ en ; # bad practice - not machine-readable
dpv :hasDuration [
a dpv :FixedOccurencesDuration ; # good practice - unambigious
rdf :value "1" ^^xsd :int ;
] ;
dpv :hasDuration "until account closure" @ en ; # bad practice
dpv :hasDuration [
a dpv :UntilEventDuration ; # good practice - specifies an event
rdf :value "Until Account Closure" @ en ;
] .
(META
Example ID: E0050source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0051 :
This example shows the various ways in which frequency can be expressed, including combining frequency with duration to express complex information such as once per day for 6 months
ex :PDH1 a dpv :Process ;
dpv :hasProcessing dpv :Collect ;
dpv :hasPersonalData pd :Location ;
dpv :hasDuration [
a dpv :TemporalDuration ;
rdf :value "P6M" ^^xsd :duration ;
] ;
# various ways to indicate frequencies
dpv :hasFrequency [
a dpv :SingularFrequency ; # data will be collected exactly once
# combined with duration - once sometime in 6 months
] ;
dpv :hasFrequency [
a dpv :ContinousFrequency ; # data will be continously collected
# combined with duration - continous collection for 6 months
] ;
dpv :hasFrequency [
a dpv :SporadicFrequency ; # data will be sporadically collected
# combined with duration - collected sporadically across 6 months
# optionally, the 'frequency' of sporadic collection can also be
# expressed as a duration i.e. a preiod
rdf :value "10" ^^xsd :duration ; # 10 times (across 6 months)
] ;
dpv :hasFrequency [
a dpv :OftenFrequency ; # often is qualitatively more than sporadic
rdf :value "1" ; # frequency can also be expressed as occurences
dpv :hasDuration [ # combined with a duration
a dpv :TemporalDuration ;
rdf :value "P1D" ^^xsd :duration ;
] ; # the result is: once per day for 6 months (from outer duration)
] .
(META
Example ID: E0051source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0052 :
This example shows a process where email address is required to be collected, and name can be optionally collected. Note that the necessity applies to the entire process i.e. both personal data and the collect processing operation. It also provides an indication of the importance of the process - for example to indicate which processes are important for the organisation (primary importance) and which are not as important or are not crucial (secondary importance).
ex :PDH a dpv :Process ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasProcessing dpv :Collect ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasNecessity dpv :Required ;
dpv :hasImportance dpv :PrimaryImportance ;
] ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasProcessing dpv :Collect ;
dpv :hasPersonalData pd :Name ;
dpv :hasNecessity dpv :Optional ;
dpv :hasImportance dpv :SecondaryImportance ;
] ;
].
(META
Example ID: E0052source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0053 :
This example show how the unavailability, or non-applicability, or unknown applicability of information can be expressed using the Applicability concepts. Note that such situations may represent risks or issues that may require additional attention e.g. where the information is unknown, further steps should be taken to determine the exact applicability.
ex :PDH a dpv :Process ;
# information about personal data is not available at the moment
dpv :hasPersonalData dpv :NotAvailable ;
# personal data is not involved, so we specify not applicable
dpv :hasPersonalData dpv :NotApplicable ;
# we don't know yet if personal data is invovled - so it is unknown
dpv :hasPersonalData dpv :UnknownApplicability ;
# another way to indicate applicability - we know some personal data
# is involved but we don't know anything more about it
dpv :hasPersonalData [
a dpv :PersonalData ;
dpv :hasApplicability dpv :NotAvailable ;
] .
(META
Example ID: E0053source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0054 :
This example shows two processes as 'activities' with the status as ongoing and proposed. The proposed activity can be useful to get an audit or approval or indicate future plans.
ex :PDH1 a dpv :Process ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasActivityStatus dpv :ActivityOngoing .
ex :PDH2 a dpv :Process ;
dpv :hasPersonalData pd :Biometric ;
dpv :hasPurpose dpv :IdentityVerification ;
dpv :hasActivityStatus dpv :ActivityProposed .
(META
Example ID: E0054source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0055 :
This example shows the compliance status associated with activities in terms of the organisation's policies and for the EU GDPR obligations. It shows how compliance issues and lawfulness can be documented as a status associated with a process. For GDPR, it uses the concepts from EU-GDPR extension regarding lawfulness.
ex :PDH1 a dpv :Process ;
dpv :hasComplianceStatus dpv :Compliant ;
# to indicate compliance with a policy
dpv :hasStatus [
dpv :hasPolicy dpv :Policy ;
dpv :hasComplianceStatus dpv :Compliant ;
] ;
# to indicate compliance with a law
dpv :hasComplianceStatus [
a dpv :PartiallyCompliant ;
dpv :hasApplicableLaw legal-eu :GDPR ;
] ;
# to highlight issues in compliance
dpv :hasComplianceStatus [
a dpv :ComplianceViolation ;
dpv :hasApplicableLaw legal-eu :GDPR ;
dct :description "Records of Processing Activities are not updated" @ en ;
dct :subject "GDPR Article 30" @ en ;
] .
ex :PDH2 a dpv :Process ;
dpv :hasLawfulness dpv :Lawful ; # doesn't indicate which law
dpv :hasLawfulness [
a dpv :Lawful ; # lawful for GDPR
dpv :hasApplicableLaw legal-eu :GDPR ;
] ;
dpv :hasLawfulness [
a dpv :Lawful ; # lawful for GDPR Article 30
dpv :hasApplicableLaw legal-eu :GDPR ;
dct :subject "GDPR Article 30" @ en ;
] ;
# using the EU-GDPR extension
dpv :hasLawfulness eu-gdpr :GDPRCompliant ;
(META
Example ID: E0055source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0056 :
This example shows how a DPIA can be documented as an audit - including a status that indicates audit is needed, and maintaining logs for how the DPIA was approved.
ex :PDH a dpv :hasProcess ;
dpv :hasImpactAssessment ex :PDH-DPIA-202402 .
ex :PDH-DPIA-202402 a dpv :DPIA ;
dct :subject ex :CorpService ; # DPIA covering Corp. Service
dct :date "2024-01-01" ^^xsd :date ;
dct :conformsTo ex :OrgPolicy ;
dpv :hasAuditStatus dpv :AuditRequired ; # an audit is requred
dpv :hasAuditStatus dpv :AuditApproved ; # status if no details are needed
# or to specify more details about the audit
dpv :hasAuditStatus [
a dpv :AuditRequested ;
dct :date "2024-01-31" ^^xsd :date ; # date of approval
] .
dpv :hasAuditStatus [
a dpv :AuditConditionallyApproved ;
dct :date "2024-03-31" ^^xsd :date ; # date of approval
] .
dpv :hasAuditStatus [
a dpv :AuditRequested ;
dct :date "2024-05-31" ^^xsd :date ; # date of approval
] .
dpv :hasAuditStatus [
a dpv :AuditApproved ;
dct :date "2024-07-31" ^^xsd :date ; # date of approval
] .
(META
Example ID: E0056source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0057 :
The following example describes a GDPR Article 20 Data Portability request not being fulfilled due to identity verification failure. The dpv:RequestRequiresAction concept indicates further action is required - specifically to provide identity documents.
ex :PDH a dpv :RightExerciseRecord ;
dpv :hasStatus dpv :RequestRequiresAction ;
dpv :hasJustification justifications :IdentityVerificationFailure ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasProcessing dpv :Share ;
dpv :hasPersonalData dpv :IdentifyingPersonalData ;
dpv :isImplementedByEntity dpv :DataSubject ;
] .
(META
Example ID: E0057source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0058 :
The following example uses the justification HighVolumeOfProcesses to represent a high volume of similar processes or requests causing a delay in fulfilling the rights request. The concept dpv:hasDuration is used to indicate the duration of the delay.
ex :PDH a dpv :RightNonFulfilmentNotice ;
dpv :hasStatus dpv :RequestActionDelayed ;
dpv :hasJustification justifications :HighVolumeOfProcesses ;
dpv :hasDuration "P6M" . # ISO 8601 6 Months
(META
Example ID: E0058source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0059 :
The following example shows the justification ContestAccuracy representing contesting the accuracy of information or process to justify why the right to rectification as per GDPR Article 16 is being exercised. The information in question is represented using dpv:hasPersonalData, with two processes indicating which data should be deleted and the correction.
ex :PDH a dpv :RightExerciseActivity , eu-gdpr :A16 ;
dpv :hasStatus dpv :RequestInitiated ;
dpv :hasJustification justifications :ContestAccuracy ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasPersonalData [ a pd :EmailAddress ; rdf :value "x@x.com" ;]
dpv :hasProcessing dpv :Delete ;
];
dpv :hasProcess [
a dpv :Process ;
dpv :hasPersonalData [ a pd :EmailAddress ; rdf :value "y@y.com" ;]
dpv :hasProcessing dpv :Store ;
] .
(META
Example ID: E0059source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0060 :
The following example shows the use of LOC extension to express the location of a process. It also shows how the location fixture and locality concepts are useful to indicate information such as data will be stored locally and shared to a remote cloud server.
ex :PDH a dpv :Process ;
# specifying the location and jurisdiction using the LOC extension
dpv :hasLocation loc :IE ; # process takes place in Ireland
dpv :hasJurisdiction loc :IE , loc :EU ; # under Irish and EU jurisdictions
# specifying data transfer to a third country
dpv :hasProcessing [
a dpv :Transfer ;
dpv :hasLocation loc :USA ;
] ;
dpv :hasProcessing [
# or explicitly specifying USA as a third country
# for cross-border data transfer
a dpv :CrossBorderTransfer ;
dpv :hasThirdCountry loc :USA ;
] ;
dpv :hasProcessing [
a dpv :Store ; # data is stored within device
dpv :hasLocation dpv :WithinDevice ;
] ;
dpv :hasStorageCondition [ # same as above, but expressed as a condition
a dpv :StorageLocation ;
dpv :hasLocation dpv :WithinDevice ;
] ;
dpv :hasProcessing [
a dpv :Transfer ; # data is transferred to a cloud service location
dpv :hasLocation dpv :CloudLocation ;
dpv :isImplementedByUsingTechnology tech :CloudService ;
dpv :isImplementedByEntity <https://www.hetzner.com/> ;
] .
(META
Example ID: E0060source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0061 :
The following example represents a notice outlining a failure to complete a GDPR Data Portability request due to identity verification failure. The notice provides steps as providing an official ID for identity verification for the data subject to complete in order to continue the request, and outlines the consequence of not doing this would be a failure to complete the request.
ex :PDH a dpv :RightNonFulfilmentNotice ;
dct :dateSubmitted "2024-01-01" ^^xsd :date ;
dct :publisher ex :SomeController ;
dpv :hasRight eu-gdpr :A20 ;
dpv :hasRecipient dpv :DataSubject ;
dpv :hasJustification justifications :IdentityVerificationFailure ;
dpv :hasProcess [
a dpv :Process ;
dpv :isImplementedByEntity dpv :DataSubject ;
dpv :hasPurpose dpv :IdentityVerification ;
dpv :hasPersonalData pd :OfficialID ;
dpv :hasProcessing dpv :Share ;
dpv :hasRecipient dpv :SomeController ;
dpv :hasObligation [
a dpv :Obligation ;
dpv :hasDuration "P30D" ^^xsd :duration ;
dpv :hasConsequenceOfFailure dpv :RequestRejected ;
] .
(META
Example ID: E0061source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0062 :
The justification concept ComplexityOfProcess represents a reason to delay a process due to the complexity of fulfilling it. To instead use it as a justification for not fulfilling the process, we create a new justification that combines the complexity of process and non-fulfilment categories.
ex :PDH a dpv :Process ;
dpv :hasJustification [
a dpv :Justification ;
skos :broader justifications :ComplexityOfProcess ;
skos :broader justifications :NonFulfilmentJustification ;
skos :prefLabel "Process could not be fulfilled due to complexity" @ en ;
] .
(META
Example ID: E0062source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0063 :
The justification RightsFreedomsImpactUnlikely represents an unlikely impact on rights and freedoms, which can be used as a justification to not provide data subjects with a notification about a data breach involving their personal data as per GDPR Article 35-3b.
ex :PDH a risk :DataBreachReport ;
dpv :hasStatus eu-gdpr :BreachNotificationNotNeeded ;
dpv :hasJustification justifications :RightsFreedomsImpactUnlikely .
(META
Example ID: E0063source file ; contributed by Harshvardhan J. Pandit on 2024-06-11)
E0064 :
This example specifies a technical measure (access control) being used and specifies that it is implemented by using the database software. It also shows how technologies can have technical measures implemented as part of the system, and also how technologies can indicate they have the capability to provide technical measures for other activities.
ex :PDH a dpv :Process ;
# method 1: directly specify the measure
dpv :hasTechnicalMeasure dpv :AccessControlMethod ;
# method 2: specify the measure with implementation details
dpv :hasTechnicalMeasure [
a dpv :TechnicalMeasure ;
skos :broader dpv :AccessControlMethod ;
# same measure can have multiple technical measures involved
dpv :isImplementedByUsingTechnology ex :CorpDataBase ;
] .
ex :CorpDataBase a dpv :Technology ;
a tech :Database ;
# indicating technology has a technical measure
dpv :hasTechnicalMeasure dpv :AccessControlMethod ;
# indicating technology is capable of providing a technical measure
# in other use-cases
tech :hasCapability dpv :AccessControlMethod .
(META
Example ID: E0064source file ; contributed by Harshvardhan J. Pandit on 2024-06-12)
E0065 :
This example shows how the legitimate interest of a controller. It describes 'bad practices' which lead to ambiguity or lack crucial information, and also describe how legitimate interest can be associated with a purpose within and outside of specific purposes. It also shows alternate ways of defining legal basis and purpose in relation to each other - for cases where such information is needed. Though we *strongly* recommend always using dpv:Process and declaring each concept such as purpose, legal basis, processing, personal data explicitly and separately for consistency and ease of reuse.
ex :PDH a dpv :Process ;
# while purpose can be part of the legitimate interest instance,
# we recommend declaring it separately within a process to enable
# consistency and to enable indicating details about the purpose
# independently from the legal basis
dpv :hasPurpose dpv :FraudPreventionDetection ;
# bad practice - always specify whose legitimate interest
dpv :hasLegalBasis dpv :LegitimateInterest ;
# better - is clear and unambigious
dpv :hasDataController ex :AcmeInc ;
dpv :hasLegalBasis dpv :LegitimateInterestOfController ;
# again bad practice if there are multiple controllers involved
dpv :hasDataController ex :AcmeInc , ex :BetaInc ;
dpv :hasLegalBasis dpv :LegitimateInterestOfController ; # which controller?
# better - explicitly state which entity
dpv :hasLegalBasis [
a dpv :LegitimateInterestOfController ;
dpv :hasDataController ex :AcmeInc ;
# also good practice to provide more details
dpv :hasJustification [
a dpv :Justification ;
dct :description "detect fraud as part of operations" @ en ;
] ;
] .
# if legitimate interest is to be defined outside of a process,
# additional relevant information can be added to it
# though we *strongly* recommend always using a process and delcaring
# purpose, legal basis, etc. separately and explicitly
# The below shows three different ways to indicate the same information
# - so the adopter can choose the best 'fit' for their internal representation
ex :FraudManagement a dpv :Purpose , dpv :LegitimateInterest ;
skos :broader dpv :FraudPreventionDetection ;
skos :broader dpv :LegitimateInterestOfController ;
dpv :hasDataController ex :AcmeInc ;
dpv :hasJustification [
a dpv :Justification ;
dct :description "detect fraud as part of operations" @ en ;
] ;
ex :FraudManagement a dpv :LegitimateInterestOfController ;
dpv :hasPurpose dpv :FraudPreventionDetection ;
dpv :hasDataController ex :AcmeInc ;
dpv :hasJustification [
a dpv :Justification ;
dct :description "detect fraud as part of operations" @ en ;
] ;
ex :FraudManagement a dpv :Purpose ;
skos :broader dpv :FraudPreventionDetection ;
dpv :hasLegalBasis [
a dpv :LegitimateInterestOfController ;
dpv :hasDataController ex :AcmeInc ;
dpv :hasJustification [
a dpv :Justification ;
dct :description "detect fraud as part of operations" @ en ;
] ;
] .
# and then this can be used in a process as a purpose and a legal basis
ex :PDH2 a dpv :Process ;
dpv :hasPurpose ex :FraudManagement ;
dpv :hasLegalBasis ex :FraudManagement .
(META
Example ID: E0065source file ; contributed by Harshvardhan J. Pandit on 2024-06-13)
E0066 :
This example show a process where service provision based on consent is permitted, and profiling based on legitimate interest is prohibited
ex :PDH a dpv :Process ;
dpv :hasPermission [
a dpv :Permission ;
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasLegalBasis dpv :Consent ;
] ;
dpv :hasProhibition [
a dpv :Prohibition ;
dpv :hasProcessing dpv :Profiling ;
dpv :hasLegalBasis dpv :LegitimateInterest ;
] .
# processes with permission/prohibition as statuses
ex :PDH a dpv :Process ;
dpv :hasProcess [
a dpv :Process ;
dpv :hasRule dpv :Permission ;
dpv :hasPurpose dpv :ServiceProvision ;
dpv :hasLegalBasis dpv :Consent ;
] ;
dpv :hasProcess [
dpv :hasRule dpv :Prohibition ;
a dpv :Prohibition ;
dpv :hasProcessing dpv :Profiling ;
dpv :hasLegalBasis dpv :LegitimateInterest ;
] .
(META
Example ID: E0066source file ; contributed by Harshvardhan J. Pandit on 2024-06-14)
E0067 :
This example shows applicable rights being asserted in a privacy notice. The notice is for a GDPR implementing use-cases and uses the EU-GDPR extension to represent rights under GDPR. It also shows how rights not currently provided by DPV can be associated.
ex :PN2024 a dpv :PrivacyNotice ;
dpv :hasApplicableLaw legal-eu :GDPR ;
dpv :hasRight eu-gdpr :A15 , # right of access
eu-gdpr :A16 , # right to rectification
eu-gdpr :A17 , # right to erasure / to be forgotten
eu-gdpr :A18 , # right to restrict processing
eu-gdpr :A20 , # right to data portability
eu-gdpr :A21 ; # right to object
dpv :hasRight [
a dpv :DataSubjectRight ;
dpv :hasApplicableLaw ex :SomeLaw ;
dct :description "specific right to do X" @ en ;
dpv :hasProcess ex :SomeRightsProcess ;
] .
(META
Example ID: E0067source file ; contributed by Harshvardhan J. Pandit on 2024-06-16)
E0068 :
This example shows the use of risk concepts in DPV and RISK extension to represent a risk of data breach associated with a process along with its potential consequences and impacts on the data subject. The scenario consists of a risk of data breach with high likelihood and severity, and whose potential consequence includes a loss of data which can lead to financial loss for the data controller and misuse of breached information to cause identity fraud for the data subject. The risk has a mitigation measure, which is to secure the data using the encryption. The residual risk if this measure is applied is shown to have a lower risk level.
ex :PDH a dpv :Process ;
dpv :hasRisk ex :R1DB .
ex :R1DB a dpv :Risk ;
skos :broader risk :DataBreach ;
skos :prefLabel "Risk of Data Breach for Process" @ en ;
dpv :hasLikelihood risk :HighLikelihood ;
dpv :hasSeverity risk :HighSeverity ;
dpv :hasRiskLevel risk :HighRisk ;
dpv :hasConsequence [
a dpv :Risk , dpv :LossOfData ;
dpv :hasLikelihood risk :HighLikelihood ;
dpv :hasSeverity risk :HighSeverity ;
dpv :isMitigatedByMeasure dpv :DataBackupProtocols , dpv :Encryption ;
dpv :hasImpact [
a risk :FinancialLoss ;
skos :prefLabel "Loss suffered due to breach" @ en ;
dpv :hasImpactOn dpv :DataController ;
dpv :hasLikelihood risk :LowLikelihood ;
dpv :hasSeverity risk :HighSeverity ;
] ;
dpv :hasImpact [
a dpv :Risk , risk :MisuseBreachedInformation , risk :IdentityFraud ;
skos :prefLabel "Breached information may be misued in identity fraud" @ en ;
dpv :hasImpactOn dpv :DataSubject ;
dpv :hasLikelihood risk :LowLikelihood ;
dpv :hasSeverity risk :HighSeverity ;
] ;
] ;
dpv :hasResidualRisk ex :R2DB .
ex :R2DB a dpv :ResidualRisk ;
dpv :isResidualRiskOf ex :R1DB ;
dpv :hasLikelihood risk :HighLikelihood ;
dpv :hasSeverity risk :LowSeverity ;
dpv :hasRiskLevel risk :LowRisk .
(META
Example ID: E0068source file ; contributed by Harshvardhan J. Pandit on 2024-06-16)
E0069 :
This example shows the use of incident concepts in DPV and RISK extension to represent a data breach incident along with its potential and actual (i.e. occured) consequences and impacts on the data subject. It shows the consequences of the incident as loss of data, and which is being misused to cause identity fraud. It also refers to the further risk of financial loss, and associates the incident with a previously identified risk (not elaborated in this example). Note that incident details such as timestamps and durations are not shown in this example.
ex :IN11 a risk :Incident ;
skos :broader risk :DataBreach ;
dpv :hasStatus risk :IncidentConcluded ;
dpv :hasConsequence [
a dpv :Incident , dpv :LossOfData ;
dpv :hasStatus risk :IncidentConcluded ;
dpv :hasImpact [
a risk :Incident , risk :MisuseBreachedInformation , risk :IdentityFraud ;
dpv :hasStatus risk :IncidentOngoing ;
skos :prefLabel "Breached information may be misued in identity fraud" @ en ;
dpv :hasImpactOn dpv :DataSubject ;
dpv :hasSeverity risk :HighSeverity ;
] ;
dpv :hasImpact [
a dpv :Risk , risk :FinancialLoss ;
skos :prefLabel "Loss suffered due to breach" @ en ;
dpv :hasImpactOn dpv :DataController ;
dpv :hasLikelihood risk :LowLikelihood ;
dpv :hasSeverity risk :HighSeverity ;
] ;
] ;
risk :refersToRisk ex :R2DB .
(META
Example ID: E0069source file ; contributed by Harshvardhan J. Pandit on 2024-06-16)
E0070 :
This example shows how existing DPV concepts and relations are used to describe what personal data a data breach incident affected and how the data was secured before the incident.
ex :IN12 a risk :Incident ;
dpv :hasPersonalData pd :EmailAddress ;
dpv :hasTechnicalMeasure dpv :Encryption ;
# Expressing duration using method 1: DPV concepts
dpv :hasDuration [
a dpv :UntilEventDuration ;
dct :description "Incident continued until we shut down power" @ en ;
];
# Expressing duration using method 2: DCT concepts
dct :temporal "2023-05-24/2023-05-26" ; # start and end
dpv :hasStatus risk :IncidentConcluded .
(META
Example ID: E0070source file ; contributed by Harshvardhan J. Pandit on 2024-06-16)
E0071 :
In this example, risk controls are used to indicate the technical measure of encryption is used to remove the consequence of misusing the data if it is breached.
ex :R3DB a dpv :Risk ;
skos :broader risk :DataBreach ;
dpv :hasRiskLevel risk :LowRisk ;
dpv :hasConsequence [
a dpv :Risk , risk :MisuseBreachedInformation ;
dpv :isMitigatedByMeasure dpv :DataBackupProtocols , dpv :Encryption ;
risk :hasControl risk :RemoveConsequence ;
] .
(META
Example ID: E0071source file ; contributed by Harshvardhan J. Pandit on 2024-06-16)
Funding Acknowledgements
Funding Sponsors
The DPVCG was established as part of the SPECIAL H2020 Project , which received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 731601 from 2017 to 2019.
Harshvardhan J. Pandit was funded to work on DPV from 2020 to 2022 by the Irish Research Council's Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790.
The ADAPT SFI Centre for Digital Media Technology is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106 (2018 to 2020) and Grant#13/RC/2106_P2 (2021 onwards).
Funding Acknowledgements for Contributors
The contributions of Beatriz Esteves have received funding through the PROTECT ITN Project from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 813497.
The contributions of Harshvardhan J. Pandit have been made with the financial support of Science Foundation Ireland under Grant Agreement No. 13/RC/2106_P2 at the ADAPT SFI Research Centre.