Meeting minutes
Repository: w3c/dpv
Agenda: https://
Meeting minutes: https://
Persistent ID for current minutes: https://
AOB
Incident Notifications
<ghurlbot> Issue 282 Incident and Data Breach Notifications (by Gogga)
GeorgKrog: Have added notification and reporting information for Cyber Resiliency Act (CRA)
HarshPandit: CRA isn't covered in DPV yet, so we should first add that to the legal extension and model basic stuff like entities, etc. and then add in incident notification and reporting; For discussion on these, suggest we break down the main issue into sub-issues to discuss each specific regulation/law
ACTION: Create sub-issues for #282 for each law
EHDS
GeorgKrog: Mapped entities based on the published version as the current DPV version is outdated and based on an earlier draft. There are 27 tabs and 250 new concepts to be considered, which I am currently reviewing.
HarshPandit: We can copy over the completed proposals to the DPV spreadsheet for EHDS and discuss using that, starting with entities.
ACTION: Copy EHDS entities proposed concepts to DPV spreadsheet
Subjective Locations
<ghurlbot> Issue 209 [Concept]: `AtX` subjective Location concepts (by coolharsh55)
HarshPandit: Continuing discussion from last week, we have the proposal that location concepts be modelled in other extensions where possible -- especially PD and TECH -- to avoid duplicate concepts and ambiguous interpretations e.g. whether it is personal data. The public/private categorisation already exists in DPV, so we will add additional concepts there to represent ownership and accessibility. For other locations, which might be needed in law e.g. AI Act Annex III to represent where the location is taking place, we have to consider whether they are locations or types of entities, and model accordingly. If there are indeed location concepts that are missing, we should identify and discuss them in the specific use-cases so as to have a better idea of the need for these concepts and to avoid creating arbitrary taxonomies.
DelaramGolpayegani: There are location concepts in the prohibitions in AI Act i.e. the prohibitions are based on them.
ArthitSuriyawongkul: For locations define in the LOC extension, how to express processes like export control which use a different notion of what is considered part of one jurisdiction or country e.g. "Ukraine except Crimea and the occupied territories of the Donetsk and Luhansk regions"
HarshPandit: The DPV LOC taxonomy is based on ISO concepts, so for specific country-based interpretations or recognition, these should be modelled within that country's legal extension. Perhaps it is a good idea to put some guidance on this in the LOC extension.
ArthitSuriyawongkul: Or a disclaimer about the interpretation and use of the LOC taxonomy for geo-political representations
ACTION: Add a notice/disclaimer to LOC regarding concepts only covering ISO notion of jurisdictions
AI cards
<ghurlbot> Issue 281 Represent AI Cards with DPV (by DelaramGlp)
to decide whether AI cards are in scope of DPVCG or not
GeorgKrog: AI Cards also used in other places, what do you mean by "AI Cards" for this work?
DelaramGolpayegani: AI documentation for use of AI systems that can provide an executive summary type of representation backed by machine-readable information
GeorgKrog: Other places where such cards are used are for AI agents to specify tasks and delegations etc. And as Factsheets from vendors e.g. to specify what is the intended purpose, domain, risk assessment, for San Jose city
ArthitSuriyawongkul: https://
ArthitSuriyawongkul: This is based on IBM Factsheet 360 which also provides a summary view
GeorgKrog: We should also think about records for AI agents to state information similar to consent records. With the factsheets, the main task is to specify the intended purpose.
ArthitSuriyawongkul: Can this be an example to test our DPV concepts?
GeorgKrog: Yes, e.g. how many CCTVs are in Dublin that do facial recognition
ArthitSuriyawongkul: I think so far we don’t work so much with procurement. (I think we really focus on the rights protection, where rights is individual rights) But if DPV goal (future goal too) is something to do with procurement, it can be yes.
HarshPandit: Procurement is a very big process, e.g. see the eProcurement ontology used by the EU, and it involves additional information such as financial history and functioning of an organisation which are not currently in scope of the DPVCG. Therefore, it is unlikely that we will produce procurement-specific work. However, we do have an overlap or intersection e.g. procurement requires meeting criteria or having documentation -- which is something that the DPV concepts and specifications can help provide.
DelaramGolpayegani: How does DPVCG decide whether something is in scope?
HarshPandit: Other CGs have formal charters and documents which specify their objectives. For us, we don't have that level of detail (due to manpower/volunteers) but our CG W3C page lists the broad objective we are focusing on. First test is whether the work is compatible with that. In the past, we had to expand that statement to accommodate both data and technology concepts. So on a conceptual level, the test is whether it is about data and technology. In this case, we know that the information in AI cards is in scope, so what we are currently discussing is whether creating a specification or guide document for stating how and what are AI Cards and how they can be created using DPV concepts is in scope of the group. This is based on consensus and whether someone is willing to do the work.
DelaramGolpayegani: Is it a factor that this work isn't well-known or used elsewhere?
HarshPandit: Not necessarily. We have done original/novel work in the past e.g. Paul's work on ROPA records, the data breach and incident reporting work, or the rights exercise work. So as long as we are not disregarding any well-established work and we can show the benefits and progress of DPV by doing it, then it is a good exercise.
no objections to the work, so we default to acceptance as the work is in scope and aligned with the existing DPV specifications -- this has +1 from GeorgKrog, HarshPandit, ArthitSuriyawongkul; discussion to be continued next week
Representing Use-Cases
<ghurlbot> Issue 284 [NEW]: Modelling Intended Uses/Purposes as Use-Cases (by coolharsh55)
continued discussion
HarshPandit: The need for this concept comes from having to represent hypothetical scenarios and specific uses and associating them within documentation. The existing concept dpv:Process is ambiguous for this as it isn't clear whether it is referring to something that is planned, being done, or is a log of having been done. Further, there are phrases such as "intended use" in law which need to be specified as the intent and part of the documentation, while there are others such as recommended uses or prohibited uses or known problematic uses which are also needed to be associated. Putting this information inside the process is not ideal as it requires scanning and filtering to identify if there are specific processes that are e.g. problematic. Instead, this UseCase concept will provide a convenient way to say "these are the problematic use-cases". See https://
ArthitSuriyawongkul: What about "intended task" in the AI Act?
DelaramGolpayegani: There isn't that specific phrasing in the AI Act, but there is "intended purpose", "intended to be used", and "tasks" mentioned
ArthitSuriyawongkul: My understanding is that the reason they don’t use the word “purpose”, in Annex XII, is because it is a general-purpose model and the model provider is not the one who decide which use cases or purposes the model will get applied for. i.e. At the time of general-purpose model development, the developer don’t have an ability to know.
HarshPandit: There "general-purpose" means there isn't one single purpose and it can take on any purpose, so it cannot be based on purpose as in specific use-cases.
HarshPandit: For the AI Act and other regulations, we extend the UseCase concept to match legal terminology i.e. as ai-act:IntendedPurpose
DelaramGolpayegani: What information should go within the use-case / intended use?
HarshPandit: That depends on the where the use-case is being applied or interpreted. E.g. in the AI Act, there would be specific requirements on what is meant by intended use, which means there should be specific concepts within the use-case to describe and meet these criteria.
ArthitSuriyawongkul: Purpose as a generalisation for use cases ?
HarshPandit: No, purpose is still a specific granular concept. dpv:Process is the parent concept of UseCase as all use-cases are describing some process.
discussion to be continued next week, currently we have +1 from GeorgKrog to adopt the concept, no objections
Next Meeting
The next meeting will be on MAY-08 Thursday 13:30WET/14:30CET
Agenda will be continuing on topics started under v2.2, and any other updates that come up.