W3C

DPVCG Meeting Call

27 MAR 2025

Attendees

Present
arthitSuriyawongkul, delaramGolpayegani, harshPandit, iainHenderson, julioHernandez, paulRyan, stratisKoulierakis
Regrets
georgKrog
Chair
harshPandit
Scribe
harshPandit

Meeting minutes

Repository: w3c/dpv

Agenda: https://www.w3.org/events/meetings/178d1c71-a92d-4da7-a196-6a89d0fe2277/20250327T133000/

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

Persistent ID for current minutes: https://w3id.org/dpv/meetings/meeting-2025-03-27

Admin

wiki

harsh: Moved content from w3c wiki to github wiki and set it so that anyone can edit it. Please help maintain. The wiki can be used to share information about guidelines, FAQ, discussions without requiring code changes in repo.

github issues

harsh: There are more (new) issues on github which are not on the agenda, please take a look

github PRs

harsh: Any suggestions or changes needed for how PRs are created and addressed?

<ghurlbot> Issue 262 Refactor documentation generator to be modular (by coolharsh55)

<ghurlbot> Issue 266 Use stable IDs for contributor and webpage BNodes to avoid false git diffs (by coolharsh55)

arthitSuriyawongkul: fix #262 and #266

beatrizEsteves: make clear to which branch we should submit

harsh: That is complicated, unfortunately. Dev branch is where we work on next version, so everything for the next version should go to the dev branch. But if we want to fix something in the published current version, then the master branch contains the code and files for it at that point in time. But in any case, I think dev branch is better as it also contains the versioned outputs (not the same scripts, but we can still do it)

arthitSuriyawongkul: how to change code directory for previous versions (answer - the code is for the current version of the branch, previous versions are overwritten but are available in git history)

Legal extensions for East/SouthEast Asian jurisdictions

<ghurlbot> Issue 253 [Concept]: Legal Concepts for East Asian and Southeast Asian jurisdictions (by bact)

accepted, except pending discussion on new authority categories – to be taken alongside authorities in AI Act, DGA, etc.

stratisKoulierakis: consideration for AI Act re. AI authorities where DPA and AI authority might coincide in some cases

v2.1 maintenance

broken link

<ghurlbot> Issue 269 [FIX]: link broken to DPV 2.1 Search Index (by TyttiKatariina)

harsh: What should be done for such changes to already published documents? Suggestions?

julianFlake: how did these happen? will this happen again?

harsh: maybe, this happened because the link was hardcoded with the version number (2.1-dev) and when we published it we changed the version number. The solution is to not use version numbers in links directly, but to use the variable in python script which is always set to the correct version so the links also get updated.

julianFlake: that's okay to do it if its one fix

harsh: only place where it won't be fixed is github release zip - but for that we can publish a minor point release e.g. 2.1.1

ACTION: fix #253 in live version on github and discuss minor point release

broken purl redirect

<ghurlbot> Issue 270 [FIX]: Info on w3.org home needs update / dead link (by bact)

ACTION: ask w3c to redirect dpv namespace to w3id

AI Act risk classification

<ghurlbot> Issue 231 Represent Risk Level classifications for AI/Systems in AI Act (by coolharsh55)

delaramGolpayegani: proposal with Harsh that we add the categorisations based on whether something is high-risk or prohibited in AI Act using a combination of concepts - for high-risk it is 5 concepts (see this paper "To Be High-Risk, or Not To Be—Semantic Specifications and Implications of the AI Act’s High-Risk AI Applications and Harmonised Standards" https://doi.org/10.1145/3593013.3594050), for prohibited it is 8 concepts (not published yet).

<ghurlbot> Issue 183 Represent activities where DPIA is required in EU-GDPR (by coolharsh55)

harsh: This is also relevant to Tytti's work on DPIA requirements in various jurisdictions - for GDPR

harsh: where to publish this? In AI act extension? Benefit is we have everything in one place in the extension - we can put disclaimer and notices in appropriate places in HTML. One issue might be that this is our interpretation and not the information in the act - so we should not put it in the same extension; or that the person using the RDF or data might not see the notice / warning in the HTML

harsh: this could be done for e.g. by having a HighRiskCategorisationProcess as a proces and within it the combination e.g. purpose X capability Y and a hasRiskLevel ai-act:HighRisk and then this is the 'template' to use for detecting if something is high risk or not

delaramGolpayegani: would be good idea to have it in the same extension

harsh: we could have examples to see how this looks and discuss it further

paulRyan: +1 to discuss with examples

beatrizEsteves: +1

ACTION: Discuss AI Act risk classification with examples

Stratis' Thesis

<ghurlbot> Issue 278 [NEW]: Misc concepts based on GDPR CoC and Certifications (by coolharsh55)

presentation slides "The Importance of Expressing GDPR Codes of Conduct and Certificates in Machine Readable Format" https://lists.w3.org/Archives/Public/public-dpvcg/2025Mar/0005.html

stratisKoulierakis: DPV should incorporate and be aligned with Codes of Conduct (CoC) and certifications under GDPR as these contain specific terminologies which are legally relevant. Proposal from my thesis. This can be done by incorporating the concepts and creating like a profile of DPV or providing guidance on how to create profiles of DPV for specific use-cases.

stratisKoulierakis: Examples: class Organisation - extend with Credit reporting agency, Private education institution; Purposes - grid management (with further examples in grid management CoC), meter management (with further examples in meter management CoC); Technical measures - Age check practices, Zoning, Email deletion; Organisational measures - Flagging AI outputs, Video monitoring, Personnel screening

harsh: language is sometimes not consistent

stratisKoulierakis: indeed, language can change - and we should remember that these language are from multiple languages or can be translated from these languages, so we should focus on the concept itself

harsh: what do you suggest by profiles? We have started adding an alignment table listing concepts in law and saying which are compatible concepts in DPV - is this is the same?

stratisKoulierakis: ODRL for example has Market Data profile - so I'm wondering if something similar can exist for DPV, would be happy to contribute to that

arthitSuriyawongkul: The energy sector examples can be relevant to Cyber Resilience Act. Smart meter is probably a Class II device in CRA (chat)

paulRyan: Find the CoC and specifications area to be interesting as this is related to my work (on ROPA specifications) as it enables covering the CoC or certification which is a very manual process and this can be an opportunity for automation

harsh: should think about how to best do this and then do it

beatrizEsteves: we can take CoC as an example of what we want to support with DPV-ODRL mapping

paulRyan: merit in Art.42 certification as this is massively a manual effort at the moment (for GDPR)

delaramGolpayegani: CoC for AI being developed for AI Act, with certifications and presumption of conformity

No updates

<ghurlbot> Issue 209 [Concept]: `AtX` subjective Location concepts (by coolharsh55)

<ghurlbot> Issue 208 [Concept]: Add Non-X (X = specific location) to represent locations that are not X (by coolharsh55)

<ghurlbot> Issue 82 Provide vocabulary to specify purposes and permissions related to AI training (by scottkellum)

Next Meeting

The next meeting will be on MAR-27 Thursday 13:30WET/14:30CET

Agenda will be continuing discussion on topics started under v2.2 and any other updates that come up.

Summary of action items

  1. fix #253 in live version on github and discuss minor point release
  2. ask w3c to redirect dpv namespace to w3id
  3. Discuss AI Act risk classification with examples
Minutes manually created (not a transcript), formatted by scribe.perl version 217 (Fri Apr 7 17:23:01 2023 UTC).