Meeting minutes
DPV v0.5 published
This version contains concepts accepted until 02 APR
It also contains the DPV-LEGAL extension that provides locations as jurisdictions, along with laws and authorities, and models EU-EEA memberships and EU Adequacy decisions
Data Subject Categories
Concepts accepted as subclasses of `DataSubject` -> `Patient`, `Employee`, `Student`, `Citizen`, `NonCitizen`, `Immigrant`, `Tourist`, `Customer`, `Consumer`, `User`, `JobApplicant`, `Visitor`, `Member`, `Applicant`, `Subscriber`, `Client`, `Participant`
Concepts discussed and rejected as subclasses of `DataSubject` -> `Trainees`, `ServiceUser`, `WebsiteUser`, `WebsiteVisitor`
georg: How to express vulnerability of VulnerableDataSubject?
harsh: the vulnerability can be associated using a property e.g. `hasVulnerability` but this is contextual because that vulnerability can only exist in specific use-cases. Additionally, every data subject category has an associated property e.g. _Consumer_ has `hasProvider` as the relation, or _Employee_ has `hasEmployer`
harsh: The concepts for vulnerability i.e. properties and specific types of vulnerabilities can be provided as a proposal, and we may decide to put them in an extension
Discussion on _Customer_ vs _Consumer_ differences took place, with agreement that they are distinct concepts (i.e. not subclasses of either). Discussion on _Customer_ also being a business-to-business relationship took place, with agreement that the context of its use within DPV as a data subject category is clear.
georg: The _Customer_ separation for Data Subject and Organisation type could be handled in a similar manner as that of Legal Roles providing a specific list in Entities taxonomy
harsh: Yes, we could add `CustomerOrganisation` as a category in the Organisation type list, but B2B concepts are not in scope for DPV
Discussion on similarities between _User_, _Consumer_, and _Subscriber_ took place with agreement that they are distinct.
mark: Raised an issue with the use of the word "user" as a term
(Due to poor audio connection, the discussion did not complete. Mark is invited to send the objection to the mailing list for discussion)
Discussion on _ServiceUser_ being the covered by _User_, and _WebsiteUser_ also similarly being covered by _User_ (as well as _WebsiteVisitor_ being covered by _Visitor_) took place. The agreement to not involve these was reached with the notion that specifying _user_ in some context e.g. personal data handling for a service is sufficient to indicate it refers to users of that service.
If there is a need to denote specific users or visitors e.g. of a specific service or a website, then the adopter is required to subclass/instantiate these concepts as necessary.
Technologies
We intend to provide an opinionated list by end of April, with a good coverage of the top-level terms. This will be the first version, and iterations can continue to expand it.
Proposals for more concepts are invited.
DPV Future
The existing wiki page specifies topics we've decided for DPV v1 to include
Discussion took place on topics and involvement of personnel.
Harsh is involved in ROPA related concepts along with Paul and Rob, and will be presenting work next week / soon.
Harsh is involved in ISO/IEC 27560 consent record and will be presenting a proposal on adding concepts to DPV based on it soon.
Harsh and Georg have interest in providing risk assessment and management concepts in general
Harsh and Georg will be working on DPIA related concepts based on risk assessment and core requirements
Georg and Harsh are interested in adding Data Breach concepts
Beatriz and Harsh are interested in working on creating SHACL shapes for providing guidelines on DPV use
Beatriz raised the requirement to have mappings with other vocabularies, especially ODRL
Georg mentioned exercising Rights e.g. information to be provided for Subject Access Request, or exercising them using specific PDH instances
Georg mentioned use of DPV in Controller-Processor or Processor-Processor or Controller-Controller agreements as specifying activities to be conducted