Closed kchason closed 2 years ago
The review checklist on PR 399 has been completed. No impact was observed on SHACL validation results.
Something I just realized - there is a slight error in the description of this Issue. observable:endTime
is not a new property. The association with observable:EventFacet
is what this proposal is adding.
This proposal digs a bit into UCO's general need to order temporally bound objects. I don't oppose adding another specialized term to set an interval closing. However, UCO should review its handling of time instants versus time intervals.
The W3C Time Ontology provides a figure demonstrating relations between time periods. UCO could project some objects into the Time Ontology and realize a general timeline (and timeline consistency review mechanism), but the projection is somewhat specialized according to whichever classes happen to have beginning-of-interval and end-of-interval time property-pairs, or some lone non-interval time property. E.g. if we add observable:endTime
as in this proposal, an EventFacet
could project into the Time Ontology like so:
kb:event-1
a observable:Event;
core:hasFacet [
a observable:EventFacet ;
observable:createdDateTime "2022-01-02T03:04:56Z"^^xsd:dateTime ;
observable:endTime "2022-01-02T03:04:57Z"^^xsd:dateTime ;
drafting:hasInterval [
a time:ProperInterval ;
time:hasBeginning [
a time:Instant ;
rdfs:comment "(Lexical value matches observable:createdDateTime, but the more stringent datatype `xsd:dateTimeStamp` is required in the Time Ontology.)"@en ;
time:inXSDDateTimeStamp "2022-01-02T03:04:56Z"^^xsd:dateTimeStamp .
] ;
time:hasEnd [
a time:Instant ;
rdfs:comment "(Matches observable:endTime, after considering the same lexical-datatype issue as in the beginning interval.)"@en ;
time:inXSDDateTimeStamp "2022-01-02T03:04:57Z"^^xsd:dateTimeStamp .
] ;
] ;
] ;
.
Projection into the Time Ontology would help us answer a few questions:
observable:createdDateTime
. Would the new property :endTime
pair with this?Facet
s, or directly on the object? EventFacet
is an instance where the time interval is in a pair of Facet
-housed properties, but Action
and Relationship
store the time on the object. This is another point where Facet
s are confusing.Projection into the Time Ontology is out of scope of this proposal, but it does raise one immediately relevant question - why are we defining the time bounds of Event
s in a Facet
?
I was starting on a second proposal to convert the usage of observable:observableCreatedTime
to observable:startTime
but it really only makes sense for this facet since the others are more discrete occurrences versus a potentially time-bound event such as those this proposal aims to support. But I do think it would make sense to change the usage in this particular instance so the pairing is a lot cleaner.
Regarding the divide between Facet and Object, I thought we've been containing most properties in the Facets so they were more portable. Especially since Action
and Relationship
tend to be "linking" objects whereas the Event
is more of a discrete object.
From discussion on the OCs call this morning, this proposal expanded in scope to add startTime
to pair with endTime
, due to differing semantics between startTime
and observableCreatedTime
.
The review checklist on PR 399 has been completed. No impact was observed on SHACL validation results.
The review checklist has been completed again, incorporating the added startTime
usage.
Competency 1 - Result 1.1 should say: Selecting all events where the specified time is between EventFacet.startTime and EventFacet.endTime.
Background
The
uco-observable:EventFacet
contains a propertycreatedDateTime
but does not contain any sense of duration by means of a duration attribute orobservable:endTime
.As at least one forensic tool has been identified to contain a start, end, and duration, UCO should similarly support the concept of duration.
Requirements
Requirement 1
Add a new property usage
observable:endTime
to theobservable:EventFacet
with a cardinality of 0 -> 1. As duration requires units that may add additional complexity, an "end" concept would be sufficient.Requirement 2
Add a new property usage
observable:startTime
to theobservable:EventFacet
with a cardinality of 0 -> 1.Risk / Benefit analysis
Benefits
Allows the concept of an event that is more than a single moment in time. Such examples may include operating system boot or application update.
Risks
As this is adding a new property and not removing or changing any existing representation, the submitter is unaware of risks associated with this change.
Competencies demonstrated
Competency 1
A user is reviewing results of a forensic investigation and is attempting to correlate all events that occurred on a device at a given point in time.
Competency Question 1.1
Can UCO support the question: What are all of the discrete events that were occurring on a device at 01 JUN 22 @ 19:48:01 EST?
Result 1.1
Selecting all events where the specified time is between
EventFacet.startTime
andEventFacet.endTime
.Solution suggestion
Add new property as defined in requirement 1.
Coordination
develop