EventFacet Duration

[kchason]

Background

The uco-observable:EventFacet contains a property createdDateTime but does not contain any sense of duration by means of a duration attribute or observable: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 the observable: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 the observable: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 and EventFacet.endTime.

Solution suggestion

Add new property as defined in requirement 1.

Coordination

• Tracking in Jira ticket OC-245

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-06-02
• Requirements to be discussed in OC meeting, 2022-06-14
• Requirements Review vote occurred, passing, on 2022-06-14
• Requirements development phase completed.
• Solution announced to OCs on 2022-06-14
• Solutions Approval to be discussed in OC meeting, 2022-06-30
• Solutions Approval vote occurred, passing, on 2022-06-30
• Solutions development phase completed.
• Implementation merged into develop
• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

The review checklist on PR 399 has been completed. No impact was observed on SHACL validation results.

[ajnelson-nist]

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.

[ajnelson-nist]

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:

• Which of the UCO time properties that "Pair up" pertain to the beginning and ending of an interval? @kchason cited observable:createdDateTime. Would the new property :endTime pair with this?
• Should time-bounding timestamps be properties in Facets, 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 Facets 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 Events in a Facet?

[kchason]

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.

[ajnelson-nist]

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.

[ajnelson-nist]

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.

[sbarnum]

Competency 1 - Result 1.1 should say:
Selecting all events where the specified time is between EventFacet.startTime and EventFacet.endTime.