=Paper=
{{Paper
|id=Vol-2939/paper1
|storemode=property
|title=Third-party Payment Specification for Mobility as a Service
|pdfUrl=https://ceur-ws.org/Vol-2939/paper1.pdf
|volume=Vol-2939
|authors=Brecht Van de Vyvere,Tim Asperges,Pieter Colpaert,Ruben Verborgh
|dblpUrl=https://dblp.org/rec/conf/i-semantics/VyvereACV21
}}
==Third-party Payment Specification for Mobility as a Service==
https://ceur-ws.org/Vol-2939/paper1.pdf
Third-party Payment Specification for MaaS
Brecht Van de Vyvere1[0000−0002−7671−6203] , Tim Asperges2 ,
Pieter Colpaert1[0000−0001−6917−2167] , and
Ruben Verborgh1[0000−0002−8596−222X]
1
IDLab, Department of Electronics and Information Systems,
Ghent University – imec
{brecht.vandevyvere,pieter.colpaert,ruben.verborgh}@ugent.be
https://idlab.technology/
2
City of Leuven, Belgium
tim.asperges@leuven.be
Abstract. Mobility as a service (MaaS) allows intelligent transporta-
tion across multiple mobility providers, such as calculating the least ex-
pensive route. However, the current standards do not tackle third-party
payments (TPPs) where a third party compensates a part of a travellers’
trip cost when certain criteria are met. For example, travellers receive
10% discount from a local government when renting a shared bike in
the cities’ centre during peak hours. To automatize TPP agreements for
MaaS, we propose and demonstrate with an example (i) a specification
to set up a TPP system specifying, among others, how multimodal cri-
teria and trips can be semantically described, and (ii) an open source
validator tool returning the compensation for a trip. In future work, we
are investigating how personal data can be integrated using Solid data
pods.
Keywords: Third-party payments · Mobility as a Service · Local deci-
sions.
1 Introduction
Standardized data models (General Transit Feed Specification (GTFS) [9],
Mobility Data Specification (MDS) [8]) or Web Application Programming In-
terfaces (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 con-
text 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 Com-
mons License Attribution 4.0 International (CC BY 4.0).
2 B. Van de Vyvere et al.
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 loca-
tion, 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 mo-
ment 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.
Table 1. State of play of third-party payment schemes in Flanders.
City Description Provider
Criteria
Deinze Free rides with shared bikes Blue Bike
Location of the trip must be
in Deinze
Leuven Free rides with bus De Lijn Citizens younger than 12
years of district Leuven
Leuven Discount on public transport NMBS and During certain events
De Lijn
Schoten Vouchers for 20 minutes free Mobit During certain events
rides with shared bike
2 Third-party payment specification for MaaS
2.1 Preliminaries
Open Standards for Linking Organizations (OSLO) [3], a program of the Flan-
ders Information Agency enables organizations in Flanders to cooperate in tra-
jectories, to develop unambiguous standards for information exchange. The “OSLO
mobility: trips and offer” standard [12] was triggered by the new decree Basic
Third-party Payment Specification for MaaS 3
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 vari-
ous 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.
2.2 System overview
The TPP specification describes the steps local governments and mobility opera-
tors 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 imple-
ment 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 agree-
ment (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
4 B. Van de Vyvere et al.
Fig. 1. Overview of setting up a TPP scheme between an agency (top row) and MaaS
provider (bottom row).
(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 ex-
ecutes a certain route composing multiple route segments. These segments spec-
ify 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 ...) ) " }
Third-party Payment Specification for MaaS 5
},
" 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
}
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.
References
1. Association, N.A.B.S.: General bikeshare feed specification,
https://github.com/NABSA/gbfs
6 B. Van de Vyvere et al.
2. Buyle, R., Colpaert, P., Van Compernolle, M., Mechant, P., Volders, V., Verborgh,
R., Mannens, E.: Local council decisions as linked data: a proof of concept. In:
Kawamura, T., Paulheim, H. (eds.) Proceedings of the 15th International Semantic
Web Conference: Posters and Demos. CEUR Workshop Proceedings, vol. 1690 (Oct
2016), http://pieter.pm/iswc2016-demo-lbld/
3. Buyle, R., De Vocht, L., Van Compernolle, M., De Paepe, D., Verborgh, R., Van-
lishout, Z., De Vidts, B., Mechant, P., Mannens, E.: Oslo: Open standards for
linked organizations. In: Proceedings of the International Conference on Electronic
Governance and Open Society: Challenges in Eurasia. pp. 126–134 (Nov 2016).
https://doi.org/10.1145/3014087.3014096, https://dl.acm.org/authorize?N20629
4. for Domestic Governance, F.A.: Lblod mandate registery,
https://data.vlaanderen.be/doc/applicatieprofiel/mandatendatabank/
5. for Domestic Governance, F.A.: Lblod subsidies,
https://data.vlaanderen.be/doc/applicatieprofiel/besluit-subsidie/
6. for Domestic Governance, F.A.: Lblod traffic measurement,
https://data.vlaanderen.be/doc/applicatieprofiel/besluit-mobiliteit/
7. programme European Union, I.: Core criterion and core evidence,
https://joinup.ec.europa.eu/release/core-criterion-and-core-evidence-vocabulary-
v100
8. Foundation, O.M.: Mobility data specification (mds),
https://github.com/openmobilityfoundation/mobility-data-specification
9. Google: Gtfs overview, https://developers.google.com/transit/gtfs
10. working group, T.: Transport operator mobility provider (tomp) api development
for mobility as a service, https://github.com/TOMP-WG/TOMP-API
11. of Mobility, D., Works, P.: Decree basic accessibility,
https://www.vlaanderen.be/basisbereikbaarheid/het-decreet-basisbereikbaarheid
12. OSLO: Oslo mobility: trips and offer, https://data.vlaanderen.be/doc/applicatieprofiel/mobiliteit-
trips-en-aanbod/
13. Van de Vyvere, B., Venselaar, M.: Third-party payment specification,
https://github.com/brechtvdv/third-party-payment-maas-specification