search

ucoProject / UCO

This repository is for development of the Unified Cyber Ontology.
Apache License 2.0
73 stars 34 forks source link

Event time bounds and `uco-action:result` #565

Open ajnelson-nist opened 7 months ago

ajnelson-nist commented 7 months ago

Bug description

As part of discussion of UCO Issue 541, an example was provided to illustrate an event where a user authenticated to a service. The example, at its current version, is rendered here. I was just trying a timelining exercise with this example, and came across something that looks incongruous.

The example currently has an event kb:event-d4a5a009-..., recording two actions as its eventContext: kb:action-7377c5e6-... and kb:action-a86738e7-.... The event and actions have this timeline (where order in sub-lists does not necessarily imply temporal order - they're just sorted by IRI here):

(The first action records no end time, and the second records no start time. UCO does not currently have a way of designating whether this means the action was instantaneous, or whether an action is not known to have ended, or not known when it was started. Other ontologies have mechanisms available for representing that these times are believed to exist with unknown time values, but UCO does not have this yet.)

However, the example also has this tie from the second action back to the event:

{
    "@id": "kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb",
    "uco-action:result": {
        "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e"
    }
}

The first action has no other to the event.

This is a confusing (to me) usage of uco-action:result. If the event "results" from the action, should it have existed prior to the action's start? By the recorded timestamps, the event's start is in the same second as the first action's start, and its end is in the same second as the second 'action's end. This doesn't necessarily mean the start instants and end instants are the same instant - that would require us having a reified instant object like OWL-Time's time:Instant. In this example, I think the instants happen to be the same because of the parthood (mereological) relationship between the event and actions: The actions are parts of the event.

Here is my main question: If a UcoObject is a result of an Action, can that object have existed before the Action's start? My understanding was no: an object being a result of an action implies the object was created at some point in the action's unfolding.

If the Ontology Committees agree that the answer is no, then I think the example needs to be revised. I think the example is more consistent if the event is a result of the first action, but is wrong as the result of the second action. Argument for being a result of the first action: The action could be interpreted as the time between a login interface loading and a user deciding to hit an authentication button, particularly if there's typing involved. The authentication event can then be interpreted as the time the button is hit. In some interfaces, the user actions can happen in the same whole-second as currently in the example.

This Issue does not necessarily need to implement a change on UCO before it's closed. But, it is likely to be referenced in a later proposal on reified time object representation, focusing on action:result.

Steps to reproduce

See linked example snippet and occurrences of xsd:dateTime on that example JSON-LD file.

ajnelson-nist commented 5 months ago

Here is my main question: If a UcoObject is a result of an Action, can that object have existed before the Action's start? My understanding was no: an object being a result of an action implies the object was created at some point in the action's unfolding.

In the December 12th meeting, @sbarnum noted an example using action:result that does not imply creation of the resulting object: DNS resolution, as an observable:ObservableAction, returns an IP address as a result. So, I think my previous guess of "no" has met a sufficiently dispelling example.

I still think there is an issue in the authentication example, but the issue now has a different form. The first (in time) action corresponds to the beginning of the event, and the second (in time) action corresponds to the end of the event. Usage of the action:result predicate does not really capture this.

I think the first and second actions each have different parts of the authentication event as a result. I would prefer, if action:result must be used, that the first action had the reified instant the authentication event began as a result; and likewise with the second action and the reified instant the authentication event ended. (E.g., if UCO adopted the OWL-Time[^1] ontology and a subclassing pattern suggested by its PROV-O alignment, this would involve use of the properties time:hasBeginning and time:hasEnd, and the classes time:Interval and time:Instant. But, there is another ontology I'm cross-checking with before bringing that adoption proposal up.) There is otherwise nothing encoding via UCO, outside of free-text annotations, how the beginning of the event and either of the actions relate to one another. That is, I do not think the core:context or action:result properties, separate or together, are sufficient to capture time relationships.

I had thought, at the time of posting this Issue, that it was a blocker on releasing 1.3.0. I no longer think so, so I'll remove it as a blocker, but I intend to leave it open until a more specific representation of the original timelining question arises.

[^1]: 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.