Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are the classes Event and Action disjoint? #563

Closed
13 tasks done
ajnelson-nist opened this issue Nov 16, 2023 · 6 comments · Fixed by #564
Closed
13 tasks done

Are the classes Event and Action disjoint? #563

ajnelson-nist opened this issue Nov 16, 2023 · 6 comments · Fixed by #564

Comments

@ajnelson-nist
Copy link
Contributor

ajnelson-nist commented Nov 16, 2023

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
  • Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-11-20
  • Requirements development phase skipped - proposal fast-tracked as follow-on to other completed proposal.
  • Solution announced to OCs on 2023-11-20
  • Solutions Approval to be discussed in OC meeting, 2023-11-28
  • Solutions Approval vote occurred, passing, on 2023-11-28
  • 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 (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
@ajnelson-nist ajnelson-nist added this to the UCO 1.3.0 milestone Nov 16, 2023
@sbarnum
Copy link
Contributor

sbarnum commented Nov 17, 2023

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
Copy link
Contributor

plbt5 commented Nov 17, 2023

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.

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
Copy link
Contributor Author

@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
Copy link
Contributor

plbt5 commented Nov 17, 2023

@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
Copy link
Contributor Author

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

ajnelson-nist added a commit that referenced this issue Nov 20, 2023
In an OWL-only sense, the ontology portion of this patch could have been
accomplished by adding one triple to `action:Action`.

For the sake of symmetry and explicitness, `core:Event` also picked up
the `owl:disjointWith` statement.  To satisfy OWL syntactic
requirements, a stub reference to `action:Action` was added, as was done
for `types:Dictionary` for Issue 541 (discussed in PR 542).

To enforce disjointedness with SHACL, a new independent shape is added,
`action:Action-disjointWith-Event-shape`.  The shape is spelled using an
anonymous node shape to avoid a multiple-inheritance issue:

* SHACL syntactically requires the subject of a triple with `sh:not` as
  predicate be a blank node.
* Separately, SHACL also only permits a shape to have up to one triple
  with `sh:not` as predicate.

Hence, if the `action.ttl` file were included twice in some graph,
SHACL-SHACL validation would fail, because the identically-written blank
nodes that are `sh:not` objects would not resolve to the same node.
Using an anonymous wrapping `sh:NodeShape` avoids this issue.
(Multiple inheritance would now cause some redundant processing to occur,
but SHACL-SHACL validation would pass.)

A follow-on patch will regenerate Make-managed files.

References:
* #563
* #542
* https://www.w3.org/TR/shacl/#shacl-shacl

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit that referenced this issue Nov 20, 2023
References:
* #563

Signed-off-by: Alex Nelson <[email protected]>
@ajnelson-nist
Copy link
Contributor Author

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

@ajnelson-nist ajnelson-nist linked a pull request Nov 20, 2023 that will close this issue
13 tasks
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Nov 20, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Nov 20, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Nov 20, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Nov 20, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 20, 2023
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 20, 2023
References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit that referenced this issue Nov 22, 2023
In an OWL-only sense, the ontology portion of this patch could have been
accomplished by adding one triple to `action:Action`.

For the sake of symmetry and explicitness, `core:Event` also picked up
the `owl:disjointWith` statement.  To satisfy OWL syntactic
requirements, a stub reference to `action:Action` is added, as was done
for `types:Dictionary` for Issue 541 (discussed in PR 542).

To enforce disjointedness with SHACL, a new independent shape is added,
`action:Action-disjointWith-Event-shape`.

A follow-on patch will regenerate Make-managed files.

EDIT 2023-11-22: An initial version of this patch included an inlined
anonymous `sh:NodeShape`.  I now believe the scenario that shape
mitigates (multi-import of a shapes graph leading to SHACL-scoped syntax
errors) is unlikely, and I also saw that the noted rationale around
`sh:not` was confused with another predicate (`sh:inversePath`).

References:
* #563
* #542

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit that referenced this issue Nov 22, 2023
References:
* #563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Nov 22, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Nov 22, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 22, 2023
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 22, 2023
References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Nov 22, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Nov 22, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to ucoProject/ucoproject.github.io that referenced this issue Nov 28, 2023
References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE that referenced this issue Dec 1, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Dec 5, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE that referenced this issue Dec 5, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Dec 5, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Dec 5, 2023
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Dec 5, 2023
References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Dec 5, 2023
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Dec 5, 2023
References:
* ucoProject/UCO#563

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Dec 5, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563
* ucoProject/UCO#571

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/CASE-Corpora that referenced this issue Dec 5, 2023
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#563
* ucoProject/UCO#571

Signed-off-by: Alex Nelson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants