Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
ICO Information Audit
<ghurlbot> Issue 202 [Concept]: InformationAudit (by Paul-Ryan76) [review] [DPV]
paulRyan: The ICO accountability framework has a concept Data Mapping for ROPA which is about identifying personal data in an organisation
georgKrog: +1 though the concept is very vague
harsh: agreed the concept is useful as it comes from ICO, though data mapping already has another well defined interpretation in the technical sense, so this would create confusion. We can use the term Information Audit which is more general but well defined, which can involve both personal data and non-personal data. We can specialise if needed. It will then be under Audit as part of the Organisational measures.
ACTION: Paul to create github issue proposing InformationAudit as the term to be included in DPV Org measure
EHDS
<ghurlbot> Issue 201 Support EU Health Data Spaces (EHDS) as an extension (by coolharsh55) [legal]
See https://
Georg found the HealthDCAT-AP spec being developed for pilot EHDS implementation includes DPV concepts for legal basis, personal data, and purpose. But it doesn't use DPV taxonomies.
georgKrog: spoke with the EC person responsible for the new data space, so this is fantastic news that DPV is recommended, and they want to promote such efforts further for EC data spaces
harsh: propose we support this initiative by creating the EHDS extension under legal/eu. The EHDS itself is being finalised, and will be formally published early next year. Like other regulations, we can provide specific concepts from it to be used within efforts such as HealthDCAT-AP.
georgKrog: would also be a good idea for DPV to be introduced to SEMIC.
beatrizEsteves: I had started work on the EHDS extension as part of the PhD at UPM earlier, but then didn't continue it. See besteves4/
harsh: question is whether we include this extension (as draft) now in v2.1 or wait for v2.2 to provide it? Early would be better for liasing with adopters.
georgKrog: +1 for providing it now, would be good to show EC how we can quickly adapt and provide such extensions
paulRyan: +1 for now
beatrizEsteves: +1 for now
agreed to provide draft EHDS extension in v2.1 release, then refine is as EHDS is published in Q1 2025 for v2.2
ACTION: Create draft EHDS extension for v2.
W3C
harsh: Spoke with W3C (Iain, Dom) - they are changing the way community groups like DPV operate. They want to encourage such CGs produce work that eventually leads to a working group (WG) and then a w3c standard (Recommendation in W3C terms). They are also changing the way github repos work - there is now a separate organisation called w3c-cg for hosting such repos. They are not changing existing repos right away to avoid breaking stuff.
harsh: I am talking to them more about this later in the coming weeks as I think we already have done sufficient work to discuss a WG and how that will work. However, I have also communicated my concerns about the nature of our work (privacy, legal) and its potential dilution or misinterpretation by specific actors within the standards development process. I have also mentioned that such WG would benefit from involvement of CG who were instrumental in making the CG spec.
harsh: personally, what I think might happen if DPV were to be taken up as a WG and then becomes a standard, is that the core concepts (e.g. data, legal basis, purpose) etc. would become a standard ontology, whereas the taxonomies etc. would be contested and won't get the adoption or the agreement. It would still be a good outcome as DPV-core becomes a standard and then it increases the adoption and leads to more adoption and extensions. However, that is far down the line - maybe up to 5 years to have this process.
harsh: the W3C folks have also mentioned that they will provide help for CGs who don't fit well within w3c or don't plan on creating w3c specs to find a home elsewhere in the future.
georgKrog: there is also another option in that if we are focused on EU regulations and use-cases, then the EC can help find us a home to house DPV within the EU frameworks, e.g. in SEMIC of elsewhere as a strategic tool to support EU compliance and ecosystem
harsh: It is also a question of funding and sustainability as DPV is currently completely volunteer led and we want to make sure it has a continous improvement and development cycle as its adoption relies on it.
note this discussion had not conclusions as such, merely discussions
Purposes
<ghurlbot> Issue 204 Create Sector Extension (by coolharsh55) [WIP] [sector]
harsh: Have added about 300 concepts based on the AIRO/VAIR concepts, with rephrasing of the terms to fit existing DPV naming practices, and also introducing new terms to balance the taxonomy with other purposes falling within the same broad concept. These 300 concepts include general purposes such as HR (jobs, hiring) which are present in lots of areas, and also sector specific purposes such as education, finance, healthcare, law enforcement and such - which VAIR modelled based on the AI Act's Annex III high-risk use-cases.
georgKrog: These purposes (for sectors) would also be useful for NIS2 and DORA implementations. NIS2 has critical infrastructures where we can use DPV to describe security aspects, and we can represent the processes associated with security. And we can combine what Jenny has for TOMs developed for NIS2. There NIS2 has more purposes for critical infrastructure which will be needed.
beatrizEsteves: agree but we should discuss whether main DPV is the place to house these new concepts e.g. DPV-PD was created as we wanted to move the taxonomies out of the main DPV spec. So I wonder if we should do the same for the sector purposes here, and if we move all purposes out of DPV, then it would be DPV 3.0 (bump version number for major / backwards incompatible changes).
paulRyan: agree with Beatriz's assessment here regarding the sector purposes.
julianFlake: agree with Beatriz, we should think about this for future releases
harsh: we can put the domain specific purposes in a separate extension while the main DPV spec keeps the general purposes. This would ensure there is no backwards incompatible change, and we also avoid the issue of having too many purposes for different sectors in the main DPV spec. For PD, the issue was also the overlapping concepts e.g. location of data vs location as personal data, which isn't such a problem here, but the sectors will also have such concepts but their meaning will be the same.
georgKrog: how will this work for implementations e.g. for our customers?
harsh: you can ask for domain and then filter the list of purposes based on that
georgKrog: if the focus is on service side of things, then it is useful to have separation of domains e.g. domain specific uses would benefit where we are focused on compliance.
… question now is whether we do this extension in v2.1 or we wait for v2.2 and then decide how to go about it. Benefit of doing it now is we get added exposure and benefit e.g. we can directly model NIS2 and AI Act regulated sector specific information. Benefit of doing it later is more discussions and more time to review etc.
beatrizEsteves: we can do the extension now and see it how it goes.
julianFlake: keep top concept in DPV, taxonomy in extension.
harsh: propose we keep all concepts in the extension (for sector specific stuff) - and keep the extension as draft so that if there are issues we can change it in the future.
georgKrog: +1
paulRyan: +1
julianFlake: +1
beatrizEsteves: +1
agreed to create the sector extension
beatrizEsteves: what should we call it - sector or domain?
harsh: sector would be preferred as we already have the concept dpv:Sector and it is also well defined elsewhere.
ACTION: Create Sector extension.
Next Meeting
next meeting will be in 1 week on TUESDAY 10 December at 13:30 WEST / 14:40 CEST. Agenda will be discussing publishing DPV 2.1 release.