Add Technician Role Class to CASE

[vulnmaster]

Change proposal written with the assistance of AI.

Background

In the discussion at CASE Issue #178, @chrishargreaves highlighted the role of Technician in investigative contexts. Currently, the CASE investigation ontology defines several role classes (Attorney, Examiner, Investigator, Subject) but lacks explicit representation for Technicians, who play a crucial role in digital forensics and other investigative processes. Technicians are responsible for technical tasks such as evidence collection, preservation, processing, and analysis under the supervision of investigators and examiners. Adding a Technician class will enhance the ontology's ability to accurately represent all participants in investigative workflows, improving provenance tracking and role-based analytics.

A technician is a forensics role focused on case administration, exhibit/item handling and pre-imaging, photography, capture and presentation of data (sciencedirect.com) [https://www.sciencedirect.com/science/article/pii/S2666281724001677], and may also include damaged media recovery for technicians with advanced training or working in labs that support this specialization. The technician role can branch into sub-roles, including but not limited to: Evidence Handling Technician, Imaging Technician, Damaged Media Recovery Technician.

Requirements

Requirement 1

Create a new class investigation:Technician as a direct rdfs:subClassOf uco-role:Role, following the established pattern used by other role classes in the ontology (Attorney, Examiner, Investigator, Subject).

Requirement 2

Define the investigation:Technician class with appropriate rdfs:label and rdfs:comment properties that accurately describe the technician's role in investigative processes, including their technical responsibilities and typical scope of work.

Risk / Benefit analysis

Benefits

• Semantic completeness – enables accurate representation of all personnel involved in investigations, including technical support staff
• Enhanced provenance tracking – allows systems to distinguish between investigative decisions (by investigators) and technical execution (by technicians)
• Improved interoperability – aligns with standard forensic practice terminology and facilitates data exchange between organizations
• Better analytics – supports role-based queries for workforce planning, training needs, and investigation efficiency metrics

Risks

The submitter is unaware of risks beyond routine ontology-maintenance overhead (documentation updates, potential SHACL test additions). No existing CASE instances break, as this is purely additive.

Competencies demonstrated

Competency 1 – Digital forensics evidence processing workflow

Scenario

A digital forensics investigation involves technicians performing technical tasks such as evidence collection, disk imaging, and initial processing. The investigation:Technician role class enables accurate representation of these personnel in investigative workflows, including tracking role assignments with temporal information (appointment dates) and linking personnel actions to their roles.

Example representation:

@prefix kb: <http://example.org/kb/> .
@prefix investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix uco-action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# The investigation
kb:investigation-2024-001 
    a investigation:Investigation ;
    uco-core:name "Laptop Forensic Analysis - Case 2024-001" ;
    investigation:investigationForm "case" ;
    investigation:investigationStatus "open" ;
    investigation:focus "Digital evidence collection and analysis" ;
    uco-core:object kb:disk-imaging-action-5d7a3e9f-c2b4-4f8a-9e3d-6c1b5a8f7e2d .

# The technician's identity
kb:technician-identity-9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d 
    a uco-core:Identity ;
    uco-core:name "Forensic Technician Williams" ;
    uco-core:role kb:technician-role-c8d9f2e1-a4b7-4c3e-8f5d-6a1e9b2c7f4a .

# The technician role (with appointment date)
kb:technician-role-c8d9f2e1-a4b7-4c3e-8f5d-6a1e9b2c7f4a 
    a investigation:Technician ;
    uco-core:startTime "2024-01-15T09:00:00Z"^^xsd:dateTime .

# The investigative action performed by the technician
kb:disk-imaging-action-5d7a3e9f-c2b4-4f8a-9e3d-6c1b5a8f7e2d 
    a investigation:InvestigativeAction ;
    uco-core:name "Disk imaging of evidence laptop" ;
    uco-action:performer kb:technician-role-c8d9f2e1-a4b7-4c3e-8f5d-6a1e9b2c7f4a ;
    uco-action:result kb:disk-image-3f8a2c7d-b1e9-4d3c-a5f7-1b2e4a9c8d6f ,
                       kb:provenance-record-e9f5c1a7-d4b8-4a6e-9c2f-3e5d7a9b1c4f .

# Evidence produced by technical work
kb:disk-image-3f8a2c7d-b1e9-4d3c-a5f7-1b2e4a9c8d6f 
    a uco-observable:File ;
    uco-core:description "Forensic disk image of evidence laptop" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet ;
        uco-observable:fileName "evidence-laptop-001.dd" ;
        uco-observable:sizeInBytes 512000000000
    ] .

