-
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
Copyright ' 2021 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
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 prolfie 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 specicfiation 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.
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 ofer” 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 ofer 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 oferings,
and of a “trips and ofer” application prolfie (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
], trafic [
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.
2.2
System overview
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 ofer” [
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.
2.3
Example
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 ofer”[
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.
{ " @ t y p e " : " R o u t e S e g m e n t R e q u i r e m e n t " ,
" d e s c r i p t i o n " : " Only s h a r e d b i k e s , on m o n d a y b e t w e e n
4 pm and 6 pm and used in the city c e n t r e of L e u v e n
." ,
" m e a n s O f T r a n s p o r t " : " http : // www . w i k i d a t a . org / e n t i t y / Q
1 3 5 8 9 1 9 " , // Bike
" l o c a t i o n " : {
" @ t y p e " : " P l a c e " ,
" g e o m e t r y " : {
" wkt " : " P O L Y G O N (( 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 ": " OpeningHoursSpecification ",
" dayOfWeek ": " http :// schema . org / Monday ",
" startTime ": "15:00:00"
" endTime ": "18:00:00"
}]
}
{
}
Listing 1.2. This route segment is performed during rush hours in the centre of Leuven
with a shared bike system.
" @type ": " RouteSegment ",
" departureTime ": "2020-06-09T16:01:00",
" arrivalTime ": "2020-06-09T17:05:00",
" telemetry ": [ "..." ],
" price ": {
" @type ": " MonetaryAmount ",
" value ": "8.2",
" currency ": " EUR "
},
" meansOfTransport ": " http :// www . wikidata . org / entity /Q
1358919" // Shared bike
3 Conclusion
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.
bikeshare
feed
specification,