Make Transport & Mobility Data FAIR

There is a growing awareness of the role and benefits of good data management and usage. Industry, academia, legislators and even day-to-day consumers of digital services now see or receive the advantages of structured, standardised and stewarded information for both humans and machines.

The transport and mobility sector is, like many others, currently going through a huge transformation. Ever-faster technology systems updates & integrations are expected and increasing customer demands for complete and more real-time updates means that data is now a critical business resource for all transport providers, system suppliers and mobility-as-a-service (MaaS) platforms.

But it is no longer good enough to consider structured and stored data as “something the IT Department look after”, every data producer and publisher in a mobility organisation now has a responsibility to ensure that data is F.A.I.R
Findable
Accessible
Interoperable
Reusable

Findability
Data, unlike the Kevin Costner movie is not a Field of Dreams… if you build it (produce / publish data), the don’t come (and find it). Transport data has to be published in such a way that is can be easily discovered by an entire ecosystem.
Many different websites and online lists of mobility data now exist, each describing similar and overlapping data sources and each potentially identifying or describing different versions, potentially with differing timeliness / frequency of data. But websites, although human-readable, are not the best way of helping system-to-system integration of multiple trusted data sources.

What is ideally needed is one directory of data (or more than one, as long as they either cover different data sets or automatically duplicate or reference each other) covering all modes of mobility across an entire transport ecosystem.

In short, what is required is a centralised service, something akin to the Domain Name Service (DNS) used for finding internet websites or the Sort Code system used by the UK banking sector to exclusively identify the persistent location (physical branch and digital address) of each account.

Accessibility
Data is made accessible when the person or system requesting it can do so easily or without unnecessary restrictions. Unfortunately there could be multiple restrictions to getting the data once its location has been found:

  • the data cannot be accessed in a standardised way
  • the technology is restricted (e.g. by propriety protocols and/or licenses)
  • unnecessary authorisation is required (e.g. API keys)

To mitigate this, transport data should be provided via a technology / protocol that is free (no-cost), open (sourced) and thus globally implementable. E.g. HTTP, FTP, REST, etc.
Note: This is not to say that All mobility data should be global and free (perhaps only that data defined as truly Open on the Data Spectrum ), other types of data can and should be limited or monetized as is commercially, ethically, or practically required.

Furthermore, data tends to disappear or degrade over time (typically because there is a cost to hosting and maintaining it). Therefore storing the metadata (e.g. details about the data publisher / owner or the original source location) can be a cheaper or longer-term option

Interoperability
Data works best when it is merged, integrated or used with other data. Making data exchangeable and readable by humans & machines (without needing specialised or clever converters or algorithms) means using common entity definitions, standards or vocabularies across an entire sector or ecosystem, preferably ones also commonly used by the analysts, architects, developers & testers in similar or related sectors.

An obvious example of this for transport & mobility would be to ensure that any technical data interoperability standards created or adopted also take from or align (e.g. easily map) with those used across the location & geospatial sector and the Smart Cities sector.

Reusability
Open Data initiatives have been gaining pace and acceptance across the mobility sector, with transport organisation and authorities publishing easily findable, accessible and (mainly) interoperable data sets online. (Perhaps less so from MaaS Platforms right now… but this will come into effect eventually either by choice or obligation).
Use of this data by others (e.g. external parties for analysis, objective insight and service improvement) has obvious advantages and promotes trust in the data and the publisher. But unlike technical interoperability, where there is the need to ensure as much data as possible works with other data… often it is legally necessary to restrict data usage or prevent freely published data from being subsequently changed or monetised without permission.
It is therefore important that any transport & mobility data source (whether it is Open or Shared / Smart) defines how it can or cannot be replicated and/or combined in different ways, along with a clear data usage / re-usage license.

University of Glasgow Students release Guidance for Implementation of Open Transport APIs

From October 2020 to March 2021 students from University of Glasgow 3rd Year Computer Science team CS21 have been working with the Open Transport Initiative as part of their Professional Software Development Honours project.

Their agreed goal was to provide a proof of concept, illustrating how the Open Transport Initiative API specifications can be implemented in practice.

CS21 team:
Ans Farooq, David O’Neill, Lewis Tse, Dominykas Meistas and Pragati Mishra

As part of their project handover, their final product and Guidance for Implementation has been published to a GitHub repository here.
https://github.com/CS21-2020-21/opentransport-api-demo

During their time implementing the API specifications they took note of certain issues which arose. To help future developers working on The Open Transport Initiative APIs they have collated some general advice here:
https://github.com/CS21-2020-21/opentransport-api-demo/blob/mirror/OpenTransportGuide.md#our-tips