# Provenance tracking for the evidence
kb:provenance-record-e9f5c1a7-d4b8-4a6e-9c2f-3e5d7a9b1c4f 
    a investigation:ProvenanceRecord ;
    investigation:exhibitNumber "2024-001-E1" ;
    investigation:rootExhibitNumber "2024-001-E1" ;
    uco-core:object kb:disk-image-3f8a2c7d-b1e9-4d3c-a5f7-1b2e4a9c8d6f .

Competency Question 1.1

Which investigative actions were performed by technicians, and which personnel hold those technician roles?

PREFIX investigation: <https://ontology.caseontology.org/case/investigation/>
PREFIX uco-action: <https://ontology.unifiedcyberontology.org/uco/action/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>

SELECT ?action ?actionName ?identity ?technicianName
WHERE {
  ?technicianRole a investigation:Technician .
  ?action a investigation:InvestigativeAction ;
          uco-core:name ?actionName ;
          uco-action:performer ?technicianRole .
  OPTIONAL {
    ?identity uco-core:role ?technicianRole ;
              uco-core:name ?technicianName .
  }
}

Result 1.1

Returns investigative actions performed by technicians, along with the personnel identities holding those roles. This enables tracking of technical tasks (e.g., disk imaging, data extraction, evidence preservation) performed by technicians, supporting proper attribution, chain-of-custody documentation, and role-based analytics for workforce planning and investigation efficiency metrics.

Solution suggestion

1. Ontology edits

   • Add the investigation:Technician class definition in the Investigation ontology module following the established pattern:

   investigation:Technician
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-role:Role ;
       rdfs:label "Technician"@en ;
       rdfs:comment "Technician is a role involved in performing technical tasks during investigations, such as evidence collection, preservation, processing, initial analysis, and repair."@en ;
       sh:targetClass investigation:Technician ;
       .

2. Documentation

   • Update the CASE documentation to include the Technician role in role descriptions and examples
   • Add usage examples showing Technician interactions with other roles in investigative workflows

3. Testing

   • Add validation tests to ensure proper integration with existing role classes
   • Create example instances demonstrating Technician role usage in investigative scenarios

This implementation maintains backward compatibility while enhancing the ontology's ability to represent the full spectrum of investigative personnel roles.

Coordination

• Tracking in Jira ticket OCCASE 502

• Administrative review completed, proposal announced to Ontology Committees (OCs) on TODO-date
• Requirements to be discussed in OC meeting, date TBD

• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on TODO-date
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release
• develop state with backwards-compatible implementation merged into develop-2.0.0
• Backwards-incompatible implementation merged into develop-2.0.0 (or N/A)
• Milestone linked
• Documentation logged in pending release page
• Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[vulnmaster]

@sbarnum per your feedback durin the OC meeting on 10/22/2025, I updated the competency 1 example so that the role is assigned to the person object. I'd appreciate any feedback that you have on the updated competency.

@ajnelson-nist and @plbt5 it would be great to have an example in CASE Examples of an investigation:Investigation that represents the typical people involved, with their titles and roles, and their typical investigative actions. A really good example might demonstrate how a person has evolved through various roles in their career or how they hold two roles at the same time.

[vulnmaster]

I removed competency 2 from the previous change proposal. I updated competency 1 based on my SHACL validation testing so that I could better demonstrate a person who holds a technician role, when they were appointed to the technician role, and demonstrate the technician performing an Investigation:InvestigativeAction

[ajnelson-nist]

I've had a look over this proposal, and in short, I believe it can be approved and added to CASE with minimal, if any, increase in implementation risks.

My nuanced wording is because the concept of "Role" is a matter UCO and CASE have been confused on between the class-level descriptions and the implementations. The demonstration in this proposal (I presume initially generated by AI) actually repeats the challenge.

Note that the person "Williams" and the role of Williams as a technician are instantiated as two different objects. From discussion recorded in other proposals and in calls, it is my understanding this is the desire of at least a few UCO Ontology Committee members: Roles and the people in those roles are disjoint. A person is never a role.

However, note that in the same demonstration, the investigative action's performer is not Williams, but instead is the role. This is incompatible with a desire expressed in another proposal (please excuse me, I forget which after being away from keyboard for some weeks): The performer of an action is an actor, i.e. has some amount of agency. The role, as an object that is not the person, does not have agency. It is not Williams' job that performs the action -- It's Williams.

