Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
See DPV v2.1 update: changelist / review tasks https://
Information Audit
<ghurlbot> Issue 202 [Concept]: InformationAudit (by Paul-Ryan76)
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?
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
ACTION: Add specialised concept for personal data audit under information audit
Human Subject
<ghurlbot> Issue 205 [Concept]: `HumanSubject` as the parent of `DataSubject` and `AISubject` (by coolharsh55)
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.
iainHenderson: +1 to do this
georgKrog: What about Organisations that are Customers - does this concept also cover that?
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.
georgKrog: +1 for now as having these categories for humans would be helpful
paulRyan: What will happen to DataSubject being the top concept?
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.
paulRyan: +1 to go ahead with the approach
delaramGolpayegani: how will this work with AISubject?
harsh: we will have HumanSubject, and then subclasses DataSubject in DPV, TechnologySubject in TECH and its subclass AISubject in AI extension
delaramGolpayegani: What about other non-human subjects such as animals which might be what AI is used on?
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
georgKrog: how will this work with natural persons and legal persons?
harsh: HumanSubject will be a specific kind of NaturalPerson, and all natural persons are legal persons (we have LegalEntity as the concept for this)
discussion concluded with agreement on adding this concept
ACTION: Add Human Subject
P7012
<ghurlbot> Issue 203 Create extension to support IEEE P7012 (by coolharsh55)
Tracking
<ghurlbot> Issue 206 [Concept]: `Tracking` (by coolharsh55)
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.
georgKrog: DSA has profiling, so maybe we should wait for more info on that?
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
georgKrog: DSA defines profiling as it is defined in GDPR Art.4-4 as well - so anything that supports expressing these would be good
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?
iainHenderson: yes, these would be good to have
georgKrog: how would these be defined?
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
Discussion concluded with agreement on adding tracking and 1P, 3P variations with a note that it may evolve in the future
ACTION: Add Tracking concepts, with 1P and 3P variations
Concepts from DPV
<ghurlbot> Issue 203 Create extension to support IEEE P7012 (by coolharsh55)
harsh: Iain, what do you think is required or would be helpful for DPV to provide for P7012?
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.
iainHenderson: 2) Purpose - The DPV purposes are not complete, the descriptions could be more detailed. Have some ideas on these as well.
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
georgKrog: so you have a purpose, and then you are modelling the minimum data required to achieve that purpose?
iainHenderson: yes, the extension is there to describe this in detail for specific sectors.
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
iainHenderson: yes, trying to explain to the UK Gov. that this can be done to simplify agreements
ACTION: Iain to propose concepts for purposes, data, and combinations of these for specific sectors for P7012
Technology Provision
<ghurlbot> Issue 207 [Concept]: Change `TechnologyProvisionMethod` concepts e.g. `tech:System` to `tech:ProvidedAsSystem` (by coolharsh55)
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.
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?
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)
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
georgKrog: +1 for n.1
julianFlake: +1 for n.1
ACTION: Change TechnologyProvisionMethod concepts to have prefix ProvidedAsX
RISK
<ghurlbot> Issue 181 Refine RISK taxonomy into a single consistent hierarchy (by coolharsh55)
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.
discussed and agreed to remove the warning
SECTOR
<ghurlbot> Issue 204 Create Sector Extension (by coolharsh55)
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)
georgKrog: within each sector there will be domains that are the same, so maybe having domains is an alternative?
harsh: what do you mean by sector and domain here?
georgKrog: e.g. the HR in Health and Finance being two different things
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
georgKrog: yes, modular is better - so let's go with that approach
Discussion concluded with agreement on using modular approach for sector
ACTION: Use modular approach in SECTOR extension for each sector
Finalise Scope of DPV 2.1
<ghurlbot> Issue 198 DPV v2.1 release management (by ghurlbot)
harsh: Do we stop the process of discussion and additions, and finalise what we have as of now as DPV 2.1?
delaramGolpayegani: +1
georgKrog: +1
julianFlake: +1
tyttiRintamaki: +1
julioHernandez: +1
paulRyan: +1 (retrospective)
iainHenderson: +1 (retrospective)
beatrizEsteves: +1 (retrospective)
Conclusion to finalise DPV and release it as v2.1
ACTION: Finalise and publish DPV 2.1 for review
Next Meeting
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.
ACTION: Circulate internal poll for next year's meeting schedule
ACTION: Inform participants there will be no meeting next week