12:51:38 RRSAgent has joined #dpvcg 12:51:38 logging to https://www.w3.org/2022/03/02-dpvcg-irc 12:52:48 ScribeNick: harsh 12:52:51 Meeting: DPVCG Meeting Call 12:52:54 Chair: harsh 12:53:01 Date: 02 MAR 2022 12:53:11 Agenda: https://lists.w3.org/Archives/Public/public-dpvcg/2022Feb/0008.html 13:03:17 Present: harsh, paul, beatriz, julian 13:03:20 Regrets: georg 13:22:24 rigo has joined #dpvcg 14:08:07 Topic: DPV License (FYI) 14:08:26 Ongoing conversation on mailing list https://lists.w3.org/Archives/Public/public-dpvcg/2022Mar/0002.html 14:08:48 Thread and DPV documentation/repo will be updated once there is some resolution on license 14:09:07 Topic: Modelling Jurisdictions (proposal) 14:09:21 See https://lists.w3.org/Archives/Public/public-dpvcg/2022Feb/0006.html for info 14:09:40 This uses the location / DPA / laws concepts from DPV to model countries, DPAs, and relevant laws 14:10:09 Currently all countries, EU membership (pre/post Brexit), EEA, EU DPAs, GDPR, and Adequacy decisions are provided 14:10:33 Sources https://github.com/coolharsh55/dpv-x/blob/master/dpv-juris/sources.md include authoritative resources 14:10:58 Volunteers can expand listing to include additional laws, DPAs, and adequacy decisions (or data transfer agreements) between countries outside EU 14:11:15 So far we have received only requests/use-cases related to EU + data transfers, which this is sufficient for 14:11:56 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) 14:12:02 Topic: Use-case documentation 14:12:48 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 14:13:19 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 14:13:51 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. 14:14:31 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) 14:14:49 Anything else can be provided for contextual information and discussion e.g. diagrams, additional descriptions. 14:15:45 Use-cases will be stored on GitHub https://github.com/w3c/dpv/tree/master/use-cases as RDF, and linked to concepts within the specification e.g. Data Transfer -> See relevant use-cases (link to page listing use-cases where data transfers are mentioned as a relevant concept) 14:16:13 Topic: Resolution of proposed concepts 14:17:17 *Consequence* 14:17:53 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 14:18:30 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' 14:19:01 For example, one personal data handling instance specifies another instance as a consequence of failure 14:19:27 No comments or preferences expressed. Harsh will check with proposal submitted (Georg) on the use-case and what concepts are necessary. 14:20:39 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 14:20:45 --- 14:20:52 *Technologies* 14:21:06 We have a rudimentary list of technologies e.g. database, apps, OS, cookies 14:21:35 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 14:21:48 Agreement on providing technologies as a separate extension (dpv-tech) 14:21:51 --- 14:21:55 *Data Breach* 14:22:31 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 14:23:02 These should be provisioned as a separate extension to avoid mixing DPV concepts (e.g. entities and actors) with data breach specific concepts 14:23:37 We invite proposals for modelling data breaches via the public mailing list 14:23:39 --- 14:23:50 *Benefits and Beneficiary* 14:24:17 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. 14:24:52 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" 14:25:36 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. 14:25:43 --- 14:25:50 *Risk Concepts* 14:27:42 DPV models risks and mitigations as broad concepts (`Concept hasRisk Risk`) (`RiskMitigationMeasure mitigatesRisk Risk`) (`Risk isMitigatedByMeasure RiskMitigationMeasure`) and (`Concept hasRiskMitigationMeasure RiskMitigationMeasure`) 14:28:16 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 14:28:45 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 14:28:59 --- 14:29:05 *Order of Things* 14:29:40 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. 14:30:21 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. 14:30:42 These were chosen to be more simple and lesser ambiguous than alternatives `followsFrom` 14:30:47 --- 14:30:58 *isRequiredFor relation expressing requirement for obligation~ 14:31:35 s/~/* 14:31:57 Julian had proposed a concept `isRequiredFor` to indicate a measure was required for some legal obligation or requirement 14:32:22 However, this is complex to represent as such requirements could be applicable to things other than technical measures e.g. legal basis, purposes, processing 14:32:39 Additionally, this would necessitate DPV to model legal obligations, compliance processes and status. 14:33:04 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) 14:33:15 Proposals are welcome to be shared through the public mailing list 14:33:25 Topic: Next Meeting 14:33:36 We will continue discussion on the resolution of proposed concepts next week 14:33:55 Next meeting will take place on MAR-09 13:00 WET / 14:00 CET 14:33:57 zakim, bye 14:33:57 leaving. As of this point the attendees have been harsh, paul, beatriz, julian 14:33:57 Zakim has left #dpvcg 14:34:06 rrsagent, publish minutes v2 14:34:06 I have made the request to generate https://www.w3.org/2022/03/02-dpvcg-minutes.html harsh 14:34:11 rrsagent, set logs world-visible 14:35:05 rrsagent, bye 14:35:05 I see no action items