University of Glasgow Students (CS20) use Open Transport APIs for successful project

Intro: We are a team of third year Computing Science students at the University of Glasgow. 

Project aims: To use the Open Transport API specifications to demonstrate the sharing of customer data between transport operators. 

Timescale: 14th October 2020 – 31st March 2021 

Names: Torrin McQueen, Tomas Mikus, Paul Traynor, Kameron Eralp, Jamie McKay 

Approach:

With Django, we created an example Operator lookup and model Operator site “Zebras”. The Open Transport API was implemented within our websites using the Django REST Framework. We populated our database with some sample customer data to demonstrate account linking. We have shown that by deploying two separate instances of Zebras and registering them with the Operator lookup, it is possible to link user accounts and share ticket data. 

We came into the project with prior knowledge on databases and web app development. However, none of us had worked with APIs before, so using Django REST framework was a bit of a learning curve. Listed below is a couple of challenges we faced using Django, and how we overcame them. 

Python does not support hyphens in variable names. We used underscores instead, but this was a problem during serialization. To make this work we passed field names with hyphens as extra keyword arguments in the Meta class of each serializer. If those fields were serializing data themselves, we had to specify the field name and source field in the init function too. For example: 

Another problem with serialization was formatting the dates and times correctly. In order to display datetime objects with milliseconds we had to create a custom encoder class within the JSON renderer. This is our custom encoder: 

Conclusion:
Overall, working on this project has been an enjoyable and rewarding experience. The Open Transport API has the potential to make a great impact on the transport industry, and we can really get behind the idea of standardising communication and data sharing in this sector. Our websites mark the first working implementation of the Open Transport API and stand as a taster of what this platform could be used for. 

GitHub library URL: 
https://github.com/uofg-cs20 

CR005 approved and “customer-account” API now v1.0.2

Last week our Board approved Change Request CR005. This change extends the purchase.ticket entity in our “customer-account” API Open Standard to include three new “code” fields, making it easier to integrate UK Rail account data.
The backwards-compatible change also to helps Modal in their recent Innovate UK & Geospatial Commission project to match real-time detection of passenger journeys with transport account data.

This also means we have now updated our “customer-account” API specification to v1.0.2 and published this here:
https://app.swaggerhub.com/apis/open-transport/customer-account/1.0.2
(This is the latest version of this API and should be used from now onwards)

For more information: contact@opentransport.co.uk

What Open Source license covers our API Specifications?

Everything The Open Transport Initiative publishes on our SwaggerHub API account is automatically covered by the Apache 2.0 Open Source license.
http://www.apache.org/licenses/LICENSE-2.0.html

