[Data Model] How to modelize a Booking scenario with several TransportSegments?

[grichka]

Hello, I am using the Data Model released in November and relationships specified in the Ontology and logical data model.

I do not understand how to use the Data Model for the following scenario :

• The shipper wants to send goods from PEK to CDG
• The forwarder contacts the carrier (airline) to handle the transportation and creates a BookingRequest
• The carrier offers 2 options
  • One direct PEK to CDG (One TransportSegment)
  • One indirect PEK to CDG via FRA (Two TransportSegments)

How can I properly create instances of BookingRequest, BookingOption and TransportSegment for this case? Thanks for your help!

[lambertciata]

This issue shall be rediscussed with the data model taskforce

[lambertciata]

Outcome of the workshop in 2021:

• We will implement the possibility to fill in potential segments at booking stage. This means adding some fields/common objects to account for that.
• Proposal to be made early 2022.

[lambertciata]

Current proposal:

[grichka]

I am not sure I understand this proposal. Can you give more details on the changes made and on how to model a booking with several legs according to this proposal?

[lambertciata]

Hi,

With this proposal the scheduledLegs object (here shown as embedded in Routing) allows to identify several legs. This is inspired by the design of XFFM message. For each leg you would have: a sequence identifier, an ID (= flight number), departure and arrival location/time.

Is that clearer?

[grichka]

So scheduledLegs is supposed to be an RDF sequence ? (an ordered list) Then I don't understand the purpose of the class BookingSegment because BookingOption can have only one BookingSegment if I remember well.

[lambertciata]

scheduledLegs is not necessarily ordered if there is a sequence identifier, however if an RDF sequence simplifies we can have a look at how it can be transcribed in the ontology.

secheduledLegs is used to identify the intended scheduled legs at the time of booking, they can differ from actual flight legs and from my understanding they are not legally binding. BookingSegment is used to record Departure and Arrival locations that are legally binding at AWB level. That means that BookingSegment is mandatory while scheduledLegs are optional.

[grichka]

Thanks for this explanation! The purpose of BookingSegment and scheduledLegs make much more sense to me now.

However I have some remarks/improvement proposals:

• the naming of the field "sequence" is not explicit: anybody cannot understand that a sequence is a number (it means something like a list of ordered things). I would propose to use the word "index" or "sequenceIndex" or "sequenceNumber".
• BookingSegment and scheduledLegs should include other important information including:
  • requestedDate (earliest, latest) to reach one location, asked by the customer
  • plannedDate (or estimated date) to reach one location
  • actualDate measured during transportation

[lambertciata]

Thanks for your comments:

• Agree with sequence, I think sequenceNumber would be the best fit.
• Requested and planned make sense, it's worth having a look if and where it is used (I understand the need for Activities though)
• Actual I would leave it to the TransportMovements that are the actual movements of the cargo