UCO should add support for the time relations

[ajnelson-nist]

Disclaimer

Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

Background

Timelining in UCO is currently doable with somewhere between one and three mechanisms that use current implemented concepts, but has some limitations:

1. Searching for all properties of datatype xsd:dateTime and comparing literals.
2. Maybe usage of uco-action:subaction to tie uco-action:Actions together in a parent-child structure, with an understanding (described further in Issue 557) that there is a containing constraint between the parent action's time boundaries and the child action's time boundaries.
   • Issue 557 had said implementing the constraint would have to wait for another mechanism. This Issue will go into that mechanism.
   • No similar constraint is currently spelled out for core:Event. A "Parthood for events" discussion touches on this in Issue 544, but goes more general. This Issue will revisit that discussion.
3. It seems uco-core:Relationship would be able to tie two timeline-able UcoObjects together with some kind of time semantics through use of uco-core:kindOfRelationship.
   • The untyped string nature of the kindOfRelationship property seems unlikely to be able to capture and validate various time topological constraints, such as the Allen relations and their relative hierarchy.

With the current vocabulary in UCO, it is unclear how to handle topological time knowledge relating two points in time (such as knowing event 1 concludes before event 2) when the precise timestamps are not known.

This proposal seeks to introduce to UCO time concepts that are mindful of four other ontologies that include time-concerned modeling.

• Two mid-level ontologies define and use some time concepts which I believe are of interest to UCO's and CASE's user base:
  • OWL-Time provides owl:ObjectPropertys for the Allen Relations - which will be excerpted here momentarily.
  • PROV-O provides a set of properties for relating the history of objects to each other and with events involving those objects. See e.g. Figure 1.
• Two foundational ("top-level") ontologies make statements on time and events as separate concepts, where time is treated more as a dimensional axis.
  • BFO - separates time as subclasses of "Occurrent" (synonym for "Perdurant" discussed elsewhere in UCO) - see "Process" vs. "Temporal Region" in the lower branches of this figure. BFO defines "Process" and "Temporal Region" as disjoint, and further defines the 0-dimensional (instantaneous) vs. 1-dimensional (>=0 duration) temporal regions as disjoint.
  • gUFO separates "Event"s from abstract time instants that serve as boundary points on any "concrete individual" within gUFO's class hierarchy. gUFO happens to use time:Instant from OWL-Time (see above) as its 0-dimensional time objects, and doesn't currently include (though is not restricted from including) 1-dimensional time objects.

The modeling distinction between "Events that have time" and "Events as time" is a point of differing opinions among the various models above. It is, on the one hand, convenient to be able to express certain time-scoped relationships directly on events, such as saying "Appointment 2 starts once Appointment 1 ends." Under a strict separation, this says "Appointment 2's temporal interval has a beginning instant that coincides with the ending instant of appointment 1's ending interval." However, the more convenient syntax also introduces the potential for some modeling mix-ups. Deleting an appointment from 10--11 AM from my calendar should not delete the time interval 10--11 AM from the time continuum. There is a balance to strike here.

OWL-Time gives a set of properties that relate "Temporal entities" to one another. OWL-Time also gives a property time:hasTime , with domain owl:Thing (i.e., anything), to let "Temporal entities" be used in a "Has-a" reference manner rather than an "Is-a" inheritance manner.

The properties that relate temporal entities are here:

(Source: OWL-Time, Figure 2.)

Note that there is also a property hierarchy in OWL-Time, e.g. to say an interval A "is during", "starts", or "finishes" an interval B is to say A "is in" B. Likewise, "before" and "after" have a parent property "disjoint".

Note also that some of the relationships imply instants of time, that either are shared (so intervals abut) or have a gap. And, some relationships imply that the temporal interval has an end, and some don't. An alternative illustration is in case-prov's documentation.

(Note that case-prov 0.12.0, linked above, happens to use the "Events are time" model. A future version may switch to "Events have time.")

To add time topological constraints to UCO, this proposal suggests a similar delegation as done with OWL-Time: To not force the user to decide on is-a vs. has-a time, and leave the distinction to downstream-from-UCO profiles if a user desires interoperability with non-UCO data or tooling (such as some timelining that "speaks" one of the reference time dialects). In short, the proposal is to define properties that parallel OWL-Time's properties in spelling, rdfs:domain, and rdfs:range, but to have the domain and range be based on the topmost "Event" class in UCO, rather than OWL-Time's time:TemporalEntity. Mappings are then possible for those desiring interoperability.

