Meeting minutes
Repository: w3c/dpv
Agenda: https://
Meeting minutes: https://
Persistent ID for current minutes: https://
v2.2 release
agreed to finalise in June, publish in July after commenting period
set schedule to finalise in June, release in July (v2.2); then next one is finalise in December and release in January (v2.3), and this will be our regular release schedule
ACTION: finalise v2.2 draft release
W3C TPAC
HarshPandit: The W3C TPAC is being scheduled. Should the DPVCG have a session during the community group portion? Typically, it costs to attend the W3C TPAC. In previous years we have done a virtual session which aligned with the event but outside of it, this was a combined session with ODRL CG. Attendance was poor.
yes we should have it as a virtual event (+6 from people)
Is ODRL CG having a meeting? Do we want to collab with them like previous years?
ACTION: Harsh will check with Victor (ODRL CG chair)
Rules
Rules ⟵ Use-Cases
<ghurlbot> Issue 284 [NEW]: Modelling Intended Uses/Purposes as Use-Cases (by coolharsh55)
continued discussion
previous discussion: issue with "Use-Case" as a term as it implies users, interactions, etc. based on its use in software/systems engineering domains; we discussed alternatives such as scenario, policy, etc.
HarshPandit: as discussed in previous meeting, we want concepts to represent or indicate something is [acceptable, unacceptable, permitted, prohibited, recommended, deterred] and separately it is [intended]; to represent this, we discussed over several meetings alternatives, and the current proposal is as follows.
HarshPandit: Reuse existing Rules concepts rather than creating new ones such as use-cases or uses which lead to ambiguity;
… the rule taxonomy would be as follows with parent dpv:Rule and relation dpv:hasRule based on keywords from RFC2119
HarshPandit: dpv:AcceptableRule (new) (no property) with subclass dpv:Permission (exists) dpv:hasPermission corresponding with RFC2119 keyword MAY with subclass dpv:Obligation (exists) dpv:hasObligation corresponding with RFC2119 keyword MUST ; and with subclass of acceptable as dpv:Recommendation (new) dpv:hasRecommendation) corresponding with RFC2119 keyword SHOULD
HarshPandit: dpv:UnacceptableRule (new) (no property) with subclass dpv:Deterrence (new) dpv:hasDeterrence (note: deterrence has multiple meanings, we are using it as "to turn aside, discourage, or prevent from acting" – Merriam-Webster corresponding with RFC2119 keyword SHOULD NOT); with subclass dpv:Prohibition (exists) dpv:hasProhibition corresponding with RFC2119 keyword MUST NOT
HarshPandit: previously Julian enquired whether we have a concept to model MAY NOT, and the argument was that it is the same as MAY i.e. it does not change the action. However, the concept dpv:Tolerated with dpv:hasTolerance was indicated to indicate something may not happen i.e. there is a tolerance regarding it, it has not been added to this list due to not being normative
ACTION: Add new Rules
Acceptable Use
HarshPandit: The goal of these concepts is to assist with modelling/representing cases where specific actions have to be indicated as being allowed / recommended etc. To model these, we propose two concepts based on common terminology with parent the existing dpv:Policy and dpv:hasPolicy as dpv:AcceptableUsePolicy and dpv:hasAcceptableUsePolicy and dpv:UnacceptableUsePolicy and dpv:hasUncceptableUsePolicy These policies will then contain details, including any rules (obligations, prohibitions, recommendations, etc.) and can be attached to specific products, services, technologies, etc.
PaulRyan: haven't come across UnacceptableUsePolicy as a term – is not used in practice (is there a need? is there an alternative for this?)
HarshPandit: agreed, modelled this to represent unacceptable uses section, but let's keep it proposed for the moment until there is certainty
HarshPandit: @beatriz is this compatible with ODRL?
BeatrizEsteves: yes, this is compatible, except in ODRL the obligation is called duty concept, but the meaning is the same
Agreed on above, except for UnacceptableUsePolicy to be kept as proposed, and not adding Tolerated (MAY NOT)
ACTION: Add Acceptable Use Policy
AI Act Intended Purpose
HarshPandit: To model the intent as required for AI Act's Intended Purpose, the existing concept of tech:IntendedUse should be kept, and AI Act's eu-aiact:IntendedPurpose should be extended from it (currently it is not)
Agree to model intended use (as it exists) and make the AI Act's concept as a specialised form of it; and for the regulation specific concepts e.g. for GDPR and AI Act, we add a note saying we are exploring how to model these in future releases e.g. Purpose Compatibility and its outcomes (see reuse concepts)
ACTION: Modify AI Act Intended Purpose concept
Secondary Use
<ghurlbot> Issue 283 [NEW]: Secondary Uses for Data Reuse (by coolharsh55)
confirming the below to be added to v2.2
add dpv:ReuseCompatibility with dpv:hasReuseCompatibility with dpv:PrimaryUse – use is as per the primary context/goal; dpv:PrimaryInitialUse - use defines the initial or first primary use and is the basis for future comparisons of compatibility; dpv:PrimaryCompatibleReuse - use has a different context but is compatible with the primary initial use; dpv:SecondaryUse - use is not compatible with the primary use
HarshPandit: Question: do we add the regulatory concepts for GDPR and AI Act and EHDS now or do we add with guidance later in v2.3?
MarkLizar: compatibility from whose perspective, use-case cenetered around humans, … (Discussion, ref to HUMAN extension)
BeatrizEsteves: EHDS use for these concepts / structure
Agree to add these concepts to 2.2, with regulation specific concepts being added to 2.3 based on requirements and interpretations (add note about this in 2.2 docs)
ACTION: Add reuse concepts to v2.2 with a note on what's coming for v2.3
Operating Factors / Environment
<ghurlbot> Issue 285 [NEW]: Modelling Operating Factors for Technology (by coolharsh55)
confirming the below for v2.2
BeatrizEsteves: add tech:OperatingFactor and tech:hasOperatingFactor and add tech:OperatingEnvironment and tech:hasOperatingEnvironment ; will support specifying product/service uses and considerations e.g. what works, what is required, etc.
Agree to add these to 2.2 with note on why these concepts exist/why they are helpful, what can be factor, what can be environment and so on (and that we're exploring modelling these in detail in future releases)
ACTION: Add operating factor and environment concept for v2.2 with note
Updates
TAIR
JulioHernandez: mapped TAIR with AI Act extension, will share when done
DPIA
TyttiRintamaki: submitted proposal on Github with concepts categorised based on extension
MLDCAT-AP
HarshPandit: https://
Next Meeting
The next meeting will be on JUN-26 Thursday 13:30WET/14:30CET
Agenda will be finalising DPV v2.2 scope and release, and starting work on v2.3