diff --git a/code/minutes-generator/data/meeting-2025-01-09.irc b/code/minutes-generator/data/meeting-2025-01-09.irc new file mode 100644 index 000000000..03d898447 --- /dev/null +++ b/code/minutes-generator/data/meeting-2025-01-09.irc @@ -0,0 +1,76 @@ +16:15:34 RRSAgent has joined #dpvcg +16:15:44 Scribe: harshPandit +16:18:43 ScribeNick: harsh +16:15:47 repo: w3c/dpv +16:15:47 OK. +16:15:55 Meeting: DPVCG Meeting Call +16:15:57 Chair: harsh +16:16:51 Present: harshPandit, paulRyan, georgKrog, tyttiRintamaki, delaramGolpayegani, iainHenderson, julianFlake +16:18:43 Regrets: beatrizEsteves +16:17:14 Date: 09 JAN 2025 +16:17:28 Agenda: https://www.w3.org/events/meetings/cfb323ac-2f0a-4a78-96e5-09194bf1c9bf/ +16:17:37 \ Meeting minutes: https://w3id.org/dpv/meetings +16:17:47 \ purl for this meeting: https://w3id.org/dpv/meetings/meeting-2025-01-09 +16:17:47 Topic: Scheduling Weekly Meeting +16:17:47 \ 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. +16:17:47 Topic: DPV 2.1 +16:17:47 Subtopic: Diagrams +16:17:47 \ See https://docs.google.com/document/d/1poo7rYNBlkd4Ag0YHB_il2Xe2hwtHWfROgl5WgrNgyc/ +16:17:47 harsh: All the pending text content has been added, the only items pending are diagrams which need to be updated. +16:17:47 julianFlake: can help, will need a list of diagrams +16:17:47 harsh: there is a list in the document, and each document also has an issue listed for the diagram +16:17:47 georgKrog: can review diagrams when finished +16:17:47 ACTION: Update diagrams - harsh and julian +16:17:47 Subtopic: Contracts +16:17:47 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. +16:17:47 georgKrog: What about maintaining records for when the contract is being signed? +16:17:47 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. +16:17:47 georgKrog: Can we use `Process` here like we do for consent records? +16:17:47 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. +16:17:47 georgKrog: Okay, agree that we need those concepts to model the states, but not clear on how the model works. +16:17:47 julianFlake: Are these states for a particular workflow? As in do they represent a state machine? +16:17:47 harsh: Yes, they can, but there are multiple workflows. For example, there may or may not be negotiation. +16:17:47 julianFlake: Should we replace the term `entity` with `party` as that is what is used for contracts? +16:17:47 harsh: We used `entity` because that's what we have in DPV. +16:17:47 julianFlake: Would still be better to have the same term that is used for contracts. +16:17:47 ACTION: Discuss and resolve whether contract terms should have 'Party' - harsh, julianFlake, georgKrog +16:17:47 julianFlake: There is a typo in the term - `ContractedAcceptedAllParties` should be `ContractAcceptedAllParties`. +16:17:47 ACTION: Fix typo in contract status `ContractAcceptedAllParties` - harsh +16:17:47 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. +16:17:47 ACTION: Resolve contract status - harsh, julianFlake, georgKrog +16:17:47 Subtopic: RISK +16:17:47 \ See https://dev.dpvcg.org/2.1-dev/risk/ +16:17:47 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. +16:17:47 delaramGolpayegani: What is the relation between control here and measure? +16:17:47 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. +16:17:47 delaramGolpayegani: For the risk controls, it would be helpful to have a tree type diagram that shows how they are structured. +16:17:47 ACTION: Add a hierarchy diagram for RISK controls +16:17:47 delaramGolpayegani: There should be another source added - ISO 23894 for the risk management concepts for AI. +16:17:47 ACTION: Add ISO 23894 as source in AI extension +16:17:47 delaramGolpayegani: In Fig.1 showing the overview of RISK extension, there should be relation showing `dpv:Impact` is a subclass of `dpv:Consequence` +16:17:47 ACTION: Add relation between Impact and Consequence in RISK Fig. 1 +16:17:47 ACTION: Add new concepts to RISK Fig. 1 +16:17:47 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. +16:17:47 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. +16:17:47 delaramGolpayegani: So do we need them as separate concepts? Why not directly use them e.g. `dpv:hasImpact`? +16:17:47 harsh: No, because that would make always be an impact - whereas each use-case should specify what its impacts are. +16:17:47 delaramGolpayegani: What if we create a subclass of Impact? +16:17:47 harsh: Would have the same effect - they would still always be instances of impact. +16:17:47 delaramGolpayegani: In that case, a note explaining the concepts would be helpful as it currently is not entirely clear. +16:17:47 ACTION: Add note/content to RISK explaining why Potential concepts are needed +16:17:47 ACTION: Update Example 5 Potential concepts in RISK +16:17:47 delaramGolpayegani: In addition to these, a spellcheck is needed as there are several typos. +16:17:47 ACTION: Use spellcheck to fix typos (in RISK, but also all docs) +16:17:47 ACTION: RISK Risk Management pt.2b-iii fix formatting of risk level +16:17:47 Subtopic: AI +16:17:47 delaramGolpayegani: The concepts in Fig.2 are confusing, would be better to directly state the actual existing relations +16:17:47 ACTION: Update AI Fig.2 use DPV relations +16:17:47 ACTION: AI 7.1 Data Risks - check table of concepts +16:17:47 Subtopic: AI Act +16:17:47 delaramGolpayegani: Section 'Statuses' - should it be statuses or status? +16:17:47 \ Agreed to keep it as Statuses +16:17:47 ACTION: AI Act status definitions are `None` +16:17:47 Subtopic: P7012 +16:17:47 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. +16:17:47 Topic: Next Meeting +16:17:47 \ The next meeting will be on Thursday. Time TBC. Agenda will be finalisation of 2.1, and planning for 2.2. diff --git a/meetings/index.html b/meetings/index.html index 48eea797f..347a6c5a5 100644 --- a/meetings/index.html +++ b/meetings/index.html @@ -14,6 +14,7 @@

