Support the distinction between Perdurants and Endurants

[plbt5]

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

Loading

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:

• the messaging app
• the individual messages
• the accounts used to send and receive messages
• the threads ordering the messages

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

Loading

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

Loading

Coordination

• Tracking in Jira ticket OC-296

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-10-27
• Requirements to be discussed in OC meeting, 2023-11-28
• Requirements Review vote has not occurred

• Requirements development phase completed.
• Solution announced to OCs on TODO-date
• Solutions Approval to be discussed in OC meeting, date TBD
• Solutions Approval vote has not occurred

• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release (N/A)
• develop state with backwards-compatible implementation merged into develop-2.0.0 (N/A)
• Backwards-incompatible implementation merged into develop-2.0.0 (or N/A)
• Milestone linked
• Documentation logged in pending release page

[ajnelson-nist]

(Practical disclaimer on this comment: I am not a memory analyst.)

I think one of the complexities this pair of classes will introduce to UCO will specifically pertain to running processes and similar: observable:Process, observable:ProcessThread, and their subclasses. I think in other foundational ontologies these would be Perdurantss (a.k.a. Occurrents), but in some conditions a Process (/Thread) can be frozen in time and analyzed, e.g. in some debuggers (such as gdb) or in paused virtual machines. In these cases, they're effectively Endurantss (a.k.a. Continuants) - we've frozen time, and everything about the object is contained in that time-slice. But trying to make an observable:Image of a running Process on a non-virtual, hypervisor-less device feels very much like the Process is a Perdurant - the imager likely cares a lot about what the Process has done before, and might do after, that Image is taken.

In a similar vein, though, I look forward to the clarity this class-pair will bring to observable:OperatingSystem. UCO is currently loose in its treatment of this class, not specifying whether an instance of an OperatingSystem is something that is running or not, i.e. akin to a Process or not. I've been wanting to propose OperatingSystemProcess as a class, knowing it should be a subclass of Process, but not knowing if it should or could also be a subclass of OperatingSystem.

[ajnelson-nist]

From discussion with @plbt5 : Another motivation for endurants vs perdurants is observable:MessageThread, whose state evolves with time.

[ajnelson-nist]

(C/o remembering something when I was writing this comment...)

Separation of Endurants from Perdurants will help UCO describe the general "lifespan" of endurants, and give us the opportunity to decide whether they should handle their relationships to general time intervals differently.

Let's take flight human flight as an example. Let's take a made-up person named Charlie, born in 1950, passed in 1990. 40-year life span. Born after the Wright Brothers' flight (1903-12-17), but alive when humanity achieved the first human-on-the-moon landing (1969-07-20). There are a few time relationships in there.

As pure time intervals, the event on 1903-12-17 "takes place before the event" on 1969-07-20.

kb:e-1903-12-17 ex:before kb:e-1969-07-20 .

If perdurants relate to time by specializing time intervals ...

drafting:Perdurant rdfs:subClassOf ex:TemporalInterval .

... then we can say, "The event of the first Wright Brothers' flight took place before the moon landing."

kb:WrightBrothersFlight ex:before kb:MoonLanding1 .

Now, let's take Charlie. Born 1950, passed 1990; let's say Jan 1 00:00 UTC on both ends. Charlie, as a human, has a "lifespan" that happens to have both ends defined. We can define Charlie's lifespan as an event, and from UCO's core:startTime and core:endTime being English-defined (as current in 1.2.0) as "The (initial|ending) time of a time range", we can define Charlie's lifespan here:

kb:Charlie
    a uco-identity:Person ;
    .
kb:CharlieLifespan
    core:startTime "1950-01-01T00:00Z" ;
    core:endTime "1950-01-01T00:00Z" ;
    .

How does kb:Charlie relate to kb:CharlieLifespan?

In other foundational ontologies, kb:Charlie is an endurant, and kb:CharlieLifespan a perdurant. If we didn't do this, and treated kb:Charlie as appropriate to bear core:startTime, then we accidentally induce kb:Charlie becoming a time range. Then it's appropriate by UCO's model to say:

