Need ability to represent general concept of an Event

[sbarnum]

Background

The ability of UCO to express any sort of temporal occurrences is currently limited to active contexts in the form of Actions where some agent (Person, Organization, Tool, Software, Application, Process, etc.) is, has or might dynamically perform some action.

For many contexts there is a need to also be able to express a passive temporal occurrence in the form of an event as a noteworthy occurrence (something that happens or might happen). The context of an event could be completely independent of any known action(s) (e.g., Fukashima reactor meltdown) or could involve one or more actions potentially along with relevant locations, persons, organizations, observable objects, etc. (e.g., event of "account logged (passive not active) into application" along with the Application, the Account, the Person, the Action of browser requesting login screen (along with Location where this occurred), the Action of Application responding with login screen, the Action of Person entering credentials, the Action of browser submitting credentials, the Action of the Application vetting credentials, the action of the Application presenting interface to browser, etc.).

NOTE: This general concept of an event is distinct from the existing UCO concept of an EventRecord which represents a digital record of some event that occurred in a digital context (the sort of log events you would find in a syslog). It is also distinct from the existing UCO concept of an EventLog which represents a collection of EventRecords.

The general concept of event as a structured UcoObject is useful for a range of cyber application domains including cyber operations, cyber threat intelligence, adversary engagement, cyber investigation, etc.

Requirements

Requirement 1

An event can be specified with a simple name and no further context

Requirement 2

An event can be specified with time bounds for its temporal beginning and end

Requirement 3

An event may be characterized with any categorizing event type label

Requirement 4

An event can be specified with context details for the event specified as core:UcoObject

Requirement 5

An event can be specified with context details for the event specified as simple strings

Requirement 6

An event can be related to any other core:UcoObject

Risk / Benefit analysis

Benefits

• Ability to convey real-world physical and digital occurrences abstract from any specific actions
• Ability to convey simple aggregated representation for occurrences that involve complex contextual details
• Ability to relate occurrences with other details for things like context, causation, temporal flow, etc.
• Represents a concept currently present (though not yet formally defined in CDO) in multiple application domains

Risks

• Potential for confusion Event as a general concept and the more concrete observable object concepts of EventRecord and EventLog. Important to ensure definitions are clear.

Solution suggestion

Implementation of the proposed solution is available in https://github.com/ucoProject/UCO/pull/542

Within the core namespace:

• Create new core:Event class as subclass of core:UcoObject with definition of "An Event is a noteworthy occurrence (something that happens or might happen)."
• Create new core:eventType datatype property as xsd:string
• Create new core:eventContext object property as core:UcoObject
• Create new core:eventAttribute object property as types:Dictionary
• Add new associated property shapes on core:Event for core:eventType, core:eventContext, core:eventAttribute, core:startTime, and core:endTime

Solution discussion

The proposed new core:Event class provides a simple mechanism for expressing general temporal occurrences with varying levels of detail (Requirements 1-5) and relating them to other CDO content (Requirement 6).

       {
            "@id": "kb:event-46d6982b-1ebd-4b85-8b2a-122d1318d99d",
            "@type": "core:Event",
            "core:name": "2016 Summer Olympics"
        }

The proposed new core:eventType property provides capability to support Requirement 3.

      {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "core:Event",
            "core:name": "user logged in",
            "core:eventType": "Authentication"
        },

The proposed new core:eventContext property provides capability to support Requirement 4.

       {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "core:Event",
            "core:name": "user logged in",
            "core:eventType": "Authentication",
            "core:eventContext": ["kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc","kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb"]
        },
        {
            "@id": "kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc",
            "@type": "action:Action",
            "core:name": "submit-login-request",
            "action:performer": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:object": ["online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"],
            "action:location": ["kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce"],
            "action:startTime": "2023-07-15T17:59:43.25Z"
        },
        {
            "@id": "kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb",
            "@type": "action:Action",
            "core:name": "authenticate-credentials",
            "action:performer": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:result": ["kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e"],
            "action:endTime": "2023-07-15T17:59:45.33Z"
        },
        {
            "@id": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "@type": "observable:OnlineService",
            "name": "Facebook"
        },
        {
            "@id": "kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9",
            "@type": "observable:ApplicationAccount",
            "hasFacet": [
                {
                    "@id": "kb:account-facet-57a3351a-5043-4d57-8fdf-ebe0deac708a",
                    "@type": "observable:AccountFacet",
                    "observable:accountType": "online-service",
                    "observable:owner": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a"
                },
                {
                    "@id": "kb:application-account-facet-f9d6b37f-0c24-4450-a08e-78f77b60ef16",
                    "@type": "observable:ApplicationAccountFacet",
                    "observable:application": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"
                }
            ]
        },
        {
            "@id": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "@type": "identity:Person",
            "core:name": "John Smith"
        },
        {
            "@id": "kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce",
            "@type": "location:Location",
            "hasFacet": [
                {
                    "@id": "kb:simple-address-facet-3ab0674c-9bbc-40a9-9050-8b9b94b6bf29",
                    "@type": "location:SimpleAddressFacet",
                    "location:locality": "Detroit",
                    "location:region": "Michigan",
                    "location:country": "USA"
                }
            ]
        }

