Are the classes `Event` and `Action` disjoint?

[ajnelson-nist]

During discussion on #541 , we had considered whether Action is strictly a subclass of the new class Event. A result of the discussion was, no, Action does not specialize Event, because they have different annotative properties that would look out of place on one another.

We did not take this further and ask the other side: Are they disjoint classes?

Do we have an example available of an Action that is also an Event? Or, should we supplement #541 before cutting UCO 1.3.0, that the two classes are disjoint?

@plbt5 , I'm interested in your input especially with respect to the endurants-vs-perdurants proposal; and @sbarnum , I'm interested in your input w.r.t. the generally-spelled "context" property. If Action and Event are disjoint, what are examples of:

1. Linking an Action to an Event;
2. Linking an Event to an Action?

If we don't decide this now, a disjointedness assertion would have to wait for a SEMVER-major UCO release.

Requirements

Requirement 1

Events and Actions are disjoint classes, and must be encoded as such.

Risk / Benefit analysis

Benefits

• Discussion around how events and actions relate to one another looks to be settled on the classes being disjoint. (The conversation is settled on the Ontology Committees voting so on Nov. 28th.)

Risks

• Nuances on why events and actions are disjoint might require frequent re-explanation to UCO adopters.
  • One focus of the explanation can be on the agency associated with an action; that is, an action has an active, motivating actor of some sort, be it a person, organization, or program. Meanwhile, an event can occur without an actor, such as the seconds where an earthquake occurs, a tree falling as either the interval of motion or the moment of impact, or the CPU clock tick a computer considers the discrete instant a month begins and certain cron jobs trigger.

Competencies demonstrated

Competency 1

Competency Question 1.1

What events are also actions?

Result 1.1

This query will always return no results.

Competency Question 1.2

How do events and actions relate?

Result 1.2

This parthood (mereology) discussion is delegated to other issues, e.g. #544 and #565.

541 had suggested that one or more actions can be the context of an event using the core:eventContext property; though, note that eventContext can be any UcoObject.

541 also suggested that an event can be a result of an action. #565 is inspecting some details about that mechanism.

Solution suggestion

• Add owl:disjointWith statements between action:Action and core:Event.
• To support applications not using OWL reasoning, supply SHACL constraints using sh:not to confirm that any action:Action is not also a core:Event.

Note: The initial spelling of the SHACL constraint uses a wrapping, anonymous sh:NodeShape to mitigate an issue an application could run into if they imported UCO twice. The technical rationale for that design pattern is documented in this commit log.

Coordination

• Tracking in Jira ticket OC-298
• [x] Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-11-20
• [x] Requirements development phase skipped - proposal fast-tracked as follow-on to other completed proposal.
• [x] Solution announced to OCs on 2023-11-20
• [x] Solutions Approval to be discussed in OC meeting, 2023-11-28
• [x] Solutions Approval vote occurred, passing, on 2023-11-28
• [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
• [x] Prerelease publication: CASE develop branch updated to track UCO's updated develop branch
• [x] Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[sbarnum]

Yes. Action and Event are disjoint. No Action is ever an Event and no Event is ever an Action.

An Event can consist of one of more Actions potentially with temporal relationships between them. All such context (Actions, Relationships, etc.) for the Event would be contained in the eventContext property.

[plbt5]

The specific question here is: What is the essential element that separates the Event from the Action, as in, essentially belongs to one but definitely doesn't belong to the other. Having answered that, is there yet another element that applies vice versa?

From the perdurant/endurant perspective, we consider both uco:Event and uco:Action subclasses perdurants. That implies that they both unfold over time. When we consider them disjoint, then their distinction should be sought in either two aspects: do they

1. unfold differently, i.e., are they composed of distinct proper parts;
2. have different types of endurants as their participants.

Let's look at their definitions.

• "An action is something that may be done or performed." (from action:Action)
• "An Event is a noteworthy occurrence (something that happens or might happen)." (from #541)

From this I'd conclude the following distinctions:

• an Action is externally dependent on humans/agents that have an implicit capability to perform something, an action. For an Event this is not required.
  • restriction: Action hasParticipant _some_ human/agent

    uco-action:Action owl:subClassOf uco:Perdurant ,
    [ rdf:type owl:Restriction ;
      owl:onProperty uco:hasParticipant ;
      owl:someValuesFrom uco:(Human/Agent) ;
    ] .

• causally, an Action produces (uco-action:result) a result of some sort, whereas an Event brings about a situation.

  uco-action:result rdfs:subPropertyOf uco:hasParticipant ;
      rdfs:domain uco-action:Action ;
      rdfs:comment "Identifies a (uco:?)Result that is produced by the uco-action:Action"@en .
  
  uco:bringsAbout rdfs:subPropertyOf uco:hasParticipant ;
      rdfs:domain uco:Event 
      rdfs:comment "Identifies a (uco:?)Situation that is brought about by the uco:Event"@en .

  Based on these constraints we now can declare Action and Event as being disjoint.

Note:

1. uco:bringsAbout would be a new property.
2. uco-action:result requires verification against its current declarations.

I'm not sufficiently involved to decide whether situation and result are required as UCO concepts. But that is beside the point of the question.

[ajnelson-nist]

@plbt5 - uco-action:result is already defined.

If you mean "Situation" as in the gUFO sense - UCO doesn't currently have that, and that will be a challenging discussion to have. I think it's worth having, because IIRC gufo:Situations are one way to handle role enactments, and I believe someone is brewing a UCO proposal to revise how uco-role:Role currently behaves.

[plbt5]

@ajnelson-nist - I've updated the examples with uco-action: result, as well added two Notes. Regarding the "Situation", I do mean this to apply in the gUFO sense; however, neither "Situation" nor "Result" are required to be defined.

[ajnelson-nist]

Thank you, @sbarnum and @plbt5 , this looks like enough to me to fast-track an additional change on top of #541 .

[ajnelson-nist]

This question has been updated to become a fast-tracked proposal, with the implementation to be voted on in the November 28th OCs call.