Requirements

Requirement 1

UCO must be able to order (place, or approximate, on a timeline) events and actions, including beginnings and ends when known or partially known.

Requirement 2

UCO must be able to represent a 0-duration---i.e., instantaneous---event.

Requirement 3

UCO should not force the decision of disjointness between time objects and events, or time objects and actions, directly. UCO must not impede users' decisions either way.

Requirement 4

UCO should introduce a unifying class as a parent to the current classes core:Event and action:Action. This could either be core:Perdurant as suggested in #544, or a structural revision to core:Event to turn it into a parent of action:Action, separating out current semantics to another class.

Non-requirements

• This proposal does not directly address timelining of non-"perdurant" objects. (The timelining of a file's MAC times are more addressed in this proposal than other temporal descriptions of the file's history. That is left for a future proposal.) That is, the focus is on core:Event and core:Action.

Risk / Benefit analysis

Benefits

B1 - Delegation on time and is-a vs. has-a

Not forcing a decision on is-a vs. has-a saves a significant degree of modeling. CASE-Examples has a page showing mappings from a "Every possible relation from object to timestamp-literal" supposedly-maximal model to other models. The page's state today is here, and leads with this figure:

Since the initial exploration of that figure, I found broader, consistent support for the possible extra separation layer of events vs. time-and-only-time intervals, and this adds a lot more paths from thing to timestamp-literal.

The proposed model in this Issue only looks at E, T0, T1, ts0, and ts1 of that figure. T, the top node, will be discussed in a later proposal on the topic of provenance.

B2 - Support expands for enriched event classes, including provenance

case-prov is a project that explores how CASE can be mapped to PROV-O. This project has identified some needs in provenance not currently met with UCO, which happen to be partially satisfied through the current Issue's proposed concepts. For instance, prov:InstantaneousEvent is not specifically a provenance-topic'd class. PROV-O happens to define a few specializations of "Instantaneous event," which still remain general: The instant a thing comes to be (prov:Generation), ceases to be (prov:Invalidation), and first becomes used in some activity (prov:Usage). Parallels to these classes will be of significant aid in CASE's provenance modeling.

B3 - Timelining benefit: Timestamp challenges

Topological time constraints can be congruous with some more straightforward mechanisms for comparing timestamps, but strangely so. E.g., say there are seven different events, which leave records with the following timestamps:

• 2020-01-02
• 2020-01-02T03:04
• 2020-01-02T03:04+00:00
• 2020-01-02T03:04-00:00
• 2020-01-02T03:04:05.123456Z
• 2020-01-02T03:04:05Z
• 2020-01-02T03:04Z

Those timestamps are presented lexicographically sorted (using cat | LC_ALL=C sort). However, those could be accurate to the same clock, merely differing on record precision and UTC spelling, and still pertain to events that occurred in any order. Topological constraints can provide a stronger sequence understanding.

Determining the specification for a unified literal-valued property for timestamping is left as out of scope of this proposal. For instance, there will be some technical and procedural-to-the-user challenges of mapping current UCO timestamps that generally use xsd:dateTime to OWL-Time's timestamp-requiring property time:inXSDDateTimeStamp. However, it seems such a property will benefit by having instantaneous events defined in UCO.

Risks

R1 - Technical risk: Subproperty usage

This proposal suggests porting properties from OWL-Time, including their subproperty hierarchies. Subproperty entailment could present an operational challenge, though this entailment is not needed by users who don't want it.

R1 - Technical risk: Domains and ranges

This proposal relies on porting rdfs:domain and rdfs:range statements forward to remain aligned on where 0-dimensional, 0-or-1 dimensional, and strictly 1-dimensional objects are linked. This misaligns with UCO's practices to date of eschewing rdfs:domain statements to avoid OWL or RDFS entailment issues.

However, avoiding rdfs:domain may be moot in the face of rdfs:range also facing the same issues of type entailment. Hence, this risk is suspected as outweighed by the benefits of more careful type review.

R2 - Editorial risk: UCO Time, OWL Time, and prefix

