4. Establishing a Three-Dimensional MaaS Data Sharing Governance

Scassa (2020), p. 44.

Drexl (2021b), p. 11.

ITF (2021a), p. 96; ITF (2021b), p. 13.

ITF (2021b), p. 13.

Governance’ generally refers to ‚the high-level management of organisations or countries, as well as the decision-making system and institutions for doing it.’; From a policy and regulatory perspective, data governance can be defined as ‘a system of rights and responsibilities that determine who can take what actions with what data’: Ducuing (2020), p. 59; The European Commission defines data governance as “the organizational approaches and structures (both public and private) to enable data-driven innovation on the basis of the existing legal framework”: European Commission (2020a), p. 8.

Abraham et al. (2019), pp. 424–438.

The general data governance system of an entire economy encompasses all general rules that are relevant for data such as GDPR, civil law, IP law, competition law, consumer law, etc.: Kerber (2020), p. 463; Kerber and Frank (2017), p. 9.; Tombal (2020).

Drexl (2021a), p. 487.

Kerber (2020), p. 471; Data governance covers aspects such as data quality, data availability, data interoperability, data standards, access rights, decision rights, accountability, and data policies: infra. Chap. 5.

Scassa (2020), p. 45.

Ibid.

Drexl (2021a), p. 487.

See below Sect. 4.4. 2.1.1.

See Sects. 3.​2 and 3.​4 in this chapter; See also Chaps. 6 and 7.

Drexl (2021a), p. 489; Sustainable Mobility for All (2021), p. 36.

Infra. Sect. 3.​2.​1.​3 and Chap. 5, Sect. 2.​1.

See Art 1 (3) in the Proposal for a Directive amending Directive 2010/40/EU: European Commission (2021).

Mobility data are data generated by activity, events, or transactions using digitally-enabled mobility devices or services.

Aticle 2 (3) of EU Proposal for a Regulation 2020/0340 (Data Governance Act): European Commission (2020b).

Ibid. Art. 2 (4).

It is worth noting that the proposed Data Governance Act defines data sharing in Art. 2 (7) in a slightly narrower manner, by covering only the sharing of data on a voluntary basis. This definition covers both mandatory and voluntary data sharing.

According to Art. 2 (6) data access does not necessarily imply the transfer or download of such data: Ibid.

It covers both voluntary and mandatory data sharing. It defines thus the relevant categories of data, data holders and data users: Infra. Sect. 4.3.3.

According to Art. 2 (l) of the Regulation 2017/1926 (MTIS Regulation) Accessibility of the mobility data’ means the possibility to request and obtain the data at any time in a machine-readable format.

Richter (2021), p. 543.

Reimsbach-Kounatze (2021), p. 67.

ITF (2021a), p. 95.

Infra. Chap. 6, Sect. 6.​4.​1.​1.

Infra. Chap. 5, Sect. 6.​2.​1.

Reimsbach-Kounatze (2021), p. 54.

IMOVE (2019), p. 11; ITF (2021b), p. 72.

Demand-side data are useful for a number of reasons. It can be utilised by service providers to further develop and refine their mobility service offers; for marketing and recruitment purposes, and for mobility management within organisations. Demand-side data can also be used within different types of transport system governance, such as the creation of incentives and policy instruments to promote or penalise particular types of travel behaviour, for traffic management, within urban development, to develop parking policies, and so on: IMOVE (2019), p. 11.

Contextual data is provided by external actor such as the whether forecasting or traffic management authorities. For instance, the Free Now multimodal mobility platform receives data about the current whether conditions at the user’s locations, which are automatically be implemented into the app. If the forecast predicts rain and the user opens the scooter tab, the app will automatically send an in-app-message saying that the current whether predictions are not ideal for a scooter ride. The app will then suggest booking a taxi or car sharing vehicle: FREE NOW (2021).

European Commission (2018a), p. 5.

Infra. Chap. 6, Sects. 6.​2 and 6.​3.

Infra. Sect. 4.4.2.2.1.

According to Art. 2 (7 & 8) of Regulation 2017/1926 (MTIS Regulation) ‘dynamic travel and traffic data’ means data relating to different transport modes that changes often or on a regular basis, as listed in the Annex; instead, ‘static travel and traffic data’ means data relating to different transport modes that does not change at all or does not change often, or change on a regular basis, as listed in the Annex.

Crozet et al. (2019), p. 50.

ITF (2021b), p. 74.

UITP (2019), p. 12; Crozet et al. (2019), pp. 47–52.

