This document will provide a guide for using DPV for Rights Exercise and Management. Currently, it is a work in progress.

Overview

This document provides guidelines and examples to express information about

• associating personal data processes with applicable rights
• notifying rights-related activities
• recording rights being exercised

Namespaces

Associating processes with rights

This section outlines how to indicate existing applicable data subject rights associated with a process, using DPV and the EU GDPR extension to represent rights available under the GDPR.

A process can be used to express information regarding the what, how, where, who, and why personal data is being processed, as well as what rights exist. For indicating applicable GDPR rights, DPV's EU GDPR extension provides a mapping between legal bases and the applicable data subject rights. This pattern can be followed by data controllers to express which rights are applicable, including rights beyond the ones in the GDPR, e.g., EU's fundamental rights and the rights depicted in other EU regulations or in other jurisdictions.

Notifying rights-related activities

This section outlines how to provide notices related with rights exercising management. Generic right notices can be provided to indicate which rights exist, when and where they are applicable, and other relevant information. Notices can be associated with specific processes or activities using the hasNotice property. dcterms:issued and dcterms:valid can be used to indicate temporal information related to notices, i.e., when it was issued and until when it is valid. Descriptions and identifiers of the notices and their creators/publishers can be recorded using DCMI Metadata Terms. The notices should also include information about the data controller as well as the entity implementing the notice, which can be the data controller or another entity acting on behalf of the data controller, using dpv:hasDataController and dpv:isImplementedByEntity, respectively. foaf:page can be used to indicate a document, e.g., Webpage, containing the contents of the notice and further functionalities.

Right exercise notices should be used to notify data subjects on where and how to exercise an active right, which information is required, or to provide updates on an exercised right request. Beyond the previously mentioned properties, DPV's isExercisedAt property can be used to associate rights with specific right exercise points, i.e., through right exercise notices, and information required to exercise a right through the association with a process, using DPV's hasProcess property. The hasRecipient, hasStatus, and hasJustification properties can be used to provide updates to the data subject on the status of a specific right exercising activity, including a justification to why such right is being exercised.

Specific notices to inform of the fulfilment, towards fulfilment or about the non-fulfilment of a right are also provided. Required actions that need to be performed by entities towards the fulfilment of a certain rights-related request, that cannot be sufficiently detailed using DPV, e.g., issuance of payment terms, can be attached to notices using policy languages such as Open Digital Rights Language (ODRL). The period of time the entities have to execute the required actions can also be expressed using ODRL constraints and/or can be included in the notices using DPV's Duration concepts.

For GDPR-specific notices, the EU GDPR extension provides concepts for direct and indirect data collection notices, required by GDPR's Articles 13 and 14, respectively, Subject Access Request (SAR) notices to fulfil GDPR Right of Access, and recipient notices to fulfil GDPR's Art.19 notification requirements, regarding the recipients to whom a rights exercise has been communicated, such as the right to rectification (Art.16), right to erasure (Art.17) or right to restriction of processing (Art.18).

In the case of GDPR's Articles 13 and 14, the data subject should be notified of the identity and contacts of the data controller and of the controller's representative if applicable, as well as receive notice of the contact details of the controller's data protection officer. The notice should also include the purposes and legal basis for data processing, and, in case such basis is the legitimate interests pursued by the controller or by a third party, said interests should be specified. Data subjects should also be made aware of any recipients or categories of recipients of the personal data, and, if applicable, about transfers of personal data to a third country or international organisation, including the existence or absence of an adequacy decision for said country and applicable safeguards. Furthermore, data subjects should be notified with regards to the data storage period, as well as their existing rights, namely the rights to withdraw consent and to lodge a complaint and the rights of access, rectification, erasure, restriction of processing, object and data portability. In case the provision of personal data is necessary for statutory or contractual obligations or there is automated decision-making, it should also be disclosed to the data subject. Beyond the previously mentioned information, GDPR's Article 14 also requires the data subject to be notified about processed categories of data and their respective sources.

In the case of the SAR notice, a DPV process can be used to notify the data subject about the type of personal data being processed, the purpose for the processing, and to which recipients it was disclosed. The storage period of the data is also indicated, as well as the existence of other data subject rights and the source of the data if not collected from the data subject. In case there is automated decision-making, it should also be disclosed to the data subject.

Recording rights being exercised

This section outlines the information that needs to be recorded and maintained when a concrete instance of a right was or is being exercised. Keeping such records is of interest to data controllers to have machine-readable information about the status and fulfillment of requests, which can be used, e.g., by auditors. To represent concrete records of rights being exercised, the RightExerciseRecord concept, a subclass of DPV's Record, can be used to associate a particular request, or even distinct requests from the same data subject, with corresponding activities exercised by entities towards fulfilling such requests, modelled as RightExerciseActivity.

Rights exercise activities

A RightExerciseActivity represents an instantiation of an activity being performed towards the exercising of a right. Such activity instances should include metadata, e.g., timestamps, duration, or involved entities, to track the provenance of a particular right exercising process, from the request itself to its acknowledgement by the data controller and to the fulfilment or non-fulfilment of the right. For easy record-keeping, each activity should be modelled as a RightExerciseActivity instance, which can be connected with other instances using DPV's isBefore and isAfter concepts.

In order to justify a certain right exercise activity, DPV contains a Justification extension to "enable representing specific justifications associated with non-fulfilment, non-requirement, delays, and exercising reasons involved in processes", which can be used to justify the non-fulfilment, non-requirement, delays, and exercising of rights.

          ex:RightExerciseActivity a dpv:RightExerciseActivity ;
              ...
              dpv:hasJustification ex:Justification .

          ex:Justification a justifications:FreedomOfExpressionImpaired ;
              dcterms:source "GDPR Article 17.3(a)"^^xsd:string .
      

Additionally, to track the status of rights exercising activities, DPV's RequestStatus concepts, including RequestAccepted for a request being accepted towards fulfilment, RequestRejected for a request being rejected towards non-fulfilment or RequestRequiresAction for a request requiring an action to be performed from another party. Figure 1 illustrates the sequence in which these concepts occur. Once the request is initiated, it should be then acknowledged by the entity implementing it and either accepted towards fulfilment or rejected towards non-fulfilment. Additionally, after being rejected, the entity fulfilling the request can also require further action from the requester (e.g., request additional data to be able to fulfil the request), which can delay the acceptance or rejection of the request, and after the required action is performed, the request can either be accepted towards fulfilment or get rejected again towards non-fulfilment or towards asking again for further action.

DPV's concepts can be used in conjunction with the W3C's PROV-O recommendation to track the provenance of a right exercising activity instance. Using this standard, provenance information, regarding the entities whom the activity is associated with, i.e., prov:wasAssociatedWith, or what data/notice was generated, i.e., prov:generated, by the right exercise activity, can be represented. prov:actedOnBehalfOf can also be used to represent delegation or representation, for instance when a parent exercises a right on behalf of its child. Similarly to notices, temporal information, descriptions and identifiers of the activities and their creators/publishers can be recorded using DCMI Metadata Terms.

In this section, we include examples of rights exercising activities covering the lifecycle of statuses of requests, using an exercised GDPR right of access as an example.

In this latest example, a SAR notice is not included as Section 3 already includes a set of modelled notices, including an example of a modelled SAR Notice.

Moreover, DCAT can be used to model resources beyond notices, for instance, a copy of the personal data, which is required in both GDPR's access and data portability rights. DCAT promotes the usage of the properties such as dcterms:format, dcterms:valid, and dcat:landingPage to include information regarding the format, validity and dataset provision location, respectively, to characterize the dataset in question. Additionally, DCAT promotes the usage of ODRL to express license and rights statements, by linking the dataset with an ODRL policy using the odrl:hasPolicy property, or the usage of DCMI Metadata Terms' license, accessRights or rights properties to link datasets with licenses, access rights statements or other types of rights statements, e.g., copyrights, respectively. The latter can be used to express 'high-level' access control statements, e.g., embargoed, restricted or open access, while the former has the advantage of also being a W3C Recommendation, for policy expression, which provides a model to represent complex policies and an easy mechanism to extend its model to cover other use cases.

In this Section, the GDPR's Right of Access is used as an example to showcase how to model right exercising activities using DPV, DCMI Metadata Terms, PROV-O and DCAT. However, a similar pattern can be followed by data controllers to fulfil the other rights as in most cases the only substantial change would be the notice concept that needs to be used for a particular right instance, e.g., eu-gdpr:DirectDataCollectionNotice for the right fulfilment notice related to GDPR's Article 13, eu-gdpr:IndirectDataCollectionNotice for the right fulfilment notice related to GDPR's Article 14 or eu-gdpr:RightsRecipientsNotice for the right fulfilment notice related to GDPR's Article 19. Additionally, the proposed model for right exercising activities is generic enough to support the representation of rights from other jurisdictions and can be easily extended if the need arises.

Rights exercise records

As previously mentioned, RightExerciseRecords can be used to associate a particular request, or even distinct requests from the same data subject, with corresponding activities exercised by entities towards the fulfilment or non-fulfilment of such requests, e.g., using the dcterms:hasPart property.

For integration with DCAT-based systems, right exercise records can also adapt DCAT's standard to represent data catalogs - a right exercise record can also be modelled as a dcat:Catalog and right exercise activities as dcat:Resources, which can be bundled and ordered using dcat:DatasetSeries. This also brings the advantage of using DCAT's ordering properties, i.e., dcat:first, dcat:last, and dcat:prev, to retrieve the latest activity related to a particular rights-related request.