Problem with the definition of stasis and with stases more generally

[alanruttenberg]

Stasis: A Process in which one or more Independent Continuants endure in an unchanging condition.

Stasis of quality: A Stasis of Specifically Dependent Continuant in which some Independent Continuant bears some Quality that remains unchanged during a Temporal Interval.

If an independent continuant endures in an unchanging condition, then it is ... unchanged. So if a process p is a stasis of quality, then p is also stasis (being a subclass), and then because it's a stasis there's a stasis of every quality of the independent continuant, since if nothing changes then no qualities change. That's what "unchanging condition" connotes in common english. Given the current definitions, stasis of quality is, for this reason, equivalent to stasis.

I'm guessing that you mean something closer to:

A Process during which some aspect(s) of one or more independent continuants doesn't change.

In addition, the definition doesn't say that the IC participates in the stasis at all times the process exists, which I would think was the intended understanding.

For stasis of quality, there is no property that relates the process to the quality.

My current view is that stases are problematic. I believe they are motivated (consciously or not) by the fact that OWL doesn't allow for time-indexed relationships. Suppose a stasis of quality "process" occupies temporal region t, and let's call the quality q, and the quality type qt (e.g. a temperature of 40 degrees). The situation is more properly stated as (instance-of q qt t). Moreover the instance-of assertion does not have any of the problems that the stasis definitions have.

I'd rather we have a uniform way of handing time-dependent instance-of in OWL that doesn't depend on an ontological commitment to stasis processes. I'm not sure how to do that at the moment. But stases seems to me to go too far beyond the sense of process as something happening.

Minor: Note that in BFO all term labels are lower case. So "independent continuant" rather than "Independent Continuant", etc.

[alanruttenberg]

In a discussion with Barry yesterday an idea came up for putting at least some stasis classes on what I'd consider a firmer footing. I'm focusing on stasis of quality and haven't reviewed the other stases so I'm not sure whether it can be used in all cases.

For stasis of quality the idea is that a stasis of quality refers to a temporal part of a history during which the quality type (which carries what's usually called the value) is constant, or, in some cases, approximately constant. By being part of the history there's no issue around having a process where there's no change since there's always something happening in the history. I write "refers to" rather than "is a" because we want it to be the case that if there are two qualities which are constant we want to ensure that the two temporal parts referred to are the same one. By saying 'refers to' I don't imply that the stasis is an information entity . I have to check but it seem reasonable to have a BFO axiom that says that

if p1 is a temporal part of p that occupies temporal region t and p2 is a temporal part of p that occupies temporal region that also occupies t, then p1 = p2.

It may be the case that that's already present, or entailed. I'll add an issue to the BFO tracker to check.

For the OWL we might be able to use a hasKey axiom that uses the combination of the history it is part of and the temporal region infer the equivalence.

[mark-jensen]

@alanruttenberg

the quality type qt (e.g. a temperature of 40 degrees)

In CCO we handle this differently. We assert an instance of a Temperature Quality and have an ICE that is a measure of it, which then has a corresponding literal value and unit of measure. The same quality instance can have different measurements associated with it over time.

quality type (which carries what's usually called the value) is constant

This would require punning, yes?

How does instance-of relate to rdf:type?

We currently handle Stasis by having the IC and DC instances both participate in the Stasis instance, also linking the two via bears/inheres. Then the Stasis occurs on a TR, which can be time indexed or have its duration measured. A problem I see is that our pattern doesn’t guarantee the particular ICE associated with value or type is what is (approximately) constant unless these are also asserted to participate in the stasis.

[mark-jensen]

The Stasis and Change heirarchies have been refactored and is available on the stasis-change branch. Discussed here