-
Notifications
You must be signed in to change notification settings - Fork 30
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
f056a57
commit 9ce19d2
Showing
3 changed files
with
304 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,102 @@ | ||
| 16:15:34 <RRSAgent> RRSAgent has joined #dpvcg | ||
| 16:15:44 <harsh> Scribe: harshPandit | ||
| 16:18:43 <harsh> ScribeNick: harsh | ||
| 16:15:47 <harsh> repo: w3c/dpv | ||
| 16:15:47 <ghurlbot> OK. | ||
| 16:15:55 <harsh> Meeting: DPVCG Meeting Call | ||
| 16:15:57 <harsh> Chair: harsh | ||
| 16:16:51 <harsh> Present: harshPandit, paulRyan, georgKrog, julianFlake, tyttiRintamaki, iainHenderson, delaramGolpayegani, julioHernandez | ||
| 16:18:43 <harsh> Regrets: beatrizEsteves | ||
| 16:17:14 <harsh> Date: 17 DEC 2024 | ||
| 16:17:28 <harsh> Agenda: https://www.w3.org/events/meetings/0e21485e-d959-4f78-930a-bd66650adace/20241217T133000/ | ||
| 16:17:37 <harsh> \ Meeting minutes: https://w3id.org/dpv/meetings | ||
| 16:17:47 <harsh> \purl for this meeting: https://w3id.org/dpv/meetings/meeting-2024-12-17 | ||
| 16:18:43 <harsh> \ See DPV v2.1 update: changelist / review tasks https://lists.w3.org/Archives/Public/public-dpvcg/2024Dec/0002.html | ||
| 16:18:43 <harsh> Topic: Information Audit | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/202 -> Issue 202 [Concept]: InformationAudit (by Paul-Ryan76) | ||
| 16:18:43 <harsh> harsh: concept is okay to add as an organisation measure, but is generic and specifies any information - (to Paul as proposer) do you think we need a specific concept for Personal Data? | ||
| 16:18:43 <harsh> paulRyan: the concept is okay as it is defined, but yet it would be good to also have a specific concept for personal data audits | ||
| 16:18:43 <harsh> ACTION: Add specialised concept for personal data audit under information audit | ||
| 16:18:43 <harsh> Topic: Human Subject | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/205 -> Issue 205 [Concept]: `HumanSubject` as the parent of `DataSubject` and `AISubject` (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: we discussed previously that our existing `DataSubject` taxonomy is a good resource and would be helpful to have it being used also alongside other /Subject/ concepts such as `AISubject`. For this, we proposed adding `HumanSubject` as the top concept under which the categories will be present, and then `DataSubject` etc. will be subclasses of this concept. Breaks backwards compatibility potentially in a minor but easily fixable way, but the benefits are greater in favour of doing this. | ||
| 16:18:43 <harsh> iainHenderson: +1 to do this | ||
| 16:18:43 <harsh> georgKrog: What about Organisations that are Customers - does this concept also cover that? | ||
| 16:18:43 <harsh> harsh: no, it doesn't - we specifically model only /natural persons/ or /humans/ and modelling organisational interrelationships is outside of our scope for now. In the future, if we want to do this, it will have to be a separate extension just for organisations and non-humans. | ||
| 16:18:43 <harsh> georgKrog: +1 for now as having these categories for humans would be helpful | ||
| 16:18:43 <harsh> paulRyan: What will happen to `DataSubject` being the top concept? | ||
| 16:18:43 <harsh> harsh: It will be under `HumanSubject` so you can say a human category like `Tourist` is a data subject and it will be okay / correct - no compatibility issues with existing uses like this. | ||
| 16:18:43 <harsh> paulRyan: +1 to go ahead with the approach | ||
| 16:18:43 <harsh> delaramGolpayegani: how will this work with `AISubject`? | ||
| 16:18:43 <harsh> harsh: we will have `HumanSubject`, and then subclasses `DataSubject` in DPV, `TechnologySubject` in TECH and its subclass `AISubject` in AI extension | ||
| 16:18:43 <harsh> delaramGolpayegani: What about other non-human subjects such as animals which might be what AI is used on? | ||
| 16:18:43 <harsh> harsh: outside of our scope for now - same as the issue with organisations as subjects. In the future we can think about this, but then we will try to explicitly denote they are /non-human subjects/ | ||
| 16:18:43 <harsh> georgKrog: how will this work with natural persons and legal persons? | ||
| 16:18:43 <harsh> harsh: `HumanSubject` will be a specific kind of `NaturalPerson`, and all natural persons are legal persons (we have `LegalEntity` as the concept for this) | ||
| 16:18:43 <harsh> \ discussion concluded with agreement on adding this concept | ||
| 16:18:43 <harsh> ACTION: Add Human Subject | ||
| 16:18:43 <harsh> Topic: P7012 | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/203 -> Issue 203 Create extension to support IEEE P7012 (by coolharsh55) | ||
| 16:18:43 <harsh> Subtopic: Tracking | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/206 -> Issue 206 [Concept]: `Tracking` (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: as discussed previously, P7012 implementation will require concepts that are not currently present in DPV; some such as `ServiceData` aren't clearly defined so we can put them in the extension, but others such as `Tracking` are already used and have a technical definition (e.g. see Do-Not-Track). Therefore we proposed to have this concept within DPV alongside the existing `Profiling` concept as a `Processing` operation that extends `Use` category of processing. This is because tracking uses data, and in that process it may also collect and generate additional data. But the minimal definition is that it uses some data to track the person across contexts. | ||
| 16:18:43 <harsh> georgKrog: DSA has profiling, so maybe we should wait for more info on that? | ||
| 16:18:43 <harsh> harsh: we already have `Profiling` in DPV, and in addition to this, we have /profiling/ in the GDPR extension as defined in Art.4-4, and we can always update the definitions and concepts as the law and regulatory context evolves | ||
| 16:18:43 <harsh> georgKrog: DSA defines profiling as it is defined in GDPR Art.4-4 as well - so anything that supports expressing these would be good | ||
| 16:18:43 <harsh> harsh: so then we should add it - should we also add /First Party Tracking/ and /Third Party Tracking/ as these are also required for P7012 and are commonly used? | ||
| 16:18:43 <harsh> iainHenderson: yes, these would be good to have | ||
| 16:18:43 <harsh> georgKrog: how would these be defined? | ||
| 16:18:43 <harsh> harsh: We will base these on existing definitions for the moment - though first and third party are not clearly defined concepts in legal terms for us to rely on them | ||
| 16:18:43 <harsh> \ Discussion concluded with agreement on adding tracking and 1P, 3P variations with a note that it may evolve in the future | ||
| 16:18:43 <harsh> ACTION: Add Tracking concepts, with 1P and 3P variations | ||
| 16:18:43 <harsh> Subtopic: Concepts from DPV | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/203 -> Issue 203 Create extension to support IEEE P7012 (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: Iain, what do you think is required or would be helpful for DPV to provide for P7012? | ||
| 16:18:43 <harsh> iainHenderson: 1) /Data/ - the DPV data types are not complete. Maybe a different way to organise it is needed e.g. customer data, service data, and so on that is more suitable for organisations to understand and use. Can come with proposal for orgs to understand and use. | ||
| 16:18:43 <harsh> iainHenderson: 2) /Purpose/ - The DPV purposes are not complete, the descriptions could be more detailed. Have some ideas on these as well. | ||
| 16:18:43 <harsh> iainHenderson: 3) /Matrix of Purpose X Data/ - providing a combination of purpose and involved data would make it much more simpler to use these concepts in practice e.g. service provision for home energey involves these specific data concepts, and in addition providing these concepts for what data can be involved will also assist in data minimisation | ||
| 16:18:43 <harsh> georgKrog: so you have a purpose, and then you are modelling the minimum data required to achieve that purpose? | ||
| 16:18:43 <harsh> iainHenderson: yes, the extension is there to describe this in detail for specific sectors. | ||
| 16:18:43 <harsh> georgKrog: /Sector/ is too broad, you should also have this for /Domain/ e.g. Health and Consultancy (Sectors) both have HR (Domain) which is different for each of them | ||
| 16:18:43 <harsh> iainHenderson: yes, trying to explain to the UK Gov. that this can be done to simplify agreements | ||
| 16:18:43 <harsh> ACTION: Iain to propose concepts for purposes, data, and combinations of these for specific sectors for P7012 | ||
| 16:18:43 <harsh> Topic: Technology Provision | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/207 -> Issue 207 [Concept]: Change `TechnologyProvisionMethod` concepts e.g. `tech:System` to `tech:ProvidedAsSystem` (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: in previous discussion, we went through how the existing tech provision methods are confusing as they contain concepts like `System` while the AI extension has `AISystem` - which are two distinct interpretations. To avoid this, the proposal is to have the TECH extension use `System`, `Service`, etc. as types of technologies, and to create distinct concepts representing how they are provided, and to add a prefix or suffix to the concept to denote this. | ||
| 16:18:43 <harsh> georgKrog: for consent via privacy notice, where you provide the notice through a method, and then you collect it through a method - what is being described here? | ||
| 16:18:43 <harsh> harsh: in this case, the notice or dialogue is a technology, and we are describing how it is provided e.g. on a website it is a component as it is operating within the website (as a system), similarly other technologies might be subscriptions or entire systems (independent) | ||
| 16:18:43 <harsh> harsh: Some options for the terms: 1) `ProvidedAsSystem` - we add prefixed /Provided as/ to denote this is a type of provision; 2) `SystemProvision` - we add suffix /Provision/ to denote it is being provisioned; 3) `SystemProvisionMethod` - we add suffix /Provision Method/ to denote we are describing the method of provision. My preference is for n.1 as it is most clear and simple | ||
| 16:18:43 <harsh> georgKrog: +1 for n.1 | ||
| 16:18:43 <harsh> julianFlake: +1 for n.1 | ||
| 16:18:43 <harsh> ACTION: Change TechnologyProvisionMethod concepts to have prefix ProvidedAsX | ||
| 16:18:43 <harsh> Topic: RISK | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/181 -> Issue 181 Refine RISK taxonomy into a single consistent hierarchy (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: since Delaram is here, good to go over this again - we have the RISK extension where there is a warning note for the taxonomy that it may change in the future i.e. it is unstable and don't rely on it. Since then we have updated it significantly. So should we remove the note? We leaned towards yes last week, but didn't have a clear agreement in the discussion. | ||
| 16:18:43 <harsh> \ discussed and agreed to remove the warning | ||
| 16:18:43 <harsh> Topic: SECTOR | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/204 -> Issue 204 Create Sector Extension (by coolharsh55) | ||
| 16:18:43 <harsh> harsh: as discussed last week, we have lots of concepts in the SECTOR extension - at the moment these are only purposes but we will also expect personal data and other things in the future - as Beatriz pointed out we may want to think about further modularising the concepts. So the question is whether we have one large extension and then the HTML has different sections for each sector or do we have modular smaller extensions within sector for each specific sector like what we do for the legal extensions? (see example on github in sector branch) | ||
| 16:18:43 <harsh> georgKrog: within each sector there will be domains that are the same, so maybe having domains is an alternative? | ||
| 16:18:43 <harsh> harsh: what do you mean by /sector/ and /domain/ here? | ||
| 16:18:43 <harsh> georgKrog: e.g. the HR in Health and Finance being two different things | ||
| 16:18:43 <harsh> harsh: we can do it this way - for general domains that are expected to be widely present, we keep them in DPV as we already have them in DPV e.g. the job hiring and other HR stuff; then the sector specific concepts or the sector-specific interpretation of domain concepts can go in the sector extensions e.g. employee in Health could be doctors, and employee evaluation for doctors means a very specific thing - so that can be extended in the sector extension | ||
| 16:18:43 <harsh> georgKrog: yes, modular is better - so let's go with that approach | ||
| 16:18:43 <harsh> \ Discussion concluded with agreement on using modular approach for sector | ||
| 16:18:43 <harsh> ACTION: Use modular approach in SECTOR extension for each sector | ||
| 16:18:43 <harsh> Topic: Finalise Scope of DPV 2.1 | ||
| 20:10:04 <ghurlbot> https://github.com/w3c/dpv/issues/198 -> Issue 198 DPV v2.1 release management (by ghurlbot) | ||
| 16:18:43 <harsh> harsh: Do we stop the process of discussion and additions, and finalise what we have as of now as DPV 2.1? | ||
| 16:18:43 <harsh> delaramGolpayegani: +1 | ||
| 16:18:43 <harsh> georgKrog: +1 | ||
| 16:18:43 <harsh> julianFlake: +1 | ||
| 16:18:43 <harsh> tyttiRintamaki: +1 | ||
| 16:18:43 <harsh> julioHernandez: +1 | ||
| 16:18:43 <harsh> paulRyan: +1 (retrospective) | ||
| 16:18:43 <harsh> iainHenderson: +1 (retrospective) | ||
| 16:18:43 <harsh> beatrizEsteves: +1 (retrospective) | ||
| 16:18:43 <harsh> \ Conclusion to finalise DPV and release it as v2.1 | ||
| 16:18:43 <harsh> ACTION: Finalise and publish DPV 2.1 for review | ||
| 16:18:43 <harsh> Topic: Next Meeting | ||
| 16:18:43 <harsh> \ Discussion on meeting schedule yielded the following conclusion: We will circulate an internal poll for the next meeting times in the new year. There will be no meeting next week owing to Christmas break. Harsh will circulate the poll, and an email for the review tasks which people can do as they have time. Tentatively, we aim to meet around JAN-03 Friday. | ||
| 16:18:43 <harsh> ACTION: Circulate internal poll for next year's meeting schedule | ||
| 16:18:43 <harsh> ACTION: Inform participants there will be no meeting next week |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.