Meeting 1: Define roles

[edwinvandenbelt]

Please react on this statement:
"There are 2 sides of the interface: the one that represents the end-user (traveller, customer) and the one that represent the operator (distributor, attributor, ...., most of the roles defined in Transmodel). The interface should be a facade hiding all complexity behind, on both sides." .

So, these are 2 sides of the interface: the end-user representative and the operator representative.

[edwinvandenbelt]

What about the 'internal roles' at the operator side? Can they be hidden completely behind a facade? (if they're not, please clarify)

[bourdelin]

In Transmodel / Corom work, we identified 4 roles for the "customer" interacting with 3 roles for the "system" side. The EUDIT project should cover the black arrows in the Corom schema :

[TOP-PHE]

I am still a bit lost with this schema. Can we map it with the live enrivonment we need to serve (at least for Rail and AIR)
Traveler (transport customer) / a company having dedicated corporate fares with different providers (Purchaser) / The travel agency managing travel budget on behalf of the company (???) / a distributor who is agregating offers from different providers together -TrainLine, Amadeus... (Fare Product Distributor????) / A railwail agreegating a offers from the different carriers involved in an international train (Fare Product Distributor / Fare Product issuer for the full offer and Fare product owner/ Fare product attributor / Fare Security manager / Fare registrar for its part of the international train / each railway involved in this trip (Fare product owner/ Fare product attributor / Fare Security manager / Fare registrar for its part of the international train)
Do we have aname in transmodel for the goblal role, Retailer, Distributor (direct or indirect) ???it would help I guess.

[edwinvandenbelt]

BoB has also additional roles (in the middle?): the inspector and the gate (or other equipment)

[fredriklj]

There are essentially three roles in BoB:

1. The Ticket Issuer,
2. The Ticket Vendor and
3. The Ticket Validator.

Number 1 corresponds to the "Operator role" you mention. However, the operator may be a contractor, operating a service on behalf of a public transport authority. So, to not cause confusion around who is actually issuing tickets, in BoB this is only called the Ticket Issuer.

Number 2 corresponds to the "end-user", but actual travellers hide behind a Ticket Vendor. This Ticket Vendor maintains agreements with Ticket Issuers, maintains relationships with customers (travellers) and act as an agent towards the Ticket Issuer. The Ticket Vendor also abstracts payments. So between the Ticket Issuer and Ticket Vendor, there is a settlement going on.

Number 3 may seem like an outlier, but it also stems from the model that the operator may not be the responsible authority. The reason to define the Ticket Validator seprately, and not hide it behind the Ticket Issuer, is that the operator might operate services for more than one public transport authority. So for interoperability, it is important to define the interfaces between the Ticket Issuer and the Ticket Validator.

We have not found any reasons to define more distinct roles than this to operate within the BoB infrastructure.

[CGantert345]

Ticket Vendor is used in TAP-TS as a generic "role" for someone involved is the process. Using Retailer instead would be more precise.

[edwinvandenbelt]

And on the end-user side, we can distinguish the customer (the one who books, party in the purchase-agreement), and the traveller(s). They can differ.

[edwinvandenbelt]

@fredriklj & @OlivierBigex you're both right. I'd like to 'split' the functionality into 2 sides: the 'caller' and the 'callee'. Or, to be more specific the 'customer-representative' and the 'operator-representative'. The 'validator' in BoB is a known outlier. I'd put all three specific roles (buyer, travel agent, and group's representative) on the side of the customer. Do I understand this correctly?

[OlivierBigex]

ok for me!

[fredriklj]

No objections :-)

[CGantert345]

I would use consumer and provider for the roles on the two sides. Caller and Callee is very sensitive to typos.

[CGantert345]

The ticket validator is in TAP-TSI known as TCO ticket controlling organisation. He is acting on behalf of the carrier or PTA (not the issuer) but is not a direct client of the API although control processes change the status of objects in the api indirectly.

[TuThoThai]

As of 10 MArch 2026, this discussion is kept open.
But, please refer to the output from CoRoM and the elements in this repo.

[edwinvandenbelt]

Respecting CoRoMs outcomes, with one addition from BoBs side, I'd say we have a

• Customer facing side (with the Transmodel roles enlisted below 'TRANSPORT USER ROLE', CoRoM roles)
• Operator facing side (see CoRoM roles, I think it should represent all the roles below 'FARE ORGANISATION ROLE' and 'TRAVEL ORGANISATION ROLE'
• Validator facing side (not really in CoRoM, but otherwise we cannot include BoB).

[CGantert345]

I would strongly request not to name the roles according to other roles behind the facades, this created the misunderstandings we a had on the meeting.

[edwinvandenbelt]

Ok. Agree, any suggestions?

[edwinvandenbelt]

Anyone with a better name for 'Operator'? 'Distributor' is in the ears of urban modes more like a retailer). To stay close to Transmodel, we could choose 'TRAVEL ORGANISATION'?

[OlivierBigex]

I understand the logic behind the split into 2 worlds which interact wth each other: those which ask for a mobility services and those which deliver or sell a mobility service. But what bothers mayby the most is that in term of sales API, a retailer or a distributor never interact directly with an operator (maybe except for PRR), because their is no commercial contract between them. According to Transmodel, except for timetables, an operator is only a relation with a fare product issuer (what we don't care in EUDIT).

In the French mirror group, we simplify the roles by telling that InterMod API are between a retailer (customer facing side) and distributors (mobility offers provider, hiding the other roles behind it, like operator or fare provider).
OSDM (and TAPTSI) follows the same logic and goes further by telling that OSDM API can also be used between a distributor and fare providers.
I don't think that we need to take into account all Transmodel roles, because EUDIT API concern only a specific part of their interactions.

If you suggest to simplify to the extreme in order to move forward, we could say that EUDIT API are between a "retailer" (+ a validator) and a "(mobility service) provider" (=a distributor or a fare provider or a fare usuer, or an operator...). But you will be stuck in the EUDIT API when you will need to detail an offer if you cannot describe the content of the offer, which could be an aggregation of offer parts provided by multiple fare providers.

To conclude, I suggest to simply make the effort to learn and stay aligned with Transmodel roles and to select those which could use EUDIT API and stop talking of other roles:

I don't know the validator role in TRANSMODEL --> to be added in this picture.

[edwinvandenbelt]

Ok, makes sense. But I don't get the left arrow. A retailer talking to the provider, on behalf of the customer/traveller (also not in the picutre). And a validator talking to the provider as well.

[OlivierBigex]

Left arrow = EUDIT API could be used between a distributor (on behalf of a retailer) and its fare providers. thus on a second layer after the first one between a retailer (on behalf of a customer/traveller) and its distributors.
OSDM enable that and in a distribution process operated by multiple layers of distributed systems, I think it's powerful.
but in a first step, we could focus on the arrow on the right, then extend later.

Hypothesis: the retailer interacts always only with a distributor (thanks to distribution contracts and agreements). But in simple distribution contexts, when there is no independent distributor, the fare provider/issuer is actually the distributor.

For validation process, I wonder if the relationship isn't anyway intermediated by the distributor. Always for the same reason: the retailer as only a commercial relationship (=commercial contract) with a distributor. Even if the distributor is only a "pass-through". If a retailer signs a distribution contract with a distributor for reaching multiple fare providers, as a retailer, I don't want to implement as many connections as operators and fare product Issuers. I expect from the distributor to orchestrate validation informations toward fare product issuers and operators.

Maybe a good debate for Use cases.