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
harsh: 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
harsh: 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
harsh: We will continue discussion on pending concepts next week at FEB-23 13:00 WET / 14:00 CET.