Examples for Data Privacy Vocabulary

Abstract

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

Example 1: Implications of using SKOS vs OWL

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: E0001; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 2: Extending concepts to represent use-case specific information

DPV defines the (broad) concept of 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.

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: E0002; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 3: Extending multiple concepts

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: E0003; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 4: Interoperability of extended concepts across use-cases

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: E0004; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 6: Nesting Processes

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: E0006; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 9: 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 [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: E0009; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 10: Indicating personal data is sensitive or special category

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: E0010; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 11: Indicating Storage Conditions

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 Ontology in OWL, and the location is specified using Location and Geo-Political Membership concepts for DPV.

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: E0011; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 12: Indicating 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.

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: E0012; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 13: Spam filter as Automated Decision Making 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 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: E0013; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 14: Denoting Legal Basis within a Process

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: E0014; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 16: Indicating details about an individual's consent

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: E0016; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 17: Representing notice, provision, expiry, and withdrawal information for consent

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: E0017; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 19: Indicating Entity Information, including DPO and Representatives

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: E0019; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 21: Using organisational measure: 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.

# 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: E0021; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 22: Privacy 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 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: E0022; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 23: Consent record example

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 Consent Records and Receipts as per ISO/IEC TS 27560:2023 using DPV.

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: E0023; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 24: Controller-Processor agreement denoting processing to be carried out

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: E0024; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 26: Example of Contextual Necessity

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: E0026; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 27: Indicating risks, consequences, and impacts

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: E0027; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 31: Using Service to group related processes

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: E0031; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 32: Indicating Controller identity and details of representative

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: E0032; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 34: Specifying recipients of data

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: E0034; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 35: Specifying data exporters and importers

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: E0035; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 36: Indicate relevant authority for processing

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: E0036; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 37: Indicating type of organisation and involvement of specific orgnisational units

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: E0037; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 39: Indicating involvement of data subjects

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: E0039; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-10)

Example 40: Extending a purpose and using human-readable descriptions

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: E0040; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 41: Indicating purposes associated with a Service

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: E0041; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 43: Indicating sector or domain and associating it with a purpose

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: E0043; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 44: Specifying personal data

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: E0044; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 45: Indicating data belongs to sensitive or special category

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: E0045; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 46: Indicating data being collected and derived

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: E0046; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 48: Indicating storage conditions for duration, location, deletion, and restoration

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: E0048; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 49: Indicating data volume, geo-location coverage, data subject scale, and a processing scale

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: E0049; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 50: Specifying duration

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: E0050; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 51: Specifying frequency

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: E0051; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 52: Specifying necessity and importance in context

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: E0052; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 53: Specifying applicability of information

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: E0053; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 55: Specifying compliance status and lawfulness

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: E0055; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 56: Specifying the audit status associated with a DPIA

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: E0056; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 57: Expressing GDPR Right to Data Portability could not be fulfilled due to Identity Verification failure

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: E0057; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 59: Exercising the right to rectification with contesting accuracy of information as justification

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: E0059; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 60: Specifying the location of a process

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: E0060; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 61: Associating justifications with right exercise non-fulfilment

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 ex:SomeController ;
    dpv:hasObligation [
        a dpv:Obligation ;
        dpv:hasDuration "P30D"^^xsd:duration ;
        dpv:hasConsequenceOfFailure dpv:RequestRejected ;
    ]
  ] .

(META Example ID: E0061; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-11)

Example 64: Indicating use of a technical measure and its implementation

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: E0064; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-12)

Example 65: Specifying legitimate interest of a controller

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: E0065; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-13)

Example 66: Specifying permissions and prohibitions

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: E0066; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-14)

Example 67: Indicating applicable rights

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: E0067; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-16)

Example 68: Using DPV and RISK extension to represent risks

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: E0068; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-16)

Example 69: Using DPV and RISK extension to represent incidents

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: E0069; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-16)

Example 70: Indicating personal data involved in an incident

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: E0070; link: source file; contributed by Harshvardhan J. Pandit on 2024-06-16)

Example 72: Using Notice Layer and Icon in a Consent Notice

This example shows a Consent Notice that is structured in 2 layers - first for a summary and a second layer providing detailed overview of the intended processing. The layers contain controls for consent and rights which are accompanied by the label to be used e.g. for the button in the UI, and the icon to be displayed alongside it. This example also shows how a consent notice can be expressed in a machine-readable form in a manner that is similar to and can be used to create a graphical notice such as on a website or in a mobile app.