The proposed new core:eventAttribute property provides capability to support Requirement 5.

       {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "core:Event",
            "core:name": "user logged in",
            "core:eventType": "Authentication",
            "core:eventContext": ["kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc","kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb"],
            "core:eventAttribute": "kb:dictionary-b222a5f4-e7eb-442a-8aab-c22c89734b9e"
        },
        {
            "@id": "kb:dictionary-b222a5f4-e7eb-442a-8aab-c22c89734b9e",
            "@type": "types:Dictionary",
            "types:entry": ["kb:dictionary-entry-7b56fc43-beb8-4331-9af2-e6e16e4fb90c","kb:dictionary-entry-3facf519-da01-4ee7-81a1-ab2f954b6c8e"]
        },
        {
            "@id": "kb:dictionary-entry-7b56fc43-beb8-4331-9af2-e6e16e4fb90c",
            "@type": "types:Dictionary",
            "types:key": "mfa-enabled",
            "types:value": "false"
        },
        {
            "@id": "kb:dictionary-entry-3facf519-da01-4ee7-81a1-ab2f954b6c8e",
            "@type": "types:Dictionary",
            "types:key": "credential-entry-mode",
            "types:value": "manual"
        },
        {
            "@id": "kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc",
            "@type": "action:Action",
            "core:name": "submit-login-request",
            "action:performer": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:object": ["online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"],
            "action:location": ["kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce"],
            "action:startTime": "2023-07-15T17:59:43.25Z"
        },
        {
            "@id": "kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb",
            "@type": "action:Action",
            "core:name": "authenticate-credentials",
            "action:performer": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:result": ["kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e"],
            "action:endTime": "2023-07-15T17:59:45.33Z"
        },
        {
            "@id": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "@type": "observable:OnlineService",
            "name": "Facebook"
        },
        {
            "@id": "kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9",
            "@type": "observable:ApplicationAccount",
            "hasFacet": [
                {
                    "@id": "kb:account-facet-57a3351a-5043-4d57-8fdf-ebe0deac708a",
                    "@type": "observable:AccountFacet",
                    "observable:accountType": "online-service",
                    "observable:owner": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a"
                },
                {
                    "@id": "kb:application-account-facet-f9d6b37f-0c24-4450-a08e-78f77b60ef16",
                    "@type": "observable:ApplicationAccountFacet",
                    "observable:application": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"
                }
            ]
        },
        {
            "@id": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "@type": "identity:Person",
            "core:name": "John Smith"
        },
        {
            "@id": "kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce",
            "@type": "location:Location",
            "hasFacet": [
                {
                    "@id": "kb:simple-address-facet-3ab0674c-9bbc-40a9-9050-8b9b94b6bf29",
                    "@type": "location:SimpleAddressFacet",
                    "location:locality": "Detroit",
                    "location:region": "Michigan",
                    "location:country": "USA"
                }
            ]
        }

The proposed property shapes on core:Event for the currently existing core:startTime and core:endTime properties provides capability to support Requirement 2.

       {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "core:Event",
            "core:name": "user logged in",
            "core:eventType": "Authentication",
            "core:startTime": "2023-07-15T17:59:43.25Z",
            "core:endTime": "2023-07-15T17:59:45.33Z",
            "core:eventContext": ["kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc","kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb"],
            "core:eventAttribute": "kb:dictionary-b222a5f4-e7eb-442a-8aab-c22c89734b9e"
        },
        {
            "@id": "kb:dictionary-b222a5f4-e7eb-442a-8aab-c22c89734b9e",
            "@type": "types:Dictionary",
            "types:entry": ["kb:dictionary-entry-7b56fc43-beb8-4331-9af2-e6e16e4fb90c","kb:dictionary-entry-3facf519-da01-4ee7-81a1-ab2f954b6c8e"]
        },
        {
            "@id": "kb:dictionary-entry-7b56fc43-beb8-4331-9af2-e6e16e4fb90c",
            "@type": "types:Dictionary",
            "types:key": "mfa-enabled",
            "types:value": "false"
        },
        {
            "@id": "kb:dictionary-entry-3facf519-da01-4ee7-81a1-ab2f954b6c8e",
            "@type": "types:Dictionary",
            "types:key": "credential-entry-mode",
            "types:value": "manual"
        },
        {
            "@id": "kb:action-7377c5e6-6b28-4bc7-ad21-6763c070bfcc",
            "@type": "action:Action",
            "core:name": "submit-login-request",
            "action:performer": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:object": ["online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"],
            "action:location": ["kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce"],
            "action:startTime": "2023-07-15T17:59:43.25Z"
        },
        {
            "@id": "kb:action-a86738e7-c890-4615-b3ab-deaccd3bafbb",
            "@type": "action:Action",
            "core:name": "authenticate-credentials",
            "action:performer": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "action:instrument": ["kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9"],
            "action:result": ["kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e"],
            "action:endTime": "2023-07-15T17:59:45.33Z"
        },
        {
            "@id": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb",
            "@type": "observable:OnlineService",
            "name": "Facebook"
        },
        {
            "@id": "kb:application-account-e7f100bb-6367-4363-9416-b7ae73af2be9",
            "@type": "observable:ApplicationAccount",
            "hasFacet": [
                {
                    "@id": "kb:account-facet-57a3351a-5043-4d57-8fdf-ebe0deac708a",
                    "@type": "observable:AccountFacet",
                    "observable:accountType": "online-service",
                    "observable:owner": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a"
                },
                {
                    "@id": "kb:application-account-facet-f9d6b37f-0c24-4450-a08e-78f77b60ef16",
                    "@type": "observable:ApplicationAccountFacet",
                    "observable:application": "online-service-a3cfc0e0-26a7-4b6a-8be8-aaa65db3dedb"
                }
            ]
        },
        {
            "@id": "kb:person-e3b1df7c-bb3b-49fe-bc1d-0203c9dff86a",
            "@type": "identity:Person",
            "core:name": "John Smith"
        },
        {
            "@id": "kb:location-ebafeec7-de26-4107-b2c0-bde4c248dcce",
            "@type": "location:Location",
            "hasFacet": [
                {
                    "@id": "kb:simple-address-facet-3ab0674c-9bbc-40a9-9050-8b9b94b6bf29",
                    "@type": "location:SimpleAddressFacet",
                    "location:locality": "Detroit",
                    "location:region": "Michigan",
                    "location:country": "USA"
                }
            ]
        }

This scope of this proposal is additive in nature to the current UCO and does not introduce any significant new complexity or affect existing capabilities.

Coordination