This concern is, in some sense, about code style, but is noted to contextualize a technical reaction of somewhat surprising reach.

Most of the concepts suggested in this proposal will go into the namespace within UCO's time.ttl, which currently does not include publicly exercised concepts. Exercising this namespace is going to reveal a tension in choice of prefix: The time: prefix is frequently understood as OWL-Time's prefix. UCO retaining time: to mean UCO's time, and re-assigning the W3C OWL-Time to owl-time: or w3c-time:, may cause conflicts with other tools that "hard-code" prefixes.

The resolution that has UCO set time: to be W3C's OWL-Time means UCO either has to:

1. Assign a different prefix to the UCO Time namespace. The IRI would not change, but the prefix would need to change, such as to uco-time:.
2. Assign a different prefix scheme to all UCO namespaces. This is already done in CASE, where UCO namespaces are assigned uco- "pre-prefixes" (uco-core:, etc.). UCO would be taking a downstream practice and bringing it upstream. This would probably be a bit of an overreaction if to just one proposal, but there is a name clash to resolve.

R3 - Foundational model risk: Re-inspecting Event

Issue 563 looked at the class core:Event introduced in Issue 541, and asked whether "Event" and "Action" are disjoint, i.e. whether an action could also be an event. The accepted step forward at the time was "No," that an event is never an action, and an action is never an event.

This strictness around the concept "Event" makes sense in some framings: A security event is not necessarily an action because it can be comprised of multiple actions, which would be comprised of multiple events, and the topic of agency keeps the two separate. However, in foundational ontologies, "Event" would typically be taken as a general parent that gets specialized into "Action," "Security event," "Incident," etc.

The properties ported over from OWL-Time would function best in UCO on some higher-level parent of the current core:Event and action:Action. What seem to be the best available options are:

1. Redefine core:Event to be general-purpose.
   1. Also, possibly, move the current semantics of core:Event that necessitate disjointedness with action:Action to another class.
2. Introduce core:Perdurant as a parent of core:Event and action:Action, as suggested in Issue 544.
   1. This might be odd to do if the other class in 544, core:Endurant, is not also introduced at the same time.

This proposal initially goes forward with option 2, introducing core:Perdurant. This could mean UCO 1.4.0 could get the time properties. On the other hand, some of the class-spellings to parallel OWL-Time suggest that revisiting core:Event's semantics may be preferable to introducing core:Perdurant.

Competencies demonstrated

Competency 1

An Action initiated in Washington, DC, kb:Action-1, has a subaction, kb:Action-2, that by remote procedure call takes place in London.

kb:Action-1
	a uco-action:Action ;
	uco-action:subaction kb:Action-2 ;
	uco-action:startTime "2020-01-01T00:00:00-05:00"^^xsd:dateTime ;
	uco-action:endTime "2020-01-01T04:00:00-05:00"^^xsd:dateTime ;
	.
kb:Action-2
	a uco-action:Action ;
	uco-action:startTime "2020-01-01T06:00:00Z"^^xsd:dateTime ;
	uco-action:endTime "2020-01-01T07:00:00Z"^^xsd:dateTime ;
	.

Competency Question 1.1

Are the times consistent with the topological ordering, with uco-action:subaction being a subproperty of uco-time:intervalDuring (ported from time:intervalDuring)?

Result 1.1

Yes, this timeline is consistent, though a normalization step outside of UCO, SHACL, or SPARQL is needed for at least casting all timezones to UTC. Sorting without timezone conversion would have the parent action's end time come before the child action's start.

Specifically, the timeline is consistent with or without this additional entailed triple (whether under OWL or RDFS entailment):

kb:Action-2
	uco-time:intervalDuring kb:Action-1 ;
	.

Solution suggestion

I am fine with my examples being transcribed and credited.

1. Introduce core:Perdurant, as described in Issue 544. Do not yet introduce its disjointedness restrictions, or core:Endurant. Set it as the parent of core:Event and core:Action.

2. Define classes in the OWL-Time namespace that specialize core:Perdurant, parallel with time:TemporalEntity.

OWL-Time	UCO Time
time:TemporalEntity	N/A
time:Instant	uco-time:InstantaneousPerdurant
time:Interval	uco-time:IntervalicPerdurant
time:ProperInterval	uco-time:ProperIntervalicPerdurant

