For our second TOMP-interview we had the opportunity to discuss with Mrs. Tu-Tho Thai, the Manager for Projects and Partnerships at ITxPT. This international non-profit organisation enables an open architecture, data accessibility and interoperability between IT-systems. ITxPT develops and promotes an open IT-architecture for public transport and other mobility services, based on standards and best practices.
As a partner in the EU-funded projects Data4PT and NAPCORE, ITxPT supports the European Union Member States and all relevant stakeholders (data providers, data consumers, Public Transport Authorities, Public Transport Operators, Transport Associations, IT suppliers etc.) in the development and implementation of European CEN public transport data standards. Concretely, ITxPT contributes to standards development and implementation through profiles, technical artefacts, validation tools, a helpdesk, communication activities, training events and workshops.
TOMP-WG – Thank you Tu-Tho for accepting the invitation to participate in this second TOMP-interview. When have you discovered the TOMP-API, why did you decide to get involved in the TOMP Working Group and what is your role in the structure?
TT – I discovered the TOMP Working Group immediately upon starting my previous job as the Director of Partnerships for MobilityData. I was told that it would be helpful for me to participate in the meetings since they were very early for my colleagues based in the USA and Canada. As they were working on GBFS, the specification on which TOMP-API built its first version, it was important not to lose contact.
The TOMP-WG meeting was one of the very first external meetings I had. I was a bit unsure of what I could bring as the newbie in town. But the kindness and warmth with which everyone in the group welcomed me was unprecedented. So, I decided to get more involved and help wherever I could. So, it was the group of people who made the difference. Kindness always pays.
TOMP in the MaaS-ecosystem
TOMP-WG – During your time at MobilityData, you were involved in various European interoperability projects (NeTEx / SIRI, MaaS Alliance, TOMP-WG, etc.). So, you have a good overview of the mobility data ecosystem. Can you describe TOMP’s position in this system? What makes this specification unique?
TT – TOMP-API is unique as it started to address a very concrete problem. It came very early in a market that had no existing open specifications for planning, booking, and travelling using shared mobility services. Also, as it was supported by the Dutch Ministry, the uptake was serious.
I would say that what TOMP-API is different for three reasons:
- Keeping the prism of the traveller through the entire process of moving from A to B,
- Its pragmatism for any evolution or addition,
- Its unique voice in Europe was something that wanted to get out of siloed mobility.
To be noted, though, that legally TOMP is a Technical Specification and not a Standard as it is governed by an open-source community and not by a standardisation body.
TOMP-WG – The TOMP-API can contribute to the efficient development of the MaaS-ecosystem. How do you think MaaS can contribute to tomorrow’s mobility: Will it be broadly adopted? Is there a business case?
TT – I believe that MaaS is a concept that has been misused to focus on the development of super apps. It lost touch with its original concept: putting together all mobility offers and making them easy, accessible, and interconnected to benefit all travellers.
When all the stakeholders of the MaaS-industry will join forces and/or inspire each other, I believe the next sustainable MaaS solution will be created. As of today, it is still impossible to plan a real multimodal trip, to book and pay for it, and to travel with full customer support aside from the combination of walking and public transport, or the combo of walking and using shared mobility.
However, solutions are emerging in different forms. Some are focusing on travellers’ accounts to be used across modes and platforms, others are looking into extending their operations (and solutions) to all existing modes in a certain area. I am hopeful that we will see numerous more solid MaaS-solutions. Then, the market will choose the most robust and suitable ones, business case included.
Do you think that MaaS can be a solution for all potential users, also for those persons with limited digital skills?
TT – I believe that MaaS can be fully inclusive, but in time. Once the urban and highly connected crowd is fully onboard with MaaS, resources from transport authorities and operators should be reallocated to accompany persons who are not digitally proficient or autonomous in their travel. To achieve this, the industry will have to focus on another very important group of people: the caretakers. They will be key to support an inclusive mobility and MaaS-solution.
Preparing for the future
TOMP-WG – Many transport operators and MaaS-providers have already adopted the TOMP-API, others have not. According to you, what are the reasons why some parties are hesitating to implement TOMP to do so?
TT – There are two main blockers in adopting TOMP or any open specification or standard.
First, there is the issue of ‘longevity’: Is the specification robust enough to stay a key player for the upcoming 3 to 5 years? Will the support for implementation be reliable in the long-term? Will this be the solution adopted by the industry and policymakers, so no one needs to pivot in 5 years?
Secondly, there are questions related to ‘governance’: Do we know who is making the technical choices? Are all able to contribute? Who are the guardians of the specifications, of its evolution, and its support?
Like many open specifications that were built based on volunteer contributions, TOMP-API has the default of being shaped based on the perspectives of its contributors. Newcomers will have different perspectives on how TOMP-API should evolve. The main question of the group is how to handle the challenges while keeping the open-source spirit alive.
A last issue faced by TOMP-API and almost all standards and open specifications will be the support for implementation. It consumes a lot of resources as needs to be done on a case-per-case basis. No one has access to unlimited resources to do so. So, inevitably standardisation will take time.
TOMP-WG – You are currently working for ITxPT. How can your organisation contribute to the further development of the TOMP-API?
TT – As of today ITxPT, via its involvement in the EU-funded project Napcore and its support to CEN Working Group dedicated to Public Transport, is trying to expose TOMP-API to the industry as a way to spark conversations around Booking API. To do so, the team invited TOMP WG co-chair Edwin Van den Belt to present the TOMP-API at the upcoming Napcore Mobility Data Days in Budapest. Hopefully, it creates a solid basis to evaluate and discuss the future of TOMP-API in the European ecosystem.
TOMP-WG – Finally, Tu-Tho, if you had an unlimited amount of time and resources to further develop and promote the TOMP-API, which actions would you take?
TT – There are three actions in which I would like to invest for the further development of the TOMP-API. First, I would gather all experts to explore further what it would take for TOMP-API to be more neutral of different modes of transport. Then, these experts would define how to bridge TOMP-API with NeTEx/SIRI and all other Transmodel-based standards. Finally, set up a team to support implementation.
TOMP-WG – Thank you very much Tu-Tho for sharing your insights with us!
Paris / Ghent, 20.10.2023
This interview was made possible with the support of the Interreg North Sea Region Programme and the Province of Oost-Vlaanderen (Belgium) as part of the Interreg ShareDiMobiHub project.