The Wright Brothers' Flight took place before Charlie.

...which, seems ok...

The Moon Landing took place during Charlie.

...aaaaand, we have a problem.

The English hints that we should relate Charlie to Charlie's lifespan if we're going to relate Charlie to events, temporally:

The Wright Brothers' Flight took place before Charlie's lifespan.
The Moon Landing took place during Charlie's lifespan.

So, I suggest we consider this as further motivation for introducing endurants and perdurants to UCO. Endurants should relate to time intervals as separated graph nodes. Perdurants can specialize time intervals, or instead relate to them in their own way like endurants.¹ My personal preference is that perdurants do specialize time intervals, but that specific decision is probably out of scope of this proposal. For this proposal, I think it's fine to confirm the time separation on endurants.

Also, I did not realize that core:startTime and core:endTime already have their English written as though UCO has defined time ranges. There is no time range class at the moment, and those two properties seem to only have constraints defined on core:Relationship at present.

Footnotes

1. I recall there's a paragraph somewhere in OWL-Time or a supplement to it that says either way is appropriate when modeling time vs. other classes; that OWL-TIme is written to not force an adopter to go either way; and that the paragraph seemed applicable in time modeling outside of OWL-Time. I can't find the paragraph at the moment, though. ↩

[ajnelson-nist]

@plbt5 completed his submission of this proposal today. We will discuss it in the 2023-11-28 meeting.

[ajnelson-nist]

PR #559 is posted implementing this proposal, and testing seems to show no conflicts against current CASE examples.

[ajnelson-nist]

An update on risks of the perdurants-vs-endurants proposal:

CASE Issue 138 proposes changing case-investigation:Investigation to become a subclass of uco-core:Event, instead of how it is currently a subclass of uco-core:ContextualCompilation.

We should confirm as part of this proposal whether uco-core:Compilation and its subclasses are endurants. @plbt5 ?

If so, we would have to consider if we're comfortable with what would need to change with data like this:

# (Today.)
kb:Investigation-1
    a case-investigation:Investigation ;
    uco-core:object
        kb:Device-1 ,
        kb:InvestigativeAction-1 ,
        kb:ProvenanceRecord-1
        ;
    .

It looks like that would become:

# (Assuming merging UCO Issue 544 and CASE Issue 138.)
kb:Investigation-1
    a case-investigation:Investigation ;
    uco-core:hasParticipant
        kb:Device-1 ,
        kb:ProvenanceRecord-1
        ;
    .
kb:InvestigativeAction-1
    uco-core:isPerdurantProperPartOf
        kb:Investigation-1
        ;
    .

@plbt5 - I didn't realize we had this asymmetry in the properties currently encoded in #559 . This looks to me like a suggestion for adding inverse properties.

[plbt5]

@ajnelson-nist I've considered whether it was necessary to include the InverseFunctionalProperty attribute to uco-core:hasParticipant, but decided that was too restrictive. At the same time, I overlooked the [owl:inverseOf](http://www.w3.org/TR/2004/REC-owl-semantics-20040210/#owl_inverseOf) attribute. Indeed, gUFO does not include an owl:inverseOf of its gufo:participatedIn, while funny enough we've defined its inverse as our uco-core:hasParticipant.

I don't see any objection to include the inverse, hence we can add

uco-core:participatesIn owl:inverseOf uco-core:hasParticipant .

to the solution of #559.

[ajnelson-nist]

Thank you. Let's talk through adding that tomorrow.

Meanwhile, this proposal is currently set as a UCO 2.0.0, backwards-incompatible proposal. Are there parts of this proposal that you think could be added as part of UCO 1.x.0 (maybe even 1.3.0), such as the disjoint classes core:Endurant and core:Perdurant with no further subclassing, and the new properties? This would make the divide available for new classes to use them along the way to UCO 2.0.0, while not impacting current classes.

[plbt5]

Yes, that would make sense, wouldn't it? One can then start to use the distinction between Ps and Es, get used to it so to speak.

However....

1. It might result in intuitive incoherence, or cognitive dissonance, when combining the E/P distinction with classes that will become their subclasses with the UCO 2.0.0 release, but until then are just classes that exist aside to E/P. I'm not sure how helpful this will be for getting an understanding of the E/P distinction, because such illogical constructer are deemed to happen.
2. It will also produce a larger pile of refactoring issues, created by 1, to be performed after UCO 2.0.0

IMO we can pursue this suggestion, as long as we make crystal clear that their use should be minimised to test and evaluation scenarios only.

[ajnelson-nist]

I'm not sure I follow why putting in E-P without subclassing now would cause a larger pile of refactoring issues? Do you mean, larger than what's currently in #559, which targets 2.0.0?

Alternative, for discussion and/or pursuit:

Let's say, instead, that we take PR #559 and clone it to apply against the current develop, changing the E-P disjointedness shape to only raise a sh:Warning-level validation result. This follows the deprecation pattern I've used on other proposals that deprecated something for removal in 2.0.0.

That could cause a lot of validation noise against current user data. The prerelease review (validating all CASE examples) for #559 has finished against 2.0.0 without raising any problems, so maybe not.

Would you prefer either, or neither, be tried before 2.0.0? We unfortunately can't try both at the same time, because putting in E-P disjointedness as a sh:Violation means we can't make current classes subclasses and be backwards-compatible.

[ajnelson-nist]

@plbt5 , I see an interesting suggestion from the property name isPerdurantProperPartOf - particularly, the "proper" word. Does this mean UCO would also need an "isPerdurantImproperPartOf" property? If we were discussing sets (or classes), we would be deciding where we would use the symbol ⊂ ("proper subset of") vs. the symbol ⊆ ("proper subset of or equal to").

I think isPerdurantImproperPartOf would be part of a sub-property hierarchy:

core:isPerdurantPartOf
    a owl:ObjectProperty ;
    rdfs:domain core:Perdurant ;
    rdfs:range core:Perdurant ;
    .

core:isPerdurantImproperPartOf
    a owl:ObjectProperty ;
    owl:propertyDisjointWith core:isPerdurantProperPartOf ;
    rdfs:subPropertyOf core:isPerdurantPartOf ;
    .

core:isPerdurantProperPartOf
    a owl:ObjectProperty ;
    owl:propertyDisjointWith core:isPerdurantImproperPartOf ;
    rdfs:subPropertyOf core:isPerdurantPartOf ;
    .

(EDITED 2023-12-11: Fixed a copy-paste error in the sub-property hierarchy.)

The rationale I see for that hierarchy is that a perdurant P1 being a proper part of another P2 implies that there exists some other portion of P2 that is outside of P1. This is a stronger statement than just being a part.

P1 being an improper part of P2 is as strong a statement as being a proper part. Though, I'm not sure what "improper" parthood would mean for certain pairings of UCO classes. (And I do think these are questions special to UCO, not generic to foundational ontologies. For instance, UCO has already decided that Activitys and Events are disjoint.)

• Event E1 improper-part-of event E2: These are the same event?
• Event E1 improper-part-of activity A1: The event is scoped entirely, expansively, to the activity, yet is not the activity (per disjointedness)?
• Activity A1 improper-part-of activity A2: These are the same activity?
• Activity A1 improper-part-of event E1: The activity is scoped entirely, expansively, to the event, yet is not the event (per disjointedness)?

...Having worked through that matrix of Perdurant's two current subclasses, I'm not sure improper perdurant-parthood is definable except for when the perdurants are the same class, and even then maybe only for core:Events. This is writable in OWL without too much trouble, but does this mesh with expected use cases for Event mixing with Activity?

Regardless of the outcome for improper-parthood, I think proper-parthood looks safer to adopt today. If the property hierarchy around proper-parthood is introduced later, I believe any existing assertions around proper-parthood would remain semantically consistent.

[ajnelson-nist]

Thanks to the kind community member who pointed out an oddity in my subproperty hierarchy above. I had a copy-paste error, now corrected.

[sbarnum]

I am sure I will have many more comments to provide once I have a chance to hear this proposal verbally presented on the OC call, have time to dig deeper into its written detail above, and discuss the topic in more depth on one or more targeted working calls but I wanted to make a quick comment now on a fundamental issue I see at the very start of the proposal.

I would disagree with the definitions used here for endurant and perdurant.

The proposal defines endurants as:

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.

I have not seen endurant defined in terms of inherent perceptual/conceptual completeness. If this were true then I would assert that pretty much everything in CDO/UCO would not fall into this bucket because evolution of understanding of UcoObjects is a fundamental basis of almost all cyber application domains. Very rarely do you have complete perception/conception of any object until its final version.

The most common definition I have seen of endurants are that they are concepts that can be defined independent of time. In other words, while your perception or understanding of it may change over time as you look at it from different angles, it is what it is and did not change over time unless some outside force acted on it to change it.

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).

These are excellent examples of "concepts that can be defined independent of time". They are not excellent examples of entities "that can be observed-perceived as a complete concept, at no matter which given snapshot of time". With almost all of these things we may observe-perceive them differently at different points in time. The nature of what they are may not change over time but our observation-perception of them does. This is the fundamental basis of duck-typing.

The proposal defines perdurants as:

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.

Again, I have not seen perdurant defined in terms of how much we can see of them or exists at any point in time. The most common definition I have seen of perdurants are that they are concepts that must be defined dependent on time. This is because they are inherently temporal in nature. Most typically they are something that occurs or happens across time but they can also be things than occur or happen only at a specific point in time. For the latter, it is still a perdurant (temporally dependent) even though we can see its entirety if we observed at the point in time that it occurred.

If we are going to discuss the concepts of endurants and perdurants we need to be very careful in how we define them and not imbue them with additional inappropriate context that is likely to cause increased confusion or misunderstanding.

[plbt5]

@sbarnum is right in his observation that the proposal suffers from definitions on the proposed new concepts. This is a sloppy practice for which I do apologise. It will be corrected before bringing this into a requirements discussion at the OC.

[ajnelson-nist]

I came across something when reviewing two foundational ontologies and Qualities (under proposal in Issue 535).

BFO has this class hierarchy, excerpted down to include endurant, perdurant, quality, and the endurant class that would be a direct superclass of uco-identity:Person:

• owl:Thing
  • entity
    • continuant (= this proposal's "endurant")
      • independent continuant
        • material entity
          • object (= parent class of UCO's Person)
      • specifically dependent continuant
        • quality
    • occurrent (= this proposal's "perdurant")

gUFO has this class hierarchy, similarly excerpted:

• owl:Thing
  • Individual
    • ConcreteIndividual
    • Endurant (= this proposal's "endurant")
      • Aspect
        • Intrinsic Aspect
          • Quality
      • Object (= parent class of UCO's Person)
    • Event (= this proposal's "perdurant")

The current state of this proposal has core:Endurant as a subclass of core:UcoObject. However, from two foundational ontologies, endurants are seen to encompass qualities, and I think UCO would consider a quality an "inherent characterization thing" (which in BFO might be a specifically dependent continuant, and in gUFO an aspect or possibly intrinsic aspect; but, this detail is not necessarily part of this proposal).

I think this subclassing ...

core:Endurant rdfs:subClassOf core:UcoObject .

... needs to be this instead:

core:Endurant rdfs:subClassOf core:UcoThing .

I haven't yet given thought to whether perdurant should also move out from under UcoObject, aside from hierarchical symmetry with endurant.

[plbt5]

I do support the change, and I advise (from an ontological perspective) to introduce a Quality class as another subclass of core:Endurant.