-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
Yes. Action and Event are disjoint. An Event can consist of one of more Actions potentially with temporal relationships between them. |
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
Let's look at their definitions.
From this I'd conclude the following distinctions:
Based on these constraints we now can declare Action and Event as being disjoint. Note:
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. |
@plbt5 - 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 |
@ajnelson-nist - I've updated the examples with |
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]>
References: * #563 Signed-off-by: Alex Nelson <[email protected]>
This question has been updated to become a fast-tracked proposal, with the implementation to be voted on in the November 28th OCs call. |
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
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]>
References: * #563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
References: * ucoProject/UCO#563 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 * ucoProject/UCO#571 Signed-off-by: Alex Nelson <[email protected]>
No effects were observed on Make-managed files. References: * ucoProject/UCO#563 * ucoProject/UCO#571 Signed-off-by: Alex Nelson <[email protected]>
During discussion on #541 , we had considered whether
Action
is strictly a subclass of the new classEvent
. A result of the discussion was, no,Action
does not specializeEvent
, 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 anEvent
? 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
andEvent
are disjoint, what are examples of: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
Risks
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 thateventContext
can be anyUcoObject
.#541 also suggested that an event can be a result of an action. #565 is inspecting some details about that mechanism.
Solution suggestion
owl:disjointWith
statements betweenaction:Action
andcore:Event
.sh:not
to confirm that anyaction:Action
is not also acore: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
develop
for the next releasedevelop
state with backwards-compatible implementation merged intodevelop-2.0.0
develop-2.0.0
(N/A)develop
branch updated to track UCO's updateddevelop
branchdevelop-2.0.0
branch updated to track UCO's updateddevelop-2.0.0
branchThe text was updated successfully, but these errors were encountered: