-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Problem
The Transport_Event class overloads event type in a confusing way - with no less than three ways to specify much the same thing. See attached current state diagram.
- In the relationship from the referencing class eg
"transportMovementEvent":{"role":"arrivalEvent",..} - In the typeCode property of the Transport_Event eg
"Transport_Event":{"typeCode":"arrivalEvent",..}. Noting that the actual allowed codes for this property are unspecified. - as specific qualifiers of various properties of Transport_Event eg
actualArrivalDateTime,scheduledArrivalDateTime,arrivalDateTime, and so on.
This semantic over-loading leaves implementers with uncertainty about how to represent, adds un-necessary complexity, and risks interoperability problems.
Proposed Solution
We propose to remove two of the three options for specifying the same thing - keeping only option 1 in the previous diagram. Modified view is shown below.
This essentially involves removing any of the DateTime properties that have an event type semantic in their name (eg arrival, departure, etc) and also removing the code list property. The reason to use the association property rather than the attribuite property is that this allows "TransportEvent" to be re-uses for events about other transport entities, not just movements. For example event types in a relationship between Transport_Equipment and Transport_Event would have values like "stuffed", "stripped", "sealed", "fumigated", etc that are not relevant to a movement.