• Tracking in Jira ticket OC-294
• [x] Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-07-19
• [x] Requirements to be discussed in OC meeting, 2023-07-20
• [x] Requirements to be discussed in OC meeting, 2023-08-29
• [x] Requirements Review vote occurred, passing, on 2023-08-29
• [x] Requirements development phase completed.
• [x] Solution announced to OCs on 2023-09-11
• [x] Solutions Approval to be discussed in OC meeting, 2023-09-19
• [x] Solutions Approval vote occurred, passing, on 2023-09-19
• [x] Solutions development phase completed.
• [x] Backwards-compatible implementation merged into develop for the next release
• [x] develop state with backwards-compatible implementation merged into develop-2.0.0
• [x] Backwards-incompatible implementation merged into develop-2.0.0 (N/A)
• [x] Milestone linked
• [x] Documentation logged in pending release page

[ajnelson-nist]

@sbarnum : Can you please clarify, with respect to Events as temporal objects, is an Event always one-dimensional, or can an Event also be 0-dimensional, i.e. instantaneous?

For context, I ask in consideration of potential UCO alignments with other ontologies that have explored either temporal interval or event representation:

• PROV-O provides prov:InstantaneousEvents, which are 0-dimensional instants.
• OWL-Time provides a few classes where a UCO Event could align:
  • time:ProperInterval - An interval of non-0 duration (end definitively comes after the beginning).
  • time:Interval - An interval of potentially-0 duration (the end could could after the beginning).
  • time:Instant - A 0-duration time point. This class is disjoint with time:ProperInterval.
  • The abstract superclass time:TemporalEntity lets a potential UCO alignment be vague.
• gUFO offers gufo:Event, which appears similar to time:Interval on a quick read (allowing for 0-duration intervals), and gUFO also incorporates time:Instant in the UFO class hierarchy.
• BFO offers one-dimensional and 0-dimensional temporal region classes, with a parent, though I'm not quite sure how a UCO Event would relate to them or their parent class occurrent:
  • Temporal region
    • Zero-dimensional temporal region
    • One-dimensional temporal region

[ajnelson-nist]

Also, @sbarnum , thank you for working through some examples. May I transcribe them to the CASE-Examples repository so they can be SHACL-reviewed and have some queries run against them? (I also noticed a few typos, just minor object-reference fixes.)

[ajnelson-nist]

@plbt5 - Can you please contextualize your feedback on the Pull Request w.r.t. uco-action:Actions (which I understand also would be a perdurant)? Also, for the sake of keeping feedback in one place, can we please leave broader discussion on the Issue, and leave detailed technical notes for Pull Requests.

[sbarnum]

@sbarnum : Can you please clarify, with respect to Events as temporal objects, is an Event always one-dimensional, or can an Event also be 0-dimensional, i.e. instantaneous?

For context, I ask in consideration of potential UCO alignments with other ontologies that have explored either temporal interval or event representation:

• PROV-O provides prov:InstantaneousEvents, which are 0-dimensional instants.

• OWL-Time provides a few classes where a UCO Event could align:

  • time:ProperInterval - An interval of non-0 duration (end definitively comes after the beginning).
  • time:Interval - An interval of potentially-0 duration (the end could could after the beginning).
  • time:Instant - A 0-duration time point. This class is disjoint with time:ProperInterval.
  • The abstract superclass time:TemporalEntity lets a potential UCO alignment be vague.
• gUFO offers gufo:Event, which appears similar to time:Interval on a quick read (allowing for 0-duration intervals), and gUFO also incorporates time:Instant in the UFO class hierarchy.

• BFO offers one-dimensional and 0-dimensional temporal region classes, with a parent, though I'm not quite sure how a UCO Event would relate to them or their parent class occurrent:

  • Temporal region

  • Zero-dimensional temporal region

  • One-dimensional temporal region

The temporal aspect of Event can definitely be either instantaneous (liftoff of SpaceX Mission XYZ) or an interval of time (2016 Summer Olympics). It requires this flexibility and cannot be restricted to only be one or the other.

[sbarnum]

Also, @sbarnum , thank you for working through some examples. May I transcribe them to the CASE-Examples repository so they can be SHACL-reviewed and have some queries run against them? (I also noticed a few typos, just minor object-reference fixes.)

Sure. I have a separate file with the full login example all together if that would be useful.

[ajnelson-nist]

Sure. I have a separate file with the full login example all together if that would be useful.

That would be! Would you mind emailing it to me?

[plbt5]

I interpret an Event as something that expands and/or develops over time, a Perdurant. Furthermore, in the definition of the UcoObject I cannot find any reference to something that is not an Endurant.

In this interpretation we do realize, don't we, that by subclassing the Event from the UcoObject we cannot make a distinction anymore between Endurants and Perdurants, let alone make them disjoint?! In my professional opinion, such distinction is a necessary feature for an interoperability standard to provide.

As the ontologist in CDO, I don't approve of this design.

A simple resolution would be to subclass the Event from the UcoThing, like the UcoObject and UcoInherentCharacterizationThing, and make those three disjoint from each other.

Perdurant and endurants are related as: 'Perd has-participants End'; implying that each and every relation that exist between their individuals are grounded in this one.

(Italic concepts are abstract, i.e., cannot be instantiated but subclassed only. Colors show disjoint parts of the taxonomy.)

[plbt5]

@plbt5 - Can you please contextualize your feedback on the Pull Request w.r.t. uco-action:Actions (which I understand also would be a perdurant)? Also, for the sake of keeping feedback in one place, can we please leave broader discussion on the Issue, and leave detailed technical notes for Pull Requests.

Duly noted, of course we shouldn't discuss such broad feedback on the PR. I should have known better. See my copy of it here.

An Action would be a particular perdurant involving persons and, potentially, a causal pattern. In that view, an Action is disjoint with objects.

[plbt5]

About the Requirements / Suggested solution concepts:

• Req3: By subclassing the Event, one already identifies an event type, e.g., Meeting. There is no need for a label.
• Req4, 5 & 6: These are about context. Assume the relation pattern between the Endurant and Perdurant, i.e., Perd has-participants End, the context is specified by the endurants/UcoObjects that are participating in the event, as well as perdurants that are part of it.

