Prepare the forge: Remarks on the mapping

[edwinvandenbelt]

There are 2 files in the /wiki:

• a more high level mapping: https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/functional-comparison.md
• a detailed one, on endpoint level: https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/functional-comparison-endpoints.md

Please keep in mind these files are set up by Claude, it really needs our expertise to make it better.

Feel free to request changes to these files!

[OlivierBigex]

OSDM mapping with Transmodel (https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#2-offers)

OSDM Offer <> SalesOfferPackage
To me, the SalesOfferPackage (SOP) is a generic offer which don't take into account the travel specification. The CustomerPurchasedPackage (CPP) does. Transmodel doesn't seem to make a difference between a purchasable offer and a booked offer (both CPP).
--> an OSDM Offer is rather a CustomerPurchasedPackage.
--> a Distributor's offer is a CustomerPurchasedPackage.
--> a Fare Product Owner /Issuer's offer a CustomerPurchasedPackageElement.

Likewise OSDM requestedOfferParts should be CustomerPurchasedPackageElement (https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#offersearchcriteria)

By the way, seems to be correct here: https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#offersummary

[OlivierBigex]

We should find a common objet for urban and long distance ticket --> if SOP is not precise enough, thus, it should be CPP.

[edwinvandenbelt]

Agree. A CPP represents what has been purchased, and should contain all information to do the operations. A OSDM Booking represents a CPP, and an offer a SOP, imho.

[f-valenza]

There is probably an object missing if we decide that CPP "is born" after purchase. I had understood that the Travel Package could reference the SOP (through en empty CPP) and represent the offer to the customer before the payment (equivalent to status Holding or Pending in OSDM). If the transaction fails, the Travel Package disappears. Otherwise, it transforms to CPP.

[OlivierBigex]

Either Transmodel has missed something regarding distribution objects (SOP <> offer and CPP <> Booking) and we are free to create new stable and rational objets, or Transmodel isn't clear enough to be understandable by most people and we are free to create new stable and rational objets until Transmodel's definitions are reviewed to be more clear thanks to EUDIT feedbacks ! The best defintion is the one that is understood by most people.

Anyway the OSDM mapping in wiki cannot be validated and taken as it is for now.

[TuThoThai]

It seems to me that the OSDM Offer <> Transmodel TRAVEL PACKAGE as described in CoRoM TR and proposed as an extention to Transmodel.

The definition is:

Aggregated information selected from any SALES OFFER PACKAGE (satisfying the trip requirements of the TRANSPORT CUSTOMER as specified by a TRIP SPECIFICATION) presented to the TRANSPORT CUSTOMER and enriched by specific information; (i) on the TRAVEL GUARANTEE; (ii) on the organisation providing the guarantee.
NOTE TRAVEL PACKAGE represents a contract between the TRANSPORT CUSTOMER and the organisation providing the TRAVEL GUARANTEE.

A TRAVEL PACKAGE is made of TRAVEL PACKAGE ELEMENTS that are defined as:

part of a TRAVEL PACKAGE specifying a PASSENGER FARE OFFER and/or CUSTOMER PURCHASE PACKAGE for a TRIP PATTERN with a set of TRAVEL GUARANTEEs and other properties that apply specifically to the part.

And for the ones who like reading UML:

[OlivierBigex]

OSDM mapping with Transmodel (https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#2-offers)

OSDM productTags <> Transmodel FARE PRODUCT / PRODUCT TAG
OSDM productTag is rather a SalesOfferPackageId (Transmodel Product is too generic).

[OlivierBigex]

their is no provider of OSDM in OSDM, only Fare Provider (under the authority of PTO/PTA), which is legitimate to set stable ProductTag.

[edwinvandenbelt]

I don't get this one. A product is stable over time, a SOP(E) is only for a specific offer... Why is a FARE PRODUCT too generic?

[OlivierBigex]

Because a producttag refers to someting that is ready to be booked, coupled with a customer context (origin, destination, zone, passenger's age...). It seems to me that that is the definition of a SOP.
But I'm not so sure here.

[f-valenza]

From my point of view, the O/D and zone are not "customer context" but rather query parameters independant from the customer. Is the "passenger's age" rather a userprofile? => in this way yes, it is a SOP (the fare product offer + parameters => feedback is an identical offer to all customers giving the same parameters).
Going back to "productTag", thanks for clarification. One of our distribution IT supplier is defining "productTag" as an id regenerated each time there is a new query which is not not suitable for a SOP_id.

[TuThoThai]

If my understanding is correct and that the ProductTag is the ID of something that is ready to be bought, then it seems to me that it could be the ID of a TRAVEL PACKAGE (see comment above for the UML & definition)

[OlivierBigex]

OSDM mapping with Transmodel (https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#4-booking--booking-parts and https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#6-fulfillments--documents)

OSDM Booking<> Transmodel CUSTOMER PURCHASE PACKAGE or FARE CONTRACT
An OSDM Booking isn't a CustomerPurchasePackage. A Booking (on Distributor side) is an higher level of aggregated purchased CustomerPurchasePackages. Moreover, an OSDM Booking isn't a FareContract. FareContract is rather an OSDM fulfilment.

It's neiher a Corom Travel Package, because this concept of Travel Package need to be refined to make the difference between a booking on retailer's side and a booking on distributor's side (not the same guarantees and not the same aggregation).

[Ulf9]

Yes this needs to be clarified. Maybe the mapping is incomplete.
Either way, the API should be constructed so it supports multiple levels of aggregation.
This was one of the initial main drivers behind the TRAVEL PACKAGE concept.
A TRAVEL PACKAGE is in essence a SALES OFFER PACKAGE/CUSTOMER PURCHASE PACKAGE enriched with information of travel guarantees and the organisation that provides them and a clear link to the group of passengers that should he managed as one unit in a REDRESS situation. In addition the concept is intended to support sub-contracting, also multi-level. Here is a text from early CoRoM work trying to clarify how RETAILERs, aggregators and DISTRIBUTORs can be considered as TRANSPORT SELLERs as well as TRANSPORT CUSTOMERs in relation to each other.

It is possible for a TRANSPORT SELLER A to create an encompassing TRAVEL PACKAGE offered to TRANSPORT CUSTOMER B, by acting as a TRANSPORT CUSTOMER towards other TRANSPORT SELLERs purchasing and grouping together their TRAVEL PACKAGEs as sub-components of his/her own encompassing TRAVEL PACKAGE.
Such sub-contracted TRAVEL PACKAGEs, covering parts of an encompassing TRAVEL PACKAGE are considered as TRAVEL PACKAGE ELEMENTs when in scope of the encompassing TRAVEL PACKAGE.
Note that creating such “super-bundles” implies an added responsibility for TRANSPORT SELLER A towards TRANSPORT CUSTOMER B to solve or expose any problems caused by the gap between different TRAVEL PACKAGE ELEMENTs.
(compare with the concept of NDC and “interlining” from the airline industry)

Examples of added responsibility (TRAVEL REDRESS):

• Provide (and arrange) necessary replacement transport as well as meals and hotel rooms
• Provide (and arrange) necessary replacement transport
• Reimburse new tickets/accommodation/meals bought by the TRANSPORT CUSTOMER

[OlivierBigex]

ok. And in some case, their is no guarantee at all, but only the fact that several CUSTOMER PURCHASE PACKAGES are necessary to travel from A to B (e.g. long distance train + urbain bus).
Anyway, the proposal for now is to focus on use cases and to "translate" in Transmodel later, by aggreeing to modify or enrich Corom previous definition. Sounds fine.

[OlivierBigex]

OSDM mapping with Transmodel (https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#bookedoffer)

OSDM BookingPart<> Transmodel SALES OFFER PACKAGE
But = Transmodel CUSTOMER PURCHASED PACKAGE

[OlivierBigex]

About Passengers https://github.com/TransmodelEcosystem/EUDIT/blob/main/wiki/mappings/osdm/README.md#5-passengers--purchaser
Draft version Of OSDM 3.8 adds informations about chip card content in passenger informations. Mapping with Transmodel ?