Standardized data models (General Transit Feed Specification (GTFS) [9], Mobility Data Specification (MDS) [8]) or Web Application Programming Interfaces (APIs) (General Bikeshare Feed Specification (GBFS) [1], Transport Operator, MaaS Provider (TOMP) API [10]) allow MaaS providers to calculate the financial cost of a trip for transportation. However, this does not exist for third-party payment schemes. The term 'third-party payment' (TPP) in the context of MaaS refers to the compensation a traveller receives from a third party, such as a local government, when a trip is performed compliant with the third parties' criteria, such as student discounts. Next to the regular payment from the traveller to the used mobility service, a second payment is performed from the third party to the traveller or service, depending on the implementation of the TPP system (see Section 2). According to the overview provided in Table 1, some TPP systems are already set up between local governments and mobility providers to increase the accessibility of shared mobility to certain groups, such as tourists or children, or during an event. These criteria are based on location, time, transport modality and traveller's profile information and are defined in local decisions in the form of subsidy measurements. A TPP system can be achieved in a pre-or postpaid fashion. From the view point of a traveller, with prepaid, a smaller part of the trip must be paid by the traveller: a split bill occurs where the second part is arranged between the third party and mobility provider. With postpaid, a traveller pays the total trip cost to the mobility provider and receives its compensation afterwards from the third party. Based on the advice of some cities (Leuven, Antwerp), we will focus in this article on prepaid so groups with a low income or certain social background can be compensated on the moment of ticketing. Prepaid can be implemented with vouchers or mobility budget containing, for example, free rides or credit. Another approach is an agreement describing the subsidy measurement criteria and how a mobility provider can send an invoice afterwards to the third party. Currently, these TPPs are made ad hoc lowering the discoverability and reusability for route planning advice in MaaS. Therefore, we propose a specification for a prepaid TPP system defining the semantic description of subsidy measurements and trips, and an open-source validator to verify whether a trip is compliant with a subsidy measurement. 2 Third-party payment specification for MaaS
Open Standards for Linking Organizations (OSLO) [3], a program of the Flanders Information Agency enables organizations in Flanders to cooperate in trajectories, to develop unambiguous standards for information exchange. The "OSLO mobility: trips and offer" standard [12] was triggered by the new decree Basic Accessibility in Flanders [11], which states that important social locations must be optimally accessible to travellers. To realize this, a traveller must have a clear view on the existing mobility offer and on how to interconnect the various transport options in a multimodal mobility context. The standard consists of a vocabulary for describing trips, transport networks and service offerings, and of a "trips and offer" application profile (AP). The AP specifies which data needs to be exchanged concerning i) trips done by users and ii) the mobility services at their disposal. This AP allows mobility providers to describe trips in a machine-readable way.
The Local Council Decisions as Linked Open Data (LBLOD) programme is a Flemish initiative to semantically annotate decisions of local governments [2]. Local administrations currently have to upload decisions from their organization into Flemish base registries, such as the database for mandates, or road signs. By embedding RDFa in their documents, the Flemish government and third parties can harvest the information themselves in an automatic way, similarly to search engines that harvest Schema.org annotations from websites. LBLOD has already initiated several OSLO trajectories for domain-specific decisions, such as the installment or removal of mandataries [4], traffic [6] and subsidy regulations [5]. The "subsidies" AP reuses terms from the European ISA standard Core Criterion and Core Evidence Vocabulary (CCCEV) [7] to describe criteria, requirements and how to group them. This AP allows local governments to define TPP subsidy measurements, its criteria and monetary compensation in a machine-readable way.
The TPP specification describes the steps local governments and mobility operators can perform to compensate a travellers' trip [13]. According to the overview provided in Fig. 1, the system starts with the local government (agency), that defines which trips can be compensated (i). When a MaaS provider can implement the subsidy and conforms with the cities' quality framework (QF), a TPP agreement can be arranged (ii), which is annotated according to the LBLOD AP for subsidies [5]. The trip of a user is described with the OSLO AP "trips and offer" [12] (iii) and can be validated with the semantically annotated agreement (iv). When a trip meets the criteria, the validator returns how much can be compensated (v). For reimbursement, the mobility provider sends an invoice with the number of trip compensations (vi). In future work, the agency should be able to verify with the validator whether the compensated trips in the report are legitimate. To do so, the report will also need to embed the machine-readable description of the compensated trips as proof.
Inspired by projects like MDS [8] and LBLOD [5], we specify which standards to use to describe subsidy measurements and trips, and how trips can be validated in an automated fashion. We provide a JavaScript Object Notation Linked Data (JSON-LD) template with corresponding table for each type of object. This way, developers do not need to understand semantic technologies to start mapping their data. A JSON-LD context is added to make the template semantically interoperable. In Listing 1.1, we give an example of a requirement for shared bikes in Leuven. Next to RouteSegmentRequirements, an agency also needs to describe the SubsidyMeasurement, which combines multiple requirements, and Payment indicating how much will be compensated. More details can be found on the Github repository of the specification [13].
Similarly, providers need to map every trip to "trips and offer" [12]. A trip executes a certain route composing multiple route segments. These segments specify the departure and arrival time, GPS telemetry, price and transport modality. For example, Listing 1.2 demonstrates a shared bike system during rush hours costing 8.2 Euro.
With the standardized description of a trip and subsidy measurement as input, an open source validator is being developed returning whether a trip is conform with the subsidy measurement and how much compensation can be given [13]. MaaS providers can incorporate this tool into their route planning engine. Also, agencies could use this tool as validation step before payment.
Listing 1.1. Travellers are eligible for a subsidy measurement when they use a shared bicycle within the centre of Leuven and on a monday during rush hours.
{ " @type " : " R o u t e S e g m e n t R e q u i r e m e n t " , " description " : " Only shared bikes , on monday between 4 pm and 6 pm and used in the city centre of Leuven ." , " meansOfTransport " : " http : // www . wikidata . org / entity / Q 1 3 5 8 9 1 9 " , // Bike " location " : { " @type " : " Place " , " geometry " : { " wkt " : " POLYGON (( 4 . 6 7 6 0 5 5 9 0 8 2 0 3 1 2 4 5 0 . 8 8 9 9 3 2 0 5 7 6 6 3 1 2 ...) ) " } } , " time " : [ { " @type " : " O p e n i n g H o u r s S p e c i f i c a t i o n " , " dayOfWeek " : " http : // schema . org / Monday " , " startTime " : " 1 5 : 0 0 : 0 0 " " endTime " : " 1 8 : 0 0 : 0 0 " } ] } Listing 1.2. This route segment is performed during rush hours in the centre of Leuven with a shared bike system.
" @type " : " RouteSegment " , " departureTime " : " 2 0 2 0 -0 6 -0 9 T 1 6 : 0 1 : 0 0 " , " arrivalTime " : " 2 0 2 0 -0 6 -0 9 T 1 7 : 0 5 : 0 0 " , " telemetry " : [ "..." ] , " price " : { " @type " : " MonetaryAmount " , " value " : " 8 . 2 " , " currency " : " EUR " } , " meansOfTransport " : " http : // www . wikidata . org / entity / Q 1 3 5 8 9 1 9 " // Shared bike }
The specification and validator proposed in this demo set the first steps towards third-party payments for MaaS. In future work, we want to make TPPs on the one hand more inclusive and on the other hand use the validator in a generic, cross-domain incentives (subsidy measurements) platform. Both aspects require the use or creation of personal data: the validator will need to be extended to handle profile information, and incentives should be assignable to a person. As cities nor MaaS operators should be responsible for managing personal data, we are looking into using Solid data pods, an innovative data storage solution for private data. With this last element added, we hope to have an interesting discussion during the workshop about the future ecosystem of TPPs for MaaS.