Investigations should be specializations of Event
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,
Investigationis 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 fromContextualCompilations, so this might not be a backwards-compatible proposal. UCO Issue 544 introduces a disjoint pair of classes, endurants and perdurants. Under that proposal,Eventwould fall underPerdurant. While not written in the current proposal's state, it is likely thatCompilationwould be interpreted as anEndurant. If all that is accepted, anInvestigationwould not be able to be aContextualCompilationandEvent, as the classes would be disjoint. - The endurant/perdurant proposal also introduces a relating predicate,
participatesIn, domain endurant, range perdurant; andperdurantProperPartOf, domain perdurant, range perdurant. This would possibly change howInvestigativeActions relate toInvestigations, as they may need to useperdurantProperPartOf(or some subproperty), while anything else (e.g.ProvenanceRecords) would need to useparticipatesIn. uco-core:objectis a vaguely-described linking predicate with no RDFS domain specified and a nearly-maximally generalUcoObjectrange, 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
- [x] Administrative review completed, proposal announced to Ontology Committees (OCs) on Nov.17, 2023
- [x] 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
developfor the next release - [ ]
developstate with backwards-compatible implementation merged intodevelop-2.0.0 - [ ] Backwards-incompatible implementation merged into
develop-2.0.0(or N/A) - [ ] Milestone linked
- [ ] Documentation logged in pending release page
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.