Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transport_Event simplification without loss #8

Open
onthebreeze opened this issue Nov 27, 2019 · 1 comment
Open

Transport_Event simplification without loss #8

onthebreeze opened this issue Nov 27, 2019 · 1 comment

Comments

@onthebreeze
Copy link
Contributor

onthebreeze commented Nov 27, 2019

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.

TransportEventIssue

  1. In the relationship from the referencing class eg "transportMovementEvent":{"role":"arrivalEvent",..}
  2. In the typeCode property of the Transport_Event eg "Transport_Event":{"typeCode":"arrivalEvent",..}. Noting that the actual allowed codes for this property are unspecified.
  3. 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.

TransportEventIssueSolution

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.

@Fak3
Copy link

Fak3 commented Nov 29, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants