MinutesOfMeeting 20220316

DPVCG Meeting 16 MAR 2022

Participants:

Regrets:

Optionality Expressed at what 'level'?

Georg raised the question as to at what level is optionality expressed e.g. how deep/high
This is relevant for e.g. in a privacy notice the data is indicated to be optional at the top or somewhere in contents
harsh: This is dependant on use-cases, any level is possible as use-cases have all kinds of requirements. So it can be used at any level.

Georg raised the question as to how to distinguish/define the location (country) of recipient as opposed to that of entity
harsh: Recipient location as in location of server, processing, etc. is defined has processing (e.g. Storage) and hasLocation it
harsh: Entity location is defined as location property on that Entity

Julian raised the topic of representing German federal states and laws as jurisdictional concepts following earlier proposal from harsh
In this, the Bavarian region has two DPAs for public and non-public organisations respectively
harsh: Suggestion is to simply name them as such e.g. DPA-public and DPA-non-public
For state names, it is recommended to follow existing norms or taxonomies e.g. ISO-3166 or EU or countrie's own standardised forms for state names

ODRL has the property consequence which links a Duty to itself, and is a sub-property of failure, thereby restricting its use in conditions where the consequences are always negative.
In DPV, the requirement is to broadly specify the consequence of an action, which can be both positive and negative
Therefore, DPV will declare its own concept, as it cannot adopt the exact inference of ODRL's concepts in this case

We discussed Consequence as the existence concept, and the requirement to express whether such consequences are positive or negative.
For this, two sets of options were proposed: Success/Failure and Materialisation/NonMaterialisation
Of these, Success/Failure were selected based on less ambiguity, more clarity, and intuitiveness
Concepts added: ConsequenceOfSuccess and ConsequenceOfFailure

These concepts were proposed in the first DPVCG meeting / workshop as relevant to determine who benefits' from processing
Proposals consisted of concepts Benefits and Beneficiary with the properties hasBenefits and hasBeneficiary
In subsequent discussions, it was agreed that the scope should be broader to also include the opposite of benefits and beneficiary
Examples proposed included: Detriment and Harm
The group discussed the notion of benefit being a type of consequence and whether it can subsequently be modelled as such
Additionally, beneficiary would be the entity impacted by a consequence thereby avoiding the need to explicitly declare beneficiary as a concept
Further discussions related the notion of Impact as being distinct from Consequence e.g. PersonalDataBreach has the consequence leaked data which then has an impact of identity theft or scams
Proposed pattern: X --hasConsequence (neg. isConsequenceFrom) --> Consequence --> hasImpactOn --> Y
Proposed pattern: Consequence --hasImpact--> Impact --hasImpactOn--> Y
The group agreed the need for further discussion and examples. Harsh will circulate email with a proposal.

hasResponsibleEntity - specifying what entity is responsible for something e.g. a controller in a joint controller relationship, or a specific department/division within the organisation (accepted)
OrganisationalUnit - specifying an unit within an organisation, with the criteria that the unit does not constitute as a separate legal entity in the sense of data controller, data processor, etc. (accepted)
InternationalOrganisation - As defined in GDPR Art.4-26, and whether this definition is sufficient for a global scope. We invite proposals, otherwise we go with this definition. (conditionally accepted)