Copyright 2021 The Open Transport Initiative Licensed under the Apache License, Version 2.0 (the

This is one of the most popular licenses for Open Standards and it gives anyone the ability to freely use, modify, distribute and sell software that uses our work. Also, because it explicitly states that anyone using it on an “As Is” basis, there is no warranty and The Open Transport Initiative has no liability.

However, the license clearly mentions that if others make modifications… they must list all the changes they have made to our original API specifications. This is different from other Open Source licenses and helps us understand how our own work can be improved.

CR005 – Change Request to Custmer-Account API

Open Transport Proposal for Change

Number: Change 005:

To: Customer-account API

Name: Expansion of the “purchase.ticket” entity for additional fare data integration

Breaking change? No

Justification:

Modal is a company who have built mobile app technology that detects a person’s public transport journey in real-time and use this to create rail Delay Repay functionality. As part of a Geospatial Commission & InnovateUK competition Modal won a pitch to investigate the feasibility of integrating location data with transport account data.

The stated aim is to make MaaS easier and to automate Delay Repay rail claims. As part of this, The Open Transport Initiative has a small amount of work, including a review of our “Customer-Account” API, to ensure it can provide enough / correct data to match up with Modal’s data.

During this work, we have identified the need to expand the “Purchase” entity of our “Customer-Account” API to provide more structured data that can be automatically read by technology services such as Modal. (The data fields we have in our spec are sufficient for a customer’s visual inspection, but not sufficient for a system-to-system integration such as this)

More specifically, the API needs to expose not just the rail ticket reference data (which we already have), but also additional structured ticket data, such as: ticket fare type, ticket routing restrictions and possibly even some travel restriction classifications.

Note: Rail Delivery Group (RDG) has a 70 page specification document (RSPS5045) to describe ALL ticket data, which they make available in an Open Data (CSV) feed: https://www.raildeliverygroup.com/files/Publications/services/rsp/RSPS504502-00FaresandAssociatedDataFeedInterfaceSpecification.pdf
We are NOT going to replicate ALL of the RDG specification, just the data needed to meet these sort of rail ticket data integrations. However, we must be aware that more data of this sort may need to be exposed in this way subsequently, so what is required now should not prevent this.

The proposal is to add 3 new “code” data fields to the schema:
Code 1 = fare
Code 2 = route
Code 3 = restriction

Notes:
– Codes can be used for UK rail integration or any other data purpose
– This use of codes data fields also allows other to be added over time, if needed.

For further information and feedback about this change contact@opentransport.co.uk

Open Transport joins the Open Data Institute

The Open Transport Initiative is pleased to announce that it has become a member of the Open Data Institute (most commonly known as the ODI https://theodi.org)

The Open Data Institute was founded in 2012 by the inventor of the web Sir Tim Berners-Lee and Sir Nigel Shadbolt. Its mission is to work with companies and governments to build an open, trustworthy data ecosystem and has a vision of a world where data works for everyone.

This mirrors the role of The Open Transport Initiative to work with all transport & mobility organisations and support the use of Open Standards. It also closely aligns with our founding aim to drive and support the adoption of shared & interoperable data for all transport modes to benefit the travelling customer.

Founder and Chair of The Open Transport Initiative Hayden Sutherland said “Our role is to work with as many reputable companies and individuals across the data spectrum, to support the use of Open Standards in the transport and mobility sector. Joining the ODI was therefore an obvious step and one that will help to communicate and improve the work we have already done”.

For more information: https://opentransport.co.uk

Powering innovation in rail by adopting interoperable smart data standards

Today Hayden, our Founder and Chair , gave a presentation to The Rail Innovation Group on their regular “Munch & Learn” webinar. The session explained the work & future aims of The Open Transport Initiative and was a combination of presentation (titled “Why all transport accounts need to make their data shareable”) and lively Q&A.

Topics covered included:

  • The UK Government has now clearly stated the intention to use legislation to “mandate industry involvement in Smart Data initiatives across the economy” – including transport & mobility
  • Now is the time for Rail to lead by example and commit to adopting interoperable customer account data standards to enable & fuel innovation across our industry

A full copy of the presentation can be found embedded below. And if you would like more information on the topics covered, please contact us: contact@opentransport.co.uk

2021 – the year Transport & Mobility adopts Smart Data initiatives?

Back in September 2020 the Government published the report:
“Next steps for Smart Data. Putting consumers and SMEs in control of their data and enabling innovation”.

In this document it clearly stated the intention to use legislation to “mandate industry involvement in Smart Data initiatives across the economy”. This means that Parliament will make different sectors, including Transport & Mobility, share customer data.

So in the same way that Open Banking delivered Financial Services account interoperability… we can expect the same regulations applied to Mobility-as-a-Service (MaaS) Platforms and Transport Providers across the UK.

The Open Transport initiative was set-up to further the creation & adoption of Open Standards in Transport. In January 2020, after getting the input from over 30 providers, suppliers, and specialists across the industry, we published THE FIRST & ONLY Open Standard API specifications for Transport & Mobility customer account smart data sharing. Learning from what has been successful in other sectors, this work is now known as the “Open Banking for Transport”.

We believe that the adoption of open and consistent smart data sharing standards will help:

  • To put customers back in control of their transportation data
  • To kick-start and enable an ecosystem of MaaS innovation
  • To deliver the UK Government intention of full customer transport account interoperability

2021 is the year that Transport & Mobility needs to shape the future of our industry or be shaped by it.

We therefore have the opportunity to work collectively and together now and adopt Smart Data sharing practices… Before we are legislated and mandated to do so.

Why build a Transport & Mobility Directory Open Standard?

Most people we speak with are surprised to find that a central directory service does not already exist.

The problem of a lack of a technical system-to-system look-up service across the transport and mobility industry was confirmed when we designed & published our Open Standard API for Mobility account interoperability (“The Open Banking for Transport”). We realised that without such a central service there was no way to find other APIs.
E.g. In the same way there was already a working & robust Internet domain name serviced BEFORE people started building websites.

We therefore decided to solve this issue by designing our own directory service and publishing for anyone to use. This specification evolved over time as we spoke with different stakeholders and standards bodies and we now have an Open Standard that also aligns to the Internet-of-Things discovery standard (PAS212)

We saw an opportunity to create a directory service that will be essential digital infrastructure for the entire industry.

And now we spend more of our time explaining the benefits and features of this service.

See also: