ucoProject / UCO

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

Support the distinction between Perdurants and Endurants #544

Open plbt5 opened 1 year ago

plbt5 commented 1 year ago

Background

A distinction that is often used in ontology engineering is that between things that simply are, denoted in philosophy as endurants, and things that happen over time, denoted perdurants.

Endurants / continuants

(taken from wikipedia, formal ontology )

Also known as continuants, or in some cases as "substance", endurants are those entities that can be observed-perceived as a complete concept, at no matter which given snapshot of time. Were we to freeze time we would still be able to perceive/conceive the entire endurant.

Examples include material objects (such as an apple or a human), and abstract "fiat" objects (such as an organization, or the border of a country).

Perdurants / occurrents

(taken from wikipedia, formal ontology )

Also known as occurrents, accidents or happenings, perdurants are those entities for which only a part exists if we look at them at any given snapshot in time. When we freeze time we can only see a part of the perdurant. Perdurants are often what we know as processes, for example: "running". If we freeze time then we only see a part of the running, without any previous knowledge one might not even be able to determine the actual process as being a process of running. Other examples include an activation, a kiss, a procedure, meetings, or a football match.

"Considered to be" is a matter of perspective

Whether we consider something as a perdurant or endurant is completely dependent on the perspective of view. In ontology engineering, we “[...] do not ask for what there is, but for what a given remark or doctrine [...] says there is” (Quine, 1961). When we model a part of reality, we necessarily create an abstraction. We abstract away those aspects that are irrelevant to our purpose. For instance, a football match is considered a perdurant for a trainer that analyses the best way to win the match; a sports-historian, though, will consider the very same football match an endurant for her interest is solely in the result of the match, who's won.

Requirements

Requirement 1

The ability in the standard to make a distinction between things that are (endurants) and things that happen (perdurants) in time, in accordance to the accepted philosophical distinction in literature.

Requirement 2

Endurant and Perdurant should be considered abstract in the sense that one cannot instantiate them directly but only indirectly through their subclasses.

Requirement 3

The ability to express that an endurant participatesIn a perdurant.

Requirement 4

The ability for a perdurant to have a proper parthood relationship with other perdurants, similar with how endurants (in the general sense, but not here) go about parthood relationships. (We do not yet see a reason to include an improper parthood relation, hence we skip that until required.)

Edited at December 1st, 2023 by @plbt5 ; This was originally proposed as:

The ability for a perdurant to have a parthood relationship with other perdurants, similar with how endurants go about parthood relationships.

Risk / Benefit analysis

Benefits

The requested distinction reflects an intuitive separation that is generally being applied by data models and recognised by applications that use or generate data. It therefore makes sense to include such distinction in the ontology in order to closely match the intended meaning of the data. This improves the support to interoperability between applications that exchange data in accordance to UCO.

It does not enforce adopters to change their data model to recognise this distinction. Only when an application is using the distinction it can map those data elements to the appropriate category. This improves the accuracy of the intended meaning of data.

Because perdurants happen in time, there is no need to indicate any timing information since that is not the essence of a perdurant. The essence of a perdurant is that it shows a sequence of things that apply in a certain order, i.e., the unfolding of a crisis. Time points or duration can be attached to a perdurant, but is not required.

Throughout its existence, its unfolding, endurants participate in its life cycle. Hence, each relation between perdurants and endurants are based on the participation relationship.

Risks

The submitter is unaware of risks associated with this change

Competencies demonstrated

Competency 1

The current UCO design requires as necessary condition that UCO observable:ObservableObjects are independent from the context of the observer. Consider two phones of agents that take part in a message conversation, controlled by a message server. These three agents will have different views on the message thread based on their role in the conversation. This implies that each agent will have their own perspective on the message thread which is context dependent.

One of the message senders could stop participating in the conversation. This would be shown on the participant's phone as departing the chat. His participation ends at that very moment. Another agent joining the same thread might, or might not, be informed there was a previous participant. This presents a disparity on the modeled observable:MessageThread depending on the user's perspective: The user who left has application records that show 2 participants. The user who joins later shows 2 or 3. The user who was there the whole time shows 3. The application could present the same "Thread identifier" in all three users' application databases.

An instant messaging conversation is not limited to one message application. A coherent stream of messages can switch between applications from day to day, because, e.g., one participating agent can only access her phone or her computer at times.

The current design in UCO would need to found itself on several distinct copies of the message thread (one per participating phone, plus one from the service). These message threads would be projections of the perdurant that is the real conversation, projected into records (endurants) in the applications' databases. Each phone's observable:MessageThread would be different from the other phones', but the conversation remains the same. The inclusion of a Perdurant as overarching evolving thing, and its necessary anticipating relationship with the observable:MessageThread from all phones and the server makes it more simple to show how the different three observable:MessageThread would fit into the message conversation.

Comprehensiveness is a goal one would like to achieve with an ontology. By introducing the distinction between endurant and perdurant, we improve the comprehensiveness of the ontology. Specifically, we start to identify classes with an evolutionary characteristic to them.

flowchart TB

core_Item(core:Item)
core_Endurant(**NEW**\ncore:Endurant)
core_Event(**NEW**\ncore:Event\nfrom Issue 541)
core_Perdurant(**NEW**\ncore:Perdurant)
core_UcoObject(core:UcoObject)
ex_InstantMessageConversation(**NEW**\nex:InstantMessageConversation\nfrom discussion)
observable_MessageThread(observable:MessageThread)
observable_Observable(observable:Observable)
observable_ObservableObject(observable:ObservableObject)

style core_Endurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style core_Event fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style core_Perdurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style ex_InstantMessageConversation fill:#9EFC3A,stroke:#5CE640,stroke-width:4px

observable_MessageThread -->|projection of| ex_InstantMessageConversation

subgraph Either
  core_UcoObject -->|subclass| observable_Observable
end

subgraph Endurants
  core_UcoObject -->|subclass| core_Endurant
  core_Endurant -->|subclass| core_Item
  observable_Observable -->|subclass| observable_ObservableObject
  observable_ObservableObject -->|subclass| observable_MessageThread
end

subgraph Perdurants
  core_Event -->|subclass| ex_InstantMessageConversation
  core_Item -->|subclass| observable_ObservableObject
  core_Perdurant -->|subclass| core_Event
  core_UcoObject -->|subclass| core_Perdurant
  observable_Observable -->|subclass| ex_InstantMessageConversation
end

Competency Question 1.1

What are the participants in the instant messaging conversation? Take into account:

  1. the global perspective
  2. phone 1's perspective only
  3. the message service's perspective

Result 1.1

The results should include:

Competency Question 1.2

How are the various message threads divided over the distinct applications? At what times are the messages set in the overall conversation?

Result 1.2

The results should show how the distinct message threads compose into a larger conversation.

Solution suggestion

flowchart TB

core_Perdurant(**NEW**\ncore:Perdurant)
core_Endurant(**NEW**\ncore:Endurant)

style core_Endurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style core_Perdurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px

subgraph Overview
  core_Perdurant -->|core:hasParticipant| core_Endurant
  core_Perdurant -->|core:isPerdurantProperPartOf| core_Perdurant
end
flowchart LR

action_Action(action:Action)
action_ActionPattern(action:ActionPattern)
core_Item(core:Item)
core_Relationship(core:Relationship)
core_Endurant(**NEW**\ncore:Endurant)
core_Event(**NEW**\ncore:Event\nfrom Issue 541)
core_Perdurant(**NEW**\ncore:Perdurant)
core_UcoObject(core:UcoObject)
identity_Identity(identity:Identity)
identity_Person(identity:Person)
location_Location(location:Location)
observable_Observable(observable:Observable)
observable_ObservableAction(observable:ObservableAction)
observable_ObservableObject(observable:ObservableObject)
observable_ObservablePattern(observable:ObservablePattern)
observable_ObservableRelationship(observable:ObservableRelationship)
pattern_LogicalPattern(pattern:LogicalPattern)
pattern_Pattern(pattern:Pattern)

style core_Endurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style core_Event fill:#9EFC3A,stroke:#5CE640,stroke-width:4px
style core_Perdurant fill:#9EFC3A,stroke:#5CE640,stroke-width:4px

subgraph Either
  core_Relationship -->|subclass| observable_ObservableRelationship
  core_UcoObject -->|subclass| core_Relationship
  core_UcoObject -->|subclass| observable_Observable
  core_UcoObject -->|subclass| pattern_Pattern
  observable_Observable -->|subclass| observable_ObservableRelationship
end

subgraph Endurants
  core_UcoObject -->|subclass| core_Endurant
  core_Endurant -->|subclass| identity_Identity
  core_Endurant -->|subclass| location_Location
  core_Endurant -->|subclass| observable_ObservablePattern
  core_Endurant -->|subclass| pattern_LogicalPattern
  core_Endurant -->|subclass| core_Item
  core_Item -->|subclass| observable_ObservableObject
  identity_Identity -->|subclass| identity_Person
  observable_Observable -->|subclass| observable_ObservableObject
  observable_Observable -->|subclass| observable_ObservablePattern
  pattern_Pattern -->|subclass| pattern_LogicalPattern
end

subgraph Perdurants
  action_Action -->|subclass| action_ActionPattern
  action_Action -->|subclass| observable_ObservableAction
  core_Perdurant -->|subclass| action_Action
  core_Perdurant -->|subclass| core_Event
  core_UcoObject -->|subclass| core_Perdurant
  observable_Observable -->|subclass| observable_ObservableAction
  pattern_Pattern -->|subclass| action_ActionPattern
end

Coordination