Feature Request startsOn and endsOn

[Toby-Broom]

Process have a start and end typically, can you add the sub properties, to occursOn, startsOn and endsOn?

[Toby-Broom]

You have temporallyStarts and temporallyFinishes but these go to 'temporal interval' so it's an extra step since the interval then point to the start and end? the object properties don't seem to be aligned with there definitions. The whistle is at an instant that defines the bounds of an interval.

[MilosDrobnjakovic]

If you are referring to process start and end instants, the way to do it is process occupies temporal region and then Temporal region has first instant and last instant. A utility (shortcut property) which reflects the property chain referenced above could be created. We are in the process of extensively defining annotations for utility properties in the architecture WG. Please feel free to join and contribute to the discussion, the meetings are every Thursday 11-12 Eastern.
The properties you are referring to are Allen interval algebra properties and serve to represent more complex temporal relations across processes and time intervals ( For more info check out https://oagi.atlassian.net/wiki/x/AYBYHwE and https://oagi.atlassian.net/wiki/x/AYCzFwE).

[Toby-Broom]

I mean just the simple way, I can make the non short cut way.

[MilosDrobnjakovic]

Those properties make sense and we will add them as utility properties once the utility property annotation and usage guidance is complete. As an adopter it would be good to have you in the room to ensure the annotations and guidance fits your needs.

[ekwallace]

We should talk about the names of these convenience properties before simply adopting them. They currently sound like they are referring to Dates (i.e. a temporal interval associated with a day or larger calendar interval) in the future within which the process would be planned to start and end. However, the discussion makes the intent seem to be that at least startsOn and endsOn refer to Instants. In any case, I would NOT expect the temporal entity associated to a Process by occursOn to ever be an Instant (since a Process, by definition, will occupy a temporal interval).

[MilosDrobnjakovic]

@ekwallace absolutely to clarify my previous response: the idea behind the requested properties makes sense (ie the property chain they aim to capture). We are in no way committing to adopt the exact name of the property referenced here nor their positioning in the property hierarchy. Naming and positioning of the properties themselves are subject to the utility property annotation and guidelines.

[wsobel]

We are having ongoing discussions on this topic in the Architecture WG, and we are working towards developing a normative guide for constructing and using utility properties. The discussion is by no means conclusive at this point, and we are still working out how we define, construct, constrain, and instruct regarding their use.

[Toby-Broom]

Yes, they would be the instants that describe the bounds of the temporal interval. As I said, I can do it the longer way. I just proposed these based on the patterns you are currently using but these are just proposals.

[jlloganiii]

Something that may be an issue. Evan said, "Dates [ . . . ] in the future within which the process would be planned to start and end." However, I don't think BFO realism supports processes in the future. If the identity criteria of a process includes its time interval (which has a start and end time), then every process must have already completely unfolded in time.

[Toby-Broom]

The planned start/end date of a process would be a specification so would not be under the occurant enitiy. The difference between a planned entity and an occurant are often the root causes of failues so its important to capture both.