Meeting minutes
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.
Recipient Country vs Entity Country
harsh: 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
Jurisdictional Concepts
harsh: 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
Consequence as concept
harsh: Overlap with ODRL
… 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
Type of Consequence
harsh: 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
Benefits and Beneficiary
harsh: 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.
Other Proposed Concepts
harsh: 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)