COMMONS13 — Ill-defined notion of "ordered by time"

The class ChronologicallyOrderedCollection is unclear when it says "structured collection whose elements are ordered by time", since the elements are more than simple (time) values but individuals with potentially many properties which are time-related. Even for the example given of bank transactions there's often a difference between the time the transaction happened and when it was recorded: my credit card statement has both "Post Date" and "Trans Date" - with the statement ordered by Post Date. And in some cases the time-related property might be on a separate linked individual. For some cases it could get a lot more complex e.g. employment for a person - there might be period overlaps.
Even ChronologicallyOrderedConstituent does not help - it seems to select only hasObservedDateTime which is both over-specific (how does it help with Employment?) and still under-specified (since hasObservedDateTime is itself pretty vague "indicates a date and time associated with an event, measurement, record, or observation" which does not discriminate the above examples or help with Employment).

Ill-defined notion of "ordered by time"

This needs much more discussion and use cases, as the concept included in the structured collections ontology is more about ordered records, not about richer concepts such as employment, for which FIBO, for example, uses the pattern expressed in the parties and situations model. That pattern is significantly richer with respect to the options for representation of a period of time for which the state of affairs holds.

We are deferring this to allow for use cases to be presented to the RTF and contrasted with suggesting that users leverage the parties and situations model for more complex states of affairs.