For example, the FDP-WG Meeting could be specified as a subclass to (an intermediary Meeting subclass to) Event (Req3), with participants Sean, Alex, Harm, me and the Facet, all four being instances of classes that have the UcoObject as highest superclass in their hierarchy (Reqs 4 and 6). Req 5 can be implemented as a string bound as attribute to one of the UcoObjects. A particular instance of our FDP-WG mtg can then be instantiated from FDP-WG Meeting, introducing the particular start and end date/times that apply.

This would make for a rather simple design without more classes than necessary to specify the required distinctions.

It would also diminish the identified risk by its clear separation (disjointness) between an Event and the EventRecord and EventLog, the latter two being subclass from UcoObject.

[plbt5]

@sbarnum : Can you please clarify, with respect to Events as temporal objects, is an Event always one-dimensional, or can an Event also be 0-dimensional, i.e. instantaneous? For context, I ask in consideration of potential UCO alignments with other ontologies that have explored either temporal interval or event representation:

• PROV-O provides prov:InstantaneousEvents, which are 0-dimensional instants.

• OWL-Time provides a few classes where a UCO Event could align:

  • time:ProperInterval - An interval of non-0 duration (end definitively comes after the beginning).
  • time:Interval - An interval of potentially-0 duration (the end could could after the beginning).
  • time:Instant - A 0-duration time point. This class is disjoint with time:ProperInterval.
  • The abstract superclass time:TemporalEntity lets a potential UCO alignment be vague.
• gUFO offers gufo:Event, which appears similar to time:Interval on a quick read (allowing for 0-duration intervals), and gUFO also incorporates time:Instant in the UFO class hierarchy.

• BFO offers one-dimensional and 0-dimensional temporal region classes, with a parent, though I'm not quite sure how a UCO Event would relate to them or their parent class occurrent:

  • Temporal region

  • Zero-dimensional temporal region

  • One-dimensional temporal region

The temporal aspect of Event can definitely be either instantaneous (liftoff of SpaceX Mission XYZ) or an interval of time (2016 Summer Olympics). It requires this flexibility and cannot be restricted to only be one or the other.

The temporal aspect of Event should be separated from each other. An event unfolds in time, and is therefore scoped/framed by temporal aspects. We could re-use the W3C Time ontology for that, including the Allen relations, as an elaboration / replacement of the TimeInterval and TimePoint specified in the above image.

If anything, these temporal aspects should be addressed separately, disjoint from the Event. This provides for the ability to separate the event and how it unfolds in time from the time dimension itself. It then allows to relate time intervals to eachother which describe how the events relate to eachother. And, consequently, allow for instantaneous (i.e., 0-dimensional) events.

[ajnelson-nist]

@plbt5 : If you were not aware, edits to comments on GitHub do not generate email notices. I didn't know until you mentioned it in this morning's meeting that there is now a figure accompanying your earlier remarks.

Your figure uses a diagramming scheme that I don't think anyone else in CDO is familiar with. (I say that because I'm not sure how many of the terms in there stem from gUFO built-in concepts, and how many are invented for UCO.) It also seems to miss some of the current implementation state of UCO, namely that UcoInherentCharacterizationThing is disjoint from UcoObject.

Qualitys are out of scope of this proposal, so if we can avoid discussing them I'd prefer to.

Event is proposed as a subclass of UcoObject. I think this is consistent with UCO class design so far with respect to how Endurant and Perdurant could be introduced. Since Endurant vs. Perdurant seems to be the basis of your discomfort with this proposal about Events, I encourage you to propose adding Endurant and Perdurant in a separate proposal. I think when you do, we will find something like this as the result (with disjointedness statements intentionally spelled redundantly just for this illustration):

core:UcoObject
    rdfs:subClassOf core:UcoThing ;
    owl:disjointWith core:UcoInherentCharacterizationThing ;
    .

core:UcoInherentCharacterizationThing
    rdfs:subClassOf core:UcoThing ;
    owl:disjointWith core:UcoObject ;
    .

core:Endurant
    rdfs:subClassOf core:UcoObject ;
    owl:disjointWith core:Perdurant ;
    .

core:Perdurant
    rdfs:subClassOf core:UcoObject ;
    owl:disjointWith core:Endurant ;
    .

action:Action
    rdfs:subClassOf core:Perdurant ;
    .

core:Event
    rdfs:subClassOf core:Perdurant ;
    .

# There might be a higher class than ObservableObject that could be an Endurant subclass.
observable:ObservableObject
    rdfs:subClassOf core:Endurant ;
    .

I think a good example of the endurant-vs-perdurant divide is seeing how observable:ObservableObject compares to observable:ObservableAction.

Can you please draft a proposal to introduce Endurant and Perdurant? I suspect if you don't, we are going to get mired down in discussion about Events supposing the classes of Endurant and Perdurant if UCO had them implemented already.

[plbt5]

@plbt5 : If you were not aware, edits to comments on GitHub do not generate email notices. I didn't know until you mentioned it in this morning's meeting that there is now a figure accompanying your earlier remarks.

@ajnelson-nist - Indeed I didn't know that git did not generate a ping when adding comments here. But no harm was done.

Your figure uses a diagramming scheme that I don't think anyone else in CDO is familiar with. (I say that because I'm not sure how many of the terms in there stem from gUFO built-in concepts, and how many are invented for UCO.) It also seems to miss some of the current implementation state of UCO, namely that UcoInherentCharacterizationThing is disjoint from UcoObject.

The diagram, just a UML class diagram, doesn't apply any gUFO concepts, although I've been applying a similar pattern.

Qualitys are out of scope of this proposal, so if we can avoid discussing them I'd prefer to.

Indeed I used the name Quality, but included a note that this class might be equivalent to the UcoInherentCharacterizationThing. I wasn't sure whether the latter sufficiently represents what is called the Quality domain in UFO and DOLCE (DUL) and BFO. Anyway, assume it is, cross the Quality name and replace it with the UcoInherentChanracterizationThing. Then, the essence of the diagram is that, in addition to the current situation with the disjoint UcoObject and UcoInherentCharacterizationThing subclassing from Uco's top class UcoThing, I added the Event as a third disjoint class subclassing from the UcoThing.

