Align LogisticsEvents structure between DM and API

[lambertciata]

In current API specifications, LogisticsEvents can be filtered by event code defined as a string.
In current DM the event code is a CodeListElement.

We need to align on the structure and API specifications to either:

• Put eventCode as a string again in the DM, and assess if some properties need to be put in the LogisticsEvent
• Keep eventCode as a CodeListElement and update API specifications.

A side issue (x) would be that we need to better define Code Lists in CCL Ontology by adding code, codeDescription, codeListName, etc. when feasible.

[NiclasScheiber]

Unsure about filtering LogisticsEvents being defined in API specs and handled server-side.
Filters are set based on business requirements by the client.
So they should compute the filter query on all returned LogisticsEvents from the /logistics-events endpoint. This also enables the client to filter for something else.

If the filter query is to stay in the API specs, an alternative would be to use LogisticsEvent#eventName for the filter.

Defining an eventCode by using a string only breaks when two separate codelists use the same code for different things.
If we do not hardcode the expected values, this will lead to ambiguity.
Hence the CodeListElement/RDF codelist, so that it is known where the code is from.

[NiclasScheiber]

Adding another thought:

Changing the filter parameter from string to IRI would also work, as it is highly encouraged to link pre-existing code lists instead of instancing CodeListElements in LogisticsEvents.

For standardized event codes in air cargo, it is intended to use the StatusCode code list of the core code lists ontology. This should cover all inter-party use cases in this domain.

For use cases outside of air cargo, you can refer to the LogisticsStatus code list, for example, of UNCEFACT out of the box. For further use cases, parties may want to host their own code list vocabulary as linked data.

Instancing a CodeListElement as embedded object should only be used as a fallback mechanism. Hence, resolving and looking for a string in the code property is unnecessary.

[aloccid-iata]

To fix this problem I suggest:

• Remove completely the eventType from the API
• Open a new discussion about an additional filter logic that can be applied to any field in Logistics Object
• Add sort and limit option on the API

[lambertciata]

Links to #267 and #268

[lambertciata]

See: 3cd15b8