Meeting minutes
dpv-legal external vocabs
Bert Van Nuffelen suggested using EU vocabularies as an authoritative source for concepts currently in DPV-LEGAL. Namely countries and EU membership.
See https://
Given that the EU vocabularies are authoritative and well-maintained, we decide to remove these concepts from DPV-LEGAL and use the ones from EU instead.
This means rewriting most of concepts to use EUvoc IRIs, e.g. for expressing laws and authorities and other sources.
If there are other authoritative vocabularies, then alignment is simple given that they all use ISO 3166 codes for countries.
ISO 27560 Consent Record
The standard is closing towards stability, with an expected publication date of June 2023.
Once the schema is relatively stable and consensus is reached, DPV will provide a guide on creating consent records based on 27560, along with providing the relevant 'schema' and vocabulary.
An example of how using DPV can be used for the current draft is here - https://
Rules
We discussed the need (and limitation) for simple mechanisms to express rules over DPV defined information.
The proposal is to have `hasRule` as a relation that takes a target `Rule`, which may be of type `Permission`, `Prohibition`, and `Obligation`. For anything more, we refer to external vocabularies such as ODRL.
These rules can be associated with any /block/ such as PDH's. If they have to be applied over single concepts, e.g. to say data category Identifier is prohibited, then it is tricky to express this.
Because using triple notations, there are two sets of information here - 1) `hasPersonalData Identifier`; and 2) `hasRule Prohibited`.
Alternative is to provide specific relations, e.g. as `hasProhibition [ hasPersonalData Identifier ]` - which is still the same solution with a less elegant expression, no explicit notation of the /rule/, and requires creating such relations for every type of rule.
Paul has asked for examples (e.g. mailing list) for how the proposed rule expression will work. The next meeting will discuss the examples and decide on rule expression.
Right Exercise
Rights can be of two types - `ActiveRight` which means some action must be taken to exercise it, and `PassiveRight` which means no action needs to be taken as it is always under exercise.
Examples are GDPR (D)SAR or Data Portability being active rights, while right to privacy is a passive (and fundamental) right.
We therefore focus on how to exercise active rights.
georg raised an interesting question - if some information is needed to exercise right, this should be indicated in the notice/record. The appropriate legal basis for this would be legal obligation.
We discussed the use-cases for rights, and tried to identify the key information / concepts.
We have `Right` and `hasRight` in DPV. We need a way to indicate how/where to exercise that right.
This can be through a relation `isExercisedAt` that points to some resource or link where the right exercise can be requested or performed.
To express what is needed for this, such as some information (e.g. email) or technical measure (e.g. authentication) - a PDH instance can be used which provides the framework for describing purposes, processing, personal data, entities associated.
To indicate who made the request, which may not always be the data subject but an authorised party, the relations `isMadeBy` and `isMadeTo` were discussed.
Note - we have `isIndicatedBy` which can be reused here with a complement as `isIndicatedTo`
To indicate the data subject whose right is being exercised, the existing `hasDataSubject` can be used. As with consent, it may not be necessary to always duplicate informatoin on who indicated and who the data subject if they are the same.
A single access point for rights can handle multiple rights. This can be indicated by using `hasRight` with all the rights.
To indicate the scope of the request, e.g. a specific purpose or personal data, or a temporal duration, `hasScope` and `Scope` can be used.
An open question is how to express the authorisation (relation or information) between Data Subject and the request initiator. We may need to establish a way for these relationships and information.
Rights exercises have stages/events. There is a request by the data subject, then an acknowledgement by the controller, then a response.
Response may be successul exercise of the right, and may contain additional information and/or actions such as download data or view a page.
Response may be failure to exercise right with justification, or an intermediary stage asking for more information or authentication.
An open question for requests - how to express data should be in a specific format, e.g. PDF.
An open question - how to express where information should be communicated, e.g. via emails.
We will circulate ideas/proposals/discussions via the mailing list, and take this up again next week.
Next meeting
We will meet again in 1 week, on OCT-15 13:00 WEST / 14:00 CEST.
Topics will be Rules and Rights Exercise, with other items on agenda and AOB.