You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
The proposed solution does not feel right to me. The eventType is an attribute of an event entity itself, and not the relationship of this event to some other entity (as proposed). Imagine that we will also want to link this event to multiple entities (vessel, voyage, port, etc) - with your proposed approach we will have to specify event type o all these links. This will raise a question - could one event be related to different entities with different relationship roles? While i can imagine someone could model it like this, but i believe that in practice developer would expect to separate events by their type.
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.
"transportMovementEvent":{"role":"arrivalEvent",..}
"Transport_Event":{"typeCode":"arrivalEvent",..}
. Noting that the actual allowed codes for this property are unspecified.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.
The text was updated successfully, but these errors were encountered: