- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Wed, 28 Oct 2020 17:40:47 +0000
- To: besteves@delicias.dia.fi.upm.es, Paul Ryan <paul.ryan76@mail.dcu.ie>
- Cc: Rob Brennan <rob.brennan@dcu.ie>, public-dpvcg@w3.org
Hi Beatriz, All. I agree in principle the value of representing obligations, but I have concerns on how we specify them within DPV itself, and what it means for someone using DPV. On 28/10/2020 16:16, besteves@delicias.dia.fi.upm.es wrote: > IMO we should add the concept of obligations to DPV and specify the ones under GDPR on the DPV-GDPR vocabulary (similar to what I proposed for the data subject's rights). We can - as and when we get consensus (and validation from a legal expert) on what the obligations are. For a start, listing obligations out as concepts itself is tricky, and then further associating them with relevant concepts (e.g. purpose, legal basis) is complex. > > And, off course, the Register of Processing Activities should be one of the legal obligations of the data controllers & processors under the GDPR. This is where there are differing views, and we need to be careful what we specify them as. A concept (e.g. ROPA) vs an obligation (e.g. maintaining a ROPA) are semantically different. Do we specify an obligation as a concept: MaintainROPA or as a rule: isController(X) --> maintain(ROPA) > In addition to ROPA, I would also like to propose the addition of the following obligations (some of them you already discuss on your paper): > > https://docs.google.com/spreadsheets/d/1FH44UTfmMxrdYUwF0OPlAKDNarUtx7GAtAA5wtLUPPQ/edit?usp=sharing > Some of these (Joint Controller, DPIA) I think we already have as proposed. Some others are dependant on concepts that must first be present e.g. communication of data breach --> data breach. Regards, -- --- Harshvardhan J. Pandit, Ph.D Research Fellow ADAPT Centre, Trinity College Dublin https://harshp.com/
Received on Wednesday, 28 October 2020 17:41:42 UTC