Meeting minutes
Repository: w3c/dpv
Agenda: https://
Meeting minutes: https://
Persistent ID for current minutes: https://
AOB
Secondary Purposes for Data Reuse
<ghurlbot> Issue 283 [NEW]: Secondary Purposes for Data Reuse (by coolharsh55)
GeorgKrog: We should discuss secondary Use e.g. in Healthcare and in Public to Private Sector regarding secondary purposes and how they should be modelled in DPV.
HarshPandit: Yes, I sent a note on this to you (Georg) and Beatriz with a proposal that models SecondaryPurpose and TertiaryPurpose and how we can relate that to the existing dpv:Purpose taxonomy.
to put this on the agenda for next meeting
Security Notifications
<ghurlbot> Issue 282 Incident and Data Breach Notifications (by Gogga)
GeorgKrog: Proposed Security notifications for different laws -- we should model that in DPV.
HarshPandit: Agreed, though there are a lot of laws in it and we should first deal with laws that are in scope of DPV first and then take a look at the rest. Also the Commission is planning changes to these obligations. I read that GDPR and NIS2 are being harmonised regarding their security incident reporting. So we should prepare with this assumption that we want a common framework.
GeorgKrog: Agreed, let's go ahead with specific regulations and put them in DPV.
ACTION: Create granular issues for security notifications
Inversive Location concepts
<ghurlbot> Issue 208 [Concept]: Add Non-X (X = specific location) to represent locations that are not X (by coolharsh55)
group accepted to add these
ACTION: Add Inversive/Inverted concepts to RDF/HTML
Subjective Locations
<ghurlbot> Issue 209 [Concept]: `AtX` subjective Location concepts (by coolharsh55)
HarshPandit: We have several groups of ubjective locations – some are in DPV. We have 3 options to resolve these – 1) keep all of them in DPV, 2) mix them with fundamental concepts in DPV like Public/Private locations and move the rest e.g. taxonomy of home, work to LOC (breaks some concepts as we move from DPV to LOC), and 3) move all of them to LOC (breaks existing DPV concepts). Option 3 would be most suitable as all concepts would be in one namespace but this also would break stuff in existing DPV uses.
GeorgKrog: Also prefer in 1 place
ArthitSuriyawongkul: for local locations e.g. within app – distinguish between locations that we can go to (as Places) and the other is locations that we can put things in (as Containers)
GeorgKrog: Ringfencing e.g. within rather than outside the space
JulianFlake: What do we do this distinction? can we use it to model these concepts?
GeorgKrog: the distinction is important e.g. for court jurisdictions
JulianFlake: if person says they gave consent within app no one knows which country they were in. So there is more than just the definition which distinction of the term
HarshPandit: think within came from AI training e.g. within device and data being kept on device, and CCTV monitoring only the shop as within premises
ArthitSuriyawongkul: within device refers to virtual location (yes)
MarkLizar: model it as scope of disclosure regarding whether the location is relevant to the user or not e.g. locally or it is being sent somewhere online
HarshPandit: to georg and julian - what do we note for concepts like within device
JulianFlake: we should model this thoroughly alongside context for location
GeorgKrog: Agreed
ACTION: Arrange a separate session on Location with Georg and Julian
Datasheets and Model Cards
<ghurlbot> Issue 94 Represent Datasheets and Model Cards with DPV (by coolharsh55)
HarshPandit: Working on these to identify information and concepts. Some are outside the scope of the DPVCG so far and am trying to find other vocabs that could cover this e.g. metrics. For remaining concepts to be proposed, most important / different is the notion of use-cases to describe scenarios which can be stuff like intended uses or forseeable misuses. Rather than creating many different concepts trying to represent these, having an usecase as a concept makes it simple to describe what is being represented. Will share an email around this. The rest of the proposed concepts are relatively easier to understand and fit within the existing DPV taxonomies.
ACTION: Harsh to share proposal on modelling Use Cases
AI cards
<ghurlbot> Issue 281 Represent AI Cards with DPV (by DelaramGlp)
DelaramGolpayegani: propose adding AI cards as a form of technical documentation for AI. We already have concepts from AIRO and VAIR with which the AI cards were developed. These would go in the AI extension as they are generic for use with any AI, though they were built specifically with AI Act in mind. It complements other approaches like Datasheets and Model Cards.
GeorgKrog: we're trying to implement and code this in Signatu (sharing screen to demonstrate)
AI Act Risk Levels
<ghurlbot> Issue 231 Represent Risk Level classifications for AI/Systems in AI Act (by coolharsh55)
DelaramGolpayegani: To go with AI Act specific terminology. Commission uses limited risk but transparency required is more expressive so preferring that.
conclusion of discussion: risk levels are prohibited, high risk, transparency required, minimal, and unknown. Other levels will be discussed later with examples as guidance evolves.
Next Meeting
The next meeting will be on APR-24 Thursday 13:30WET/14:30CET
Agenda will be continuing on topics started under v2.2, and any other updates that come up.