ex:ExampleNotice a dpv:ConsentNotice ;
    dct:title "Consent Notice for Service X"@en ;
    dct:hasLocation "https://example.com/service-x"^^xsd:anyURI ;
    dpv:hasNoticeLayer [  # Layer showing the 'overview'
        a dpv:NoticeLayer ;
        dct:description "Consent to use location for providing x"@en ;
        dpv:hasPurpose dpv:ServicePersonalisation ;
        dpv:hasPersonalData pd:Location, pd:Email ;
        dpv:hasLegalBasis dpv:ExpressedConsent ;
        dpv:hasConsentControl [  # Consent control with label and icon
            a dpv:ProvideConsent ; 
            dct:title "Accept"@en ;
            dpv:hasNoticeIcon ex:iconGiveConsent ; 
        ], [ 
            a dpv:RefuseConsent ;
            dct:title "Refuse"@en ; 
            dpv:hasNoticeIcon ex:iconRefuseConsent ; 
        ] ;
    ], [  # Layer showing the 'detailed' view
        a dpv:NoticeLayer ;
        # link to full privacy notice for the service
        dpv:hasNotice "https://example.com/privacy-notice"^^xsd:anyURI ;
        dpv:hasProcess [ # process for use of location
                a dpv:Process ;
                dpv:hasPurpose dpv:ServicePersonalisation ;
                dpv:hasPersonalData pd:Location ;
                dpv:hasProcessing dpv:Collect, dpv:Use ;
                dpv:hasLegalBasis eu-gdpr:A6-1-a ;
            ], [ # process stating location is also used to prevent fraud
                a dpv:Process ;
                dpv:hasPurpose dpv:FraudPreventionAndDetection ;
                dpv:hasPersonalData pd:Location ;
                dpv:hasProcessing dpv:Collect, dpv:Store, dpv:Use ;
                dpv:hasLegalBasis dpv:LegitimateInterest ;
                dpv:hasStorageLocation loc:EU ;
                dpv:hasRecipient ex:AcmeInc ;
            ] ;
        dpv:hasConsentControl [
            a dpv:ManageConsent ; 
            dct:title "Manage Consent"@en ;
            dpv:hasNoticeIcon ex:iconManageConsent ; 
        ], [ 
            a dpv:WithdrawConsent ;
            dpv:hasRight eu-gdpr:A7-3 ;  # asserts control includes a right
            dct:title "Withdraw Consent"@en ;
            dpv:hasNoticeIcon ex:iconWithdrawConsent ; 
        ] ;
        dpv:hasRight [
            a eu-gdpr:A20 ; # icon used to indicate rights exercise
            dct:title "Right to Data Portability"@en ;
            dpv:isExercisedAt "https://example.com/rights"^^xsd:anyURI ;
            dpv:hasNoticeIcon ex:iconExerciseRight ; 
        ] ;
        dpv:hasDataController ex:Company ;
        dpv:hasDataProcessor ex:AcmeInc ;
        dpv:hasApplicableLaw legal-eu:law-GDPR ;
        ] ;
    ] .

