Meeting minutes
DPV License (FYI)
Ongoing conversation on mailing list https://
Thread and DPV documentation/repo will be updated once there is some resolution on license
Modelling Jurisdictions (proposal)
See https://
This uses the location / DPA / laws concepts from DPV to model countries, DPAs, and relevant laws
Currently all countries, EU membership (pre/post Brexit), EEA, EU DPAs, GDPR, and Adequacy decisions are provided
Sources https://
Volunteers can expand listing to include additional laws, DPAs, and adequacy decisions (or data transfer agreements) between countries outside EU
So far we have received only requests/use-cases related to EU + data transfers, which this is sufficient for
Proposal open for review until MAR-31. Comments will be reviewed and incorporated until then, after which this will be published as an extension to the DPV (e.g. dpv-juris)
Use-case documentation
It is imperative and important to document the use-cases to both (i) assess DPV in terms of concepts is sufficient to model that use-case; and (ii) to demonstrate usefulness of DPV
Use-case is a term used for a generic description of a situation which will be analysed to identify relevant concepts that the DPV should represent
For descriptions of "how to do X in DPV", consider writing documentation in the form of guides that target a specific domain or application. For e.g. creating ROPA with DPV.
Use-cases should be simple to describe and record. For this reason, the minimal concepts identified to describe an use-case are: ID (assigned by DPVCG after acceptance), title, description, relevant concepts to model, and source (optional)
Anything else can be provided for contextual information and discussion e.g. diagrams, additional descriptions.
Use-cases will be stored on GitHub https://
Resolution of proposed concepts
*Consequence*
The use-case is to denote what are the consequences of something not taking place e.g. (i) data not provided could result in service not being provided; (ii) rights not possible to exercise
In this, (i) can be inferred from expressing data is necessary for a service. However, for indicating two, the proposal is to provide a way to indicate something is a consequence of 'failure'
For example, one personal data handling instance specifies another instance as a consequence of failure
No comments or preferences expressed. Harsh will check with proposal submitted (Georg) on the use-case and what concepts are necessary.
Note -> ODRL already models consequence and failure relations. Unless these are analysed and found to be non-compatible with the use-case, DPV should not repeat their semantics
---
*Technologies*
We have a rudimentary list of technologies e.g. database, apps, OS, cookies
Instead of DPV provisioning an ad-hoc incomplete list of technologies, these should be provided as a separate extension similar to dpv-pd that can grow at its own pace
Agreement on providing technologies as a separate extension (dpv-tech)
---
*Data Breach*
Instead of modelling data breach as a singular concept, DPV should look towards modelling all concepts relevant to data breaches e.g. records, what data was affected, actors involved, notification to authorities and data subjects
These should be provisioned as a separate extension to avoid mixing DPV concepts (e.g. entities and actors) with data breach specific concepts
We invite proposals for modelling data breaches via the public mailing list
---
*Benefits and Beneficiary*
We have benefits and beneficiary as a proposed set of concepts from the inception of DPV in 2018. The intention was to indicate who 'benefits' from some data being processed i.e. the company or the user.
Prior discussions on this stopped at trying to determine the opposite concept from benefit e.g. harm or detriment, and how to indicate these along with "who is harmed"
Current (today's) proposal is to model these as 'impacts' and indicate the entity being impacted. For e.g. for benefits, this becomes the beneficiary. For harms, this becomes the person harmed.
---
*Risk Concepts*
DPV models risks and mitigations as broad concepts (`Concept hasRisk Risk`) (`RiskMitigationMeasure mitigatesRisk Risk`) (`Risk isMitigatedByMeasure RiskMitigationMeasure`) and (`Concept hasRiskMitigationMeasure RiskMitigationMeasure`)
To model additional information, such as likelihood, frequency, consequence and impacts of risks (e.g. data breaches) - this requires concepts associated with risk assessment and risk management
We invite proposals for an extension to the DPV to model risk related concepts (as above, including impacts such as benefits) to be shared via the public mailing list
---
*Order of Things*
The use-case was how to express order of 'things' i.e. whether they occur before or after something. This is more generic than modelling activities that take place in a sequence as part of a workflow.
The proposal was to provide concepts `isBefore` and `isAfter` to indicate something comes before or after within some (unspecified) context. This could be temporal, spatial, or another context.
These were chosen to be more simple and lesser ambiguous than alternatives `followsFrom`
---
*isRequiredFor relation expressing requirement for obligation*
Julian had proposed a concept `isRequiredFor` to indicate a measure was required for some legal obligation or requirement
However, this is complex to represent as such requirements could be applicable to things other than technical measures e.g. legal basis, purposes, processing
Additionally, this would necessitate DPV to model legal obligations, compliance processes and status.
This requires more clear proposals with description for what concepts are necessary and how they should fit within the existing model (of concepts in DPV)
Proposals are welcome to be shared through the public mailing list
Next Meeting
We will continue discussion on the resolution of proposed concepts next week
Next meeting will take place on MAR-09 13:00 WET / 14:00 CET