Meeting minutes
previous minutes - https://
Joint Controllers
previous discussions were regarding using plural vs singular i.e. controller(s)
paul: should be plural i.e. controllers
Agreement on using plural, the concept will be JointDataControllers
previous discussions about how to refer to joint data controllers were about subclassing it from DataController and using hasDataController
Use-case for discussion - Two DataController A and B are engaged in a JointDataControllers relationship AB. One could specify multiple hasDataController [A,B] which would make them JointDataControllers or explicitly say hasDataController AB and indicate AB hasDataController [A,B]
Agreement on JointDataControllers as a concept and its use within DPV
Indicating who carries out the data processing
georg: In a personal data handling instance, how to specify who is carrying out the processing, i.e. DataController or DataProcessor
We have <x hasRecipient Recipient> as the current way to indicate data goes to some entity, and it is implied that the entity then carries out processing for specified information
However, sometimes it is important to explicitly indicate which entity is carrying out the processing and not just being a recipient for it.
Proposal for a property "isProcessedBy" with range Entity to indicate who carried out processing. Since receiving data / collecting data is a type of processing, it will fall under isProcessedBy ?
The property can be used at appropriate 'levels' as necessary e.g. directly on Processing types such as collect or use, on PersonalDataHandling instances, or for annotating Policy instances
To be revisited in later discussion for finalising
Referencing Agreement between Data Controller and Data Processor
A DataController engages a DataProcessor under a DataProcessorAgreement which outlines the instructions and obligations for carrying out processing.
How to reference this agreement within the personal data handling use e.g. hasDataController A [as DataController] ; isProcessedBy B [as DataProcessor] ; and A--B has some agreement
Current proposal puts the DataProcessorAgreement under TechnicalOrganisationalMeasure given its derivation from LegalAgreement
paul: The placement of DataProcessorAgreement under TechnicalOrganisationalMeasure does not seem correct or elegant since its not an organisational measure
harsh: we have two ways of using this, one is creating a property called "hasEntity" and using that to associate entities with agreements (and elsewhere as necessary) - which works when representing the Controller--Processor relationship from a third party perspective
harsh: The second one is from a Processor perspective the agreement is its legal basis, so using hasLegalBasis ; and for the Controller it is also the legal basis so using hasLegalBasis ; and both pointing to the DataProcessorAgreement instance
harsh: For the Controller using this in a PersonalDataHandling instance, the use could be something like hasTechnicalOrganisationalMeasure DataProcessorAgreement with the DataProcessorAgreement using hasEntity or hasDataController to connect to the entity with type and role
Entity and Data Subject Subclasses
julian: The discussion of these concepts arose from prior proposals, and it should be considered whether to include them all in an ad-hoc manner within the DPV or only those that add value - such as due to there being obligations or requirements associated with them from laws or domains
Consensus on adding only those concepts which are necessary to be modelled based on requirements
For entities and organisations, the ADMS vocabulary provided some categorisation such as National/Regional/SupraNational authorities which we propose for inclusion
ADMS itself is a mix of different concepts, so inclusion of a few here would be better
Next Meeting
We will meet next WED NOV-24 13:00 WET / 14:00 CET
Discussion will continue regarding Entity and Data Subject subclasses and other items on agenda
There may be a guest presentation by DPVCG member Fajar on use of DPV within the WELLFORT project. Details and timings TBD.