This is a deeper design question UCO has to address, because it is an extremely easy incongruency to fall into between writing the classes and writing the individuals. There are different mentalities we can draw on from other ontologies, a few of which tackle the temporality nature Cory addressed in his first revision. PROV-O, BFO, gUFO, and maybe ORG offer options.

One other critique about the demonstration: uco-core:role does not exist. To represent role enactments, we have used a core:Relationship object with a kind of relationship string Has_Role. It's possible to carry this forward so we can answer questions like "In what role(s) did Williams perform this action?" But, I think we'd also need to look at stronger typing in subclasses of core:Relationship, because the SHACL spelling gets pretty cumbersome (needing to spell out logical-implications with "not" and "or"). If we pursue this, the "in what role..." question's answered by using the role enactment relationship as another input to the action.

It might be possible for uco-core:role to exist, but we'd need to shift the time-bounds question from the relationship between person and role to solely the role. E.g., Williams could have two "Technician" roles - the "Technician" role that is his job at his employer, and the "Technician" role within the particular investigation. Assuming stable employment, the latter would have a "terminal" time earlier than the former. There would be no need to time-bound the relationship between Williams and either role if the role-objects are themselves time-bound.

Putting time-bounds on the Role object is an option, and in line with BFO and PROV-O (maybe ORG); but, I think this is blocked on UCO Issue 651, or a related proposal that simplifies timestamp usage at the most-general level of UcoThing.

With all that said: Adding the Technician role is consistent with all prior usage of Role in UCO and CASE. So, I believe there is no additional risk of this proposal, and I think it's fine to vote for Solutions Approval Tuesday.

Re: @vulnmaster

@ajnelson-nist and @plbt5 it would be great to have an example in CASE Examples of an investigation:Investigation that represents the typical people involved, with their titles and roles, and their typical investigative actions. A really good example might demonstrate how a person has evolved through various roles in their career or how they hold two roles at the same time.

I agree, this is a worthwhile example to post. I've logged it on CASE-Examples Issue 155.

[plbt5]

Roles and the people in those roles are disjoint. A person is never a role.

I must strongly object to this view. Although the person and the role are different things, as in "a person is not defined by the role it plays", the role is definitely enacted by the person and cannot be disjoint with each other.

Evidence for this view can be seen in this excerpt from Guizzardi's UFO lecture, and also in other foundational ontologies one can witness this pattern.

[ajnelson-nist]

@plbt5 : I think I understand your point, but I wish to address a couple language ambiguities.

First, I should clarify my earlier remark. More precisely, I mean "An instance of some class ex:Person is never also an instance of gufo:Role." My writing was ambiguous, and could be read as this incorrect statement: "An instance of some class ex:Person is never also an instance of some instance of gufo:Role."

In gUFO, it is perfectly fine for a thing instantiating ex:Person to also instantiate a class instantiating gufo:Role. For those less familiar with gUFO, I get the repetition might be a little odd-looking, but it's from gufo:Role being a meta-class (/second-order class). Here is an example:

ex:Person
  a owl:Class ;
  .

ex:Teacher
  a owl:Class ;
  a gufo:Role ;
  rdfs:subClassOf ex:Person ;
  .

kb:X
  a ex:Teacher ;
  .
# Entailed:
# kb:X
#  a ex:Person ;
#  .

gUFO design goes into why roles are like this, but a short explanation is that there are times that kb:X a ex:Teacher is not true. However, kb:X a ex:Person will always be true.

Now, the reason I'd noted earlier that some of us consider that the class of people and the class of roles would be disjoint is because there's another interpretation of Role that differs from gUFO. Where in gUFO an instance of "Role" is a class, in other ontologies, "Role" is an individual, a thing distinct from a person.

In some ontologies, like BFO, the role is inherent in the person. (Well, inherent in a bigger class than people, but let's leave it at people for now.)
In some ontologies, like PROV-O (and I've heard, but not tried out in this manner yet, at least one other), the role is inherent in a person's participation in an activity. There's an example graph here.
ORG has a different representation of Role that "Denotes a role that a Person or other Agent can take in an organization." Role enactment is done through another class org:Membership. I'll need to refresh myself on this before I can say more.

We'll be trying these out on CASE-Examples Issue 155.