Event is proposed as a subclass of UcoObject. I think this is consistent with UCO class design so far with respect to how Endurant and Perdurant could be introduced.

If I read the description of UcoClass, I interpret that as being an Endurant. I can't see any reference to something that might be a Perdurant. This would make the three disjoint top level classes as depicted in the diagram a close match with the contemporary top level foundational ontologies. That is, a very good initial distinction to separate the UCO landscape in three non-overlapping areas.

Since Endurant vs. Perdurant seems to be the basis of your discomfort with this proposal about Events, I encourage you to propose adding Endurant and Perdurant in a separate proposal.

If we can agree that:

1. the UcoObject is equivalent / close match to Endurant;
2. the UcoInherentCharacterizationThing is equivalent / close match to a Quality domain; and
3. the Event represents a Perdurant,

then we've already achieved the objective of the very proposal that you refer to, and in a design that is more simple (and, hence, easier to understand and maintain) since it doesn't require the additional taxonomy introduced by your example. In turtle:

core:UcoObject
    rdfs:subClassOf core:UcoThing ;
    rdfs:comment "a.k.a. Endurant" ;
    owl:disjointWith core:UcoInherentCharacterizationThing ,
        core:Event ;
    .

core:UcoInherentCharacterizationThing
    rdfs:subClassOf core:UcoThing ;
    rdfs:comment "a.k.a. Quality domain" ;
    owl:disjointWith core:UcoObject ,
        core:Event ;
    .

core:Event
    rdfs:subClassOf core:UcoThing ;
    rdfs:comment "a.k.a. Perdurant" ;
    owl:disjointWith core:UcoObject ,
        core:UcoInherentCharacterizationThing ;
    .

Whether one would like to subclass the Action from the Event or the UcoObject is dependent on what UCO would like to represent with the Action. Maybe some have a case or need for it to represent an Event where others will have a case for it being a UcoObject; then we would be needing two versions of it in UCO, an Action-qua-Event and an Action-qua-Object.

[ajnelson-nist]

