Skip to content

Transport_Event simplification without loss #8

@onthebreeze

Description

@onthebreeze

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions