Modelling Acceptable and Intended Uses as DPV Rules

In the previous meetings of the DPVCG, we have discussed the concept UseCase as a way to describe a scenario or situation at a broad level, which is then included in specific contexts such as whether it is permitted/acceptable, prohitibed, known to be problematic, etc. within documentation or as a reference. The motivation for this comes from the push from regulations such as the AI Act and from community documentation efforts such as the Data Sheets and Model Cards to specify (i.e. document) information described using words such as intended, acceptable, or prohibited -- which are followed by the context described using words such as use, purpose, and policy.

The initial proposal was to express each of these as a category of UseCase, so that we would have e.g. PermittedUseCase to indicate Actor A permits Actor B to carry out the specified use-case, and e.g. IntendedUseCase where Actor A expresses a deliberate desire or intent for themeselves or someone else to carry out the specified use-case. These concepts would then be extended in specific extensions to represent the legally relevant concepts and interpretations, e.g. in the AI-Act we would have IntendedPurpose as it occurs in the text as an extended concept from IntendedUseCase, and where we can add restrictions or criteria for what information should be present in such use-cases under the AI Act for them to be considered valid intended purposes.

These concepts would be useful then in documentation, e.g. when describing an AI system or a technology or a purpose, we would now have the ability to directly and explicitly specify which things should be avoided, or are permitted, or should not happen at all (i.e. are prohibited). The existing concept Process can also represent these activities and scenarios, but it represents a very broad and detached concept as it only represents activities or events. We can include information inside (i.e. associated with) the process to specify whether it was intended or acceptable or prohibited, but we also want the ability to indicate "this process is acceptable" as a relation between something and a process.

# using current style 
ex:D a tech:Documentation ;
    dpv:hasProcess ex:P, ex:Q . # don't know why P & Q are included here
ex:P a dpv:Process ;
    ex:hasIntention ex:Intended . # have to query/search to get this info
ex:Q a dpv:Process ;
    ex:hasAcceptability ex:Acceptable . # same - needs query/search

# proposed style
ex:D1 a tech:Documentation ;
    ex:hasIntendedUseCase ex:P ; # explicit that P is intended to happen
    ex:hasAcceptableUseCase ex:Q . # explicit that Q is also acceptable
ex:Q a dpv:UseCase . # but Q isn't defined as acceptable or prohibited
ex:D2 ex:hasProhibitedUseCase ex:Q . # interpretation changes across contexts

In later discussions, it emerged that "use case" as a term may not be suitable as it implies there is an actor that interacts with the system following from the established use of this term in software engineering. Though systems engineering also refers to the concept "use case" in relation to the functioning of a system. Upon further thought, I concur with the perspective here (with thanks to Julian), as "use case" implies there is some "use" and that implies there is possible a "user" or something that is being "used". This phrasing particularly diverts the interpretation towards descriptions where the system or software is being interacted with or upon by an actor. Whereas, what we also want to capture are things that should not happen regardless of whether they are in use or not (e.g. prohibited to deploy this -- regardless of access to users, or e.g. deterred to carry out without measure X and its converse as recommended to use measure X). We discussed alternatives to this, including terms "scenario" to describe situations, "case study" which has been used by GDPR authorities DPC (IE) and ICO (UK), and "use policy" which is common in industry articles.

When I look back at why we want to model these concepts, the primary objective is to allow the association or reference of whatever we call that concept from within a document i.e. to make it part of the documentation. What we call that is secondary to its importance as assisting in the interpretation of what to do with the description (i.e. is it permitted, is it a recommendation). Ignoring the need to define the term upfront, if I consider instead how to model this relation, I see that we already have a partial solution in the example above where I use the phrasing ex:hasIntended... from the documentation to the description. So it is only the suffix of this relation that we are debating. Why not go with existing concepts, of which we then have three candidates: dpv:Policy, dpv:Rule, dpv:Process.

dpv:Policy is defined currently as "A guidance document outlining any of: procedures, plans, principles, decisions, intent, or protocols". This means it can contain all of the concepts that we are trying to model. But that does not make them all categories of policies -- but they can definitely be part of it. dpv:Rule is defined as "A rule describing a process or control that directs or determines if and how an activity should be conducted". This means it must indicate a follow-up interpretation, which terms like permitted or recommended or prohibited do imply, but others like intended do not because they are not directing but declaring. Therefore, some of our concepts can be rules, but not all. Finally, we have dpv:Process, which is defined as "An action, activity, or method", and which is vague enough that it can fit all of our new concepts.

From this, we have two alternatives: 1) we model everything as processes, i.e. as AcceptableProcess, IntendedProcess, etc. -- and they work as expected using the existing uses of process concept as a composite block within which other concepts can be used; or 2) we only model those concepts that are rules i.e. permission (MAY), prohibition (MUST NOT), obligation (MUST), recommendation (SHOULD), deterrence (SHOULD NOT), with intention and acceptable relegated as concepts under dpv:Context. This is how it looks in examples:

# Method 1 -- extending dpv:Process
ex:D a tech:Documentation ;
    dpv:hasAcceptableProcess ex:P ;
    dpv:hasUnacceptableProcess ex:Q ;
    dpv:hasRecommendedProcess ex:R .

# Method 2 -- extended dpv:Rule
ex:D a tech:Documentation ;
    dpv:hasPermission ex:P ; # acceptable = permitted
    dpv:hasDeterrence ex:Q ; # unacceptable = choose prohibited vs deterred
    dpv:hasRecommendation ex:Q .

My personal preference is for Method 2 because it aligns well with the existing rules taxonomy, and also is directly useful when declaring actions in contracts or policies or guidelines, and also to express them in other standards such as ODRL which don't have these additional rule types (but IMHO should). I do not like Method 1 after playing around with those concepts because it puts the focus on the process which raises the question what and who defines what acceptability means for a process, whereas in Method 2 we just focus on this is permitted and it can be applied to anything -- so we don't have to dictate where and how to apply this concept. I also like Method 2 because it frees up the complicated question of how to model eu-aiact:IntendedPurpose which we are discussing as an extension of dpv:IntendedUseCase. We can now go back to tech:IntendedUse which is defined to be exactly what the AI Act wants to be documented, and make the AI Act concept an extension of this (it currently is extending dpv:Purpose which is an error IMO).