W3C

– DRAFT –
DPVCG Meeting Call

10 NOV 2021

Attendees

Present
:, beatriz, georg, harsh, julian, mark, paul
Regrets
-
Chair
harsh
Scribe
harsh

Meeting minutes

Data Subject Rights

georg: DPV does not have a good expression of rights (affirmed by paul), it can better the descriptions for where the rights apply and what is involved

harsh: currently, we have the ability to say a certain right is applicable to given context e.g. personal data handling has rights

georg: information about when rights apply and what is involved under the right

harsh: we looked at this sometime earlier, with the discussion concluding that there isn't a clear or simple way and it gets complex when dealing with non-GDPR rights

georg: for example, Right of Access is applicable to information provided by data subject etc.

harsh: gets very complex for other rights, e.g. right to forget

beatriz: have modeled rights in GDPR paper (under review sem-web journal) where we used ODRL to represent the right and what is involved e.g. information to be provided

beatriz: also contains informations about what information needs to be provided under each right

beatriz: see work at https://protect.oeg.fi.upm.es/sota/gdprif

beatriz: the information helps controllers specify where the right is applicable or is triggered by

beatriz: the ODRL CG/WG organises workshops where a collaboration with DPV can be established to work on obligations as a use-case

harsh: there is related work by Sushant / Sabrina using ODRL and Sabrina / Vos / Satoh regarding further modeling of rules and obligations ; as well as the DAPRECO KG

mark: there's also MIT data rights roundtable https://www-prod.media.mit.edu/articles/data-rights-roundtable-with-mit-media-lab/

georg: having information on how to exercise a right is beneficial e.g. contact via email or social media

harsh: we can add a property to express 'exercised_by' but is this sufficient and correct? Needs more investigation.

harsh: we table this as of interest for now, and invite specific proposals to continue discussion at later date

Joint Controllers

harsh: proposal is to have concept JointDataControllers representing the group of Data Controllers as a single instance to indicate it shares the responsibilities of a controller and that it comprises of more than one entity

harsh: the relation hasDataController will continue to point to data controller as well as joint controllers to enable simplicity in expressing who is responsible

georg: how to distinguish which controller is doing what in the joint controllers relationship?

harsh: separate personal data handling instances for each controller, and another one for the joint controller (representing combined attributes)

harsh: in earlier discussions, we also discussed the possibility to express multiple data controllers in an use-case, thereby automatically making them joint controllers. However, this does not state the relationship explicitly, and does not allow for expressing the agreement between the two (e.g. JointDataControllersAgreement). Hence the need for this concept.

paul: Should this be singular e.g. JointDataController or plural given that it is a single entity / instance when modelling it in DPV?

harsh: GDPR mentions plural (A.26 Joint Controllers), so the wording here reflects that

Next Meeting

We will meet again next week at usual time - NOV-17 13:00 WET / 14:00 CEST

We will continue discussion on these topics / agenda

Minutes manually created (not a transcript), formatted by scribe.perl version 159 (Fri Nov 5 17:37:14 2021 UTC).