This document lists the examples for concepts in DPV and aligned vocabularies. The examples are available in DPVCG GitHub repo under ./examples path.

DPV Family of Documents

Related Links

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 further information, please see the contribution section.

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

IRIhttps://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).
  1. An Example MUST have a title (provided using dct:title)
  2. An Example MUST have a description (provided using dct:description)
  3. An Example MUST have an identifier with prefix 'U' (provided using dct:identifier)
  4. An Example MAY have one or more contributors (specified using dct:contributor)
  5. An Example MAY have a date (e.g. creation or modification) (specified using dct:date)
  6. An Example MAY specify the source of its information (using dct:source)
  7. An Example MAY specify its primary subject or concept (using dct:subject)
  8. An Example MAY specify relevant requirements derived from it (using dct:references)

Examples

E0001: Dummy Example 1

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 .

E0002: Dummy Example 2

Dummy Example 2 description

Relevant Concepts: dpv:Concept

source: https://w3id.org/dpv/examples/E0002.ttl

E0003: Extending Purpose for Use-Case

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" .

E0004: DPV-OWL: Extending Purpose for Use-Case

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" .

E0005: Combining concepts to indicate they always occur together

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 .

E0006: Maintaining Interoperability between Use-Cases

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 .

E0007: Use of PersonalDataHandling to group how data is being processed

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 ;

E0008: Nesting PersonalDataHandling for modular expression of processing operations

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 .

E0009: Adding human-readable descriptions

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" ;

E0010: Using NACE codes to restrict Purposes

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 .

E0011: Storage Conditions

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 ;
    ] .

E0012: Data Sources

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 .

E0013: Automated Processing with Human Involvement

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 .

E0014: Derivation and inference of personal data

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 .

E0015: Indicating personal data is sensitive or special category

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 .

E0016: Protecting data using encryption and access control

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 .

E0017: Indicating staff training for use of Credentials

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 .

E0018: Notice used in an activity

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 consents 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 .

E0019: Consent record

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"
    ] .

E0020: Controller-Processor agreement

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 .

E0021: Data transfer safeguards

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 .

E0022: Denoting Legal Basis

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 .

E0023: Consent as legal basis

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 .

E0024: Details of 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 .

E0025: Consent Notice

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 .

E0026: Using consent types

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 .

E0027: Describing Entities

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 "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 .

E0028: Contextual Necessity

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 .

E0029: Risk and Consequence

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 .

Concept Mappings