The mission and vision of the TOMP Working Group call for an interoperable standard that can work with all existing and recognized standards. That is why it is very important for us to align with other standards to the best of our capacity. European mobility standards are based on Transmodel, and we want to become interoperable by using it as our data model. The trick, of course, is to secure what we already have (invested in) and, on the other hand, facilitate the inter-operation with others. Below is the story of how we made (and make) it happen.
Scenarios for the ‘house of TOMP’
Earlier this year, were released possible scenarios for the TOMP-API in the (near) future:
– join forces with OSDM
– join forces with CEN standards (the EU-scenario)
– keep on relying on public funding to support the open-source work
– get “adopted” by an existing non-profit organisation that is not a public entity
– set up an independent non-profit organisation supported by working group members and partners.
Most of these options have one common foundation: making sure that the TOMP-API can be used by anyone throughout Europe, and – if possible – become a European ‘reference standard’. A reference standard means that when you do not have an existing standard to solve the same use cases, you should use that reference standard.
Paving the way to becoming a European reference standard
That sounds exciting, right? But then, the next question is: how do we get there?
Step 1: Learn to speak “Transmodelian”
It means that we need to make sure that we are at least ‘Transmodel compliant’ by using concepts from Transmodel (CEN European reference data model for public transport information). In other words, we create a mapping from the TOMP-API concepts to Transmodel ones. Then, we can act progressively: whenever we can, we use the same wording as in Transmodel. We also evaluate what is needed to change the existing wording.
Of course, there is always the alternative to stop at the mapping stage, but its maintenance will request lots of resources and can create complications for the implementation of the TOMP-API in systems that use Transmodel as their data model.
Since nothing can be decided without the right information, representatives of the TOMP-WG joined the CEN standardisation group for Public Transport (CEN/TC278 WG3) and more specifically the sub-group dedicated to Transmodel (SG4) to learn “Transmodelian”. Our first impression from participating in this sub-group, is that Transmodel is huge and covers an enormous amount of concepts.
Step 2: Enrich “Transmodelian”
As we started the mapping exercise, we noticed that some concepts were missing or not comprehensive enough, especially in handling request/responses covered by the TOMP-API (planning, booking, trip execution, support, payment). This has much to do with the fact that Transmodel is a “living” standard with additions and revisions being made to keep up with the evolution of public transport. In addition, one of the biggest (r)evolutions of these past years is the momentum gained by shared mobility options, which were the initial modes of the TOMP-API.
So, we ended up advocating for Transmodel to become even richer, by adding our knowledge and concepts!
Digging into booking: our steppingstone for recognition
Now, in the work of making the TOMP-API a reference standard while being very mindful of our limited resources, we drew a game plan.
Step 1: Mutual learning between peers for booking
We also got to cross paths with a European project: CoRoM. Initially designed as a bridge between Transmodel and CoRoM, it added to its deliverable a ‘blueprint’ for a booking-API based on Transmodel. The opportunity could not be missed!
We were invited to join this project. And, as we speak (or write these lines), we are actively taking part in the conception of this blueprint. Through the project discussions, we learnt a lot and keep on learning. It might also impact the booking part of the TOMP-API as well.
But, more importantly, we can bring our perspective to the content of the blueprint. It was as if all the stars were aligning one after the other!
Step 2: Advocate for more than booking to fit the needs of shared mobility operators
Though it might seem that we are very much focusing on the booking part of the TOMP-API, we did not forget about the trip execution, support and payment. In our opinion, these are valuable things to bring to the table in the near future.
As much as booking (and delivering a ‘fulfillment’, a ticket) is enough for conventional public transport, new modes (or shared/micro mobility) need these additional functionalities. As they do not seem available yet in Transmodel, guess who will be advocating for them to be added?
What is next?
It will not come as a surprise that our will to make sure the TOMP-API can be used throughout Europe calls for a new version, that would not be backward compatible (version 2.0).
Open discussions are on-going with the Transmodel sub-group, CoRoM project members, ITxPT (as the technical partner of Data4PT, supporting the adoption of NeTEx and SIRI), and MobilityData (as the maintainers of GBFS and GTFS) to make sure that the new version can be used regardless of the format used to create the input data (a.k.a., the information about available mobility services).
The Working Team 1 (the technical specialists) is tasked to describe a ‘version 2.0’, using Transmodel as a ‘base layer’. The main rule we try to use is ‘Minimal impact, maximum alignment‘. We are also aligning it with other standards and specifications that are widely used. And, we are evaluating what to put in a version 1.6, that would act as the bridging the gap between versions 1.5 and 2.0.
The other Working Teams are supporting the work by bringing implementation cases of TOMP-API (ensuring we do not break what exists) and by disseminating our current work (making sure we keep true to our transparency values).
Authors: Edwin van den Belt (Dat.mobility) and Tu-Tho Thai (ITxPT)
Edited by: Jelten Baguet (Mpact)