Delete/Deprecate TimeInterval?

[rjyounes]

I had initially thought of things like pay periods as subclasses of gist:TimeInterval, but I think now they are better classes as Events. By nature the delimiting times of a time interval don't change (see PR #1111), whereas the dates of a pay period might, in extreme cases of natural or human-made disaster.

This raises the question of whether there's a need for TimeInterval in an enterprise ontology. It certainly adds confusion by raising the question of whether to refer to start and end datetimes or time intervals with start and end datetimes for, say, events. There is apparently no utility in the indirection time interval generates in this case.

What about something like Q1 2024 (as defined by a specific company or fiscal year)? Is that more of a pure time interval? It's hard to imagine the start and endpoints changing even in the case of war or hurricanes, in the way that the end date of a college semester or company's pay period might. On the other hand, it's not particularly desirable that pay period would be an event and fiscal year or financial quarter would be time intervals.

If we decide to keep the class, we should pin down its precise meaning and use in annotations, with some example subclasses.

[rjyounes]

Another possibility is to move away from the notion of TimeInterval as exclusively a "pure" time interval and allow possible date changes, in order to encompass pay periods, financial quarters, etc. as well as intervals like July 23, 2024, 2-4pm EDT. However, that makes the line between it and Event even fuzzier. And there are significant differences between the two types of time intervals which may then be swept under the rug.

[dylan-sa]

I'm in favor of keeping TimeInterval and clarifying its meaning in annotations.

Sometimes we think of time intervals in terms of their boundaries (e.g., 'the time period between 2 and 4 p.m. tomorrow'), and sometimes we think of them in terms of events that occurred or we expect to occur within them (e.g., 'the time period it takes to complete a task, however long that takes').

'Pay Period 13 of 2024' could mean 'the period of time between 12/15/24 and 1/11/25', or it could mean something more like 'the period of time following Pay Period 12 2024, lasting at least 4 weeks, where we expect certain administrative tasks to be completed, however long those take'. Thinking of pay periods in this latter way, there is a sense in which their dates can change--maybe the time interval we expected 'Pay Period 13 of 2024' to refer to ended up being a different one because a natural disaster caused certain tasks to be completed later. I don't think that makes it any less a time interval. A pay period still doesn't have the kinds of properties we'd expect events to have--it doesn't cause other events to occur, for example.

[uscholdm]

I'm in favor of keeping TimeInterval and clarifying its meaning in annotations.

Me too.

[rjyounes]

A pay period still doesn't have the kinds of properties we'd expect events to have--it doesn't cause other events to occur, for example.

This is not so cut-and-dried. A pay period most certainly does trigger other events to occur - e.g., timesheet review, payroll, etc. In fact, a pay period is defined by human activity that happens in and around it as well as by the dates it occurs. That is, 'the period of time between 12/15/24 and 1/11/25' is not a pay period unless some organization declares it to be and establishes certain activities in relation to it. Not so for 2-4 pm this afternoon. However, I grant you that in theory TimeInterval need not be limited to the latter. It's a fuzzy concept. Perhaps we didn't understand it well enough before defining it in gist.

[uscholdm]

It's a fuzzy concept. Perhaps we didn't understand it well enough before defining it in gist.

Not what what 'it' refers to. 'I agree that PayPeriod is a bit fuzzy. In my view TimeInterval, as an interval on the time line has negligible fuzz - its clean and precise.