Meeting minutes
DPV serialisations
DPV is a specification that describes its data model as concepts and relationships. Formally expressed using SKOS.
DPV-SKOS is serialisation of DPV spec in SKOS+RDFS. DPV-OWL is serialisation of DPV spec in OWL2.
Existing adopters can change IRI / move to either DPV-SKOS or DPV-OWL as needed.
This allows alternate expressions of DPV (e.g. using a different interpretation in OWL, or in UML, BPMN, etc.)
This is similar to PROV family of documents https://
No comments or objections.
DPV Namespaces
Currently, we have namespaces on w3.org (dpv, dpv-gdpr, dpv-nace).
However updating and maintaining is taking an (unforseeable) amount of time. Suggestion is to move to w3id.org to have better and quicker control for using these.
'Core' Activities as mentioned in GDPR Art.37
GDPR Art.37 mentions 'core' activities as one of the relevant criteria for appointing a DPO. The Cyprus DPA in their ROPA guidance and template has suggested indicating this information as well. How do we model this in DPV?
Proposal by harsh and paul is to have this expressed as 'Core Purpose' and 'Auxiliary Purpose' for categories of purpose. The argument is that the concept of 'core activity' is relevant to DPV's Purpose of PersonalDataHandling, and that associating it with Purpose would be better for saying a purpose is 'core' or not.
The Article 29 Working Party Guidelines on Data Protection Officers ('DPOs') (wp243rev.01) - endorsed by EDPB https://
Discussion on what it means for something to be 'core', where to associate it within DPV, how it is to be used.
Terms considered -> core, auxiliary, ancillary, required, optional, necessary, main, primary, secondary
Relevant discussion on how to express something is *necessary* or *optional* e.g. personal data is optional.
Relevant discussion on how to express something is *not being done* or *will not be done* - terms discussed include prohibition, assertion, negation, dispensible.
---
Conclusion of discussion
We have `Necessity` as subtype of `Context` with `Required`, `Optional`, and `NotRequired` as three levels of necessity.
We have `Importance` as subtype of `Context` with `PrimaryImportance` and `SecondaryImportance` as indicative of how 'essential' or 'core' something is.
These can be used at any level as required - for personal data, personal data handling, purpose, etc.
Next Meeting
We will meet again in a week's time at 13:00 WET / 14:00 CET
We will continue discussion on proposed terms from the spreadsheet and other items on the agenda.