(This comment ended up having a bit of scope creep. Let us please remember this Issue is about core:Event. The summary of the exploration below is, core:Event seems fine with respect to a potential addition of endurant+perdurant, but the endurant+perdurant discussion calls core:Item's purpose into question. These are preparatory notes for @plbt5 , and some questions for @sbarnum .)

@plbt5 , we need to adhere to Action being a subclass of UcoObject, bluntly because that's what's in UCO 1.0.0. Without further thinking about the history, once we hit 1.0.0, we have had to live with that piece of the hierarchy. So, UcoObject would encompass both endurants and perdurants.

I suggested you review ObservableAction vs ObservableObject because there is another "splitting" point that we can potentially consider a "top" endurant class: core:Item. Here is the class diagram (inlined syntax using Mermaid), though with the path to identity:Person thrown in for an extra question for @sbarnum :

flowchart LR

action_Action -->|subclass| observable_ObservableAction[**observable_ObservableAction**]
core_Item -->|subclass| observable_ObservableObject[**observable_ObservableObject**]
core_UcoObject -->|subclass| action_Action
core_UcoObject -->|subclass| core_Item
core_UcoObject -->|subclass| identity_Identity
core_UcoObject -->|subclass| observable_Observable
identity_Identity -->|subclass| identity_Person
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject

@sbarnum : core:Item only appears in one usage within UCO, as a parent class of observable:ObservableObject (here). I think we now need to understand its purpose better, and whether it is being underused currently, or is even still necessary.

I've never understood from the English in the IRI or its documentation comment why core:Item is, or is where it is. What, representable today in UCO under core:UcoObject, is not a core:item? Structurally, I've understood it to have a class-hierarchy influence that helps distinguish ObservableObject from ObservableAction. But why are neither identity:Person nor identity:Identity also a subclass of core:Item?

I wouldn't be raising this question if UCO used owl:disjointWith more earlier. And from discussion we've been having in the Facet Design Pattern Working-Group, I'll be proposing some owl:disjointWiths soon. But I now think we need to understand core:Item a bit more, because of some other details pertaining to observable:Observable's direct subclasses.

For reference, see this diagram, which starts at core:UcoObject and charts the subclass paths to only the direct subclasses of observable:Observable:

flowchart LR

action_Action -->|subclass| observable_ObservableAction
core_Item -->|subclass| observable_ObservableObject
core_Relationship -->|subclass| observable_ObservableRelationship
core_UcoObject -->|subclass| action_Action
core_UcoObject -->|subclass| core_Item
core_UcoObject -->|subclass| core_Relationship
core_UcoObject -->|subclass| observable_Observable
core_UcoObject -->|subclass| pattern_Pattern
observable_Observable[**observable_Observable**]
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject
observable_Observable -->|subclass| observable_ObservablePattern
observable_Observable -->|subclass| observable_ObservableRelationship

(I noticed when making this diagram there might be an oversight on ObservablePattern; let's discuss that on Issue 543.)

My confusion now stems from the definition comment of observable:Observable (here in UCO 1.2.0):

An observable is a characterizable item or action within the digital domain.

Written like that, it looks like the English-adhering implementation of Observable would instead be:

observable:Observable
    a owl:Class ;
    owl:disjointUnionOf (
        observable:ObservableAction
        observable:ObservableObject
    ) ;
    .

Because I doubt that's the intention:

• Should core:Item also be a superclass of pattern:Pattern, and core:Relationship?
  • Should we still even have core:Item? I admit I still can't understand its purpose aside from functionally being a class-hierarchy shim that looks a bit like an endurant/perdurant separation point.
• Should Observable's definition be expanded, since I imagine introducing core:Event would induce observable:ObservableEvent?

With the above sketches, here is my current thinking on the subclass hierarchy if core:Endurant and core:Perdurant were introduced, also including core:Event:

flowchart LR

core_UcoObject -->|subclass| core_Endurant[**NEW** core_Endurant]
core_UcoObject -->|subclass| core_Perdurant[**NEW** core_Perdurant]

action_Action -->|subclass| action_ActionPattern
action_Action -->|subclass| observable_ObservableAction
core_Endurant -->|subclass| core_Item
core_Endurant -->|subclass| core_Relationship
core_Endurant -->|subclass| identity_Identity
core_Endurant -->|subclass| pattern_LogicalPattern
core_Item -->|subclass| observable_ObservableObject
core_Perdurant -->|subclass| action_Action
core_Perdurant -->|subclass| core_Event[**NEW** core_Event]
core_Relationship -->|subclass| observable_ObservableRelationship
core_UcoObject -->|subclass| observable_Observable
core_UcoObject -->|subclass| pattern_Pattern
identity_Identity -->|subclass| identity_Person
observable_Observable -->|subclass| observable_ObservableAction
observable_Observable -->|subclass| observable_ObservableObject
observable_Observable -->|subclass| observable_ObservablePattern
observable_Observable -->|subclass| observable_ObservableRelationship
pattern_Pattern -->|subclass| action_ActionPattern
pattern_Pattern -->|subclass| pattern_LogicalPattern

I didn't see anything inconsistent about this Issue's proposed core:Event, supposing introduction of Endurant and Perdurant.

For the coming proposal on Endurant and Perdurant, we should be aware that there are at least two classes that don't clearly relate into that dichotomy because they have subclasses for both: observable:Observable and pattern:Pattern.

[ajnelson-nist]

An update: I've transcribed the example @sbarnum provided me to CASE-Examples, here.

To keep this Issue moving towards resolution:

1. @sbarnum , you have a few outstanding issues calling for replies, from me and @plbt5 .
2. @plbt5 , you left a "Changes Requested" review on the accompanying PR. After @sbarnum replies, please specify again what you want changed in light of the comments since your last proposed Turtle, if anything. In the meanwhile, it would still be helpful to have you propose adding Endurant & Perdurant in another Issue, as that is (I think) a truly bigger discussion than Event.

[ajnelson-nist]

This change proposal is now scheduled for a Requirements Review vote on August 29th.

@sbarnum , there are requests for replies from you in this comments thread.

[ajnelson-nist]

@sbarnum : Is the Event class you're proposing purely a temporal class, or is it potentially a spatial class as well? I ask because as I was peeking at the temporal region BFO class, I saw a sibling class spatiotemporal region that is directly-disjoint with temporal region. Another class , spatial region, is disjoint from a higher level in the hierarchy (synonymic with the Endurant-vs-Perdurant disjointedness). These three tie together with these properties (which IIRC apparently waiting for BFO 2.1 to be reintroduced to the OWL encoding):

• BFO_0000151 - "projects onto spatial region at some time"
• BFO_0000152 - "spatial projection of spatiotemporal at some time"
• BFO_0000153 - "projects onto temporal region"

Again, this is not a suggestion that UCO align with BFO. However, seeing this distinction made in another ontology makes me suspect it is something that UCO needs to be explicit about, and the uco-action:location (and possibly uco-action:environment) property suggest to me that the "Context" property you've proposed (core:eventContext) could turn a temporal Event into a spatiotemporal one.

Is core:Event intended to be only temporal, or can it also be spatiotemporal?

[ajnelson-nist]

I am concerned with eventType as a functionally less-potent form of owl:Class+rdf:type.

You gave this example:

      {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "core:Event",
            "core:name": "user logged in",
            "core:eventType": "Authentication"
      }

Why would we not define this?

      {
            "@id": "kb:event-d4a5a009-7b4d-445d-8d06-9dc85f263b3e",
            "@type": "observable:AuthenticationEvent",
            "core:name": "user logged in"
      }

I appreciate that this looks like another instance of the design pattern where UCO exchanges ontological functionality for the sake of ease of use of non-ontological users. (I.e., "Semi-open vocabularies", but no vocabulary accompanies this proposal.) But we should be aware that untyped strings' weakness mean some classes of events would be extremely difficult to correlate. Take for instance these strings:

• Authentication
• Successful Authentication
• Unsuccessful Authentication
• Failed Authentication
• Cancelled Authentication
• Incomplete Authentication

I hope it is clear that there is some hierarchy behind those events, at least in that "Successful authentications" would be a subset of "Authentications"; "Successful authentications" is disjoint with "Unsuccessful authentications"; and some unsuccessful authentication subclasses are "Security events", potentially leading to a reportable incident if there were some sequence of them (like, 1,000 correlated authentications, 999 failed followed by 1 successful).

I think eventType as a simple-string field is potentially significantly harmful to information interchange operations. Aside from the capitalization-normalization issues, it looks to me like there is potentially a significant loss of event class hierarchy.

I don't wish to hold up adding Event. But I currently do not support Requirement 3, and it reminds me that I've wanted a general caveating superproperty core:nonStructuralType (or similar) that effectively applies a caveat "Use of this property or its subproperties provides significant agility in data entry, but trades away some ability to standardize values, and loses ability to relate values such as in an OWL or RDF class hierarchy".

[sbarnum]

Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments.

First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal aspect, it itself is not simply a temporal specification (instantaneous or interval). It is more than that and can include who, what, why, where, etc. in addition to the when. The temporal specification would be one aspect of the Event expressed via startTime and endTime properties. It is very intentional that an Event could be either a point-in-time (instantaneous) or a bounded (startTime and endTime known) or unbounded (only one end of the interval known) interval, or temporally untethered such that a particular Event can be described without knowing its temporal dimension. This could be situations where something is known to have occurred but not when or where something could potentially occur sometime in the future and it is not known when. It is critical that Event support this level of flexibility as all of these scenarios are real-world and need ability to express.

Second, this proposal intentionally proposes introducing the concept of Event in as simple a manner as possible and intentionally avoids complex ontological discussions such as perduant vs endurant. Any such discussions should be handled separately in other proposals after the simple introduction of Event as a UcoObject. Such complexities should not prevent or delay the intitial introduction of Event.

Third, Event MUST be a subclass of UcoObject. It is a domain object within the CDO/UCO ontology and graph. It must be possible to cleanly relate Event to other UcoObjects as specified in Requirement #6. The purpose of UcoObject is for exactly this sort of situation. UcoObject is definitely NOT limited to EITHER perduant OR endurant. It is absolutely intended to be able to handle either of them.

Fourth, I will intentionally avoid going down the rabbit hole here on the question of potentially introducing perduant & endurant concepts as the should be more fully discussed in a separate proposal but it should be noted that this is another example of where we should be careful to balance how much ontological rigor we should introduce (sometimes because we can rather than necessarily that we should) with actualy practicality and flexibility of use. Reserving deeper discussion to occur in a separate discussion, core:Item is intended to represent a "thing" (yeah, I know that is pretty ambiguous) that would certainly fall into the endurant bucket if we ever go there but would be a particular subclass of endurant rather than the whole bucket and would be separate from things like Identity/Person/Organization, Pattern, Relationship, etc. Understanding that this is NOT a final conclusion from me and reserving the right to discuss further and potentially change my mind in a separate discussion regarding potentially incorporating perduant & endurant, this diagram from @ajnelson-nist is likely the closest thing to what would make sense to me except that Relationship should not be a subclass of Endurant as it often has a temporal dimension and could be considered perdurant in nature. I believe Relationship would either be a subclass of Perdurant or potentially more likely would be a subclass of UcoObject outside of Endurant or Perduant like Observable and Pattern are. You may want to include Location in this diagram as well as a subclass of Endurant.:

Fifth, on the question of where eventType should be a string or only conveyed via subclassing of Event this is definitely a situation where real-world practicality must trump a desire for hard restrictive ontological rigor. This is exactly the same situation as vocabularies. In fact, it is VERY likely that there should be one of more vocabularies for eventType defined in the future but they are not currently defined and should not hold up the introduction of Event for use. The key here is that like many other vocabulary scopes it is not at all possible for CDO/UCO to identify and define all possible types of event (they will be continuously growing/changing and particular corners of the community will always need to identify types of Events that are only relevant to themselves. Like with vocabularies it is not practical or acceptable to expect end users to define such event types not covered in CDO/UCO via formal ontological specification means. Such restrictions would a death knell for adoption. This does not mean that subclassing of Events cannot occur as desired and appropriate after the initial introduction of Event. They would simply be in addition to the eventType field (and could specify the exact eventType string as a constraint within the subclass) rather than a replacement for the eventType field. It would be simple for an adopter to utilize specific subclasses where desired or to analyze generic Event objects using their eventType property to derive particular subclassing if such subclasses have been defined sometime in the future. Having eventType as a string property does not prevent any of this from being possible in the future but it does protect flexibility for adopter practicality for the real world.

Sixth, in response to @ajnelson-nist question about alignment of the proposed Event with BFO's temporal region, spatiotemporal region, and spatial region, I think this illustrates part of my frustration with BFO and ontological overrigidity in general. In BFO, temporal region is an occurrent region in time and is purely a "when", spatial region is a location in space and is purely a "where", and spatiotemporal region is a location in space at a particular time and is therefore a pure restrictive combination of "where" and "when". These are all disjoint from each other which is not practical for real-world characterizations of events, especially as used in the cyber domain. In the cyber domain, events are something that occurred, is occurring or may occur in the future and may have associated details about "when" (potentially without "where" or could have multiple "where"s), may have associated details about "where" (potentially without "when"), and possibly all sorts of other contextual details (who, why, how, with, etc.). They do not fall purely within the BFO buckets. In CDO/UCO they must remain flexible enough to support practical use.

[packet-rat]

Please note that Event Start may change to an earlier time as an investigation proceeds. Several seemingly independent Events can also end up being related as investigations proceed.

Pat Maroney - AT&T

---

From: Sean Barnum @.> Sent: Monday, August 21, 2023 2:26:20 PM To: ucoProject/UCO @.> Cc: Subscribed @.***> Subject: Re: [ucoProject/UCO] Need ability to represent general concept of an Event (Issue #541)

Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments. First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal

Wow. Lots of comments to respond to. Sorry, I was also not getting notifications of these comments.

First, the intent for Event as a a noteworthy occurrence (something that happens or might happen) is that while it has an inherent temporal aspect, it itself is not simply a temporal specification (instantaneous or interval). It is more than that and can include who, what, why, where, etc. in addition to the when. The temporal specification would be one aspect of the Event expressed via startTime and endTime properties. It is very intentional that an Event could be either a point-in-time (instantaneous) or a bounded (startTime and endTime known) or unbounded (only one end of the interval known) interval, or temporally untethered such that a particular Event can be described without knowing its temporal dimension. This could be situations where something is known to have occurred but not when or where something could potentially occur sometime in the future and it is not known when. It is critical that Event support this level of flexibility as all of these scenarios are real-world and need ability to express.

Second, this proposal intentionally proposes introducing the concept of Event in as simple a manner as possible and intentionally avoids complex ontological discussions such as perduant vs endurant. Any such discussions should be handled separately in other proposals after the simple introduction of Event as a UcoObject. Such complexities should not prevent or delay the intitial introduction of Event.

Third, Event MUST be a subclass of UcoObject. It is a domain object within the CDO/UCO ontology and graph. It must be possible to cleanly relate Event to other UcoObjects as specified in Requirement #6https://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/6__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeJvwpKL0$. The purpose of UcoObject is for exactly this sort of situation. UcoObject is definitely NOT limited to EITHER perduant OR endurant. It is absolutely intended to be able to handle either of them.

Fourth, I will intentionally avoid going down the rabbit hole here on the question of potentially introducing perduant & endurant concepts as the should be more fully discussed in a separate proposal but it should be noted that this is another example of where we should be careful to balance how much ontological rigor we should introduce (sometimes because we can rather than necessarily that we should) with actualy practicality and flexibility of use. Reserving deeper discussion to occur in a separate discussion, core:Item is intended to represent a "thing" (yeah, I know that is pretty ambiguous) that would certainly fall into the endurant bucket if we ever go there but would be a particular subclass of endurant rather than the whole bucket and would be separate from things like Identity/Person/Organization, Pattern, Relationship, etc. Understanding that this is NOT a final conclusion from me and reserving the right to discuss further and potentially change my mind in a separate discussion regarding potentially incorporating perduant & endurant, this diagram from @ajnelson-nisthttps://urldefense.com/v3/__https://github.com/ajnelson-nist__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeBmgK30k$ is likely the closest thing to what would make sense to me except that Relationship should not be a subclass of Endurant as it often has a temporal dimension and could be considered perdurant in nature. I believe Relationship would either be a subclass of Perdurant or potentially more likely would be a subclass of UcoObject outside of Endurant or Perduant like Observable and Pattern are. You may want to include Location in this diagram as well as a subclass of Endurant.:

[Endurant_and_Perduant_subclassing_Alex]https://urldefense.com/v3/__https://user-images.githubusercontent.com/2760288/262107646-bc1dd56e-a63f-4e0e-baa7-75b968992cf0.png__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vge1eVHpio$

Fifth, on the question of where eventType should be a string or only conveyed via subclassing of Event this is definitely a situation where real-world practicality must trump a desire for hard restrictive ontological rigor. This is exactly the same situation as vocabularies. In fact, it is VERY likely that there should be one of more vocabularies for eventType defined in the future but they are not currently defined and should not hold up the introduction of Event for use. The key here is that like many other vocabulary scopes it is not at all possible for CDO/UCO to identify and define all possible types of event (they will be continuously growing/changing and particular corners of the community will always need to identify types of Events that are only relevant to themselves. Like with vocabularies it is not practical or acceptable to expect end users to define such event types not covered in CDO/UCO via formal ontological specification means. Such restrictions would a death knell for adoption. This does not mean that subclassing of Events cannot occur as desired and appropriate after the initial introduction of Event. They would simply be in addition to the eventType field (and could specify the exact eventType string as a constraint within the subclass) rather than a replacement for the eventType field. It would be simple for an adopter to utilize specific subclasses where desired or to analyze generic Event objects using their eventType property to derive particular subclassing if such subclasses have been defined sometime in the future. Having eventType as a string property does not prevent any of this from being possible in the future but it does protect flexibility for adopter practicality for the real world.

Sixth, in response to @ajnelson-nisthttps://urldefense.com/v3/__https://github.com/ajnelson-nist__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeBmgK30k$ question about alignment of the proposed Event with BFO's temporal region, spatiotemporal region, and spatial region, I think this illustrates part of my frustration with BFO and ontological overrigidity in general. In BFO, temporal region is an occurrent region in time and is purely a "when", spatial region is a location in space and is purely a "where", and spatiotemporal region is a location in space at a particular time and is therefore a pure restrictive combination of "where" and "when". These are all disjoint from each other which is not practical for real-world characterizations of events, especially as used in the cyber domain. In the cyber domain, events are something that occurred, is occurring or may occur in the future and may have associated details about "when" (potentially without "where" or could have multiple "where"s), may have associated details about "where" (potentially without "when"), and possibly all sorts of other contextual details (who, why, how, with, etc.). They do not fall purely within the BFO buckets. In CDO/UCO they must remain flexible enough to support practical use.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/ucoProject/UCO/issues/541*issuecomment-1686819689__;Iw!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vgeiwB16B0$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAYSFYMAYMQETK4EKB2GOEDXWOR4ZANCNFSM6AAAAAA2QJYQ7A__;!!BhdT!mU_XFBhtt7ZQazSwuy5X-ynMSXjLbbQredaNwGAlXOYggs535Ymu9XQ8C7OrFmQOKOBKHUEPIwjYGLcA7vge715I9HM$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ajnelson-nist]

@packet-rat - Agreed. One example is a reportable cybersecurity incident that ends up becoming comprised of more and more events that are realized to be associated - e.g., a set of authentication attempts. This leads us to discuss an encoding and logical-enforcement matter: Say we have an attack event, A, originally believed to start at time T0. We record a start time of T0 on A. Later we realize a more technically-narrow event E was part of the attack, and it started at time T1 well before T0.

I think some of what @sbarnum suggested in Requirements 4 and 6 suggest UCO is required to be able to support "Batching" the event E into the attack A. But, if we do, is it a data error for E's start time to be before A's start time? I'm not sure if we need to discuss this as core:Event is introduced, but we would need to discuss this if we end up defining a property or strictly-typed core:Relationship that "batches" core:Events into core:Events.

I'll have more replies for @sbarnum's remark coming soon.

[ajnelson-nist]

First, let's please consider Endurants and Perdurants as out of scope of this proposal on Events. Another proposal (with revised figures) is under draft, on Issue 544. @sbarnum, you have agreement from @plbt5 and me that Relationship wasn't correctly placed in my initial sketch. And thank you for the Location suggestion, I agree and have updated the figure over on 544 to reflect that.

Second, on core:Item: I look forward to one day understanding why a uco-identity:Person is not a uco-core:Item. But, I think that topic is comfortably out of scope of discussing Event, and more in scope for endurant/perdurant over on 544.

Third, @sbarnum, is this the case:

action:Action
    rdfs:subClassOf core:Event ;
    .

If not, can you give an Action that is not an Event?

Fourth, @sbarnum, thank you for the response on eventType. In deferrence to current practices, I won't oppose Requirement 5.

However, I need to urge against a particular practice you suggested, my own emphasis added:

This does not mean that subclassing of Events cannot occur as desired and appropriate after the initial introduction of Event. They would simply be in addition to the eventType field (and could specify the exact eventType string as a constraint within the subclass) rather than a replacement for the eventType field.

UCO should never propose such a tie of string-literal value to an Event subclass. The reason is, this prevents any other eventType value from being used on further subclasses of the first subclass to bind the value. For a demonstration of why this is a problem, take observable:Observation, a subclass of action:Action, that binds the value "observe" to core:name. (See Line 5060.) If we later defined further subclasses of Observation, like AutomatedObservation, that class would also be stuck with "observe" as its mandatory core:name value on any instance, due to inheritance. (I consider this a technical flaw in Observation's implementation, but haven't gotten around to proposing excising it yet.)