Meeting minutes
Repository: w3c/dpv
Meeting minutes: https://
purl for this meeting: https://
Integrating AIRO/VAIR
see issue #143
<ghurlbot> Issue 143 Integrate AIRO/VAIR concepts for AI and AI Act vocabulary (by coolharsh55) [todo] [help-wanted] [AI] [eu-aiact]
We reviewed the concepts proposed to be integrated from AIRO/VAIR using this spreadsheet - https://
AIRO
harsh: have added notes under the column ed-note - most concepts are okay to integrate. So we will discuss the differences / open issues.
harsh: for airo:AILifecyclePhase I think we should use Stage rather than Phase as that is the term used in the ISO 22989 document. I tried to understand the difference between phase and stage, and apparently it is that phase is fuzzy it can go across different activities whereas stage is expected to be more discrete and things move from one stage to another.
harsh: airo:Change refers to AI Act requiring assessment of change. Delaram to review the concept resolution comment.
harsh: For risk controls, have added properties as discussed before e.g. risk:mitigates and the concept risk:MitigationControl as its domain and dpv:RiskConcept as its range.
harsh: For data, suggest we add tech:hasInputData and tech:hasOutputData along with classes for input/output data to enable expressing use of data in a technical manner while the main DPV continues modelling the legal context.
VAIR domains
harsh: These domains would be useful in other places as well. So perhaps we should add a note stating we may move this concept elsewhere?
delaramGolpayegani: yes, that is okay - we are providing these concepts as they are needed for AI Act e.g. to model the high-risk categorisations.
VAIR AI
harsh: Concepts are mostly resolved. My only reservation is regarding ai/tech:MultiAgentSystem which I don't think we should model right now because the term Agent is also used in the legal domain and in AI domain its use is quickly evolving to a controversial stage because it also refers to independence. So we can look to model this carefully in v2.2.
group agreed to this resolution
VAIR component
harsh: Concepts are mostly okay, except for the use of tech:Component which in TECH is a role or a provision method rather than actually stating it is a component or a part. So we model those as dpv:Technology instead. The other change is tech:Platform which is also a relevant concept for DSA/DMA so we can reuse it there.
VAIR capability
harsh: Have added top concepts here to try to create a hierarchy. The only two concepts that need discussion are ai:SensitiveAttributeInference and ai:Profiling. For ai:SensitiveAttributeInference - there is no source in 22989. Do you rememner where this was obtained from?
delaramGolpayegani: probably from an earlier version of the AI Act - the parliament version.
harsh: Okay, IMO this is too specific and we shouldn't model this if isn't strictly needed in the context of AI capabilities. We can model it using DPV infer as processing and sensitive data.
delaramGolpayegani: Profiling in AI Act is dependant on the GDPR definition of profiling.
harsh: Okay, so in DPV we have just a generic definition of profiling. So the only difference here should be the use of AI to do profiling. Hence the simple defintion. We should model profiling as defined in GDPR in the EU-GDPR extension.
paulRyan: +1
georgKrog: +1
delaramGolpayegani: okay, so we add the definition in AI extension, but not the AI Act extension. If it is needed, we can extend it as a concept in the AI Act extension.
VAIR technique
harsh: all concepts are fairly technical and don't need any changes as such.
VAIR provision
harsh: These concepts existing in TECH, so nothing to be added here. Though in TECH, we model Software as a type of technology rather than a provision method as software can be provided as a product, service, etc. Safety component is defined in AI Act, so perhaps it is not needed as a subtype of component in TECH.
VAIR risk
harsh: am yet to review these
delaramGolpayegani: not sure how to model these as specific risk concepts
harsh: I just create a column called Role and then enter S,R,C,I to indicate which category of risk concept it is, and then the table is generated automatically. I can review these concepts to see how to do that here.
georgKrog: the CEN/CENELEC work on standards is currently having issues with the definition of risk in ISO 31000 series as it is incompatible with the requirements of the Act
delaramGolpayegani: the definition in the AI Act is that risk is a combination of likelihood and severity for a harm. The one in ISO is generic.
harsh: What does this mean for DPV? We have defined risk also as a negative event but haven't included likelihood and severity in the definition. I think its mostly compatible?
delaramGolpayegani: I think so.
harsh: Let's check with Dave. He would have more context about the risk definition being discussed.
VAIR stakeholders
harsh: Propose we model the organisation types in DPV as they will be useful also elsewhere - have created a structure for this in the spreadsheet.
delaramGolpayegani: The AI Act has a definition for law enforcement authority
harsh: Wouldn't these concepts be commonly well known? Or is the AI Act redefining what they mean? I don't think so. But if they are needed in the AI Act, then we can extend them to state the entity as defined in the Act.
delaramGolpayegani: There is also the question of how to model Agent as in agent acting on behalf of the entity.
harsh: As before, let's postpone this discussion as we should be careful in our approach for modelling agents as here they refer to the legal meaning and in the other place they were a technical concept. Is there a difference between Representative and Agent?
georgKrog: yes, they are different concepts
georgKrog: we can model these agents and state who they are acting on behalf of
harsh: Okay, let's make a note to discuss for v2.2: LegalAgent and its relation actingOnBehalfOf
ISSUE: Model Agent and LegalAgent
<ghurlbot> Created issue #197 Model `Agent` and `LegalAgent`
VAIR outputs
harsh: We are trying to model how the data is being used as an output? E.g. as an action, as a decision? So my worry is that the concept ai:Action might get mistaken to mean the action as an activity instead of being a data.
delaramGolpayegani: no, these are actions as in actions made by a robot
harsh: I see, so do we model these as SystemInput and SystemOutput?
delaramGolpayegani: maybe, but then how do we use these as an output of the model - which is different from a system?
harsh: good point, okay - so here some of these outputs may be data and ai:Content is always data. So we can represent content directly as output data, whereas for the other concepts we want to indicate how the outputs are being used i.e. their role. So can we remove ai:Content and model the rest as OutputRole? Delaram can make the decision of how to finalise this.
VAIR involvement
harsh: concepts are okay - two changes where I added prefix Entity here to indicate these are specific to entities and added parent concept EntityInvolvement to have this be in that taxonomy and allow the reuse of property hasEntityInvolvement along with hasIntentionStatus.
VAIR lifecycle
harsh: the ISO 22989 describes these stages with specific words, so added some more proposed concepts - Delaram to review and finalise. Also added concepts from ISO 15288 for software development which can be in TECH, and then we extend them for AI
VAIR documentation
harsh: concepts are okay, though some are quite long at 48 characters eu-aiact:PostMarketMonitoringSystemDocumentation - any way to shorten these?
delaramGolpayegani: could shorten Documentation to Doc ?
harsh: doesn't read well and the AI Act uses the full phrase - so maybe lets keep it for now
VAIR purpose
harsh: These are still WIP - what should do with these?
delaramGolpayegani: review them as is - I started working on these but it isn't clear how to align them with the DPV purpose taxonomy
harsh: in general, I think we want to keep the breadth of top concepts narrow and have as much depth as needed as it helps in the selection process. I will take a look at these.
Bias work
delaramGolpayegani: the concepts for bias that were proposed by me and Daniel will be present in v2.1?
harsh: yes, we discussed and accepted them.
delaramGolpayegani: there is also the work by Mayra tibonto/
harsh: okay, so what you can do is since we are adding your concepts to DPV, you can align these concepts with DPV v2.1 and then add them in v2.2
delaramGolpayegani: there is also an ontology on Machine Learning which we can mention for modelling more specific ML context
Note: to add these references to the HTML
v2.1 release
ISSUE: DPV v2.1 release management
<ghurlbot> Created issue #198 DPV v2.1 release management
harsh: Let's use the remaining time to discuss which items we should complete in 2.1 and which ones to move in v2.2
harsh: so taking issues from https://
group discussed and moved issues to v2.2 future release
harsh: For the release itself, do we think we will have this completed by DEC-17 which is likely to be our last DPVCG meeting this year?
julianFlake: there is an issue for NIS2 - so is the NIS2 extension complete?
harsh: No, the issue is only for creating the NIS2 extension, which is done, so we will add more NIS2 concepts in the next release
georgKrog: there is a NIS2 consultation paper recently published by ENISA (probably this - https://
georgKrog: there is also a Data Spaces webinar on NOV-22 (to be shared on mailing list)
julianFlake: we can have a release candidate in December, and then we have a final release in January
group agreed to this approach
Next Meeting
next meeting will be in 1 week on TUESDAY 19 November at 13:30 WEST / 14:40 CEST. Agenda will be discussing AIRO/VAIR integration, selecting the next set of items/issues on GitHub with any updates on github/mailing list and AOB. This meeting we also continue discussion and resolutions for publishing DPV 2.1 release.
harsh: Two important topics that are relevant for DPV 2.1 and we should aim to support them. First is the AI/AI Act stuff -we went through that today and we will be able to integrate that. Second is the set of concepts required for P7012 use of DPV, which I will discuss and propose together with Beatriz.