W3C

DPVCG Meeting Call

12 JUN 2025

Attendees

Present
BeatrizEsteves, HarshPandit, JulianFlake, JulioHernandez, StratisKoulierakis, TyttiRintamaki
Regrets
DelaramGolpayegani, GeorgKrog
Chair
JulianFlake
Scribe
HarshPandit, JulianFlake

Meeting minutes

Repository: w3c/dpv

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

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

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

Representing 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.

Alternate proposal

refined proposal https://harshp.com/dev/dpv/use-cases-02

Method 1: we continue using dpv:Process e.g. hasRecommendedProcess

Method 2: we continue using dpv:Rule e.g. hasRecommendation

For Intended and Acceptable concepts, we should use something else as these are interpretations or findings and not instructions in the same deontic set as others (e.g. recommendation = SHOULD, deterred = SHOULD NOT). We continue using tech:IntendedUse as it is defined, and we change the parent of eu-aiact:IntendedPurpose from dpv:Purpose to tech:IntendedUse. We add two "policy" concepts under the tech/org Policy concept for representing AcceptableUsePolicy and UnacceptableUsePolicy.

In documentation, we can then specify these directly by using the relations, e.g. for a given ex:Document rdf:type tech:Documentation, we can have: dpv:hasRecommendation dpv:Recommendation (+ e.g. dpv:Process) and dpv:hasProhibition dpv:Prohibition (+ e.g. dpv:Process), tech:hasIntendedUse tech:IntendedUse (+ e.g. dpv:Process), eu-aiact:hasIntendedPurpose eu-aiact:IntendedPurpose (+ e.g. dpv:Process);

Pros of doing this - we keep using our existing concepts and don't introduce new concepts as the discussion has shown that we do not have a consensus on the meanings and interpretations which is essential, and we don't have to update any of our guides or documentations as the core concepts have not changed. Cons - we don't use the exact same terms as others e.g. Acceptable Use. To specify these, we define these as RISK concepts to indicate their involvement as a consequence of something i.e. I assess a process and find it unacceptable and similarly for unintended. Note: Acceptable Use Policy (AUP) is the widely and formally used term and "Acceptable Use" is the same term with a different phrasing in most contexts

Discussion

Discussion of the different concepts around Permissions, Prohibitions, Obligations.

Current suggestion is to have 5 different concepts corresponding to: must, should, may, should not, must not. (comment for the notes: this list refers to RFC2119)

Concepts should probably not be suffixed with any term discussed last week (Use, Usage, UsePolicy, Process, etc.). The focus should be on the first part of e.g. "Prohibited(Use(Case))". Therefore concepts should be expressed by non-composite terms, if possible.

Intention, Recommendation are additional concepts that require appropriate terms.

Operating Factors / Environment

<ghurlbot> Issue 285 [NEW]: Modelling Operating Factors for Technology (by coolharsh55)

As proposed previously, for DPV 2.2, we are adding: tech:OperatingFactor and tech:hasOperatingFactor with definition as a factor that affects or influences the operation of the technology; tech:OperatingEnvironment and tech:hasOperatingEnvironment with definition as the environment (whether physical or virtual) within which the technology operates

no new discussions

Secondary Use

<ghurlbot> Issue 283 [NEW]: Secondary Uses for Data Reuse (by coolharsh55)

As proposed previously, for DPV 2.2, we are adding:

dpv:ReuseCompatibility with dpv:hasReuseCompatibility, and then dpv:PrimaryUse – use is as per the primary context/goal with 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; with dpv:SecondaryUse - use is not compatible with the primary use.

Question: do we add extended concepts from these for the regulations now in DPV 2.2 or later in DPV 2.3? (did not discuss below concepts)

for GDPR: Purpose Compatibility (defined in guidelines) we have eu-gdpr:PurposeCompatibility (parent: dpv:ReuseCompatibility), eu-gdpr:PurposeCompatible (parent: dpv:PrimaryUse), eu-gdpr:PurposeIncompatible (parent: dpv:SecondaryUse)

for AI Act: Intended Purpose Compatibility (mentioned but not defined e.g. see Art.3-23 substantial modification and Art.3-13 reasonably foreseeable misuse) we have eu-aiact:IntendedPurposeCompatibility, eu-aiact:IntendedPurposeCompatible, eu-aiact:IntendedPurposeIncompaible

for EHDS: Secondary Use (defined in law e.g. Chapter IV Secondary Use) we have eu-ehds:ReuseCompatibility, eu-ehds:PrimaryUse, eu-ehds:SecondaryUse

AOB

no updates for following items on agenda: TAIR (AI Act concepts), P7012, ODRL, EHDS, DPIA

Next Meeting

The next meeting will be on JUN-19 Thursday 13:30WET/14:30CET

Agenda will be finalising DPV v2.2 scope and release, and starting work on v2.3

Minutes manually created (not a transcript), formatted by scribe.perl version 217 (Fri Apr 7 17:23:01 2023 UTC).