Describing Intent in Documentation through Use-Cases

Background

One of the limitations currently present in DPV is the inability to state use-cases as hypotheticals distinctly from processes that are being considered or implemented in context. This article proposes modelling use-cases as a distinct concept to alleviate this.

DPV has concepts and properties to express that something is intended/unintended or is permitted/prohibited. However, these do not act directly at the level of describing an entire process, or more commonly a scenario or an use-case. When planning and creating documentation, it would be desirable and convenient to directly state what is intended, suggested, recommended, dissuaged, prohibited, and so on without having to create a bunch of processes which are only distinguishable by specific property values within then. As the goal of DPV is to foremost provide a vocabulary that allows expression of information in a convenient manner, we should provide such concepts that are required and used by technology actors, regulations, policies, and other contexts without requiring them to use DPV specific abstract models like dpv:Process.

The second issue in the above is the conflation between words use and dpv:Use. Here, use means different things (see Polysemy), where in DPV it refers to the technical operation of using data e.g. what goes on in a microprocessor whereas the way it is used in policy documents refers to description of an use-case or scenario regarding the data or technology. This second use of use is similar to dpv:Process as it can involve describing purposes, data, technologies, and entities in specific roles and configuraitons. To distinguish between these two uses of use, we should define a new concept called dpv:UseCase which is a subclass of dpv:Process and refers to ''potential scenarios that describe functioning of the process in a specific scenario or to describe the effects of the process in specific scenarios''. To enable associating it, the property dpv:hasUseCase should be provided.

The concept dpv:UseCase refers to an idea or a hypothetical, and thus distinguishes it from other processes which might be plans for implementation or logs of activities completed. It also is different from dpv:Process by referring to possibilities without saying these are what will happen or what is planned to happen. The existing concept dpv:ActivityProposed is distinct from a use-case as it is concretely saying this is proposed, whereas a use-case (like Process by itself) is just an idea which could be proposed, or could be describing things that should not happen, and so on.

Having dpv:UseCase is convenient, because now it allows associating situations and scenarios, like for intended use as intended use-case within specific documentations like those required by the AI Act. To enable this, we subclass dpv:UseCase and create relevant properties. Where possible, we involve existing concepts in DPV. To remember here, we are providing a convenience feature for people who want to specifically represent intended uses and similar terms, even if it is possible to do the same using dpv:Process dpv:hasIntention dpv:Intended, as 1) the domain term is clear and has well-defined meaning (presumably); and 2) it should be possible to derive the second from the first e.g. using a reasoner.

Modelling Use-Case

Based on the above, the following are proposed from an analysis of the GDPR's DPIA requirements, AI Act's FRIA and Technical Documentation requirements, research papers such as Datasheets for Dataset and Model Cards for AI Models:

1. dpv:UseCase and dpv:hasUseCase with parents dpv:Process and dpv:hasProcess respectively. This ensures all use-cases are treated as processes in DPV modelling and therefore can continue using all the combinations of concepts/properties that can be used with a process.
2. dpv:IntendedUseCase and dpv:hasIntendedUseCase to describe use-cases that are intended i.e. the entity intends for them to happen. They are defined as dpv:UseCase with dpv:hasIntention dpv:Intended and the entity that intends for them to happen is described using dpv:hasResponsibleEntity. The specifics of the intention, including who should implement what, is expressed using dpv:Process and dpv:isImplementedByEntity. The converse of this is dpv:UnintendedUseCase with dpv:hasUnintendedUseCase. Note that permitted use-cases are the same as intended use-cases. However, if this is confusing, we should create dpv:PermittedUseCase as the parent of dpv:IntendedUseCase.
3. dpv:DeterredUseCase and dpv:hasDeterredUseCase to describe use-cases that are deterred i.e. they are dissuaded from being implemented or from taking place. Here, deterrence is not a prohibition, but more like a warning. This should be accompanied with a new concept called dpv:Deterrence in dpv:Rule with property dpv:hasDeterrence. The use-case is a subclass of this concept (and same for property).
4. dpv:RecommendedUseCase and dpv:hasRecommendedUseCase to describe use-cases that are recommended i.e. they are suggested to happen, but are not an obligation, with the same logic as above. This will have dpv:Recommendation and dpv:hasRecommendation added to the Rules taxonomy, same as above.
5. dpv:ProhibitedUseCase and dpv:hasProhibitedUseCase to describe use-cases that are prohibited. It will have dpv:Prohibition as parent, and dpv:hasProhibition as parent property. This enables directly stating uses that are prohibited e.g. in a documentation.
6. dpv:ForeseenUseCase and dpv:hasForeseenUseCase, which are the parents of all above concepts as if you can define them then they are foreseeable. This concept enables expressing use-cases which are neither intended/permitted, deterred, recommended, or prohibited, but which could happen e.g. someone uses the technology in a different way. They are useful to state e.g. warnings, recommendations, procedures, and so on.

Examples

For example, consider documentation where there are different parts associated with which uses are okay and are permitted/intended, which are not, which are expressly prohibited, and so on. The below example shows how the existing DPV concepts represent only some of the information but are not sufficient to capture the context/intent of representing that intent i.e. communicating it as specific use-cases in the documentation. Another issue with this model is that it is not possible to identify which processes are problematic, which are permitted, etc. without a query as the information exists only within the process -- which could be at different levels in nested processes, whereas the documentation has specific sections at the highest levels. This produces a discrepency between the way the documentation is written and used and the way the information representing the documentation is representing it.