Infra Sect. 4.4.

Infra. Chap. 5, Sect. 5.​2.​1.​3; Data reported to public authorities enables them to plan, manage transport operations or enforce regulations. ITF (2021c), p. 6.

Infra. Chap. 6, Sect. 6.​3.​2.​5.​1.

Infra. Chap. 5, Sect. 5.​2.​2.​4.​5.

Infra. Chap. 5, Sect. 5.​2.​1.​3.

See Art. 4 (1) Regulation (EU) 2016/679 (GDPR Regulation).

Infra. Chap. 7, Sect. 7.​2.

Reimsbach-Kounatze (2021), pp. 55-56. See also economic barriers in Chap. 5, Sect. 5.​2.​2.​3.

Regulation 2016/679 ((GDPR Regulation).

Infra. Chap. 7, Sect. 7.​2.

See Chap. 7, Sect. 7.​3.​1.

The expression ‘holding data’ has been used as a functional substitute for ‘owning’ data because in the legal tradition of EU Member States data cannot be seen as property. Therefore, due to the general absence of legally recognized rights defining who is entitled to allow or restrict the access to non-personal data, these rights are often agreed upon contractually or exercised de fact. However, the legal meaning of “holding data” is not clear which means that it is not always clear the applicable (legal) regime in each case and who has the right to authorise the sharing of data: Espinosa Apráez (2021), pp. 12 and 24.

Ibid. p. 24.

Infra. Chap. 5, Sect. 5.​2.

The sharing of transport service data held by a public or private transport and the accessing by a public or private MaaS operator would arise under mixing data sharing models. On the one hand, a private owned MaaS platform can access the transport service data of both private (B2B) and public (G2B) transport service providers. Thus, it involves simultaneously and respectively a B2B and a B2G data sharing. On the other hand, a MaaS platform owned from a public entity, or a public transport provider can access private and public transport service data. Thus, it concerns simultaneously and respectively business to government (B2G) and government and government (G2G) and data sharing.

OECD (2019), p. 59.

WBCSD (2020), p. 14; OECD (2019), p. 39.

European Commission (2018b, 2020b); according to OECD, contractual agreements and freedom of contract remain crucial as a market-based approach to enhance data access and sharing in a B2B context: OECD (2019), p. 13.

Against these risks, and to incentivise and co-ordinate actions that facilitate data access and sharing in the private sector, many governments have put in place incentives for voluntary initiatives such as: (i) contract guidelines; and (ii) data partnership. Ibid. p. 121.

Tombal (2022), p. 105; OECD (2019), p. 46.

OECD (2019), p. 101.

Tombal (2022), p. 419.

Infra. Chap. 7, Sect. 7.​2; The status quo can be summed up as follows: contract is King—and freedom of contract the main self-regulatory instrument within the current data economy: Grünberger (2021), p. 257.

European Commission (2020b); Espinosa Apráez (2021), p. 11.

Tombal (2022), pp. 12–127.

For instance, for societal initiatives which mainly aim to pursue general purpose goals (healthier environment, smoother mobility, increased access to healthcare, etc.), but which, in doing so, indirectly benefit individuals as well. Ibid. p. 127.

Infra. Chap. 6, Sect. 6.​4.​1.​1.

Infra. Chap. 6, Sect. 6.​2.​1.​2.

ITF (2021a), pp. 63–64.

Static data include aspects such as the location and attributes of infrastructure (e.g. location and characteristics of roads, parking, car-sharing stations, public transport stops), timetables, terms of use and fares. Dynamic information includes real-time information on the network status of service performance like delays, congestion and detours, or service conditions like the current availability of car-sharing vehicles or prices of ride-sourcing services. Ibid. p. 64.

Infra. Chap. 5, Sect. 6.4.1.3.

European Commission (2013), p. 1; Art. 2 (Art. 2 (l3) of the Regulation 2017/1926 (MTIS Regulation) ‘travel information service’ means an ‘ITS service, including digital maps, that provides users, and end-users, with travel and traffic information of at least one transport mode.

European Commission (2013), pp. 11–13.

Infra. Sect. 4.4.2.2.1.

European Commission (2013), p. 17.

Infra. Chap. 6 Sect. 6.​4.​1.​1.

Infra. Sect. 4.4.2.2.

ITF (2021b), p. 78.

As further discussed in Chap. 10, Sect. 10.​2, this definition is based on whether there is a single contract (single ticket) or separate contracts (two or more tickets) for a passenger multimodal transport.

ITF (2021a), pp. 64 and 88.

These include better air quality, less congestion, achievement of climate goals/decarbonisation, increased efficiency of the transport system, increased capacity, social inclusivity, the promotion of jobs and innovation. Ultimately, integrated ticketing can contribute to more sustainable transport by providing alternatives to private modes of transport. Further, integrated ticketing should increase customer convenience and the efficiency of public transport: Frazzani et al. (2019), p. 39.

See Chap. 10, Sect. 10.​2.

Frazzani et al. (2019), p. 9.

ITF (2021a), p. 64 and p. 88.

Frazzani et al. (2019), p. 9.

(a) Search/query: the user is searching for information concerning the journey, timetable, price, and/or best option/combination; (b) Booking/preliminary reservation; (c) Payment and Clearing; (d) Ticket issuance and validation during the trip; (e) Change of reservation: re-routing or changes in case of errors or delays; (f) Complaints’ management in case of errors/delays; (e) distribution of the fare revenue between the different actors of the transport chain. Ibid. pp. 40–41.

Ibid. p. 41.

Static data include aspects such as the location and attributes of infrastructure (e.g. location and characteristics of roads, parking, car-sharing stations, public transport stops), timetables, terms of use and fares. Dynamic information includes real-time information on the network status of service performance like delays, congestion and detours, or service conditions like the current availability of car-sharing vehicles or prices of ride-sourcing services. ITF (2021a), p. 64.

See Chap. 10, Sect. 10.​4.

Kerber (2020), p. 471.

Amokrane et al. (2020), p. 346.

Protocol interoperability refers to the ability of two services or products to interconnect, technically, with one another. Data interoperability is roughly equivalent to data portability but with a continuous, potentially real time, access to personal or machine user data via API. Full protocol interoperability refers to standards that allow substitute services to interoperate (i.e., messaging systems). Crémer et al. (2019), pp. 58–59.

Specifying and enabling the use of common data access methods, semantics and syntaxes reduce the costs of co-ordinating and delivering MaaS services. Machine language requires a clear, consistent and unequivocal definition of terms and meanings. The first step in building interoperability and common reporting frameworks in a MaaS environment is to create and adhere to a common lexicon. While clarity on the semantic meaning of terms may be settled within each transport operator’s own data architecture—for example, a public transport operator will have a consistent definition of what a bus stop is or what it means to say a passenger has commenced a trip. Data syntaxes deployed in support of MaaS provide the structure in which the building blocks of language are organised to communicate meaning and to trigger action. Again, there is little room for interpretation in machine language. Therefore, specifying a data syntax that enables communication, or finding an efficient way to translate meaning from one syntax to another, is a core concern in the deployment of MaaS. At present, there is no broadly accepted data syntax on which to build MaaS applications, or to convey information from mobility service providers to authorities: ITF (2021a), pp. 102–103; Standards are a condition for interoperability. Even when commonly used machine-readable formats are used for accessibility, interoperability is sometimes not guaranteed. These common formats may enable “syntactic” interoperability, i.e. the transfer of “data from a source system to a target system using data formats that can be decoded on the target system”. But they do not guarantee “semantic” interoperability, “defined as transferring data to a target such that the meaning of the data model is understood”.21 Both, syntactic and semantic interoperability are needed. Besides being accessible and interoperable, data need to be findable. This may require that data be catalogued and/or searchable: OECD (2019), p. 93.

Ibid. p. 32.

(a) NeTex, a standard for sharing public transport schedules and related data could be extend also to private transport providers (emphasis added); (b) Service Interface for Real-Time Information (SIRI), a syntax for exchanging data on planned and current (real-time) services; (c) and Operating Raw Data and statistics exchange (OpRa), which focuses on raw data to being collected, exchanged and/or stored to support the study and control of public transport services. ITF (2021c), p. 35.

Dragonfly (2020).

Ibid. ITF (2021a), p. 104.

OECD (2019), p. 32.

Ibid.

Supra. Chap. 3, Sect. 3.​3.​2.​1.​1.

Kamargianni and Matyas (2017); Kamargianni et al. (2016).

Wong and Hensher (2020), p. 4.

Supra. Chap. 3, Sect. 3.​3.​2.​1.​1.

Smith et al. (2018), p. 593.

For instance, it was debated whether or not the PTAs would be biased if they adopted the MaaS Operator role: Smith (2020), p. 58; Wong and Hensher (2020), p. 4.

The uptake of MaaS predicates a market that is increasingly centred on data exchanges and their value. This value is best optimised when data-driven solutions are co-ordinated and framed within a coherent data governance framework. This framework is emerging but is unevenly specified and deployed across sectors, regions, and urban contexts: ITF (2021a), p. 84.

Smith (2020), p. 89; Smith et al. (2018), pp. 592–599.

EMTA has defined five possible MaaS development scenarios: (1) The ecosystem competition scenario is characterized by several, mutually exclusive, vertically integrated mobility ecosystems that compete with their respective own transport assets and their integrated mobility application. (2) The Pure Public Initiative scenario describes a MaaS development that is induced and controlled by a public party, for example a transport authority, an in-house transport operator or a newly established public entity, which takes on both the Data and Systems integration and Service Provision roles. The MaaS service could either be developed and operated entirely by the public domain or be awarded or licensed to a private organization for a certain time period. (3) The (Decentralized) Commercial Initiative Scenario describes the development of MaaS services by commercial market parties in an open competition, be that incumbent transport service providers (e.g. car-sharing providers) or new entrants. The role of the public domain is mainly the facilitation of the market by ensuring access to relevant transport data and system logics (e.g. reservation and ticketing), additionally to its traditional role of infrastructure and public transport provision. (4) The standardized ecosystem scenario bases on the standardization of technology to allow public and commercial MaaS entities to access data and systems of transport service providers for the creation of integrated services. (5) The Public infrastructure for open market scenario bases on the separation of the two newly introduced roles in the MaaS ecosystem. The public domain takes on the Data and System Integration role, providing a public digital infrastructure that enables commercial and (semi)public organizations to compile services (Service Provision role). This scenario stems from the understanding that infrastructure that enables societal and economic activity is a public sector duty to ensure fair, sustainable and public value development: EMTA (2019), pp. 9–11.

UITP (2019), pp. 17–19.

Two possible MaaS development scenarios: (a) Broker model: a situation where the MaaS operator is a single entity and acts as a broker, meaning that it buys and resells capacity in MaaS packages (i.e., broker model). In this case, the MaaS operator takes on full risk and responsibility of the activities. As a principal-agent relationship, bilateral agreements are essential to ensure data exchange, interface compatibility, provision of availability of services and the related fare pricing; (b) Partnership mode: is when the MaaS operator is a partnership of several organisations participating in the MaaS scheme. In this case, there is a MaaS operator who coordinates the activities of the partnership and can be referred to as the “MaaS coordinator” (i.e., partnership model). The MaaS operator coordinates the activities of partners and form an alliance in the MaaS ecosystem. Such alliance requires multilateral agreements and encounters the challenge of revenue allocation. The operating costs of the MaaS scheme are assigned to the whole “MaaS partnership” while revenues are allocated to the participating partners. The MaaS coordinator and the participating partners share the same risks: Caiati (2020), p. 7.

ITF (2021a), p. 71.

With the ‘bottom-up’ strategy, (market-driven scenario) a commercial MaaS platform operator signs a separate contract with each mobility provider to access the service data and resell their tickets. The PTA does not participate in any of these agreements, nor the management of the platform. There are two symmetrical risks with this approach. Either the private operator enters a monopoly situation, and the regulatory power of the public authorities becomes very weak, or the operator fails to achieve the required data integration and the MaaS remains uncompleted. With the ‘top-down’ strategy, (public-private scenario) an open public platform centralises data from all mobility services and makes them available to all stakeholders. This structure includes different operators, whether it is a technology integration company or a mobility operator. Public regulation is limited to providing the same level of information for everyone, with competition remaining between the different mobility providers. Delegating the job to a public transport operator (public-controlled scenario) is a particular form of aggregation. The public transport operator brings the benefits of its expertise on the most structured modes of mobility. It also has a powerful and historical link with the local community, who trust it to turn MaaS into reality. But, in this case, two risks also exist: an asymmetry between mobility figures and a weak capacity for the public authorities to govern data: Crozet and Coldefy (2021), p. 45.

Butler et al. (2021), p. 8.

Esztergár-Kiss et al. (2020).

MaaS Alliance (2017); MaaS Alliance (2018); Audouin (2019) and Smith (2020) have shed lights on the role that public bodies are playing into the birth of MaaS, and more specifically on the way they are governing their development.

The first graphic represents the market-driven scenario where many MaaS platform would co-exist, and all transport providers (private or public) are legally forced to open up their data and API’s so that their services can be resold by various MaaS operators. The role of the MaaS data integrator does not exist in this scenario since there is a decentralized data sharing governance. This model favours a more rapid development of market solutions. The second one represents the public-controlled scenario where MaaS is run by public transport with selected mobility service. The third one represents the public-private scenario where there the MaaS integrator provides an open back-end platform for various MaaS platforms.

For instance, the city of Antwerp wants to allow different solutions to coexist while guaranteeing the public interest and promoting these solutions throughout the territory, among citizens and businesses: Essaidi (2020), p. 23, IMOVE (2018) p. 15.

Infra. Chap. 7, Sect. 7.​4.

OECD (2019), p. 32.

Data can be made available to collaborators On-Site, wherein parties access and analyze data without it leaving the company’s servers and computer devices, and/or Online wherein data is made available through a portal, sandbox environment, or other sharing mechanism: Verhulst et al. (2019), p. 40.

European Commission (2018a), p. 8.

The term “data sandbox” is used to describe any isolated environment, through which data are accessed and analysed, and analytic results are only exported, if at all, when they are non-sensitive: OECD (2019), p. 33.

Data intermediaries enable data holders to share their data, so it can be re-used by potential data users. They may also provide additional added-value services such as data processing services, payment and clearing services and legal services, including the provision of standard licence schemes: Ibid. p. 36; European Commission (2018a), p. 8.

Blockchain technology have been proposed as a solution to address some of the challenges related to data sharing as well. Instead of relying on a centralised operator, a blockchain operates on top of a peer-to-peer network, relying on a distributed network of peers to maintain and secure a decentralised database. What is significant for trust in data access and sharing are the following properties of blockchain technology: a blockchain is highly resilient and tamper resistant (i.e. once data has been recorded on the decentralised data store, it cannot be subsequently deleted or modified by any single party), thanks to the use of cryptography and game theoretical incentives: OECD (2019), p. 56; Reimsbach-Kounatze (2021), p. 53.

For more discussion on this category of data infra. Chap. 5, Sect. 5.​2.

Infra. Chap. 7, Sect. 7.​2.

Crozet and Coldefy (2021), p. 45.

ITF (2021a), pp. 101–102.

Esztergár-Kiss et al. (2020).

The Data GrandLyon platform uses an Extract, Transform, Load (ETL) software to make data available, where possible, in open and standardized formats to facilitate its interoperability and reuse. Data providers retain ownership of their data on the Data Grand Lyon platform. The platform also does not make any guarantees on the quality of the data: Sustainable Mobility for All (2021), p. 82.

ITF (2021a), p. 71.

As discussed in Chap. 7, an example of MaaS data integrator has been already developed in the Netherlands: Chap. 7, Sect. 7.​4.​2.​1.​2.

It aims to link municipal, regional and national data platforms through a national data space concept (i.e., a mobility data marketplace): BMWI (2020).

UDT was supposed to be a data governance body to address both the collection and the sharing of the novel category of ‘urban data’ and to facilitate urban data sharing while accommodating different interests in data, but it failed in practice: Sidewalk Labs (2019).

The ‘shared server’, can be interpreted as a data trustee solution and it implies that all car data would be transmitted to an external server (outside of the car), which however is governed by a neutral entity that makes the data available to the stakeholders of the ecosystem of connected cars in a non-discriminatory way under certain general principles: Kerber (2020), p. 470.

OECD (2019), pp. 36–37.

Kerber (2020), p. 470.

Martens et al. (2020), p. 35.

Infra. Chap. 6, Sect. 6.​4.​1.​3.

Prüfer (2020), p. 15.

Verhulst et al. (2019), p. 16.

Infra. Chap. 7, Sect. 7.​4.​2.​1.​2.

Kamargianni and Matyas (2017)

Wong and Hensher (2020), p. 4.

They are based on the principle of interoperability: direct contact in the back end via API between the transport providers sharing the transport service data and MaaS platforms accessing them: infra. Chap. 6.

The Whim MaaS operator, basically integrates data such as routes, pricing information or real-time position through the access to the APIs of different transport operators. APIs represent a set of processes that govern the interactions between different web-based services, together constituting what is referred to as the back-end where the MaaS provider operates. The MaaS platform operator also takes care of building the front-end, or the app that is connected to the back-end, which is the major customer interface. In this case, the authors referred especially to the MaaS Whim app, but the same logic is valid for other MaaS providers: Audouin and Finger (2018).

Sustainable Mobility for All (2021), p. 76).

Infra. Chap. 6, Sect. 6.​3.​1.

Schweitzer and Welker (2021), p. 103; Schweitzer and Welker (2019).