Investigations should be specializations of Event

[ajnelson-nist]

Background

UCO Issue 541 introduced general uco-core:Events.

CASE's Investigation class has, to date, been encoded as a uco-core:ContextualCompilation. (This class design predates my own involvement in CASE, so I can only guess to motives for this.)

ContextualCompilation provides a "Set" construct that lets arbitrary items be grouped together, using uco-core:object.

Requirements

Requirement 1

Investigation should exercise Event.

Requirement 2

Investigations must maintain the ability to link InvestigativeActions, ProvenanceRecords, and other CASE classes that tie to investigative contexts.

This proposal does not impose a requirement they need to be linked with the same predicate as today, but other developments in UCO might mean they would no longer be linked the same way.

Risk / Benefit analysis

Benefits

• This appears, to the proposer, to align investigations with a more concrete experience than an abstract "Compilation of objections that share a context." As currently modeled, Investigation is more a representation of the set of things pertaining to an investigation, rather than the investigation itself.

Risks

• An in-flight proposal on the UCO tracker affects how Events could be required to behave differently from ContextualCompilations, so this might not be a backwards-compatible proposal. UCO Issue 544 introduces a disjoint pair of classes, endurants and perdurants. Under that proposal, Event would fall under Perdurant. While not written in the current proposal's state, it is likely that Compilation would be interpreted as an Endurant. If all that is accepted, an Investigation would not be able to be a ContextualCompilation and Event, as the classes would be disjoint.
• The endurant/perdurant proposal also introduces a relating predicate, participatesIn, domain endurant, range perdurant; and perdurantProperPartOf, domain perdurant, range perdurant. This would possibly change how InvestigativeActions relate to Investigations, as they may need to use perdurantProperPartOf (or some subproperty), while anything else (e.g. ProvenanceRecords) would need to use participatesIn.
• uco-core:object is a vaguely-described linking predicate with no RDFS domain specified and a nearly-maximally general UcoObject range, so it is not clear if existing data would need to be changed.

Competencies demonstrated

(Competencies deferred for discussion.)

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

For CASE 1.x.0, BEFORE merging of UCO Issue 544, add to Investigation's definition:

investigation:Investigation
    rdfs:subClassOf uco-core:Event ;
    .

AFTER merging of Issue 544 (assuming UCO Ontology Committee votes so), subtract this subclassing:

investigation:Investigation
    rdfs:subClassOf uco-core:ContextualCompilation ;
    .

uco-core:object can retain its usage on Investigation, but I suggest this is thanks to a lack of specification, which does not feel future-proofed. This SHACL shape can be added to maintain current data behavior, but Issue 544 could also obviate the property:

investigation:Investigation
    sh:property [
        a sh:PropertyShape ;
        sh:class uco-core:UcoObject ;
        sh:nodeKind sh:IRI ;
        sh:path uco-core:object ;
    ] ;
    .

Note: That shape also omits the minimum-1 constraint on uco-core:object. I am not sure if that constraint was purposefully intended to fail SHACL validation on an investigation containing no objects, or if it was an overzealous translation of an owl:someValuesFrom restriction.

By the time of UCO 2.0.0's release and CASE 2.0.0's release, I think Investigation should no longer be a ContextualCompilation.

---

Coordination

• Tracking in Jira ticket ONT-492

• Administrative review completed, proposal announced to Ontology Committees (OCs) on Nov.17, 2023
• Requirements to be discussed in OC meeting, date Nov.28, 2023

• 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

[sbarnum]

I would object to Investigation being made a subClass of Event and especially any proposal to remove it as a subClass of ContextualCompilation.

It is true that one aspect of an Investigation is a set of actions that occur overtime in the investigative process but it is not only that. It is also the set of data/information/knowledge analyzed and the set of data/information/knowledge learned in the investigation.
It is not purely a temporal (perdurant) thing and it is not purely a data/information/knowledge (endurant) thing. It is both. Both aspects are relevant and highly interconnected.
This is one example of the problematic nature of enforcing formal rigor in dividing any concept exclusively between endurant (concepts that can be defined independent of time) and perdurants (concepts that must be defined dependent of time) in ontologies intended for practical purposes.
In practical use some concepts can be both perdurants and endurants in that they have some aspects that are dependent of time and others that are not.

The very heart of an investigation is a contextual compilation of things that happened during the investigation (perdurant things) and things that were observed, collected, analyzed, and learned during the investigation (endurant things).
Trying to split out these two aspects into separate graphs while maintaining coherence of interrelationships would be far more complex than the current approach and the current approach already enables capture of relevant details whether perdurant or endurant using core:object.

I would not object to making Investigation a subclass of both ContextualCompilation and Event as long as core:eventType was hard set to "Investigation" and the cardinality of core:eventContext was set to maxCount=0 to prevent confusion between it and core:object on ContextualCompilation.