Content uploaded by Joe Preece
Author content
All content in this area was uploaded by Joe Preece on Jun 02, 2023
Content may be subject to copyright.
Noname manuscript No.
(will be inserted by the editor)
Leveraging Ontochains for Decentralised Public
Transit Ticketing: An Investigation with the System
for Ticketing Ubiquity with Blockchains
Joseph David Preece ·Christopher Morris ·
John Easton
Received: date / Accepted: date
Abstract Transport ticketing systems are crucial for enabling seamless, ecient,
and sustainable mobility. However, traditional ticketing systems face limitations
such as ticket fraud, lack of interoperability, and the inability to adapt to changes
in the dynamic transport networks they issue tickets for. This paper presents new
approaches to the System for Ticketing Ubiquity with Blockchain (STUB), a novel
smart transport ticketing solution that employs ontochains, a hybrid data structure
combining blockchains and ontologies. STUB aims to address these limitations by
providing a secure, transparent, and exible platform for ticket issuance, validation,
and management. We describe the key components and workow of the STUB sys-
tem, highlighting the use of Transport Network Ontologies (TOnNes) for modelling
complex relationships within transportation systems and blockchain technologies for
ensuring secure and tamper-proof transactions to record changes to the TOnNe’s
state. Additionally, we discuss the implementation of Merkle proofs for ecient and
secure validation between on-chain and o-chain ontological data. The proposed
STUB system has the potential to signicantly impact the future of transportation
ticketing by oering a more seamless, interoperable, and user-friendly experience
whilst addressing the challenges associated with traditional ticketing systems.
Keywords blockchain ·ontology ·ticketing ·data
1 Introduction
Transportation systems around the world are becoming increasingly interconnected,
driven by the need for seamless, ecient, and sustainable mobility. Ticketing systems
play a crucial role in facilitating smooth and reliable access to various transportation
services, and enhancing access to mobility for customers across the world. However,
The authors gratefully acknowledge the nancial support provided by the TruBlo Consortium,
funded by the European Union’s Horizon 2020 research and innovation programme under grant
agreement No. 957228.
Joseph Preece
University of Birmingham, United Kingdom
E-mail: j.d.preece@bham.ac.uk
2 Joseph David Preece et al.
traditional ticketing systems often suer from issues such as a lack of interoperability,
and limited exibility in pricing and payment options. These challenges have led
to growing interest in the development of smart transport ticketing solutions that
harness emerging technologies to overcome the limitations of traditional systems.
One promising approach to smart transport ticketing involves the integration
of blockchains, which oer a decentralised, transparent, and tamper-proof platform
for secure transactions. Blockchains have been widely recognised for their potential
applications in various industries due to their inherent ability to provide trust and
security. However, previous approaches have only dealt with tickets stored as tokens
within the blockchain, failing to address the complexities of validation in multi-modal
settings.
In this paper, we present the new approaches to STUB, a novel system for smart
transport ticketing that leverages ontochains, a nascent data structure that combines
the advantageous properties of blockchains and ontologies. STUB aims to address
the limitations of traditional ticketing systems by providing a secure, transparent,
and exible solution for ticket issuance, validation, and management. By integrating
ontologies for transport network representation and blockchains for secure transac-
tion processing, STUB oers a comprehensive framework for the next generation of
transport ticketing systems.
This paper is structured as follows:
–Section 2 provides a comprehensive literature review on the role of blockchains,
ontologies, and ontochains within transportation, and details existing transport
ticketing systems;
–Section 3 addresses the shortcomings of previous implementations of STUB;
–Section 4 outlines the TOnNe, used to construct knowledge graphs about the
transport network;
–Section 5 describes the architecture and workow of the STUB system, and
elaborates on the use of Merkle proofs for ontology validation within STUB;
–Section 6 describes the testing methodologies and environment used to validate
the mechanisms explained in Section 5;
–Section 7 concludes the paper, presenting a discussion of the main contributions,
potential challenges, and comparison to other proposed solutions, and suggests
directions for future research.
2 Background
2.1 Blockchains
A blockchain is a distributed, digital ledger that records transactions in a secure,
transparent and tamper-evident manner. Each “block” contains a portion of these
transactions and a cryptographic link to the previous block, creating an unbreakable
“chain” of data. The use of specialised consensus algorithms ensures that all users
on the network agree on the latest state of the ledger, making it nearly impossible
to alter or manipulate past transactions.
Blockchains have a variety of potential applications within the transport sector.
Namiot et al. [20] discuss the use of blockchain in storing information related to
the transport industry, such as vehicle operating conditions, which can be used in
Title Suppressed Due to Excessive Length 3
insurance telematics applications. Calle et al. [7] identify seven capabilities enabled
by blockchain in the context of transportation operations, including reliable data,
data privacy, and decentralised data control. Eremina et al. [9] present a study on the
use of blockchain in transport management, specically in creating a decentralised
network of road lane sharing in real-time. Astarita et al. [2] provide a literature
review on the application of blockchain-based systems in transportation, highlighting
its potential in various elds such as food track and trace, regulatory compliance,
and smart vehicles’ security.
With regards to ticketing specically, the majority of literature addresses the is-
sues within the events and entertainment sectors [18, 10, 8]. Ferrick [10] argues that
blockchain can eliminate fraud, improve consumer sentiment, and reduce costs for
exchanges, brokers, and concert-goers. Cha et al. [8] proposes a privacy-preserving
blockchain-based ticketing service that can ensure the authenticity of purchased tick-
ets and protect user privacy. Previous work of the author [25, 28, 27, 26] has identied
the potential for blockchain within the transport ticketing sector, storing tickets as
tokens transacted on a blockchain network to enable transparent proof-of-ownership
(PoO) and proof-of-validity (PoV) on a multi-modal transport network, alongside
Nguyen et al. [21], who propose a “decentralised network in which the transportation
providers can verify and conrm their tickets through a blockchain containing smart
contracts as tickets”.
2.2 Ontologies
An ontology is a formal, graphical representation of knowledge within a particular
domain, which includes a set of concepts and categories, and the relationships be-
tween them. Ontologies enable machines to understand the meaning and context of
data, by providing a common vocabulary that can be used to annotate and classify
information. They are often used in articial intelligence and the semantic web to
enable intelligent reasoning and decision making. In computer science, the accepted
denition of an ontology is that given by Gruber [14], namely that “an ontology is an
explicit specication of a conceptualisation” in which a conceptualisation is dened
as “the objects, concepts, and other entities that are presumed to exist in some area
of interest and the relationships that hold them”.
Previous work, notably the InteGRail European project [17] which started work
in 2005, investigated the use of ontology to integrate data in the rail domain. This
study found it to be advantageous as a means of data interchange and produced
a simple ontology. The advantages of an ontology approach have been discussed
elsewhere, in the context of passenger information by Verstichel et al. [36] or remote
condition monitoring by Tutcher et al. [35]. These papers nd signicant benets
to all stakeholders from the ease with which data can be exchanged. Within other
industries, signicantly more progress has been made, with biomedical research and
medical data exchange have long been leaders in this eld. The Gene Ontology
from that domain, introduced by Smith and Kumar [32], has been in use since 2004,
allowing researchers in the eld of genetics to share information more easily. Building
on that previous work this project will encode information about public transport
systems to an ontology and that is what will be stored on the ledger.
The core data to be modelled within the context of STUB captures the current
state of a transport network. Transport network data is well suited to graph-based
4 Joseph David Preece et al.
representation, and this approach is widely used for modelling transport networks
of all types. In STUB, we propose to go further than a simple graph representa-
tion, by using a linked data approach to capture not just the raw data but, but
also derived contextual information; the relationship between data, information and
inferred knowledge, as rst presented by Sharma [30].
2.3 Ontochains
Next Generation Internet’s (NGI) ONTOCHAIN (OC) is a software framework that
combines ontologies and blockchains to provide a decentralised and secure platform
for managing and sharing data [24, 31]. The ontology provides a common framework
for dening and representing concepts and relationships within a domain, whilst
the blockchain provides a tamper-evident and immutable ledger for recording and
verifying changes to the ontology. Together, they enable the creation of distributed
applications that can share and reason about complex data in a secure and trans-
parent manner, without the need for a centralised authority.
OC comprises a novel protocol suite grouped into high-level application protocols
and lower-level core protocols. Papaioannou and Stamoulis [23] studies the business
model of OC, and establishes that open source licensing enables the joint exploitation
of decentralised software frameworks. The OC blockchain-based software framework
is being built by many companies, each having its own business agenda [22, 12, 4, 15,
3, 1, 16, 33]. The work of STUB has been developed alongside from the OC research
framework, and henceforth these data structures will be referred to as ontochains,
without necessarily linking to the work of OC directly.
2.4 Ticketing Standards
Previous literature collectively suggests that smart ticketing standards for transport
already exist and have been implemented in various ways, although problems still
remain. Blythe [5, 6] discuss the use of smart cards for payment and access to trans-
port services, with the latter paper highlighting the emergence of interoperability
standards through ITSO. Turner and Wilson [34] discuss the United Kingdom (UK)
government’s vision for a seamless transport ticketing infrastructure by 2020, built
on smart card ticketing technologies, and the challenges of integration. (However,
we note this has not yet been achieved). Gnoni et al. [13] propose an Integrated
Mobility System (IMS) that uses Radio Frequency Identication (RFID) technology
to improve ticketing management in a public transport network.
In more recent times, the European Union (EU) declared 2018 as the year of
modality. Finger et al. [11] state that “the attainment of seamless multi-modal door-
to-door mobility has emerged as a clear priority on the EU policy agenda”, and that
“dierent approaches to ticketing and payment systems have been observed to date
across the dierent EU Member States, and, in some instances, even across dierent
regions of the same country”. However, they proceed to state that “it is becoming
increasingly clear, however, that an overarching EU framework may be needed for
the successful implementation of multi-modal transport especially in cross-border
contexts”.
Title Suppressed Due to Excessive Length 5
Prior to this, the EU published Council Regulation No. 2017/1926, requiring
all transport service providers (TSPs) operating within the bounds of the EU to
provide access to their data in specic formats. However, Scrocca et al. [29] note
that “[TSPs] have a poor knowledge of the EU regulation”, and that they “deem
the conversion of their data to these standards as technically complex”. As time
has progressed, projects have started to produce tangible results, notably projects
within the Shift2Maas, Ride2Rail, and IP4MaaS under the Innovation Programme 4
(IP4) of Europe’s Rail. However, widespread usage remains limited, likely due to the
diculties raised by Scrocca et al. [29]. We note these diculties, and have decided to
pursue the initial concepts of STUB with the restrictions of such standards, allowing
it to develop more organically.
3 Addressing the Limitations of STUB 1.0
Whilst the initial version of STUB made signicant strides towards creating a de-
centralised, secure, and transparent ticketing system [28], it had notable limitations,
primarily stemming from the lack of a consensus on the transport network itself.
This absence of a structured knowledge representation model for the transport net-
work led to several challenges in validating tickets and coordinating between dierent
transportation modes and TSPs.
To help understand the issue, let us establish a toy transport network. Figure 1
illustrates a simple transport network with ve stations: the starting station S; the
destination station D; and three interim stations A,B, and C. Three TSPs operate
within this graph, named after their illustrated colours of Red, Yellow, and Blue.
Each TSP represents various styles of transport service; for example, Red operate
a direct service S→Dmuch like a high-speed rail line, whilst Yellow operate a
local-stopping service S→A→B→C→Dmuch like a bus would.
Now assume a customer (named Bob) buys a ticket from the Red TSP to travel
S→D. This ticket should detail important information about his journey, including
the starting stop, destination stop, the day of travel, and any network, TSP, or
service restrictions to prevent Bob from using transport he does not have permission
to use. In this example, the ticket allows him to travel from Sto D, on the red
service S→D, or the Blue service S→B→D, as Red and Blue have reached
a prior agreement. Services oered by Yellow are invalid. Figure 1b illustrates the
valid routes in solid lines. Bob will need to prove the validity of this ticket when
travelling, in some cases to TSPs that did not vend the original ticket (Blue).
Capturing this information within a blockchain is trivial, and STUB 1.0 used
a smart contract architecture to capture journey metadata that was pre-agreed by
the TSPs. This was an adequate solution for the small testing networks used during
the development of the proof-of-concept (PoC). However, proving the validity for a
complex transport network required extensive preagreements and knowledge about
the transport network prior to engagement. Each participating TSP had to establish
explicit agreements with other TSPs, resulting in a complex web of interdependencies
that hindered the ecient and timely processing of ticket validation. This complexity
also increased the potential for errors and inconsistencies, as the system relied heavily
on manual coordination and communication between parties.
Furthermore, the absence of knowledge of the transport network hindered the
system’s exibility and adaptability. As transport networks continuously evolve due
6 Joseph David Preece et al.
S
D
A
B
C
(a) Areas of operation.
S
D
A
B
C
(b) Bob’s valid routes to D.
Fig. 1: An example transport network.
to the introduction of new services, infrastructure changes, and policy updates, a
system without a robust knowledge model struggles to keep up with this dynamic
environment. This lack of adaptability may lead to outdated information, reduced
eciency, and an increased potential for discrepancies in ticket validation processes.
With the blockchain already achieving the PoO, it provides the ideal framework to
share this knowledge amongst the stakeholders. Yet blockchains are not well-suited
to querying such complex data structures in an ecient manner; rather, they excel
in sharing the data and ensuring its provenance and ownership. Hence, the idea of
using an ontology with a blockchain was born.
4 Transport Network Ontologies
To address these limitations, STUB 2.0 incorporates the TOnNe, enabling a more
structured representation of the underlying transportation system. This addition en-
Title Suppressed Due to Excessive Length 7
hances the ticket validation process, improves the passenger experience by providing
a unied view of transportation options, and allows the system to adapt more read-
ily to changes in the transport network. By integrating the TOnNe with the secure
transaction capabilities of blockchain technology, STUB 2.0 oers a more compre-
hensive and ecient solution for transport ticketing. This section focuses on the
construction of the TOnNe itself; please refer to Section 5 to see how it is integrated
within the STUB ecosystem.
Before we proceed, let us establish the terminology used for a typical transport
network.
Transport service provider A company that oers transportation services to indi-
viduals, businesses, or organisations. TSPs can provide a range of transportation
options and are responsible for planning, scheduling, and providing transportation
services, as well as managing vehicles and infrastructure..
Stop A physical location where a transport service stops to pick up or drop o pas-
sengers, goods, or vehicles. These stops can be planned or unplanned and may include
locations like bus stops, train stations, and airports. In some cases, a transport stop
may be a temporary location set up to accommodate a specic event or situation,
like a shuttle service for a concert or festival.
Service A scheduled or on-demand service that moves people, goods, or vehicles from
one location to another. This can include services like buses, trains, and subways.
Planned stop A pre-determined location where a transport service will stop to pick
up or drop o passengers, goods, or vehicles. These stops are scheduled in advance
and may be listed on a transport service’s route map or timetable. Examples of
planned stops on a bus route might include designated bus stops or transit centres.
Consider a transport network with one TSP named TSP1. Within this transport
network, there are two stops: North Terminal and South Terminal. There is one
service named Southbound, which makes two planned stops. Figure 2 illustrates the
TOnNe that represents the transport network.
OrganisationTSP1 type
StopNorth Terminal hasOrganisation
type
South Terminal
hasOrganisation
type
Service
Southbound
hasOrganisation
type
PlannedStop
Southbound
North Terminal
hasStation
hasService
type
Southbound
South Terminal
followedBy
hasStation
hasService
type
Fig. 2: A toy example of a TOnNe.
We see that the TOnNe is made of a number of vertices that represent the
subjects and objects, connected by edges that represent predicates. These subjects,
predicates, and objects are the basis of triples, which is how graph databases store
this information before parsing it into graphs. Figure 3 demonstrates how this infor-
mation can be stored within the Turtle format.
8 Joseph David Preece et al.
1@p re fi x rdf : <ht tp : // ww w. w 3. or g /1 99 9/ 02 /2 2 - rdf- sy nta x -n s# > .
2@p re fix r dfs: <http : // w ww . w3. o rg / 2 00 0/0 1/rdf- s ch ema # > .
3@p re fix ex: < ht tp: / / ex amp le. o rg / > .
4
5ex :Or ga n is a ti o n a rd fs: Cla ss .
6ex :S top a r df s :C las s .
7ex:Service a rdfs:Class .
8ex :Pl an n ed S to p a rdf s:C las s .
9
10 ex :T SP1 a e x: O rg a ni s at ion ;
11 ex :ha sOr gan is a ti o n e x: Nor th Ter min al , ex :So uth Te r mi n al ;
12 ex:hasService ex:Southbound .
13
14 ex:NorthTerminal a ex:Stop ;
15 ex:type ex:TSP1 ;
16 ex :h a sS t at ion ex: Sou thb oun dNo r th T er m in a l .
17
18 ex:SouthTerminal a ex:Stop ;
19 ex:type ex:TSP1 ;
20 ex :h a sS t at ion ex: Sou thb oun dSo u th T er m in a l .
21
22 ex :S o ut h bo und a e x:S erv ic e ;
23 ex:type ex:TSP1 ;
24 ex:hasService ex:SouthboundNorthTerminal , ex:SouthboundSouthTerminal
.
25
26 ex :So uth bou ndN ort hTe rmi n al a e x :P lan ned Sto p ;
27 ex:type ex:Southbound ;
28 ex :h a sS t at ion ex: Nor thT erm in a l ;
29 ex:hasService ex:Southbound ;
30 ex :f o ll o we dBy ex: Sou thb oun dSo u th T er m in a l .
31
32 ex :So uth bou ndS out hTe rmi n al a e x :P lan ned Sto p ;
33 ex:type ex:Southbound ;
34 ex :h a sS t at ion ex: Sou thT erm in a l ;
35 ex:hasService ex:Southbound .
Fig. 3: The example TOnNe, represented in the Turtle format.
5 Piecing the Puzzle Together: The STUB Ontochain
5.1 System Architecture
The STUB system is designed with a modular architecture that consists of two main
components, the blockchain and the ontology, to form the ontochain. This section
details the components and their interactions within the STUB system architecture.
Figure 4 illustrates the system architecture for STUB.
Blockchain STUB utilises a Hyperledger Besu implementation as its underlying
blockchain platform. The blockchain component consists of the following sub-components:
Smart Contracts; These programmable, self-executing agreements reside on the blockchain
and govern the rules for ticket issuance and management. They ensure that trans-
Title Suppressed Due to Excessive Length 9
STUB
Besu
Ontology
API Middleware
Smart
Contracts
Transactions
Ontology
Parser
Triple
Store
Organisation
Application
Customer
Application
Administrator
Application
CustomerValidator Vendor Administrator
Fig. 4: The smart contract architecture for STUB.
actions adhere to predened conditions and facilitate secure, automated process-
ing of the ticketing data.
Transactions; Transactions represent various actions within the system, such as
ticket purchases, validation events, and updates to the transport network infor-
mation. They are stored immutably on the blockchain, providing a transparent
and tamper-proof record of all activities.
Ontology The ontology component models the complex relationships within the
transport network, allowing for a more structured representation of the underlying
system. It consists of the following sub-components:
Triple Store; STUB employs StarDog as its Triple Store, which stores the transport
network information in the form of subject-predicate-object triples. This storage
structure enables ecient querying and retrieval of the ontological data.
Ontology Parser and Reasoning Engine; This sub-component is responsible for pro-
cessing the ontological data, validating its consistency, and performing reasoning
tasks on the StarDog triple store. It allows the system to infer new knowledge and
make informed decisions based on the existing transport network information.
10 Joseph David Preece et al.
Middleware The middleware serves as the connecting layer between the blockchain
and the ontology components, forming the basis of the ontochain. It extracts data
from the smart contracts on the blockchain and constructs it within the Triple Store,
allowing the ontological data to be reasoned on and utilised by other parts of the
system.
API An application programming interface (API) interacts with both the ontology
parser and the smart contracts, enabling external applications to query and interact
with the STUB system. This API serves as the primary interface for TSPs, adminis-
trators, and customers to access the ticketing system and leverage its functionality.
By integrating these components, the STUB system architecture oers a robust
and exible solution for smart transport ticketing. The combination of blockchain
technology and ontology-based modelling enables STUB to provide a secure, trans-
parent, and interoperable platform for ticket issuance, validation, and management,
addressing the limitations of traditional ticketing systems and STUB 1.0.
5.2 Smart Contract Architecture
The STUB system’s smart contract architecture is designed to facilitate secure and
ecient management of transport ticketing processes, representing the ontological
data within the smart contracts to ensure the ownership and validation of the trans-
port network data within.
STUB (Singleton) This is the main contract that serves as the central entry point for
the system. It acts as a registry and controller for other smart contracts within the
architecture, managing the relationships between tickets, transport network graphs,
and organisations.
Organisation This abstract contract represents the various entities involved in the
transport ticketing ecosystem, such as TSPs, government agencies, and other stake-
holders.
TransportServiceProvider A concrete implementation of the Organisation contract,
representing individual TSPs within the system.
TransportNetworkGraph This contract represents the transport network’s overall
structure, including stops, services, and planned stops. It is responsible for main-
taining relationships between these elements, as well as the associated tickets and
organisations.
Service An abstract contract representing the various transportation services oered
by the TSPs, such as bus routes, train lines, or ferry services. This can be built upon
by concrete subclasses.
PlannedStop This abstract contract represents planned stops within the transport
network, dening the schedule and location of stops for each service. This can be
built upon by concrete subclasses.
Title Suppressed Due to Excessive Length 11
Stop An abstract contract representing physical stops within the transport network,
such as bus stations, train stations, or ferry terminals. This can be built upon by
concrete subclasses.
Ticket This contract represents individual tickets issued within the STUB system.
It maintains relationships with the associated services and planned stops, ensuring
secure and accurate ticket validation.
The relationships between these components, as depicted in Figure 5, demon-
strate the modular and interconnected nature of the STUB smart contract archi-
tecture. By organising the contracts in this manner, the system enables ecient
querying, updating, and management of transport ticketing processes and on-chain
TOnNe data, whilst maintaining a high level of security and transparency.
«Singleton»
STUB
Organisation
TransportServiceProvider
TransportNetworkGraph
Service
PlannedStop
Stop
Ticket
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
1
*
*
1
1
*
1
1
1
1
Fig. 5: The smart contract architecture for STUB.
12 Joseph David Preece et al.
5.3 Proof-of-Validity
As the ontology is a representation of the TOnNe, TSP need to ensure that their
local version of the triple store matches the on-chain version, as this is the trusted
version. To achieve this, the hash digests of the objects are checked down a hierar-
chy recursively, until a mismatched hash digest is found. This is principle of Merkle
proofs, This simple concept, though complex through the implementation within the
STUB ecosystem, is what drives the PoV. The trust between TSPs is on the Hyper-
ledger Besu ledger, which is maintained and consented by the participating TSPs.
Therefore, the only trusted version of the TOnNe is the copy that resides within
the world state of the blockchain, meaning no modications can happen without
consensus of all TSPs.
A Merkle tree, also known as a hash tree, is a data structure to eciently verify
the integrity of large amounts of data Merkle [19]. Figure 6 illustrates a Merkle tree.
Merkle trees work by breaking down a large amount of data into smaller blocks, and
then creating a hash of each block using a cryptographic hash function. These hashes
are then organised into a binary tree structure, with each leaf node representing a
data block and each non-leaf node representing the hash of its child nodes.
The process starts with creating leaf nodes for each data block and then combin-
ing pairs of leaf nodes to create their parent nodes. The process is repeated until a
single node is left, which is the Merkle root. This root is a hash of all the data blocks
and serves as a digital ngerprint of the entire data set. To verify the integrity of a
data set, one only needs to compare the Merkle root of the data set with a previously
stored value. If the values match, the data has not been tampered with. However, if
the values do not match, the data has been modied or tampered with. Additionally,
Merkle Trees also allow for ecient verication of partial data sets by providing a
mechanism for “Merkle proofs” which are small pieces of data that can be used to
prove that a specic data block is included in the data set without revealing the
entire data set.
We use the concept of Merkle proofs to validate the TOnNe, illustrated in Fig-
ure 7. Here, the TOnNe follows a hierarchical object-oriented programming (OOP)
structure, with a superclass entity at the root (the TransportNetworkGraph), and
various subclasses and member classes. The single entity for the TOnNe that will
persist within the blockchain also stores a reference to each child entity within a
mapping. To check whether the on-chain and o-chain TOnNes are identical, the
hash digest of the root entity is computed from the o-chain TOnNe. If the hash
digest matches the on-chain hash digest, we can immediately verify that the on-chain
and o-chain TOnNes are identical, and that no updates to the o-chain version are
required. However, if the has digest is dierent, then there has been a change to the
on-chain version, and it must be determined where.
A crude way to do this would be to parse the entire structure again, but this is
computationally infeasible, especially as the size of the TOnNe begins to increase.
As such, the next layer of entities are checked. For example, there exists a mapping
structure that contains all of the planned stop entities. By computing the hash digest
of all of the o-chain planned stop entities and comparing it to the on-chain hash
digest, we reveal whether the stopping points have changed. If so, we can continue
to move down in levels of granularity (sorted by TSP, region etc.) until we reach the
specic changes, without having to perform an entire search.
Title Suppressed Due to Excessive Length 13
H(ABCD)
H(AB) H(CD)
H(A) H(B) H(C) H(D)
Fig. 6: A Merkle tree.
H(TOnNe)
H(Organisations) H(Stops) H(Services) H(PlannedStops)
H(TSP1) H(NorthTerminal) H(SouthTerminal) H(Southbound) H(Southbound
NorthTerminal)
H(Southbound
SouthTerminal)
Fig. 7: The Merkle proof tree for the TOnNe.
5.4 Proof of Journey
Returning to the example from Section 3, assume that Bob decides to use Yellow, for
which his ticket is not valid. The Yellow validator would take the ticket information,
ensure they have the the latest version of the TOnNe by checking the merkle root
values of the on-chain version and the o-chain version, and validate the ticket.
Because the ticket is invalid, Yellow can reject the ticket and issue Bob with a ne,
or ask him to leave the transport at the next available convenience. However, tickets
which are valid are marked as such, updating the ticket on the ledger with identifying
information about who and where the ticket was validated. This data is propagated
via the ledger, allowing any future validators to track the journey of a customer via
their shared ticketing data on the ledger.
14 Joseph David Preece et al.
6 Testing
The Reading Underground, illustrated in Figure 8, served as a suitable test environ-
ment for the STUB. With seven TSPs oering 14 services across 52 stops, it provided
ample size to indicate the durability of the STUB design. Utilising the True Suite
as a testing environment and ingesting the provided data, we assessed the STUB’s
ability to read the latest changes from the blockchain and update its own state using
Merkle proofs and the architectures described in Section 5.
True Suite Setup We set up a local testing environment using the True Suite.
True provided a robust framework for smart contract development, testing, and
deployment on various blockchain networks. It allowed us to simulate user interac-
tions with the STUB system and test its performance. Furthermore, we set up a
testing environment within StarDog to provide the ontology environment.
Smart Contract Deployment We deployed the STUB smart contracts to the True
Suite’s local test blockchain. This enabled us to test the functionality of the contracts
and ensure they could correctly manage ticketing data and user interactions.
Middleware Integration We integrated the Merkle proof concept into the STUB
system via a middleware. This middleware allowed ecient verication of data con-
tained within a Merkle tree, providing a secure and scalable method for the STUB
system to read and update its state based on the latest changes in the blockchain.
Network Data Ingestion We ingested the data from the Reading Underground, in-
cluding station names, route directions, and corresponding STUB tags for each sta-
tion, as outlined in the provided table. This data served as the basis for our testing
environment.
User Simulation We simulated user interactions with the STUB system, such as pur-
chasing tickets, validating tickets at stations, and requesting route information. This
tested the system’s ability to read and update its state based on the blockchain data,
as well as evaluate its overall functionality. This was achieved via a combination of
smart contract invocations via the True tests, and through queries and commits via
SPARQL Protocol and RDF Query Language (SPARQL) to the StarDog instance.
7 Conclusion
In this paper, we introduced STUB, a novel smart transport ticketing solution that
leverages ontochains, a hybrid data structure combining the strengths of blockchains
and ontologies. Through the integration of these two technologies, STUB aims to
address the limitations of traditional ticketing systems by providing a secure, trans-
parent, and exible framework for ticket issuance, validation, and management.
We have outlined the key components and workow of the STUB system, demon-
strating how TOnNes can eectively model complex relationships within transporta-
tion systems, while blockchain technologies ensure secure, decentralised, and tamper-
proof transactions that relate to the TOnNe and tickets. Furthermore, we discussed
Title Suppressed Due to Excessive Length 15
Fig. 8: The ctional Reading Underground network used to test the capabilities of
STUB.
the implementation of Merkle proofs for ecient and secure validation of ontological
data within STUB.
When compared to other existing or proposed smart transport ticketing sys-
tems, STUB demonstrates several advantages. By utilising ontochains, STUB facil-
itates improved interoperability between dierent transportation modes and TSPs,
enabling a more seamless and user-friendly experience for passengers. Furthermore,
the incorporation of blockchain technology ensures a high level of security and trans-
parency, mitigating the risks of ticket fraud and data tampering.
However, the implementation of STUB in real-world scenarios may encounter
potential challenges and limitations. Scalability remains a concern, as the system
would need to handle a large number of transactions and maintain performance levels
in the face of growing demand. Techniques for improving blockchain scalability, such
as sharding or o-chain solutions, should be considered in future iterations of STUB.
Data privacy is another important aspect to consider, as the transparent nature
of blockchain could raise concerns regarding the protection of sensitive user infor-
mation. Employing privacy-preserving techniques, such as zero-knowledge proofs or
condential transactions, could help address these concerns while maintaining the
benets of a transparent and secure system.
Integrating STUB with existing transportation infrastructure may also present
challenges, as it requires collaboration among various stakeholders, including TSPs,
government agencies, and payment processors. Developing standardised interfaces
16 Joseph David Preece et al.
and protocols for data exchange could facilitate smoother integration and encourage
widespread adoption of STUB.
In conclusion, STUB represents an innovative step towards the next generation
of smart transport ticketing systems. By harnessing the power of ontochains, STUB
provides a robust and adaptable framework that has the potential to transform the
way we access and utilise transportation services in the future.
List of Abbreviations
API application programming interface 10
EU European Union 4, 5
IMS Integrated Mobility System 4
IP4 Innovation Programme 4 5
NGI Next Generation Internet 4
OC ONTOCHAIN 4
OOP object-oriented programming 12
PoC proof-of-concept 5
PoO proof-of-ownership 3, 6
PoV proof-of-validity 3, 12
RFID Radio Frequency Identication 4
SPARQL SPARQL Protocol and RDF Query Language 14
STUB System for Ticketing Ubiquity with Blockchain 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
12, 14, 15, 16
TOnNe Transport Network Ontology 1, 2, 6, 7, 11, 12, 13, 14
TSP transport service provider 5, 7, 10, 12, 14, 15
UK United Kingdom 4
Conict of interest
The authors declare that they have no conict of interest.
References
1. Arshad J, Azad MA, Prince A, Ali J, Papaioannou TG (2022) Reputable–a
decentralized reputation system for blockchain-based ecosystems. IEEE Access
10:79948–79961
2. Astarita V, Giofrè VP, Mirabelli G, Solina V (2019) A review of blockchain-based
systems in transportation. Information 11(1):21
Title Suppressed Due to Excessive Length 17
3. Bella G, Cantone D, Longo C, Nicolosi Asmundo M, Santamaria DF (2021) Se-
mantic representation as a key enabler for blockchain-based commerce. In: Eco-
nomics of Grids, Clouds, Systems, and Services: 18th International Conference,
GECON 2021, Virtual Event, September 21–23, 2021, Proceedings 18, Springer,
pp 191–198
4. Bella G, Cantone D, Longo C, Nicolosi Asmundo M, Santamaria DF (2022)
Blockchains through ontologies: the case study of the ethereum erc721 standard
in oasis. In: Intelligent Distributed Computing XIV, Springer, pp 249–259
5. Blythe P (1998) Integrated ticketing smart cards in transport. In: IEE Sem-
inar on Using ITS in Public Transport and in Emergency Services (Ref. No.
1998/524), IET, pp 4–1
6. Blythe PT (2004) Improving public transport ticketing through smart cards.
In: Proceedings of the institution of civil engineers-municipal engineer, Thomas
Telford Ltd, vol 157, pp 47–54
7. Calle MHBM, Tavares TM, Ganga GMD, Godinho Filho M (2021) Blockchain-
enabled capabilities in transport operations: an overview of the literature. Inde-
pendent Journal of Management & Production 12(9):s728–s740
8. Cha SC, Peng WC, Hsu TY, Chang CL, Li SW (2018) A Blockchain-Based
Privacy Preserving Ticketing Service. In: 2018 IEEE 7th Global Conference on
Consumer Electronics (GCCE), IEEE, DOI 10.1109/gcce.2018.8574479, URL
http://dx.doi.org/10.1109/GCCE.2018.8574479
9. Eremina L, Mamoiko A, Bingzhang L (2020) Use of blockchain technology in
planning and management of transport systems. In: E3S Web of Conferences,
EDP Sciences, vol 157, p 04014
10. Ferrick B (2019) The Times they Are A-Changin’: Incorporating Blockchain
Networks into the Event Ticket Industry. SSRN Electronic Journal DOI
10.2139/ssrn.3318703, URL http://dx.doi.org/10.2139/ssrn.3318703
11. Finger M, MONTERO-PASCUAL JJ, Seramova T (2019) Towards EU-wide
multimodal ticketing and payment systems. European University Institute
12. García R, Cediel A, Teixidó M, Gil R (2021) Copyrightly: Blockchain and se-
mantic web for decentralised copyright management. In: Economics of Grids,
Clouds, Systems, and Services: 18th International Conference, GECON 2021,
Virtual Event, September 21–23, 2021, Proceedings 18, Springer, pp 199–206
13. Gnoni MG, Rollo A, Tundo P (2009) A smart model for urban ticketing based
on rd applications. In: 2009 IEEE International Conference on Industrial En-
gineering and Engineering Management, IEEE, pp 2353–2357
14. Gruber TR (1993) A translation approach to portable ontology specications.
Knowledge acquisition 5(2):199–220
15. Kalafatelis A, Panagos K, Giannopoulos AE, Spantideas ST, Kapsalis NC,
Touloupou M, Kapassa E, Katelaris L, Christodoulou P, Christodoulou K, et al.
(2021) Island: An interlinked semantically-enriched blockchain data framework.
In: Economics of Grids, Clouds, Systems, and Services: 18th International Con-
ference, GECON 2021, Virtual Event, September 21–23, 2021, Proceedings 18,
Springer, pp 207–214
16. Kochovski P, Stankovski V, Gec S, Faticanti F, Savi M, Siracusa D, Kum S
(2020) Smart contracts for service-level agreements in edge-to-cloud computing.
Journal of Grid Computing 18:673–690
17. Köpf H, et al. (2010) Integrail–publishable nal activity report. Integr Integr
Railw Syst no FP6—012526, Tech Rep IGR-PDAP 156:7
18 Joseph David Preece et al.
18. Lima MB, Banakar RM (2020) Fifa Ticketing System using Blockchain Hy-
perledger Sawtooth Platform. International Journal of Engineering and Ad-
vanced Technology 9(4):1031–3035, DOI 10.35940/ijeat.d7789.049420, URL
http://dx.doi.org/10.35940/ijeat.d7789.049420
19. Merkle RC (1988) A digital signature based on a conventional encryption func-
tion. In: Advances in Cryptology—CRYPTO’87: Proceedings 7, Springer, pp
369–378
20. Namiot D, Pokusaev O, Kupriyanovsky V, Akimov A (2017) Blockchain appli-
cations for transport industry. International Journal of Open Information Tech-
nologies 5(12):130–134
21. Nguyen TH, Partala J, Pirttikangas S (2019) Blockchain-based mobility-as-a-
service. In: 2019 28th international conference on computer communication and
networks (icccn), IEEE, pp 1–6
22. Norta A, Kormiltsyn A, Udokwu C, Dwivedi V, Aroh S, Nikolajev I (2022)
A blockchain implementation for congurable multi-factor challenge-set self-
sovereign identity authentication. In: 2022 IEEE International Conference on
Blockchain (Blockchain), IEEE, pp 455–461
23. Papaioannou T, Stamoulis GD (????) A business model for multi-tiered decen-
tralized software frameworks: The case of ontochain
24. Papaioannou TG, Kochovski P, Shkembi K, Barelle C, Simonet-Boulogne A, Cia-
ramella M, Ciaramella A, Stankovski V (????) A blockchain-based, semantically-
enriched software framework for trustworthy decentralized applications
25. Preece J, Easton J (2018) A review of prospective applications of blockchain
technology in the railway industry. Preprint to The International Journal of
Railway Technology
26. Preece J, Morris C, Easton J (2022) Towards stub 2.0: Using graph-based world
states in hyperledger besu to facilitate distributed transport ticketing. In: 2022
IEEE International Conference on Big Data (Big Data), IEEE, pp 3838–3844
27. Preece JD (2020) Ticket to ride: An investigation into the use of blockchain
technology in the rail industry. University of Birmingham
28. Preece JD, Easton JM (2019) Blockchain technology as a mechanism for digital
railway ticketing. In: 2019 IEEE International Conference on Big Data (Big
Data), IEEE, pp 3599–3606
29. Scrocca M, Comerio M, Carenini A, Celino I (2020) Turning transport data
to comply with eu standards while enabling a multimodal transport knowl-
edge graph. In: The Semantic Web–ISWC 2020: 19th International Semantic
Web Conference, Athens, Greece, November 2–6, 2020, Proceedings, Part II 19,
Springer International Publishing, pp 411–429
30. Sharma N (2008) The origin of data information knowledge wisdom (dikw) hi-
erarchy. Preuzeto 25:2021
31. Shkembi K, Kochovski P, Papaioannou TG, Simonet-Boulogne A, Ciaramella M,
Barelle C, Stankovski V (????) The semantic web and blockchain at a meeting
point
32. Smith B, Kumar A (2004) Controlled vocabularies in bioinformatics: a case study
in the gene ontology. Drug Discovery Today: BIOSILICO 2(6):246–252
33. Sopek M, Tomaszuk D, Głąb S, Turoboś F, Zieliński I, Kuziński D, Olejnik R,
Łuniewski P, Grądzki P (2022) Technological foundations of ontological ecosys-
tems on the 3rd generation blockchains. IEEE Access 10:12487–12502
Title Suppressed Due to Excessive Length 19
34. Turner M, Wilson R (2010) Smart and integrated ticketing in the uk: Piecing
together the jigsaw. Computer Law & Security Review 26(2):170–177
35. Tutcher J, Easton JM, Roberts C (2017) Enabling data integration in the rail in-
dustry using rdf and owl: The racoon ontology. ASCE-ASME Journal of Risk and
Uncertainty in Engineering Systems, Part A: Civil Engineering 3(2):F4015001
36. Verstichel S, Ongenae F, Loeve L, Vermeulen F, Dings P, Dhoedt B, Dhaene T,
De Turck F (2011) Ecient data integration in the railway domain through an
ontology-based methodology. Transportation Research Part C: Emerging Tech-
nologies 19(4):617–643