3. For the Allen relations and their parent properties implemented in OWL-Time, define analagous properties with the same local name (post-prefix) under the UCO Time namespace. E.g., uco-time:intervalDuring would be:

uco-time:intervalDuring
	a owl:ObjectProperty ;
	rdfs:comment "If a proper-intervalic perdurant P1 is intervalDuring another proper-intervalic perdurant P2, then the beginning of P1 is after the beginning of P2, and the end of P1 is before the end of P2.  (Definition adapted from OWL-Time's intervalDuring.)"@en ;
	rdfs:seeAlso time:intervalDuring ;
	rdfs:domain uco-time:ProperIntervalicEvent ;
	rdfs:range uco-time:ProperIntervalicEvent ;
	.

4. Downstream from UCO, in a profile that demonstrates linkage of UCO and OWL-Time, a property chain axiom can be defined. This particular implementation detail is out of scope of UCO, but shows that no incompatibility is introduced from UCO adapting OWL-Time's properties at a separated layer.

uco-time:ProperIntervalicPerdurant
	rdfs:subClassOf [
		a owl:Restriction ;
		owl:onProperty owl:hasTime ;
		owl:allValuesFrom time:ProperInterval ;
	] ;
	.

uco-time:intervalDuring
	owl:propertyChainAxiom (
		time:hasTime
		time:intervalDuring
		[
			owl:inverseOf time:hasTime
		]
	) ;
	.

5. Adapt shapes done to check usage of OWL-Time from here. A strategy for reviewing domains and ranges of properties may focus on checking for inconsistencies rather than assertions, to save on multi-typing of graph nodes.

E.g., a shape checking the "Domain" of uco-time:intervalDuring would probably only check that the subject in the intervalDuring triple is not a uco-time:InstantaneousPerdurant.

uco-time:intervalDuring-subjects-shape
	a sh:NodeShape ;
	sh:not [
		a sh:NodeShape ;
		sh:class uco-time:InstantaneousPerdurant ;
	] ;
	sh:targetSubjectsOf uco-time:intervalDuring ;
	.

This relieves a user of needing to assert types like this:

kb:Action-1
	a
		uco-action:Action ,
		uco-time:ProperIntervalicPerdurant
		;
	uco-action:subaction kb:Action-2 ;
	.
	
kb:Action-2
	a
		uco-action:Action ,
		uco-time:ProperIntervalicPerdurant
		;

	# uco-ation:subaction usage would entail this under RDFS or OWL inference:
	uco-time:intervalDuring kb:Action-1 ;
	.

6. Consider tying together review shapes from the new subproperty hierarchy through multi-targeting. This is a way of addressing within UCO the challenge of applying review shapes for "parent" properties to "child" properties. E.g., uco-time:intervalIn has domain and range uco-time:ProperIntervalicPerdurant. Re-doing subject and object review tests for the child properties, like uco-time:intervalDuring would be explicit, but redundant. It is possible to instead use sh:targetSubjectsOf with multiple targets, one per child property (this is done, albeit not necessarily for property hierarchy reasons, in SHACL-SHACL, that SHACL graph that syntax-reviews SHACL):

uco-time:intervalIn-subjects-shape
	a sh:NodeShape ;
	sh:not [
		a sh:NodeShape ;
		sh:class uco-time:InstantaneousPerdurant ;
	] ;
	sh:targetSubjectsOf
		uco-time:intervalin ,
		uco-time:intervalDuring ,
		uco-time:intervalStarts ,
		uco-time:intervalFinishes
		;
	.

This can be maintained within CDO ontologies with some (up to interpretation, "light") testing against monolithic graphs that are built as part of CI. New subproperty statements can be kept in line with shape-targeting predicates, though the placement of the new targeting statements will need to go alongside the new properties - so, an "Upstream" shape gets new targeting in the "Downstream" ontology.

The benefit of doing this would be relieving users of needing to consider rdfs:subPropertyOf entailment.

7. Set all UCO prefixes to use uco- (e.g. core: -> uco-core:).

Coordination

• Tracking in Jira ticket OCUCO-328

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2025-04-25
• Requirements to be discussed in OC meeting, 2025-04-29
• Requirements Review vote occurred, passing, on 2025-04-29
• 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