Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
Scheduling Weekly Meeting
Poll circulated on mailing list with time slots for weekly meeting. Most suitable slots are Thursday 13:30-16:30 (all times are GMT) and Monday 13:30-14:30. However, as Mondays are typically when institutes schedule meetings and events. Thursday 13:30-14:30 does not work for Beatriz, and 14:30-16:30 is not preferred for Julian. To maximise regular participation, we'll select a time on Thursday after confirming with participants.
DPV 2.1
Diagrams
See https://
harsh: All the pending text content has been added, the only items pending are diagrams which need to be updated.
julianFlake: can help, will need a list of diagrams
harsh: there is a list in the document, and each document also has an issue listed for the diagram
georgKrog: can review diagrams when finished
ACTION: Update diagrams - harsh and julian
Contracts
harsh: In last meeting, we discussed the need for concepts to represent the states when a contract is being signed, and to distinguish between this entity signing the contract, and some but not all entities signing the contract, and all entities signing the contract.
georgKrog: What about maintaining records for when the contract is being signed?
harsh: This can be done separately for the use-case, like creating a record for the entity, or to put the record in the contract with a timestamp.
georgKrog: Can we use Process here like we do for consent records?
harsh: No, because in consent we give consent or refuse it for the entire process, whereas in contract, it can be contain multiple processes and the contract is being signed as a whole or not. So we need concepts at the contract level.
georgKrog: Okay, agree that we need those concepts to model the states, but not clear on how the model works.
julianFlake: Are these states for a particular workflow? As in do they represent a state machine?
harsh: Yes, they can, but there are multiple workflows. For example, there may or may not be negotiation.
julianFlake: Should we replace the term entity with party as that is what is used for contracts?
harsh: We used entity because that's what we have in DPV.
julianFlake: Would still be better to have the same term that is used for contracts.
ACTION: Discuss and resolve whether contract terms should have 'Party' - harsh, julianFlake, georgKrog
julianFlake: There is a typo in the term - ContractedAcceptedAllParties should be ContractAcceptedAllParties.
ACTION: Fix typo in contract status ContractAcceptedAllParties - harsh
harsh: In the interest of time, let's continue this discussion via emails. If we have consensus - we add them to v2.1, otherwise we add them to v2.2 later.
ACTION: Resolve contract status - harsh, julianFlake, georgKrog
RISK
See https://
harsh: Had to make changes in the risk control concepts so that they are aligned and in a hierarchy - discovered this while trying to use them in an example. Created specific concepts to represent proactive and reactive controls which refer to whether the control is applied before the event or after its effects. In addition, we already have controls specific for source, consequence, and impact. Also created relevant properties for each.
delaramGolpayegani: What is the relation between control here and measure?
harsh: Measure as in DPV is the legal notion of having something in place, whereas in risk management it has a different meaning. Control is what is used in ISO terms to have something that controls a particular thing.
delaramGolpayegani: For the risk controls, it would be helpful to have a tree type diagram that shows how they are structured.
ACTION: Add a hierarchy diagram for RISK controls
delaramGolpayegani: There should be another source added - ISO 23894 for the risk management concepts for AI.
ACTION: Add ISO 23894 as source in AI extension
delaramGolpayegani: In Fig.1 showing the overview of RISK extension, there should be relation showing dpv:Impact is a subclass of dpv:Consequence
ACTION: Add relation between Impact and Consequence in RISK Fig. 1
ACTION: Add new concepts to RISK Fig. 1
delaramGolpayegani: For Potential concepts as in RISK, why are they needed? They can be confusing when using e.g. if there is an incident, then the impact is noted, and then the potential impact is noted.
harsh: They are potential in the sense of potentially taking on roles within the use-case. In your example, the potential impact would be risks, so it shouldn't use the potential concept directly. Instead, think that the use-case wants to identify what potential impacts can occur - and then for an incident you can select from one of those. So this is possible with our potential concepts to create a taxonomy of concepts representing risks, impacts - and then they can be asserted in context to apply as risk or consequence or as incidents.
delaramGolpayegani: So do we need them as separate concepts? Why not directly use them e.g. dpv:hasImpact?
harsh: No, because that would make always be an impact - whereas each use-case should specify what its impacts are.
delaramGolpayegani: What if we create a subclass of Impact?
harsh: Would have the same effect - they would still always be instances of impact.
delaramGolpayegani: In that case, a note explaining the concepts would be helpful as it currently is not entirely clear.
ACTION: Add note/content to RISK explaining why Potential concepts are needed
ACTION: Update Example 5 Potential concepts in RISK
delaramGolpayegani: In addition to these, a spellcheck is needed as there are several typos.
ACTION: Use spellcheck to fix typos (in RISK, but also all docs)
ACTION: RISK Risk Management pt.2b-iii fix formatting of risk level
AI
delaramGolpayegani: The concepts in Fig.2 are confusing, would be better to directly state the actual existing relations
ACTION: Update AI Fig.2 use DPV relations
ACTION: AI 7.1 Data Risks - check table of concepts
AI Act
delaramGolpayegani: Section 'Statuses' - should it be statuses or status?
Agreed to keep it as Statuses
ACTION: AI Act status definitions are None
P7012
harsh: Created a document with Iain and Beatriz for listing concepts required for implementing P7012. Since this is draft, and P7012 is itself yet to be published, we can continue working on this while the other 2.1 stuff is being sorted. Will add a document and share it next week.
Next Meeting
The next meeting will be on Thursday. Time TBC. Agenda will be finalisation of 2.1, and planning for 2.2.