Relax the domains of hasDateTimeType and hasTimeStamp (not only Events)

[ocorcho]

Does it make sense to relax the domains of hasDateTimeType and hasTimeStamp so that they are not only applied to Events but also to TransportServices?

This is because when a logistics transport service is assigned to provide support to a business transaction, without any event happening yet, there is a requested arrival time (and maybe even planned), for instance, which may only be associated to the logistic service, directly.

If it does not make sense, how would you encode this with the current model?

[silenroc1]

Thanks for the suggestion. At the moment I want to keep especially the Event module clear and concise. Relaxing the domain of hasDateTimeType and hasTimestamp to include classes from multiple modules adds unclarity.

Other options we can discuss:

• A shortcut-way of modelling would be to add another property in the BusinessService module that reuses the DateTimeType enumerations. This could be an argument to move the DateTimeType enumerations to e.g., the classifications module.
• To find a proper modelling solution, I'd be interested in some more explanation of the use case? You describe a logistics transport service being assigned to a business transaction "without any event happening yet", but still there already is a requested arrival time. To me this sounds like there is an event. My preferred way of modelling would be to add another type of event called e.g., "booking", "businessAgreement" or something similar, that contains an association with two businessService-module concepts: the logistics transport service and the businessTransaction or the physical infrastructure. This can be the intermediate event before a specific transport means is assigned to the trip. Alternatively, we may assign to it a semi-random transport means identifier to indicate that the exact transport means for this trip has not yet been identified.

We can discuss this second option further if it aligns with your thoughts.

[ocorcho]

Both options may make sense. After discussion with the SIMPLE team, it seems that the first option would actually make more sense, since in this context we are still in the business transaction sphere, as we understood that most events are really logistic transport events and this is mostly a commercial one. Of course, if there are other pilots that have a similar problem and there is a decision to go for the inclusion of events related to bookings/businessAgreements, we will be also happy to change accordingly.