ex:Document1 a tech:Documentation ;
    dpv:hasProcess [  # Intended Use/Purpose
        a dpv:Process ;
        dpv:hasIntention dpv:Intended ;
    ] ;
    dpv:hasProcess [  # Prohibited Uses
        a dpv:Process ;
        dpv:hasRule dpv:Prohibited ;
    ] ;
    dpv:hasProcess [  # Recommended Uses/Steps
        a dpv:Process ;  
        dpv:hasActivityStatus dpv:ActivityProposed ;
    ] ;
    dpv:hasProcess [  # Problematic (but no prohibited) uses
        a dpv:Process ; # WARNING: problematic is not just about risk
        dpv:hasRisk [a dpv:Risk] ;
    ] .

By contrast, the proposed concepts and properties are explicit in meaning and also provide convenience in writing the information in a way that matches the documentation structure.

ex:Document1 a tech:Documentation ;
    dpv:hasIntendedUse [
        a dpv:IntendedUseCase ; # infer dpv:Process
        dpv:hasIntention dpv:Intended ;
    ] ;
    dpv:hasProhibitedUseCase [  # Prohibited Uses
        a dpv:ProhibitedUseCase ; # infer dpv:Process
        dpv:hasRule dpv:Prohibited ; # inferable
    ] ;
    dpv:hasProcess [  # Recommended Uses/Steps
        a dpv:RecommendedUseCase ;
        dpv:hasActivityStatus dpv:ActivityProposed ;
    ] ;
    dpv:hasDeterredUseCase [  # Problematic (but no prohibited) uses
        a dpv:DeterredUseCase ;
    ] .

With the above, there is a high chance that people directly just use the use-case concepts instead of working with dpv:Process or dpv:Rule concepts in a document, which should be okay, as for the domain it is suitable to continue using terms which have existing meaning and are well-understood or that match common use over terms that are not. As stated in each clause, the concepts can be transformed to underlying concepts e.g. using a reasoner or using OWL, so there is no 'loss' of semantics as such.

Distinction from tech:IntendedUse

The existing concept tech:IntendedUse should be removed as it overlaps with the proposed concepts, which are better expressed, and are aligned with the dpv:Process concept whereas tech:IntendedUse is not. If we want to keep the concept, it should be clarified to refer to how the technology is being intended to be used in a technical sense e.g. operating with some parameters or conditions in mind. This is thus clear and distinct from intended use-cases which are proposed in this model. However, by itself, this concept is not sufficient to express ideal conditions and environments of operation, or similarly express problematic conditions. Therefore, I will be proposing another set of concepts in a different article to overhaul the tech:IntendedUse as a taxonomy of how the technology should be operated. For this article, the below example shows the distinction between the technical intended use and the intended use-case.

ex:SomeDocumentation a tech:Documentation ;
    tech:hasIntendedUse [
        a tech:IntendedUse ;
        dpv:hasDuration "P6M"^^xsd:duration ;
        dct:description "Use the technology only for 6 months at a time"@en ;
    ] ;
    dpv:hasDeterredUseCase [
        a dpv:DeterredUseCase ;
        dpv:hasRisk risk:AccidentalMisuse ;
        dct:description "Using it beyond 6 months can lead to errors"@en ;
    ] .

AI Act's Intended Purpose

The modelling of use-cases allows increased expressitivity and lack of confusion as to how specific legal statements and phrases can be modelled in DPV. For example, the AI Act has 160 uses of the word intended, which includes statements like intended purpose. All of these are dpv:IntendedUseCase in the above proposal. If the phrases in the AI Act were changed to match what we have, i.e. as intended use-case, the interpretations would not differ -- which is quite valuable to have when working with regulations. At the same time, it is also valuable to have the terms in DPV be consistent with the wording of the regulation where possible and sensible. In this case, having aiact:IntendedPurpose would be a good idea as this is part of the regulation and will be used by stakeholders.

The proposal is to add aiact:IntendedPurpose as a subclass of dpv:IntendedUseCase with the definition that it describes the intended uses and purposes of the AI system/model/etc. as defined by the AI Act in the form of use-cases. A warning note should be added to state that intended purpose refers to intended use-case rather than the DPV purpose taxonomy. This is because the AI Act's notion of purpose is broader than DPV's as it encompasses all contextual details including data, entities, etc. which in DPV are modelled through dpv:Process at a broad level and through dpv:UseCase for describing use-cases and scenarios -- which is appropriate for this case.

ex:Document a aiact:TechnicalDocumentation ;
    aiact:hasIntendedPurpose [
        a aiact:IntendedPurpose ;
        dct:description "A facial recognition technology for checking visitors at the door are allowed to enter or not"@en ;
        dpv:hasPurpose dpv:EnforceSecurity ;
        tech:hasUser dpv:HomeOwner ; ## this concept does not exist
        dpv:hasLocation loc:HomeLocation ; ## this concept does not exist
        dpv:isImplementedUsingTechnology [
            a ai:AISystem ;
            ai:hasCapability ai:FaceRecognition ;
            tech:hasSubject dpv:Visitor ;
        ] ;
    ] .