Meeting minutes
DPV v0.4 and Primer
DPV v0.4 and Primer are ready to be published.
DPV-SKOS and DPV-OWL need some minor adjustments to produce serialisations.
These will be published later in the day.
Use-Cases and Examples
Moving forward, the emphasis is on collecting and documenting use-cases that are to be used as requirements for DPV.
This can mean ensuring the required concepts are present, or identifying areas which need further discussion / enrichment.
Use-cases are also useful to demonstrate where the DPV can be applied, and can act as descriptions for creating examples.
We will have both simple (something has personal data) and complex (modelling data transfers with its own specific legal basis based on GDPR requirements ...) use-cases and examples.
jan: The modelling of COVID-19 passed, where consent is collected, or data is collected and retained, could be a relevant use-case.
jan: The depiction of how DPV concepts act together towards assisting/fulfilling GDPR compliance requirements would be another relevant area for use-cases.
harsh: A relevant resource regarding DPV is the Standard Data Protection Model (SDM) - a specification developed by German DPAs https://
harsh: Alignment of DPV with such specification / standards can help in demonstrating its practicality as well as ensuring the vocabulary is 'complete' and 'useful' through the concepts and examples.
Frequency
There is a proposal on modelling `Frequency` as a concept in terms of period repetitions for representing how often something happens.
For example, data collection duration could be 1 year, and the frequency of daily would indicate it happens once per day over the year.
`Frequency` could be expressed (using `hasFrequency`) over concepts such as Processing, PersonalDataHandling, etc.
Concept is accepted after discussion.
Optionality of Concepts
georg: How to indicate, for example, personal data is optional to a purpose?
harsh: One way to (directly) express this is to say `Purpose hasPersonalData PersonalData` and to indicate that as `hasContext Optional` at either Purpose or PersonalData scope.
harsh: A better way to do this would be to instead create 'units' e.g. using `PersonalDataHandling`, and to denote them as being required or optional. So for this use, two `PersonalDataHandling` where one represents the required parts and the other optional ones.
harsh: The Primer has a rudimentary example for this in the `Context` section.
Consequence of not providing data
georg: How to represent the consequences of personal data not being provided for a purpose? (as required within GDPR)
harsh: It is very difficult to model what happens when something is _not_ done. One logical consequence is that if personal data is _required_ for a purpose, then not providing it results in that purpose not being fulfilled.
harsh: The second aspect to representing such consequences is then understanding what happens, other than the purpose, in case personal data is not provided
Proposal for two subtypes of `Consequence` as `ConsequenceOfSuccess` and `ConsequenceOfFailure` to indicate the resulting consequences when something 'succeeds' or 'takes place', and when it 'fails' or 'does not take place'.
Discussion welcome until next week.
Expressing Order
To express order to denote something happens, takes place, or is placed before or after something. E.g. collection of data is prior to use - where this order is arbitrary and loosely defined, as collection can continue while usage also takes place.
Proposal is to have two concepts: `followsFrom` and `isFollowedBy` to denote the order of concepts.
Discussion on the correctness of terms, with alternate proposals: `followsOn` instead of `followsFrom`.
Rudimentary consensus on relations `isBefore` and `isAfter` as abstract denotion of order. To be discussed until next week.
Scope of DPV
harsh: Where possible, large overlaps with other existing vocabularies that are either: standardised, well-defined, or widely-used - is to be avoided so DPV instead can focus on specific terms not available elsewhere.
harsh: For cases where similar concepts (to those existing externally) are needed, we may define rudimentary and simplistics ones in the vocabulary for convenience and completeness.
harsh: For more complex uses and requirements, it is recommended to instead utilise the other vocabularies in conjunction / combination with DPV.
Discussion relevant to the recording of 'data flows', start times, etc. - which are possible through PROV.
Similar overlaps exist with ODRL in terms of permissions, prohibitions, parties. etc.
The recommendation is to utilise these (or others) where the requirements for using DPV have a significant overlap or alignment with their provisions. For example, to model the order in which data is collected and its timestamps, PROV can provide the necessary concepts to represent processing as workflows.
harsh: GDPRov http://
Next Meeting
We will continue discussion on pending concepts next week at FEB-23 13:00 WET / 14:00 CET.