(META Example ID: E0072; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 73: Tracking the status of a Notice across its lifecycle

In this example, statuses associated with a notice are maintained in a record. The first part shows a notice status within a common process representing all users showing the notice has been communicated i.e. shown or delivered to the users. The second method shows a data processing record where the notice status is included as part of other matters e.g. data collection or rights exercise. The third method shows a record containing only the notice status for a specific user. The fourth method shows how the notice status can also be recorded as part of the notice metadata itself.

ex:ExampleNotice a dpv:Notice ; # a generic notice
    dpv:hasLocation "https://example.com"^^xsd:anyURI . # where notice will be shown

# Method 1: Notice has been communicated to all users
ex:SampleProcess1 a dpv:Process ;
    dpv:hasNotice ex:ExampleNotice ;
    dpv:hasDataSubject dpv:User ;
    # Method 1a: a notice is shown
    # Location is not in the status, but is in the notice
    dpv:hasNoticeStatus dpv:NoticeCommunicated ;
    # Method 1b: the latest notice version is used by the user
    # Location is included for where notice was provided
    dpv:hasNoticeStatus [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeCommunicated, dpv:NoticeLatest ;
        dpv:hasLocation "https://example.com/dashboard"^^xsd:anyURI ;
    ] .

# Method 2: Processing record per user with notice status
ex:Log1 a dpv:DataProcessingRecord ;
    dpv:hasDataSubject ex:Alice ;
    dpv:hasNotice ex:ExampleNotice ;
    dpv:hasNoticeStatus [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeCommunicated ;
        dct:date "2025-01-01"^^xsd:date ;
    ], [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeUsed, dpv:NoticeLatest ;
        dct:date "2025-01-02"^^xsd:date ;
    ] .

# Method 3: Record per user with only the notice status
ex:NoticeLog1 a dpv:DataProcessingRecord, dpv:NoticeStatus ;
    dpv:hasDataSubject ex:Alice ;
    dpv:hasNotice ex:ExampleNotice ;
    dpv:hasNoticeStatus [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeCommunicated ;
        dct:date "2025-01-01"^^xsd:date ;
    ], [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeUsed, dpv:NoticeLatest ;
        dct:date "2025-01-02"^^xsd:date ;
    ], [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeStale ;
        dct:date "2025-01-03"^^xsd:date ;
    ], [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeUpdated, dpv:NoticeLatest ;
        dct:date "2025-01-04"^^xsd:date ;
    ] .

# Method 4: Track notice lifcycle in the notice itself
ex:ExampleNotice a dpv:Notice ;
    dpv:hasNoticeStatus [
        a dpv:NoticeStatus ;
        skos:broader dpv:NoticeCommunicated ;
        dpv:hasLocation "https://example.com/"^^xsd:anyURI ;
        dct:date "2025-01-01"^^xsd:date ;
    ] .

(META Example ID: E0073; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 74: Expressing involvement of a 'human subject' in a process

This example shows how the involvement of humans can be expressed in various contexts. The first part shows how a specific individual can be asserted to be involved as a 'human subject' in some process. The second part shows how a process or service can assert the involvement of specific categories of humans as subjects. The third part shows how humans can be expressed to be involved in a specific role (as participants) and are declared to be vulnerable. The fourth part clarifies the distinction between stating involvement of users as humans for oversight, and as data subjects in relation to their personal data.

# 1) Expressing a person is a human subject (in some context)
ex:Alice a dpv:HumanSubject .
ex:SampleProcess dpv:hasHumanSubject ex:Alice .
# 2) Expressing some process or service involves human subjects
ex:Service dpv:hasHumanSubject dpv:Tourist .
ex:MedicalExperiment dpv:hasHumanSubject dpv:Patient .
# 3) Expressing human subjects involved are vulnerable
ex:MedicalTrial a dpv:Process ;
    dpv:hasHumanSubject [
        a dpv:HumanSubject ;
        skos:broader dpv:Participant, dpv:VulnerableHuman ;
        dct:description "Participating subjects who have condition X"@en ;
    ] .
# 4) Data Subjects is a specific role for Human Subjects
ex:DataProcess a dpv:Process ;
    # Human Subject only indicates involvement of the User as a Human
    dpv:hasHumanSubject dpv:User ;
    dpv:hasHumanInvolvement dpv:HumanInvolvementForOversight ;
    # Data Subject means the User is the 'subject of personal data'
    dpv:hasDataSubject dpv:User .

(META Example ID: E0074; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 75: Expressing involvement of tracking and profiling in processing

This example shows how the involvement of tracking and profiling can be expressed within a process. The first method simply states that tracking and profiling occur - this should be considered as bad practice as it does not clarify what the tracking and profiling involves in terms of data and entities - in particular what is being inferred as part of the profiling of data subjects. The second method is a verbose representation showing tracking is a composite process consisting of collecting and using location to generate a 'location tracking data' for the individual, which is then used in the profiling process to infer financial status of the individual.

Through the explicit details of data involved in tracking and profiling, the transparency and accountability principles are easier to satisfy, and we can additionally perform appropriate risk/impact assessments to analyse whether the tracking and profiling should be allowed or not. The verbosity also shows that tracking and profiling are two separate processes - which is essential when the same tracking or profiling occurs in more than one process. The last part shows how this verbosity can be reduced by taking the tracking and profiling (which as mentioned earlier are likely to be common to several processes) and assigning them a unique IRI or identifier, and using to indicate their involvement in a process.

# 1) Stating that tracking and profiling is involved (not good practice)
ex:Service a dpv:Service ;
    # Purpose missing - not good practice
    dpv:hasPersonalData pd:Location ;
    dpv:hasProcessing dpv:Tracking, dpv:Profiling .
# 2) Stating tracking and profiling specifics (good practice)
ex:Service a dpv:Service ;
    dpv:hasPurpose dpv:ServicePersonalisation ;
    dpv:hasProcessing [
        # Tracking based on location
        a dpv:Processing, dpv:Process ;
        skos:broader dpv:Tracking ;
        dpv:hasProcessing [
            a dpv:Processing ; # Collect Location
            skos:broader dpv:Collect, dpv:Use ;
            dpv:hasPersonalData pd:Location ;
        ], [
            a dpv:Processing ; # Generate Location tracking data
            skos:broader dpv:Generate, dpv:Store ;
            dpv:hasPersonalData ex:LocationTrackingData ;
        ] ;
    ], [
        # Profiling based on Location to infer Financial Status
        a dpv:Processing, dpv:Process ;
        skos:broader dpv:Profiling ;
        dpv:hasProcessing [
            a dpv:hasProcessing ; # Use tracked location
            skos:broader dpv:Use ;
            dpv:hasPersonalData ex:LocationTrackingData ;
        ], [
            a dpv:hasProcessing ; # Infer financial status
            skos:broader dpv:Infer, dpv:Store ;
            dpv:hasPersonalData pd:FinancialStatus ;
        ] ;
    ] .
# Refactored version of above where tracking and profiling are declared
# outside the process as ex:LocationTracking and ex:FinancialProfiling
ex:Service a dpv:Service ;
    dpv:hasPurpose dpv:ServicePersonalisation ;
    dpv:hasProcess ex:LocationTracking, ex:FinancialProfiling .

(META Example ID: E0075; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 76: Representing contract metadata and controls

The below example shows using [DCT] and DPV properties to represent metadata about contracts. [DCT] is used for generic properties such as titles and descriptions, as well as contract-specific properties such as when it was accepted by all parties and the provenance of the contract document. The DPV properties are useful to express properties such as entities involved in specific roles such as Service Provider or a Data Controller, and to denote the type of contract which is useful for its interpretation - such as whether it is a negotiated or a standard form (non-negotiated) contract.

ex:ServiceContract a dpv:LegalBasis ;
    skos:broader dpv:StandardFormContract, # pre-drafted contract with no negotiation
        dpv:B2BContract, # Business-to-Business
        dpv:ServiceLevelAgreement, # outlines use of service and quality/metrics
        dpv:ControllerProcessorAgreement ; # agreement between processor and controller
    dct:title "Contract for use of Cloud Service X"@en ;
    dct:created "2024-01-01"^^xsd:date ; # when contract was drafted
    dct:issued "2025-01-01"^^xsd:date ; # when contract was given to parties
    dct:creator ex:BetaInc ; # who drafted the contract
    dct:dateAccepted "2025-01-01"^^xsd:date ; # when all parties accepted it
    dpv:hasIdentifier "C240101" ; # identifier for the contract
    dct:language "en" ; # language of the contract
    dct:format [ # machine-readable version in ODRL
        dpv:hasLocation "https://example.com/C240101/ODRL"^^xsd:anyURI ;
        dct:conformsTo "http://www.w3.org/ns/odrl/2/"^^xsd:anyURI ;
    ], [ # human-readable version in English
        dpv:hasLocation "https://example.com/C240101/text"^^xsd:anyURI ;
        dct:language "en" ;
    ]
    dct:provenance [ # record for when entities signed the contract
        a dpv:RecordsOfActivities ;
        dct:hasPart [
            dpv:hasEntity ex:AcmeInc ;
            dct:dateAccepted "2025-01-01" ;
        ], [
            dpv:hasEntity ex:BetaInc ;
            dct:dateAccepted "2025-01-01" ;
        ] ;
    ] ;
    dct:subject ex:ServiceX ; # contract is about ServiceX by BetaInc
    dpv:hasDuration [ # duration of contract i.e. validity
        a dpv:TemporalDuration ;
        rdf:value "P1Y"^^xsd:date ; # 1year
    ], [
        a dpv:UntilEventDuration ; # OR a party ends it
        dct:description "A party terminates the contract"@en ;
    ] ;
    # Entities i.e. Parties involved in the contract
    dpv:hasEntity ex:AcmeInc, ex:BetaInc ;
    # Roles - Service Provider and Consumer
    dpv:hasServiceProvider ex:BetaInc ;
    dpv:hasServiceConsumer ex:AcmeInc ;
    # Roles - GDPR Data Controller and Processor
    dpv:hasDataController ex:AcmeInc ;
    dpv:hasDataProcessor ex:BetaInc ;
    dpv:hasApplicableLaw legal-eu:law-GDPR ;
    dpv:hasContractControl [
        a dpv:ContractControl ; # how to accept, refuse, or later terminate
        skos:broader dpv:AcceptContract, dpv:RefuseContract, dpv:TerminateContract ;
        dpv:isExercisedAt "https://example.com/C240101/manage"^^xsd:anyURI ;
    ] .

(META Example ID: E0076; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 77: Representing the status of contracts

This example shows how the lifecycle of a contract in terms of its drafting and acceptance, as well as the fulfilment of its requirements and whether they have been breached.

ex:SomeContract a dpv:Contract ;
    dpv:hasEntity ex:AcmeInc, ex:BetaInc ; # parties to the contract
    # 1) stating status of contract within the contract
    dpv:hasContractStatus dpv:ContractAccepted ;
    # 2) multiple statuses, and a timestamp for the event
    dpv:hasContractStatus [
        a dpv:ContractStatus ;
        skos:broader dpv:ContractDrafted, dpv:ContractOffered ;
        dct:date "2024-12-31"^^xsd:date ;
    ] ;
    # 3) status per entity - a type of provenance
    dpv:hasContractStatus [
        a dpv:ContractStatus ; # Acme received the contract and accepted it
        dpv:hasEntity ex:AcmeInc ;
        skos:broader dpv:ContractOfferReceived, dpv:ContractPartiallyAccepted;
        dct:date "2024-12-29"^^xsd:date ;
    ], [
        a dpv:ContractStatus ; # Beta received the contract and accepted it
        dpv:hasEntity ex:BetaInc ; # All parties have accepted the contract
        skos:broader dpv:ContractOfferReceived, dpv:ContractAccepted;
        dct:date "2024-12-30"^^xsd:date ;
    ], [
        a dpv:ContractStatus ;
        dpv:hasEntity ex:AcmeInc ; # Acme gets the completed/signed contract
        skos:broader dpv:ContractOfferReceived, dpv:ContractAccepted;
        dct:date "2024-12-31"^^xsd:date ;
    ] .

ex:SomeOtherContract a dpv:Contract ;
    # 1) Contract fulfilments are not complete, but no breaches either
    dpv:hasContractualFulfilmentStatus dpv:ContractUnfulfilled ;
    # 2) Contract is fulfilled - date recorded for event
    dpv:hasContractualFulfilmentStatus [
        a dpv:ContractStatus ;
        skos:broader dpv:ContractFulfilled ;
        dct:date "2024-12-31"^^xsd:date ;
    ] ;
    # 3) Contract breach - with date and justification
    dpv:hasContractualFulfilmentStatus [
        dpv:ContractBreached ;
        dct:date "2024-12-31"^^xsd:date ;
        dpv:hasJustification "explanation of the breach"@en ;
    ] .

(META Example ID: E0077; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 78: Representing clauses or terms within a contract

This example shows how specific clauses in a contract can be modelled, and also how their fulfilment status can be represented and tracked.

dpv:SomeContract a dpv:Contract ;
    dpv:hasContractualClause [
        a dpv:ContractualClause ; # types of clause - use one or many
        skos:broader dpv:ContractPreamble ;
        skos:broader dpv:ContractDefinitions ;
        skos:broader dpv:ContractJurisdictionClause ;
        rdf:value "Contents ..."@en ; # directly embed contents
        foaf:page "..."^^xsd:anyURI ; # URL
        dct:format "..."^^xsd:anyURI ; # different formats e.g. languages
        # Fulfilment status can be within the clause
        dpv:hasContractualFulfilmentStatus [
            a dpv:ContractStatus ;
            skos:broader dpv:ContractFulfilled ;
            dct:date "2024-12-31"^^xsd:date ;
        ] ;
    ] .
# OR, Fulfilment status can also be expressed per entity
# with a reference to a common clause or template
dpv:hasContractualFulfilmentStatus [
    a dpv:ContractStatus ;
    skos:broader dpv:ContractFulfilled ;
    dpv:hasContractualClause ex:SomeClause ;
    dpv:hasEntity ex:SomeEntity ;
    dct:date "2024-12-31"^^xsd:date ;
] .

(META Example ID: E0078; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 79: Stating status of Legal Obligations

This example shows how the status of using legal obligations can be represented in terms of it being carried out and it being completed. Note that though the legal obligation has been stated as 'completed', this is not an assessment of whether the requirements of the legal obligation have been completed and are verified, but instead the status represents the use of legal obligation as a legal basis within the process is completed.

ex:SomeProcess a dpv:Process ;
    dpv:hasLegalBasis [
        a dpv:LegalObligation ;
        dpv:hasApplicableLaw ex:CJA2010 ;
        # Method 1: ongoing status
        dpv:hasStatus dpv:LegalObligationOngoing ;
        # Method 2: completion status with date
        dpv:hasStatus [
            a dpv:LegalObligationStatus ;
            skos:broader dpv:LegalObligationCompleted ;
            dct:date "2024-12-31"^^xsd:date ;
        ] ;
    ] .

(META Example ID: E0079; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 80: Stating status of Legitimate Interest

This example shows how the status of using legitimate interests can be represented in terms of whether the existence and use of legitimate interest has been communicated to the data subject, and whether the data subject has objected to its use.

ex:SomeProcess a dpv:Process ;
    dpv:hasLegalBasis [
        a dpv:LegitimateInterestOfController ;
        dpv:hasJustification [
            a dpv:Justification ;
            dct:description "detect fraud as part of operations"@en ;
        ] ;
        # use of legitimate interest informed to data subjects
        dpv:hasStatus dpv:LegitimateInterestInformed ;
    ] .

ex:Log a dpv:LegitimateInterestStatus ;
    skos:broader dpv:LegitimateInterestObjected ;
    dpv:hasDataSubject ex:Alice ;
    dct:date "2024-12-31"^^xsd:date .

(META Example ID: E0080; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 81: Stating status of using Official Authority

This example shows how the status of using the official authority as the legal basis can be represented.

ex:SomeProcess a dpv:Process ;
    dpv:hasLegalBasis [
        a dpv:OfficialAuthorityOfController ;
        dpv:hasApplicableLaw ex:CJA2010 ; # law that gives authority
        dpv:hasDataController ex:AcmeInc ;
        # Method 1: status that authority is being utilised
        dpv:hasStatus dpv:OfficialAuthorityExerciseOngoing ;
        # Method 2: status with date
        dpv:hasStatus [
            a dpv:OfficialAuthorityExerciseStatus ;
            skos:broader dpv:OfficialAuthorityExerciseCompleted ;
            dct:date "2024-12-31"^^xsd:date ;
        ] ;
    ] .

(META Example ID: E0081; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 83: Stating status of using Vital Interest

This example shows how the status of using vital interest as the legal basis can be represented.

ex:SomeProcess a dpv:Process ;
    dpv:hasLegalBasis [
        a dpv:VitalInterestOfNaturalPerson ;
        dpv:hasJustification "what is the interest..."@en ;
        dpv:hasHumanSubject ex:Alice ; # whose vital interest it is
        # Method 1: Vital interest being utilised
        dpv:hasStatus dpv:VitalInterestOngoing ;
    ] .
ex:SomeProcess a dpv:Process ;
    dpv:hasLegalBasis [
        a dpv:VitalInterestOfDataSubject ;
        dpv:hasJustification "what is the interest..."@en ;
        dpv:hasDataSubject ex:Alice ; # whose vital interest it is
        # Method 2: status completed with date
        dpv:hasStatus [
            a dpv:VitalInterestStatus ;
            skos:broader dpv:VitalInterestCompleted ;
            dct:date "2024-12-31"^^xsd:date ;
        ] ;
    ] .

(META Example ID: E0083; link: source file; contributed by Harshvardhan J. Pandit on 2024-12-17)

Example 84: Stating status of Rule fulfilment

This example shows how the status of rules can be expressed in terms of their fulfilment or violation.

# Method 1) Rule and status in process
ex:SomeProcess a dpv:Process ;
    dpv:hasRule dpv:Obligation ;
    dpv:hasStatus dpv:ObligationFulfilled .

# Method 2) Rule with embedded status
ex:SomeProcess a dpv:Process ;
    dpv:hasRule [
        a dpv:Obligation ;
        dpv:hasStatus dpv:ObligationFulfilled ;
    ] .

# Method 3) Embedded status with date
ex:SomeProcess a dpv:Process ;
    dpv:hasRule [
        a dpv:Obligation ;
        dpv:hasStatus [
            a dpv:RuleFulfilmentStatus ;
            skos:broader dpv:ObligationFulfilled ;
            dct:date "2025-01-01"^^xsd:date ;
        ] ;
    ] .

# Method 4) Rule status per entity
ex:Log1 a dpv:RuleFulfilmentStatus ;
    skos:broader dpv:ObligationFulfilled ;
    dpv:hasEntity ex:AcmeInc ;
    dct:date "2025-01-01"^^xsd:date ;
ex:Log2 a dpv:RuleFulfilmentStatus ;
    skos:broader dpv:ObligationUnfulfilled ;
    dpv:hasEntity ex:BetaInc ; # as of this date
    dct:date "2025-01-01"^^xsd:date ;

(META Example ID: E0084; link: source file; contributed by Harshvardhan J. Pandit on 2025-01-01)

Example 85: Role of dpv:Processing and using it in dpv:Process

This example shows the myriad ways that processing could be used to describe other non-processing operation information such as personal data and entity involved. To accurately represent the information in a consistent and reusable manner, we recommend using dpv:Process as the way to combine concepts in to a 'unit' and to reuse this in other processes. This means dpv:Processing only specifies information about the processing operation involved, and optionally the technology being used if it is relevant to the context.

In Method 1, the processing instance contains personal data and entity involved - this is not recommended as the instance now contains information not related to the processing operation itself. Method 2 shows a processing instance which is implemented using a specific technology. This is acceptable as it describes the processing operation in terms of involved technology, and can be a way to reuse the processing operation in other processes while someone (e.g. IT department) can change the underlying technology. Method 3 represents the best practice of using dpv:Process to describe all concepts in a modular and granular manner with a separation of concerns. Processes can include other processes - so we can describe processing and technology and data involved as a process and involve it in other processes. This makes the task of finding information easier as we only have to look for composition of processes, instead of investigating each purpose or processing or another concept involved for what data or technology it involves.

# Method 1) Processing has non-processing concepts - not recommended
ex:SomeProcessing a dpv:Processing ;
    skos:broader dpv:Collect, dpv:Store ;
    dpv:hasPersonalData dpv:Location ;
    dpv:isImplementedUsingTechnology ex:SomeMethod ;
    dpv:isImplementedByEntity ex:AcmeInc .
ex:SomeProcess a dpv:Process ;
    dpv:hasProcessing ex:SomeProcessing .

# Method 2) Processing has implementing technology
ex:SomeProcessing a dpv:Processing ;
    skos:broader dpv:Collect, dpv:Store ;
    dpv:isImplementedUsingTechnology ex:SomeMethod ;
ex:SomeProcess a dpv:Process ;
    dpv:hasPersonalData pd:Location ;
    dpv:hasProcessing ex:SomeProcessing ;
    dpv:isImplementedByEntity ex:AcmeInc .

# Method 3) Processing only covers operations - best practice
ex:SomeProcessing a dpv:Processing ;
    skos:broader dpv:Collect, dpv:Store ;
ex:SomeProcess a dpv:Process ;
    dpv:hasPersonalData dpv:Location ;
    dpv:hasProcessing ex:SomeProcessing ;
    dpv:isImplementedByEntity ex:AcmeInc ;
    dpv:isImplementedUsingTechnology ex:SomeMethod .

# Composition of processes and processing
ex:AnotherProcess a dpv:Process ;
    dpv:hasProcess ex:SomeProcess ; # collect, store location by Acme
    dpv:hasProcess ex:SomeOtherProcess . # share location with Beta

(META Example ID: E0085; link: source file; contributed by Harshvardhan J. Pandit on 2025-01-01)

Example 86: Using Risk Controls to indicate measures adopted for a specific event

This example shows how risk controls can be used to represent the specific measures in place to detect, monitor, address, and inform stakeholders regarding risks, consequences, and impacts. The first part shows a risk with its associated consequence and resulting impact. The second part shows the process where this risk is present, and the specific controls put in place to: (1) monitor the process for vulnerabilities and avoid the source of risk with oversight,; (2) avoid the consequence event; and (3) monitor for occurence of the impact event, and if it occurs to halt it and to inform the affected person.

In this example the specific details of the control such as the technology being used, or what characteristics are changed when avoiding an event are not specified to reduce the length of content. To express this information, the specific control can reference two events as Risk and Residual Risk respectively - one which shows the initial values such as likelihood, and another one which shows the modified values. Currently the DPVCG does not dictate a specific method for expressing such information, and welcomes suggestions on best practices for the same.

ex:UnwantedEvent a dpv:Risk ;
    dpv:hasConsequence ex:UnwantedEffect .
ex:UnwantedEffect a dpv:Consequence ;
    dpv:hasConsequenceOn ex:SomeTechnicalSystem ;
    dpv:hasImpact ex:UnwantedEffectOnPerson .
ex:UnwantedEffectOnPerson a dpv:Impact ;
    dpv:hasImpactOn ex:SomePerson .

ex:SomeProcess a dpv:Process ;
  dpv:hasRisk ex:UnwantedEvent ;
  risk:hasControl [
    a risk:RiskControl ;
    a risk:AvoidSource, risk:MonitorVulnerabilities, risk:OversightControl ;
  ] ;
  risk:hasControl [
    a risk:RiskControl ;
    a risk:DetectionControl, risk:ContaimmentControl, risk:LoggingControl ;
    risk:detects ex:UnwantedEvent ; # detect risk occuring
    risk:contains ex:UnwantedEvent ; # if it occurs, contain it
    risk:logs ex:UnwantedEvent ; # record it occurred
  ] ;
  risk:hasControl [
    a risk:RiskControl ;
    a risk:AvoidConsequence ; # specifically avoid consequence event 
    risk:avoids ex:UnwantedEffect ; # try to prevent consequence
  ] ;
  risk:hasControl [
    a risk:RiskControl ;
    a risk:ImpactControl ; # specifically control the impact event
    a risk:MonitorImpact, risk:TransparencyControl, risk:HaltImpact ;
    risk:monitors ex:UnwantedEffectOnPerson ; # monitors for event
    risk:halts ex:UnwantedEvent ; # halts the event
    dpv:hasNotice [ # informs the person about it
        a dpv:SecurityIncidentNotice ;
        dpv:hasRecipient ex:SomePerson ;
    ] ;
  ] .

(META Example ID: E0086; link: source file; contributed by Harshvardhan J. Pandit on 2025-01-12)

Example 87: Flexibility of RISK taxonomy in expressing varying roles

This example shows how the same concept risk:DataBreach can take on different roles across contexts. The first part shows data breach as a consequence of a malware attack, while the second part shows it as a risk source which could lead to identity fraud and misuse. In these, the same concept of data breach being a consequence or a risk source is context-dependant. The RISK extension does not specify or assert that a data breach is always a risk source or risk or consequence - only that it has the potential to be these things. Therefore, inclusion of RISK extension in the graph does not 'pollute' it or cause misinterpretations such as data breach showing up as a consequence even though it has been asserted to (only) be a risk source.

The third part shows how these different roles are associated with the concept, and how this can be used in UI/UX to provide users with a list of options for selecting risks. It also shows the distinction between marking or annotating a concept to include it in risk identification process (risk:PotentialRisk) and asserting that the concept is applicable as a risk in a process (dpv:hasRisk). This allows use-cases to directly use the RISK extension's subjective classification of concepts in UI/UX - such as to populate the dropdown of risks, and also provides flexibility to ignore that and create their own thesauri or categorisations by using the risk:PotentialRisk concept to annotate concepts, or to create specific subclasses for contextual classifications.

# Part 1: Data Breach as a consequence
ex:ProcessA a dpv:Process ;
    risk:hasRiskSource risk:MalwareAttack ;
    dpv:hasRisk risk:UnauthorisedDataAccess ;
    dpv:hasConsequence risk:DataBreach . # <-- same concept as consequence

# Part 2: Data Breach as a risk source
ex:ProcessB a dpv:Process ;
    risk:hasRiskSource risk:DataBreach ; # <-- same concept as risk source
    dpv:hasRisk risk:IdentityFraud ;
    dpv:hasConsequence risk:IntentionalMisuse ;
    dpv:hasImpact risk:RightsImpact .

# Part 3: Creating a UI/UX for selecting consequences
# RISK extension contains:
risk:DataBreach a risk:PotentialRisk. # potential to be a risk 
risk:DataBreach a risk:PotentialConsequence . # potential to be a consequence
# UI/UX contains HTML dropdown showing risks to select from
<select id="risks"></select>
# The options in <select> are populated using the query over RISK extension
SELECT ?concept { ?concept a risk:PotentialRisk . }
# This gives
<select id="risks">
	<option value="...">...</option>
	<option value="risk:DataBreach">Data Breach</option>
</select>
# User selects risk:DataBreach, which is then recorded in the data
ex:SomeProcess a dpv:Process ;
	dpv:hasRisk risk:DataBreach .

(META Example ID: E0087; link: source file; contributed by Harshvardhan J. Pandit on 2025-01-12)

Example 88: Expressing impact on specific rights

To express a specific right has been impacted, the relevant rights impact concept is utilised along with a rights impact category from the RISK extension, which together indicate a right is being impacted in the specified manner. In this example, a customer of a company has complained that their GDPR rights have been violated. Upon investigation, it was found that the GDPR's Transparency Right (Article 13) was impacted by limiting the scope of the right as not all processing was represented, and further the right was obstructed as it was not easy to obtain the information on the website.

ex:SubmittedComplaint a dpv:Process ;
  dpv:hasImpact eu-gdpr:GDPRRightsImpact, risk:RightsViolated  ;
  dct:description "Customer complaint: GDPR rights have been violated"@en .

ex:InvestigatedComplaint a dpv:Process ;
  dct:subject ex:SubmittedComplaint ;
  dpv:hasImpact [
    a eu-gdpr:A13-Limited ;
    dct:description "The privacy notice did not provide all information"@en ;
    ] ;
  dpv:hasImpact [
    a eu-gdpr:A13-Obstructed ;
    dct:description "The privacy notice was not easy to find on website"@en ;
    ] .

(META Example ID: E0088; link: source file; contributed by Harshvardhan J. Pandit on 2025-01-12)

`:`	`<<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#>`

Examples for Data Privacy Vocabulary

for Data Privacy Vocabulary (DPV)

Abstract

Status of This Document

1. Vocabulary

1.1 Conformance

1.2 Example

2. Examples

2.1 E0001: Implications of using SKOS vs OWL

2.2 E0002: Extending concepts to represent use-case specific information

2.3 E0003: Extending multiple concepts

2.4 E0004: Interoperability of extended concepts across use-cases

2.5 E0005: Process used to combine core concepts and represent an use-case

2.6 E0006: Nesting Processes

2.7 E0007: Extending Purposes and adding human-readable descriptions

2.8 E0008: Using NACE codes to restrict Purposes

2.9 E0009: Derivation and inference of personal data

2.10 E0010: Indicating personal data is sensitive or special category

2.11 E0011: Indicating Storage Conditions

2.12 E0012: Indicating Data Sources

2.13 E0013: Spam filter as Automated Decision Making with Human Involvement

2.14 E0014: Denoting Legal Basis within a Process

2.15 E0015: Indicating consent as a legal basis

2.16 E0016: Indicating details about an individual's consent

2.17 E0017: Representing notice, provision, expiry, and withdrawal information for consent

2.18 E0018: Using consent types

2.19 E0019: Indicating Entity Information, including DPO and Representatives

2.20 E0020: Using technical measure: Protecting data using encryption and access control

2.21 E0021: Using organisational measure: Indicating staff training for use of Credentials

2.22 E0022: Privacy Notice used in an activity

2.23 E0023: Consent record example

2.24 E0024: Controller-Processor agreement denoting processing to be carried out

2.25 E0025: Data transfer safeguards

2.26 E0026: Example of Contextual Necessity

2.27 E0027: Indicating risks, consequences, and impacts

2.28 E0028: Rule specifying permission

2.29 E0029: Rule specifying prohibition

2.30 E0030: Rule combining DPV with ODRL

2.31 E0031: Using Service to group related processes

2.32 E0032: Indicating Controller identity and details of representative

2.33 E0033: Indicating Processor as the implementing entity in a process

2.34 E0034: Specifying recipients of data

2.35 E0035: Specifying data exporters and importers

2.36 E0036: Indicate relevant authority for processing

2.37 E0037: Indicating type of organisation and involvement of specific orgnisational units

2.38 E0038: Indicating subsidiaries of an organisation

2.39 E0039: Indicating involvement of data subjects

2.40 E0040: Extending a purpose and using human-readable descriptions

2.41 E0041: Indicating purposes associated with a Service

2.42 E0042: Indicating legal compliance as a purpose along with the relevant law

2.43 E0043: Indicating sector or domain and associating it with a purpose

2.44 E0044: Specifying personal data

2.45 E0045: Indicating data belongs to sensitive or special category

2.46 E0046: Indicating data being collected and derived

2.47 E0047: Indicating processing conditions for duration and location

2.48 E0048: Indicating storage conditions for duration, location, deletion, and restoration

2.49 E0049: Indicating data volume, geo-location coverage, data subject scale, and a processing scale

2.50 E0050: Specifying duration

2.51 E0051: Specifying frequency

2.52 E0052: Specifying necessity and importance in context

2.53 E0053: Specifying applicability of information

2.54 E0054: Specifying status associated with activities

2.55 E0055: Specifying compliance status and lawfulness

2.56 E0056: Specifying the audit status associated with a DPIA

2.57 E0057: Expressing GDPR Right to Data Portability could not be fulfilled due to Identity Verification failure

2.58 E0058: Expressing a right exercise request is delayed due to high volume of requests

2.59 E0059: Exercising the right to rectification with contesting accuracy of information as justification

2.60 E0060: Specifying the location of a process

2.61 E0061: Associating justifications with right exercise non-fulfilment

2.62 E0062: Using justifications across categories

2.63 E0063: Expressing data breach notifications to data subjects are not required using a justification

2.64 E0064: Indicating use of a technical measure and its implementation

2.65 E0065: Specifying legitimate interest of a controller

2.66 E0066: Specifying permissions and prohibitions

2.67 E0067: Indicating applicable rights

2.68 E0068: Using DPV and RISK extension to represent risks

2.69 E0069: Using DPV and RISK extension to represent incidents

2.70 E0070: Indicating personal data involved in an incident

2.71 E0071: Using risk controls to express how tech/org measures address the risk

2.72 E0072: Using Notice Layer and Icon in a Consent Notice