DPVCG Meeting Minutes

purl: https://w3id.org/dpv/meetings

See W3C DPVCG Calendar for upcoming meetings, agenda, and joining instructions.

    +
  1. DPVCG Meeting 09 January 2025 Thursday
  2. DPVCG Meeting 02 January 2025 Thursday
  3. DPVCG Meeting 17 December 2024 Tuesday
  4. DPVCG Meeting 10 December 2024 Tuesday
    5. diff --git a/meetings/meeting-2025-01-09.html b/meetings/meeting-2025-01-09.html new file mode 100644 index 000000000..6c7d4c2d0 --- /dev/null +++ b/meetings/meeting-2025-01-09.html @@ -0,0 +1,165 @@ + + + + +DPVCG Meeting Call – 09 JAN 2025 + + + + + + + + + + +
    +

    W3C

    + +

    DPVCG Meeting Call

    +

    09 JAN 2025

    + + +
    + +
    +
    +

    Attendees

    +
    +
    Present
    delaramGolpayegani, georgKrog, harshPandit, iainHenderson, julianFlake, paulRyan, tyttiRintamaki
    +
    Regrets
    beatrizEsteves
    +
    Chair
    harsh
    +
    Scribe
    harsh, harshPandit
    +
    +
    + + +
    + +
    +

    Meeting minutes

    +

    Repository: w3c/dpv

    +

    Meeting minutes: https://w3id.org/dpv/meetings

    +

    purl for this meeting: https://w3id.org/dpv/meetings/meeting-2025-01-09

    +
    + +
    +

    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://docs.google.com/document/d/1poo7rYNBlkd4Ag0YHB_il2Xe2hwtHWfROgl5WgrNgyc/

    +

    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://dev.dpvcg.org/2.1-dev/risk/

    +

    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.

    +
    +
    + + + + +
    Minutes manually created (not a transcript), formatted by scribe.perl version 217 (Fri Apr 7 17:23:01 2023 UTC).
    + + +