You are viewing a javascript disabled version of the site. Please enable Javascript for this site to function properly.
Go to headerGo to navigationGo to searchGo to contentsGo to footer
In content section. Select this link to jump to navigation

Urban IoT ontologies for sharing and electric mobility

Abstract

Cities worldwide are facing the challenge of digital information governance: different and competing service providers operating Internet of Things (IoT) devices often produce and maintain large amounts of data related to the urban environment. As a consequence, the need for interoperability arises between heterogeneous and distributed information, to enable city councils to make data-driven decisions and to provide new and effective added value services to their citizens. In this paper, we present the Urban IoT suite of ontologies, a common conceptual model to harmonise the data exchanges between municipalities and service providers, with specific focus on the sharing mobility and electric mobility domains.

1.Introduction

According to the United Nations, today 55% of the world’s population lives in urban areas,1 a proportion that is expected to increase to 68% by 2050.2 For the last decade, our cities have been digitally instrumented in many different ways, becoming the producers of a continuously increasing wealth of data, that spans multiple human activities and business domains. The large availability as well as the decreasing cost of Internet of Things (IoT) devices have been leading to an unprecedented flow of digital information about urban environments.

Municipalities and city councils are facing every day the challenge of governance over their digital sources: the amount and heterogeneity of such information require specialised technological infrastructure but, on the other hand, offer the opportunity to create data-driven solutions to support decision-making and to offer value-added services to citizens. City governments need to manage and interact with a large set of service suppliers, from utilities to transport and logistics, from telecommunication to local businesses, each of which generates information flows that are of potential interest for urban planning and management.

In this context, mobility is also undergoing a profound change and transformation: on the one hand, sustainability and environmental concerns are pressing travellers and transport stakeholders to invest in eco-friendly solutions with a rising interest in electric mobility; on the other hand, new transport modes and mobility habits are growing, with stronger attention to micro-mobility (especially bicycles, scooters and motorcycles) and transport-on-demand services based on the sharing economy principles.

At the urban level, this implies a steady increase in the number of different and competing service providers which act as mobility suppliers for the city. They are often independent organizations with their own digital infrastructure and adopting different data formats and standards in their internal processes. As a consequence, exchanging data with the city councils and between organizations becomes a challenge: a strong urgency for interoperability arise, with the need for common languages and interfaces.

Our work addresses this interoperability challenge, by designing a modular suite of ontologies for Urban IoT devices, with specific modules dedicated to sharing mobility (car sharing, bike sharing, etc.) and electric mobility (vehicle charging infrastructures). Those ontologies have the goal to constitute the reference model for data exchange between service providers and municipalities; the model can indeed be used to define and annotate APIs. This effort was initiated thanks to the sponsorship of the municipality of Milan in Italy with its Information Systems and Digital Agenda Department (in Italian: Direzione Sistemi Informativi e Agenda Digitale – SIAD), which has the visionary and ambitious goal to effectively manage all the IoT flows thanks to integrated data governance powered by open data and Semantic Web technologies. We were supported by the domain and technical experts of the city of Milan in all phases of our ontology engineering process. Thanks to the large applicability of the usage scenarios defined and the investigation of the relevant international standards, however, the results of our work are valid for any urban environment.

The remainder of this paper is organized as follows: Section 2 discusses relevant standards, project and vocabularies in the considered domains; Section 3 briefly summarises the adopted ontology engineering methodology; Section 4 reports the performed domain analysis and the identified requirements; Section 5 illustrates the modules of the Urban IoT ontologies; Section 6 provides the evaluation of the ontologies considering automatic pitfalls detection and ontology evaluation criteria; Section 7 describes the choices for the online publication; Section 8 exemplifies the intended usage of the ontologies; Section 9 discusses the potential long-term impact of the proposed vocabularies; finally, Section 10 draws the conclusions.

2.Related work

In the context of smart cities, several efforts have been conducted to define shared vocabularies and standards to guarantee the interoperability of data collected within a city, in particular from IoT devices. Considering sharing and electric mobility services in the urban area, in the following we describe some of the most widely adopted standards to represent data in those domains, we mention some previous works investigating Semantic Web technologies for IoT interoperability, and we present a review of ontologies and vocabularies to describe mobility services in an urban context.

2.1.Domain standards

The General Bikeshare Feed Specification (GBFS) [18] is a data format for real-time/read-only data describing the status of vehicles made available by sharing mobility service providers. The format specification, originally defined by Google, is currently led by the North American Bike Share Association (NABSA). GBFS is used by hundreds of services worldwide3 and it is supported by several user applications offering mobility services. Although the first releases of the standard only allowed to describe station-based bike-sharing services, the latest versions embrace also free-floating services and micro-mobility vehicles. The specification prescribes the regular publication of a feed composed of several JSON files describing the sharing mobility service (hours, calendar, area, pricing plans, alerts), the status of free-floating vehicles, the stations (if available) and their status (number of vehicles available, number of docks available, etc.).

The Mobility Data Specification (MDS) [19] defines a set of Application Programming Interfaces (API) based on a shared vocabulary for sharing mobility services (bicycle, car, motorcycle, micro-mobility vehicles). Originally designed for the Los Angeles Municipality, the specification is now led by the Open Mobility Foundation (OMF),4 gathering different municipalities and companies to support the definition of open-source solutions for Mobility in cities. The specification identifies two main roles: mobility providers offering sharing mobility services to users, and regulatory agencies (e.g., the municipality) governing those services in a given region.

The MDS defines three main endpoints: (i) Provider API: implemented by providers, data pulled by agencies, provides a historical view of data on the service operations (e.g., trips and vehicle status changes); (ii) Agency API: implemented by agencies, data pushed by providers, encompasses real-time events in the system (e.g., new vehicle registration or a user trip); (iii) Policy API: implemented by agencies, data pulled by providers, provides updates about local rules/policies that may affect the mobility service operation (e.g., the maximum number of vehicles concurrently placed in a city area at a given time). The MDS specification is designed for communications between mobility providers and regulatory agencies and prescribes GBFS as a format to share real-time data on the services with users.

The Open Charge Point Interface (OCPI) [17] is a well-established protocol to guarantee interoperability between the eMobility Service Providers (eMSP), offering services to the owners of electric vehicles, and the Charge Point Operators (CPO), operating the recharging stations and their Electric Vehicle Supply Equipment (EVSE). The same organization can perform both roles, however, this distinction allows to regulate hubs and enables roaming scenarios where recharging stations of a CPO can be used by customers of different eMSPs. The OCPI protocol defines data exchanges between those two involved actors and it is not designed for data sharing with third parties (agencies or final users). However, this specification adopts the terminology largely used in this domain, therefore its modules can help to identify the data to be produced and collected in order to describe the infrastructure, the real-time status and the recharge sessions.

The design of the Urban IoT ontologies strongly relied on the analysis of the presented domain standards aiming at identifying the relevant domain actors, concepts and terminology. For sharing mobility, our ontologies build on the MDS and GBFS specifications to define a uniform conceptual model for both static and dynamic data from sharing service providers dealing with different vehicles (bike, car, motorcycle and micro-mobility). For electric mobility, our ontologies abstract from the OCPI protocol details to consolidate relevant information for authorities and third-party users. Moreover, the Urban IoT ontologies also elicit commonalities and contribute by identifying a set of core concepts related to the considered domains as discussed in Section 5.2.

2.2.IoT semantic interoperability

Different solutions have been proposed to build an ecosystem within smart cities where different IoT devices, providers of services and authorities can share and access data to create additional value. To implement the envisioned ecosystem, it is important to guarantee horizontal interoperability for different types of users (e.g., providers, authorities, users of the service) accessing the same dataset, but also vertical interoperability among different datasets describing the same domain. Most importantly, the mentioned interoperability should be both structural, i.e., from the point of view of the technologies employed, but also semantic, i.e., considering shared vocabularies and definitions. Several works in the literature and research projects showcase how Semantic Web solutions can offer a complete framework to tackle these issues with IoT devices [1].

The work of Kolbe et al. [14] describes a prototype developed within the bIoTope project5 and showcases how ontologies applied on-top of the lower-level messaging specifications can effectively guarantee interoperability in the context of a parking scenario with connected vehicles emitting data.

Similarly, Yoo et al. [29] present a semantic model to gather data from electric vehicles enabling interoperability between different IoT data provides. They also discuss how this interoperability can enable new services, such as a charging location search optimised with traffic information.

Both papers refer to the Semantic Sensor Network (SSN) ontology [11] as a suitable model to describe data collected from IoT devices. SSN is an extensive ontology to describe actuators and sensors, their observations, the data collection procedures, the investigated features of interest, the sampling approach, the performed samples and the observed properties. For the last few years, the SSN ontology has become a de-facto standard for IoT interoperability [1], given its simplicity in representing IoT devices as sensors, or group of sensors, collecting observations and samples. One aspect favouring its wide adoption is related to the ontology modularity and the possibility to cover most of the use cases with its lightweight and self-contained core module SOSA (Sensor, Observation, Sample, and Actuator) [13]. A more dedicated vocabulary is the IoT-Lite Ontology [3] specialising a small subset of classes and properties of the SSN to represent IoT platforms through a simpler model.

The Sensor Interface Specification (SENSORIS) is an effort by multiple stakeholders in the automotive domain to define a global standardised interface for exchanging data between sensor vehicles and the cloud. The specification, already released in a public stable version [12], aims at overcoming the different data formats currently adopted by different carmakers. The objective is to define standardised communication formats and protocols between vehicle sensors and dedicated IoT infrastructures in the cloud (defined as vehicle cloud). Moreover, the specification enables also communication between different clouds, empowering the definition of third-party services (defined as service cloud) leveraging data from the dedicated vehicle cloud of different stakeholders.

The SynchroniCity project,6 funded by the European Union’s Horizon 2020 programme, aimed at implementing an ecosystem for IoT-enabled smart city solutions. To guarantee interoperability, the project defined a set of SynchroniCity data models.7 By gathering different actors and initiatives (e.g., manufacturers and system integrators) they defined the data models in collaboration with the Open & Agile Smart Cities (OASC) consortium8 as city stakeholders. The JSON specifications of the models are based on the FIWARE Data Models9 and were developed taking into account also the IoT Big Data Harmonised Data Models developed by the GSM Association,10 the Schema.org vocabulary and the SAREF ontology [8]. The SynchroniCity data models describe also IoT devices in the sharing and electric mobility domain through the CarSharingStation, the BikeHireDockingStation and the EVChargingStation models. SAREF4AUTO [9] is a dedicated extension of the SAREF ontology defined for the automotive domain to bridge the gap between the SAREF ontology and important initiatives in the sector, like the above mentioned SENSORIS specification and the SSN and SOSA ontologies. The main focus of the ontology is related to the description of the state of a vehicle and its behaviour in traffic situations. In particular, data from different sensors can be represented to handle use cases related to driving (e.g., platooning considering multiple vehicles) and/or parking.

The Urban IoT ontologies leverage the widely-adopted SOSA ontology to support the ongoing efforts mentioned by different related works in guaranteeing interoperability for data from IoT devices. Our defined ontologies extend the generic concepts provided by SOSA to reflect the domain semantics of the sharing and electric mobility domains taking into account already existing vocabularies, such as the SynchroniCity data models. Differently from the SENSORIS specification and other similar projects, the Urban IoT ontologies focus on the exchange of macro-data from different service providers and do not investigate the details of communication protocols between devices. The initial release of the Urban IoT ontologies models the sharing and electric mobility domains, but the ontologies aim at offering core concepts for semantic interoperability of different IoT-enabled services in a smart city.

2.3.Mobility vocabularies and ontologies

Considering urban mobility services, interoperability should not be limited to the employed IoT devices, but it should be extended to other data, such as the description of user services, the historical usage data, the description and the geographical representation of the involved facilities and areas, etc.

Analysing the literature and using Semantic Web tools, like the Linked Open Vocabularies (LOV) portal [25], it is possible to identify well-adopted ontologies already defining these concepts.

The Velopark project [22] collects information on bicycle parkings providing a pre-defined data model to describe facilities and services. The Velopark Rich Snippets Generator11 allows the user to insert information through a graphic interface and to obtain an RDF representation in JSON-LD [24]. The obtained snippet can be uploaded to the Velopark portal where the user can access details on all the different bicycle parkings in a uniform way. The vocabulary to describe the parkings mainly relies on classes and properties from Schema.org12 and a set of additional concepts defined in the Velopark Vocabulary.13 Moreover, the Open Mobility Vocabulary14 (MobiVoc) was reused. This ontology, developed with the support of industrial partners, is mainly based on Datex II,15 the European standard for traffic information and traffic data, and currently describes electric charging points, parking facilities and highway roadworks sites.

To represent service providers, service users and geographic locations, a set of standardised vocabularies have been defined by the Semantic Interoperability Community (SEMIC)16 group of the European Commission ISA2 Programme on Interoperability for public administrations. The defined e-Government Core Vocabularies17 include the following modules: Location, Business, Person and Public Organisation. Each of these vocabularies can be further specialised through the definition of national profiles.18 The Location [20] module offers a generic abstraction for geographical data that can be implemented using the well-adopted GeoSPARQL [2] and Basic Geo Vocabulary19 based on WGS84.

It is also worth mentioning the ongoing Ciudades Abiertas20 project that is developing a set of vocabularies to make Spanish municipalities data semantically interoperable. In particular, the Vocabulary for the representation of data about the public bicycle system21 offers a well-designed example of how to model station-based bike-sharing services.

Differently from other mobility vocabularies, the Urban IoT ontologies focus on service providers and data from their IoT devices operating in the urban area. The developed ontologies exploit and re-use a set of ontological and non-ontological sources by identifying the relevant concepts in these widely-used vocabularies and by bounding them with domain specific classes and properties. In particular, classes and properties from the Schema.org and the Core Vocabularies by SEMIC are employed to avoid re-defining concepts related to organization, services, places and geospatial data in order to follow linked data best practices. In the ontology engineering process, similar efforts, like the Velopark portal and the Ciudades Abiertas bike-sharing vocabulary, were analysed to validate modelling decisions in similar use cases, but not directly re-used because of their limited scope and specific requirements.

3.Applied methodology for ontology engineering

In this work, we applied the Linked Open Terms methodology (LOT) [27], a consolidated industrial method to develop ontologies and glossaries. In this section, we summarise the main phases of the methodology and we explain how we applied them to the Urban IoT ontologies design and development.

3.1.Ontology requirements specification

The first activity is aimed to specify the ontology requirements. Based on a domain analysis, including an investigation on the existing data flows, we identified a set of use cases and user stories.

Then, we defined a set of “competency questions”, i.e. the definition of the information that should be retrieved from data modelled with the target ontology, and a set of “facts”, i.e. the requirements associated with the domain specific terminology (e.g., attributes describing a specific term, etc.). In this phase, we heavily involved domain experts and stakeholders, to ensure a comprehensive set of requirements and an effective ontology specification.

Details are included in Section 4.

3.2.Ontology implementation

The second step is the actual ontology implementation. We started the conceptualisation process with the identification of a glossary of terms, starting from the facts and competency questions.

Then we produced a first conceptual model with the required set of classes and properties; in line with the best practices of ontology engineering, we analysed the relevant and existing ontological models to assess their reuse. In this phase, we found it useful to create a graphical representation of the model to ease the conceptualisation.

Finally, we proceeded with the actual ontology coding in the OWL language, including the import or reference to the selected reused ontologies, and we validated the output, both with the support of automatic diagnosis tools and by manually assessing the implemented axioms with respect to the requirement specification (facts and competency questions).

Details are presented in Sections 5 and 6.

3.3.Ontology publication

The third activity is the documentation and publication of the ontological model. In particular, after selecting the suitable licence and agreeing on the hosting modalities with our stakeholders, we published the ontology online following a content-negotiation mechanism, making the resource available in different formats which are both human-readable and machine-readable. The ontology is also assigned with a unique and permanent Web identifier.

The outputs of this activity are the ontology itself in different formats (Turtle, RDF/XML, JSON-LD, N-Triples) and the associated HTML documentation containing meta-data, the classes and properties description and graphical representation. In the documentation, we also included some illustrative examples identified with the support of the domain experts.

Details on publication are discussed in Section 7.

3.4.Ontology maintenance

Maintenance is the final activity of the methodology. The purpose is to update or add new requirements, to identify and correct errors, and to schedule new development iterations for the ontology. In our case, since the Urban IoT ontologies are new, we simply set up a mechanism to facilitate the collection of suggestions and requests from the ontology adopters.

Details on maintenance are offered in Section 7.

4.Urban IoT ontology requirements

This section discusses the activities and the outcomes of the ontology requirements specification phase. Figure 1, summarises the steps performed and the artefacts produced in this phase.

Fig. 1.

LOT ontology requirement specification phase and its outputs for the urban IoT ontologies.

LOT ontology requirement specification phase and its outputs for the urban IoT ontologies.

4.1.Domain experts

As mentioned, the need for the Urban IoT ontologies came from the Milan Municipality. Therefore, in the requirements phase, we involved fifteen different experts, who helped us eliciting their needs and analysing the two identified domains of sharing and electric mobility. The city stakeholders were from the Mobility Department (Area Pianificazione e Programmazione Mobilità), the municipality team responsible for mobility and transport planning and governance, which participated with six experts, and from the Data Department (Area Gestione ed Integrazione dati), which engaged four experts in interoperability and open data. In addition, we involved two domain experts from AMAT,22 the municipal agency for mobility and environment, which is in charge of collecting and processing mobility data for the city. Last but not least, three colleagues inside our institution participated to provide additional expertise on the selected domains.

4.2.Domain analysis

The original demand was related to the IoT-collected data originating from sharing mobility and electric mobility providers: the municipality goal is to harmonise the data flows between such service suppliers and the city. To ensure the definition of comprehensive requirements on the considered sharing and electric mobility domains, we set up focused interviews with the mentioned experts during the ontology requirements phase, with the goal to collect not only their expertise but also some ontological and non-ontological resources to support our effort.

Interviewing the Mobility Department experts, we were able to identify the relevant terminology, to define potential user stories, and to delimit the scope of the ontologies. During these interviews, we also collected a set of relevant documents: council resolution for the creation of a digital urban ecosystem, public tenders for sharing services and charging stations, information on the active sharing services with related processes and structures, customer satisfaction questionnaires used to evaluate the services.

Most importantly, the city mobility experts suggested we consider relevant domain-specific international standards: GBFS, MDS, and OCPI. During the interviews, the sharing mobility domain required a wider investigation due to the information complexity, but we could benefit from the already available guidelines, defined by the municipality for service providers, that helped us in identifying the main data to be modelled. For the less complex electric mobility domain, similar normative guidelines were not available. Therefore, we organised multiple meetings in which the electric mobility experts gave us additional insights on the national regulations, on the different actors and technologies involved, and on the current governance and planning implemented in Milan.

From the Data Department experts, we collected information on the already available open data in the selected domains, i.e., formats, information represented and naming conventions, from their Open Data portal,23 as well as from their previous efforts to generate Linked Open Data.24

Additionally, we interviewed the mobility experts from AMAT to understand the analysis that they are currently performing on the already available data sources, and the additional potential investigations that they would like to implement, in case the service suppliers would provide further data from their IoT infrastructure.

Finally, to get a broader view of the domain, also beyond the specific case of Milan, we considered other similar efforts in public and private projects. To this end, we contacted the experts within our own institutions to discuss their views on the sharing and electric mobility domains. They indicated relevant European and national related projects: SynchroniCity proposing data models to support interoperability in the urban environment, SharingCities25 defining useful scenarios and KPIs, and eMoticon26 investigating transnational interoperability for electric mobility; they also suggested related initiatives in other cities, and public APIs already available in the considered domains.

As a result of the domain analysis, we collected transcripts of the meetings and investigated a wide set of ontological and non-ontological resources, some of them already discussed in detail in Section 2.

Table 1

The list of the sample user stories and competency questions, one for each of the seven described use cases

Use CasesUser StoriesCompetency Questions
UC1 [Sharing Mobility] Urban sharing services usage statisticsStatic data – The Municipality wants to analyse the beginning and end locations of all the trips, in order to enable the combined use with public transportWhat are the final locations of trips that started from a specific sharing station in a day?
UC2 [Sharing Mobility] (Near) Real-Time data elaboration for urban sharing servicesDynamic data – The Municipality analyses the events associated with individual vehicles to obtain statistics on maintenance and removal from the fleet of vehicles by operators. The purpose is to assess the reliability of the vehicles made available (life cycle) and the number of vehicles actually available in the various time slots and types of days (weekdays/pre-holidays/holidays)How many sharing service vehicles are currently unavailable due to breakdown, rebalancing, recharging, disposal?
UC3 [Sharing Mobility] Sharing services data publishing in open formatsOpen data – The user wants to know the fuel/charge levels of the sharing vehicles available around him, to evaluate if these vehicles are able to cover the route neededWhat is the charge/fuel level of the vehicles currently available in a specific area?
UC4 [Electric Mobility] Urban electric charging infrastructures usage statisticsStatic data – The Municipality wants to analyse the city areas where the highest number of charges by occasional users take place, to plan the placement of high-power charging infrastructures and/or information points for users coming from other citiesHow many charging sessions are carried out by occasional users on a specific day for each charging station location?
UC5 [Electric Mobility] (Near) Real-Time data elaboration for urban electric charging infrastructuresDynamic data – The Municipality wants to analyse the distribution of the “in charge” columns during the different moments of the day to evaluate the city areas where the demand for charging infrastructures is concentratedWhich EVSEs, for each charge category, are currently reported as “in charge”?
UC6 [Electric Mobility] Electric charging infrastructure data publishing in open formatsOpen data – A user wants to identify all the charging infrastructures compatible with its vehicle and available in a specific moment in a defined point of the cityWhat are the charging stations with at least one EVSE having a certain connector type and being currently available?
UC7 [Mobility Area] Data integration for mobility areasOpen data – The Municipality wants to analyse the charges and the trips made within a mobility area to evaluate the effective use of the servicesHow many charges and how many trips have started within a specific mobility area in one day?

4.3.Use cases and user stories

From the information collected during the domain analysis, we defined 7 use cases for the sharing and electric mobility domains (cf. first column of Table 1).

Six use cases separately cover the two domains (sharing mobility and electric mobility): for each of them, we distinguished the analyses of static data, real-time data, and data made openly available to third-party users (e.g., the citizens). A seventh use case was defined to investigate the combined use of data from both domains and from other IoT devices. To investigate this aspect, we leveraged the concept of mobility area, used in Milan but common also to other cities, i.e. a physical place aggregating public transport stops, sharing services stations, charging stations and additional mobility-related services to facilitate a seamless experience for the user (e.g. WiFi hotspots).

In the Urban IoT ontology repository,27 a full description of the use cases is available, highlighting the main actors and the information flow; in the following, we provide a short summary.

Actors The use cases identify different actors. The Municipality is the facilitator actor who makes the collected data available for others; it also uses data for internal purposes: to analyse the existing services, to make statistical assessments, or to evaluate the need to activate new services, with the support of the Urban Mobility Manager. The Mobility Service Providers (sharing service operators and charge point operators, both active suppliers and willing to be authorised) need to provide data from their IoT infrastructure to the city, in compliance with the Mobility requests. The benefits from the urban IoT data management should advantage the final users of the mobility services (citizens or tourists, including both existing and potential mobility service subscribers.

Static data use cases The Municipality analyses current and historical information, shared by different operators active on the territory. The Mobility Service Providers provide data related to the subscribed Users, databases of the performed trips or charges. The Urban Mobility Manager executes the elaborations on the collected data on behalf of the Municipality, which uses the results to promote sustainable mobility, mobility services, and to evaluate the activation of new tenders.

Dynamic data use cases The Mobility Service Providers make available their dynamic data (vehicles or charging points in use or available) in near real-time. The Urban Mobility Manager executes data analysis on such data, to let the Municipality investigate, on the one hand, the available vehicles placement, flow, state, etc. and, on the other hand, the distribution of the available charging points, their location and their usage.

Open data use cases Some static and dynamic data can be made available by the Municipality to possible Users of the mobility services or to other third parties (e.g. broker services which provide an aggregated view of the available services in the city via a mobile app).

Mobility area use case The Municipality integrates static and dynamic data related to the different available services in the mobility areas, to execute analysis whose results are made available in an open format (open data, linked open data and service). In this case, the different operators (not only for sharing and charging points but also providers of smart parking, public transport or other mobility area providers) make available their static or dynamic data accordingly to the contractual requests of the Municipality. The Urban Mobility Manager integrates all data to provide open data and services with added value to users or third parties. 28

From the definition of those seven use cases, we elaborated and defined 69 user stories (also available in the repository), which are described following the template: [actor] wants [something] in order to get [benefit]. A small selection of user stories, one for each use case, is in the second column of Table 1.

4.4.Requirement specification

From the use cases and user stories of the domain analysis phase, we derived the actual requirement specification, in the form of Facts and Competency Questions. Hereafter, we clarify the purpose and scope of our ontology engineering and then we detail the final requirements, which underwent a validation phase with the involvement of the domain experts.

4.4.1.Ontology purpose and scope

The use cases and user stories were the basis for drawing the boundary of our ontology scope and, as a consequence, the purpose of our engineering effort.

Indeed, we based most of our modelling on the existing standards (MDS, GBFS and OCPI), but they do not consider the information related to the final user; therefore, we decided to extend our modelling by including a very basic user profile, with features that allow for socio-demographic analysis on the service usage, while guaranteeing user anonymity.

On the other hand, the data currently collected by Milan municipality does not include information about service pricing or maintenance, but the investigation with the domain experts revealed the need to consider them. In this respect, we decided to include in our scope some parts of those aspects. Regarding maintenance, we introduced a detailed description of the events associated to the vehicles fleet, useful to analyse maintenance activities or vehicle re-balancing. Regarding pricing, we extended our scope to incorporate basic fee typologies (e.g., hourly price or cost per kWh), to allow for some comparative analysis, still preserving each service provider confidential business information (e.g., we excluded details related to specific promotions or to individual usage session costs).

4.4.2.Facts

Facts represent preliminary definitions for concepts identified in the domains. For the sharing mobility, the main concepts defined are sharing service operator, sharing service, offer, user, trip, vehicle, sharing station, dock, sharing station state, dock state and vehicle state. Similarly, for electric mobility, there are the charge point operator, the charging station, the Electric Vehicle Supply Equipment (EVSE), the EVSE state, the connector, the e-mobility service provider, the offer, and the charging session. A further mobility area concept was defined to describe physical places dedicated to both services.

4.4.3.Competency questions

Competency questions identify the inquiries that an ontology adopter should be able to express on the data. Therefore, for each identified user story, we defined one or more related competency questions that express the user need. In Table 1, a selected set of competency questions is presented in the third column (related to the user stories offered in the same table).

4.4.4.Requirements validation

The combination of facts and competency questions constituted our Ontology Requirement Specification Document (ORSD). The formalised requirements were presented back to the domain experts that supported our domain analysis for their validation.

They went through the lists of facts and competency questions and thoroughly assessed the clarity, accuracy, completeness with respect to their needs, and the fitness-for-use. In this phase, they suggested minor adjustment of vocabulary and some additional interesting queries that we added to the final version of the ORSD.

The complete list of 136 facts and 87 competency questions is available in the requirements folder of the ontology repository.29

5.Urban IoT ontology implementation

Based on the requirements gathered and formalised in the previous steps, we then proceeded to the implementation phase. This section describes our conceptualisation effort and the resulting modular suite of Urban IoT ontologies.

5.1.Ontology conceptualisation

In the conceptualisation step, we designed a modular solution to facilitate adaptability and extensibility. In particular, as both the domains needed a representation of providers operating IoT-based services offered to users in a city, it was decided to create a common Core module as general as possible.

We designed the Core module as a base vocabulary that can be easily specialised to define Urban IoT modules, which extend the core to describe specific services. We developed the Sharing mobility and Electric mobility modules as extensions of the Core module; the former adds all the specific contents related to the sharing mobility domain, while the latter describes in detail the electric mobility domain. In the future, new Urban IoT modules can be added to model other city services encompassing a sensor infrastructure.

Moreover, despite the fact that the involved domain experts were from Milan, the resulting suite of ontologies is generic and covers the needs of any city, as already discussed; however, this modular approach allows also for local specialisations, in case a specific urban environment needs its peculiar extensions to the provided modules.

During the implementation of the three modules, we considered and re-used existing relevant vocabularies to model identified concepts and relations. For the first conceptualisation of the three modules, we adopted a graphic approach to better visualise the overall structure, the connection between the Core concepts and the ones for the specific domains, and the relations with other existing vocabularies. Once the conceptualisation was completed with the graphic model, we encoded the ontology modules using OWL axioms.

In the following paragraphs, we present the main classes and properties of the three modules, using the mentioned graphic model split in different diagrams to support the explanation. Figure 2 reports the legend to understand the adopted notation for classes, instances, object properties and sub-classes.

The full documentation of the three modules of our suite of ontologies is available online.30

Fig. 2.

Legend and prefixes used in the ontology diagrams.

Legend and prefixes used in the ontology diagrams.

5.2.Core module

The Core module (prefix uiot) defines the concepts and the principal properties that will be reused in other modules. In particular, it designs the aspects related to a service provider who manages the IoT devices in the urban area, the service usage by the users and the modelling of an IoT device that collects and sends data. The concepts defined from the Core module are expressed at a high level of abstraction and are declined in the specific domain inside the other modules of the Urban IoT suite that imports it (as the Sharing mobility module and the Electric mobility module). The Core module was implemented by reusing different vocabularies, some of them discussed in detail in Section 2. Schema.org was chosen to re-use the already defined concepts of organization, service and places. The Sensor, Observation, Sample, and Actuator (SOSA) ontology was selected for the modelling of the IoT devices and the data collected from them since it provides a widely adopted standard lightweight vocabulary. The Core Vocabularies defined by SEMIC were chosen to model data about geospatial entities as they provide abstractions over common vocabularies (e.g., GEOSPARQL and WGS84) and many European countries have already adopted national profiles for these vocabularies. Finally, the W3C Time Ontology31 and the Dublin Core32 were re-used as recommendations for time concepts and metadata.

The main concepts of the Core module have been modelled by extending the Schema.org vocabulary, as described in Fig. 3, in the graph on the left. A service provider can be modelled as a schema:Organization that provides one or more schema:Service. The offered service can make available for the users some uiot:ServiceResource that can be used by the user in a uiot:UsageSession. The offer for the service usage can be modelled as a schema:Offer; all the offers can be associated with the service that made them available. Furthermore, the specific offer, if applied to a usage session, can be directly associated with the latter.

Fig. 3.

Core module, with specific details on sosa and locn usage.

Core module, with specific details on sosa and locn usage.

Service users are modelled as uiot:ServiceUser and can be uiot:ServicePrivateUser, namely physical persons (subclass of schema:Person) subscribed to a service, or uiot:ServiceBusinessUser namely legal entity (subclass of legal:LegalEntity, which is the prefix of one of the Core Vocabularies by SEMIC) subscribed to a business contract. Only a uiot:ServicePrivateUser can perform a uiot:UsageSession. A uiot:ServiceBusinessUser can enable a list of uiot:ServicePrivateUser to the service usage and to be associated to a usage session. However, it is necessary to specify the physical person that used the service by the specific business contract.

For the modelling of an IoT urban device the Core module uses the pattern SOSA defined in the related ontology, see Fig. 3, the graph at the bottom right. Intuitively, an IoT urban device can be seen as a sosa:Sensor (or an aggregation of sensors) that emits sosa:Observation, which reports the sampled value of a series of sosa:ObservableProperty. The following pattern guarantees the extensibility of sampled properties from a sensor, allowing the definition of different types of sosa:Observation associated with a sensor. In the Core module, uiot:SensorRecord is defined as an aggregation of data received by a sensor at the same moment. In particular, a uiot:SensorRecord can contain a series of sosa:Observation. A sosa:Sensor is associated with the uiot:SensorRecord it has emitted, with the specification of the last record by the property uiot:latestRecord.

To address the requirements about mobility areas, the Core module defines also a uiot:MobilityStation as a place where different services related to urban mobility are aggregated (see in Fig. 3 the top right graph), like for example sharing stations for the sharing mobility or charging stations (defined respectively in the Sharing mobility and Electric mobility modules). A uiot:MobilityStation is a place (schema:Place) described by a dct:Location that can be defined by an address (locn:Address) and/or a spatial representation by geometry (locn:Geometry). locn:Geometry defines the abstract concept and can be serialized in different formats as indicated in the Core Location ontology, e.g., using GeoSPARQL. A uiot:MobilityStation can be modelled as an aggregation of specialised uiot:MobilityStation for a specific service, using the uiot:includedInMobilityStation property.

Fig. 4.

Sharing mobility module detail.

Sharing mobility module detail.

5.3.Sharing mobility module

The Sharing mobility module (prefix uiots) defines classes and properties modelling the sharing mobility service providers, the vehicles for sharing and the sharing stations (acting as IoT devices), and the trips performed by the users. The concepts defined from the Sharing mobility module reuse and extend the Core module already described, which is imported from the ontology. The module is complemented with the definition of SKOS [16] vocabularies used in the ontology to describe: car supply, European emission standard, propulsion type, vehicle category, sharing mobility vehicle state, sharing mobility vehicle event, and dock state in sharing station.

Figure 4 presents the main classes and properties of the Sharing mobility module. In the considered domain, a service provider can be modelled as a uiots:SharingMobilityProvider (subclass of schema:Organization) which delivers one or more uiots:SharingMobilityService (subclass of schema:Service). A service provides users with a series of uiots:SharingMobilityVehicle which form a network of Urban IoT devices on the city soil, and they are subclasses of schema:Vehicle and uiot:ServiceResource. The vehicles can be used through the service in trip sessions (uiots:SharingMobilityTrip). The fee for using the service can be modelled as a uiots:SharingMobilityOffer which extends the modelling of schema:Offer allowing to define a fixed cost of the offer, and/or a trip cost per minute (uiots:pricePerTripMinute), and/or a cost per km traveled during the trip (uiots:pricePerTripKm). Service users are modelled as uiot:ServiceUser defined in the Core module. A uiot:ServicePrivateUser is associated with the uiots:SharingMobilityService she uses and to the uiots:SharingMobilityTrip made. A uiots:SharingMobilityService can also be associated with one or more uiots:SharingStation for the release/collection of vehicles. A uiots:SharingStation, specialisation of a uiot:MobilityStation, can in turn be modelled as an IoT device that emits data on the station state and, therefore, as a subclass of sosa:Sensor. A uiots:SharingStation registers a uiots:SharingStationRecord, which is a uiot:SensorRecord that can aggregate a set of uiots:DockRecord if a physical infrastructure made of uiots:Docks exists. A uiots:SharingMobilityVehicle is an IoT device that registers a series of uiots:SharingMobilityVehicleRecord. A uiots:SharingMobilityVehicleRecord is a uiot:SensorRecord and it is associated with the timestamp of collection, to the recording sensor, to the current vehicle state (skos:Concept in sh-kos:vehicle-state), to the latest vehicle event registered (skos:Concept in sh-kos:vehicle-event), and to a series of sosa:Observation composing the record.

Fig. 5.

Electric mobility module detail.

Electric mobility module detail.

5.4.Electric mobility module

The Electric mobility module (prefix uiote) defines classes and properties modelling the electric mobility service providers, the charging infrastructure and the charging stations (acting as IoT devices), and the charging sessions performed by the users.

Figure 5 presents the main classes and properties of the Electric mobility module. The concepts defined in the Electric mobility module reuse and extend the ones in the Core module which is imported from the ontology. The module also re-uses other external vocabularies and, in particular, Mobivoc33 exploiting its comprehensive plug types modelling. The Electric mobility module is complemented by the definition of the following SKOS vocabularies used in the ontology: charge access method, EVSE charge category, EVSE state, parking restriction, and power supply. This module defines two types of actors as non-disjoint subclasses of schema:Organization: the uiote:ChargePointOperator referring to the actor operating the charging stations (uiote:ChargingStation), and the uiote:eMobilityServiceProvider managing the charging service for the users. In case both roles are performed by the same organization, a unique individual would be defined as instance of both subclasses. A uiote:ChargingService (subclass of schema:Service) is a charging service managed by a uiote:eMobilityServiceProvider. The uiote:ChargingService makes available specific uiote:ChargingStation operated by uiote:ChargePointOperators. The offer for the Electric mobility module is represented by uiote:ChargingServiceOffer which is a subclass of schema:Offer and it is associated with a charging service. It can also be directly associated with a uiote:ChargingStation and it represents an offer for occasional users using the station without being registered to any charging service.

A charging station (uiote:ChargingStation) is both a uiot:ServiceResource, that can specify also an owner (uiote:hasChargingStationOwner) and a sub-operator managing it (uiote:hasSubChargePointOperator), and a uiot:MobilityStation, that can be described through a dct:Location and/or specifying nearby facilities (uiote:hasFacilityNearBy). Inside the charging station several charging columns (Electric Vehicle Supply Equipment, modelled as uiote:EVSE) are included. For each uiote:EVSE at least one connector (uiote:Connector) is associated, describing the available plugs and cables to charge a vehicle. A uiote:EVSE is an IoT device and can, therefore, be modelled as a sosa:Sensor emitting uiot:EVSERecord. An uiot:EVSERecord is associated with the timestamp of collection, to the current EVSE state (skos:Concept in el-kos:EVSE-state), and to any additional sosa:Observation enriching the record.

6.Urban IoT ontology evaluation

To complement the description of the Urban IoT ontologies we report general statistics about the different modules developed, and we discuss the evaluation of the modules considering pitfalls detected by automatic scanning tools and well-established ontology evaluation criteria.

Table 2

Statistics for the implemented ontologies – core module (uiot), sharing mobility module (uiots) and electric mobility module (uiote) – and additional SKOS thesauri – concept schemes related to sharing (sh-kos), vehicles (vh-kos) and electric (el-kos)

uiotuiotsuiotesh-kosvh-kosel-kos
Classes244213
Datatype Properties312920
Object Properties413930
Named Individuals185383733
Concept Schemes354
SKOS Concepts353328

6.1.Ontology statistics

Table 2 reports the main ontology statistics computed using the Ontometrics tool [15]. It lists the number of classes, datatype properties, object properties, named individuals for each module, and the number of concept schemes, SKOS concepts, named individuals for the SKOS thesauri.

Analysing the modules with a OWL2 profile checker34 the developed ontologies conformed to the OWL2 DL and OWL2 RL profiles.35

6.2.Pitfalls detection

To detect pitfalls in the Urban IoT ontologies, we leveraged the automatic scanning utility provided by the OOPS! tool [21]. The resulting reports are made available in the repository36 and identify no critical issues, but only important and minor pitfalls. The automatic scanning allowed us to identify and fix oversights that could not be easily detected by hand. In particular, we added missing annotations (rdfs:label or rdfs:comment), inverse relation axioms, and domain and range declarations.

The scanning of the final version of the modules only reports important pitfalls related to two specific design choices. The first one is related to the choice of not importing in the modules the re-used vocabularies. Since many of them are quite large (e.g., Schema.org), and not directly bound to the considered domain, we decided to simply re-use the referenced entities via their IRIs. In some cases, to help in the usage of the ontology, we added also annotations to external classes and properties, e.g. adding rdfs:labels in Italian, and/or vann:usageNotes. The second design choice is related to the decision of not specifying disjoint axioms between sub-classes. In general, we decided to limit the use of logical axioms, preferring to specify intended usage of classes and properties through annotation and documentation, and leaving potential validation to the definition of shapes (e.g., using SHACL); indeed, we do not expect the intended users to exploit reasoning in their systems and analysis.

We also decided not to address the remaining minor pitfalls, e.g., inverse relations that we considered useless, and particular naming conventions in IRIs (e.g. uiote:eMobilityServiceProvider class).

6.2.1.Evaluation criteria

In this section, we discuss the different modules taking into account well-established criteria for ontology evaluation [28].

Accuracy The ontology development process was assisted by experts and stakeholders about the domain. Moreover, the different modules were designed using well established non-ontological and ontological resources described in Section 2, e.g., de-facto standards in the domains considered (GBFS, MDS and OCPI) and other ontologies developed in these domains (MobiVoc, Ciudades Abiertas, etc.).

Adaptability The ontology is divided into modules to facilitate its reusability and extensibility. For example, the core module was designed to easily allow the definition of new modules extending it to deal with other services and IoT devices in the urban area (e.g., intelligent parking lots, cameras, access gates, etc.). Moreover, in accordance with the municipality of Milan, and to facilitate the adoption of the ontologies also by other cities, we did our best to design the ontology without introducing any biased modelling decision.

Clarity The custom terms defined in all modules adopt the main terminology defined in the domains considered. A terminological alignment has been specifically carried out in the requirements validation phase with the support of the domain experts. To make the ontology terminology understandable for a broader audience, we decided to use English in the local name of the encoded IRIs of classes and properties, and to provide rdfs:label and rdfs:comment in both English and Italian.

Completeness A broad set of user stories and competency questions has been defined for the ontologies, interviewing different actors and investigating different aspects of the considered domains (as described in Section 4.2). After the encoding of the ontologies, we double-checked that every defined competency question could be defined and answered. In the repository a report of the performed validation activity37 is available. The document associates each competency question with the set of classes, properties and individuals needed to formulate SPARQL queries on actual data modelled using the ontologies.

Efficiency As commented, we decided to introduce only minor logical constraints as axioms in the ontology. As a result, enabling reasoning does not affect efficiency. Moreover, the modularity allows keeping the size of the different modules limited.

Conciseness In the domain analysis with domain experts, we clearly defined the scope boundaries determining the relevant elements in the considered domains. Moreover, in the encoding of the ontologies we re-used as much as possible already existing vocabularies when dealing with concepts not specifically related to the domain (e.g., CORE Location ontology for addresses and geometries, SOSA for sensors data, Schema.org for organizations, etc.). This has the double advantage of keeping the ontologies concise, while clearly stating and referring to a model to represent related data.

Consistency No inconsistency was found enabling reasoning (we used the HermiT reasoner v1.4.3.45638).

Organizational fitness The municipality of Milan acknowledged the deployability of the ontologies as the reference model for data that should be provided by service providers in the sharing and electric mobility domains. An additional evaluation will be performed when different providers will start to contribute their data using the proposed model and/or other municipalities will adopt the ontologies.

7.Urban IoT ontology publication and maintenance

The documentation and the hosting of the ontologies described are available on the GitHub pages of the Milan Municipality.39 The license adopted is the Creative Commons with Attribution right (CC-BY), which allows licensees to copy and distribute the work and make derivative works, giving the authors proper credits.

The content negotiation mechanism follows the best practices for publishing vocabularies/ontologies on the Web, in particular the Recipe 3 [5]. This recipe describes an extended configuration for a vocabulary with a hash namespace, setting the server to provide human-readable (HTML) or machine-processable (RDF) content from the vocabulary URI. We leveraged the WIDOCO tool [10] to generate the different representations of the ontologies, and the Vapour tool [4], a linked data validator, to identify and fix issues in the content negotiation mechanism.

As Linked Data web applications need stable identifiers, a permanent URL was requested to the Permanent Identifier Community Group and it is registered as http://w3id.org/urban-iot. The maintenance is supported by an issue tracker,40 which allows proposing additions/modifications/removal of use cases and user stories directly as GitHub issues. Such proposals are then evaluated by the team members and possibly implemented.

Listing 1.

SPARQL query for the competency question on sharing mobility dynamic data formulated in Table 1

SPARQL query for the competency question on sharing mobility dynamic data formulated in Table 1

8.Urban IoT ontology usage examples

This section exemplifies the intended usage of the presented Urban IoT ontologies. We first select some of the competency questions reported in Table 1 showcasing how they can be expressed using our ontologies and the SPARQL query language. Then, we present some usage examples by representing fictitious data through the ontologies as JSON–LD snippets.

8.1.Queries and competency questions

Hereafter, we discuss two SPARQL queries covering, respectively, a dynamic and a static data scenario. The complete set of SPARQL queries encoding the competency questions in Table 1 is made available as an external resource.41 Prefixes used in the queries are not reported to ease the readability, but they can be found in Fig. 2.

Considering dynamic data, we focus on the sharing mobility user story described in Table 1. Listing 1 defines a SPARQL query for the associated competency question: How many sharing service vehicles are currently unavailable due to breakdown, rebalancing, recharging, disposal?. To compose the query pattern, we ask for all the uiot:latestRecord associated with a uiots:SharingMobilityVehicle that are in an unavailable state. Then, we group the resulting uiots:SharingMobilityVehicleRecords using the uiot:latestSharingVehicleEvent to obtain different statistics for each possible event causing the unavailability of the vehicle.

Considering static data, we take the example of the electric mobility user story described in Table 1. Listing 2 defines a SPARQL query for the associated competency question: How many charging sessions are carried out by occasional users on a specific day for each charging station location?. To compose the query pattern, we ask for all the uiote:ChargingSession performed by an unregistered user. Then, we introduce a filter condition to consider only the sessions performed on the specific day of interest, and we access the data of the uiote:ChargingStation associated with the session to obtain its location. Finally, we group the results by the charging station identifier and position to obtain the desired aggregations.

Listing 2.

SPARQL query for the competency question on electric mobility static data formulated in Table 1

SPARQL query for the competency question on electric mobility static data formulated in Table 1

8.2.Usage examples

JSON–LD [24] allows annotating a JSON document to represent Linked Data. In the documentation of the Urban IoT ontologies, we decided to provide the usage examples in this format to help the service providers, often not familiar with RDF, in the definition of semantically annotated APIs according to the defined vocabularies. In the following paragraphs, we discuss some relevant examples, the complete set of examples can be found in the documentation of the different modules available online. The following examples are defined using the basic JSON–LD context made available in the repository.42

Listing 3 describes a fictitious SharingMobilityService, called Bike Milano, operating in the city of Milan. The described service is a station-based (uiots:allowsFreeFloating equal to false) bike-sharing (uiots:hasSharingMobilityCategory) service offered by an imaginary Bike Milano Provider. The example data also describe the basic price to use the service, which is 0.60 Euro for each trip minute. The description can be enriched with the encoding of the operation area (locn:Geometry) and other geometries describing the service.

Listing 3.

Usage example describing a mock uiots:SharingMobilityService in Milan

Usage example describing a mock uiots:SharingMobilityService in Milan

Listing 4 describes a hypothetical uiots:SharingStation associated with the Bike Milano sharing service described in Listing 3. The station is equipped with physical infrastructure (uiots:PhysicalSharingStation) and contains four uiots:Docks. The docks can be of different uiots:DockKinds that can be defined by the service provider to implement constraints on which dock can be used by a specific vehicle.43 In Listing 4, we describe only one of the dock, others can be similarly defined in the array. Moreover, the station is located within a uiot:MobilityStation.

Listing 4.

Usage example describing a uiots:SharingStation associated with the service described in Listing 3

Usage example describing a uiots:SharingStation associated with the service described in Listing 3

Listing 5 describes a fictitious status update for a uiote:ChargingStation. This type of data can be pushed regularly by charging stations and aggregated to make available the real-time status of charging stations in the city. In Listing 5, the latest uiote:EVSERecord of one EVSE in the charging station is reported describing the current uiote:EVSEState and the timestamp of the update. The description can be complemented by adding a similar record description for each EVSE in the charging station.

Listing 5.

Usage example describing a mock status update for a uiote:ChargingStation

Usage example describing a mock status update for a uiote:ChargingStation

9.Long-term impact

Engineering an ontology is only the first step in the journey for interoperability. We have reported here our effort to build this suite of Urban IoT ontologies and the process we followed to come up with this result. The long term goal, however, is the effective governance of all Urban IoT data flows, overcoming the heterogeneity of information sources with standardised interfaces and the definition of reference APIs for dynamic data exchange.

Indeed, the municipality of Milan has embraced this view for an urban digital ecosystem [6] that coordinates a multitude of different and possibly competing stakeholders, including the sharing mobility and electric charging service providers, adopting a coopetition [30] and API economy perspective. According to this vision, interoperability plays a pivotal role in the city data governance: this is why, for the last few years, the Milan city council has introduced the requirement for specific data provision in all the calls for tenders that the city service suppliers respond to. This means that, to supply sharing mobility and electric charging services, those actors are contractually bound to grant the municipality access to the data produced by their IoT devices and sensors. The ontologies presented in this paper are going to be the reference model for urban IoT data interoperability in Milan in the near future.

As illustrated throughout the paper, even if we started from the requirements of Milan municipality, the presented ontologies have wide applicability. We indeed addressed use cases and user stories with global relevance and we investigated and included concepts and abstractions coming from international standards and formats. That is why we believe that the impact of our urban IoT ontologies can be leveraged in any urban context.

With specific reference to sustainable mobility, we are also confident that our effort supports broader interoperability in the transport sector. There is a growing interest in multimodal travel solutions that integrate different transport modes and mobility solutions. The European Commission, for example, is promoting the setup of the so-called National Access Points (NAPs) to share transport-related data in all member states.

In this context, an ontological reference model can play a central role in the construction of a transport knowledge graph that integrates information from different providers [23], including sharing and electric mobility. This impact can be for example achieved with the adoption of an any-to-one centralized mapping approach [26], in which the Urban IoT global conceptual model allows for bilateral mappings between the specific formats used by the mobility stakeholders [7].

Finally, this semantic interoperability governance approach, with the setup of a digital ecosystem for data exchange, provides benefits not only to urban planners and managers but also to the mobility providers themselves. The rising concept of Mobility-as-a-Service (MaaS) requires stable and clear business agreements between different parties and the adoption of a reference conceptual model can facilitate the information exchange and, as a consequence, the combination of different services into unified offerings.

10.Conclusion and future work

In this paper, we presented the first version of the Urban IoT ontologies, developed to promote interoperability of the data exchange between service providers, operating IoT devices in the urban area, and municipalities. With the support of stakeholders and domain experts from the municipality of Milan, we carried out an ontology engineering effort to implement the initial modules to cover the domains of sharing mobility and electric mobility.

Following the consolidated Linked Open Terms methodology, we involved throughout the different phases fifteen domain experts to elicit and specify a comprehensive set of requirements. During the domain analysis, we considered a wide set of ontological and non-ontological resources: on the one hand, this helped us in analysing already existing data flows and standards at the international level; on the other hand, it fostered the re-use of existing vocabularies during the implementation. In the ontology requirement specification phase, we identified 7 use cases and 69 user stories, which then resulted in the definition of 136 facts and 87 competency questions.

The definition of a global graphical conceptual model, based on these requirements, allowed us to detect similar concepts and relations defining three interconnected ontology modules: a Core module to describe service providers, services, users, mobility stations, IoT devices and their status updates; a Sharing mobility module specialising the Core classes and properties in terms of sharing mobility services, sharing mobility operators, sharing stations, sharing mobility vehicles and trips; finally, an Electric mobility module specializing them in terms of charging point operators, e-mobility service providers, charging stations and charging sessions.

The resulting ontologies – published online according to the Semantic Web best practices – underwent a thorough evaluation, both manual and using automatic diagnosis tools, and we can affirm that we managed to guarantee accuracy, adaptability, clarity and completeness of the model. Since the original goal was to allow for a harmonised data exchange between the municipality and service providers, we offered a set of detailed usage examples and we discussed the impact resulting from their adoption to promote interoperability.

Together with the municipality of Milan, we already started disseminating this ontological effort both on the local territory and across Europe, to promote its broader adoption and validation.

In the future, we aim at validating the proposed Urban IoT ontologies by involving service providers in piloting activities for the provision of semantically annotated data to the municipality. Moreover, we would like to organise co-design meetings with citizens and potential third-party users to: (i) determine how data collected from sharing and electric mobility providers can be effectively made available and accessed by citizens, and (ii) gather ideas and additional use cases for the definition of added value services that could be built on top of these data. Last but not least, we aim at expanding the current set of modules of the Urban IoT ontologies, by conceptualising additional domains such as intelligent parking lots, surveillance cameras, access gates, etc.

Notes

2 2018 Revision of World Urbanization Prospects, cf. https://population.un.org/wup/.

18 Cf. for example the Italian profiles defined at https://github.com/italia/daf-ontologie-vocabolari-controllati.

42 The context is available at https://comune-milano.github.io/ontologie-iot-urbani/docs/urban-iot-context.jsonld. To facilitate the reading of the examples, the JSON–LD snippets in this paper contain a placeholder (urban-iot-context.jsonld) as @context. All the examples can be edited, viewed or converted to other formats using the JSON–LD Playground already initialised with the correct context at the following link https://tinyurl.com/yy3abvss.

43 To complement the description of this constraint, each uiots:SharingMobilityBicycle associated with the service should be bound to the uiots:DockKind that it can use.

Acknowledgements

We would like to thank all the domain experts involved in the shaping of the Urban IoT suite of ontologies and, in particular, Matteo Massenzio and Alessio Cannizzaro from SIAD – Comune di Milano, who supported us in all the steps of this work.

References

[1] 

D. Androcec, M. Novak and D. Oreski, Using Semantic Web for Internet of things interoperability: A systematic review, Int. J. Semantic Web Inf. Syst. 14(4) (2018), 147–171. doi:10.4018/IJSWIS.2018100108.

[2] 

R. Battle and D. Kolas, Enabling the geospatial Semantic Web with Parliament and GeoSPARQL, Semantic Web 3(4) (2012), 355–370. doi:10.3233/SW-2012-0065.

[3] 

M. Bermúdez-Edo, T. Elsaleh, P.M. Barnaghi and K.L. Taylor, IoT-lite: A lightweight semantic model for the Internet of things, in: 2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), IEEE Computer Society, 2016, pp. 90–97. doi:10.1109/UIC-ATC-ScalCom-CBDCom-IoP-SmartWorld.2016.0035.

[4] 

D. Berrueta, S. Fernández and I. Frade, Cooking HTTP content negotiation with vapour, in: Proceedings of 4th Workshop on Scripting for the Semantic Web (SFSW 2008), CEUR Workshop Proceedings, Vols 368, CEUR-WS.org, 2008. http://ceur-ws.org/Vol-368/paper3.pdf.

[5] 

D. Berrueta, J. Phipps, A. Miles, T. Baker and R. Swick, Best practice recipes for publishing RDF vocabularies, Technical Report, W3C, 2008, Accessed July 2020.

[6] 

I. Celino and A. Carenini, Towards a semantic city service ecosystem, in: Proceedings of the Fifth Workshop on Semantics for Smarter Cities a Workshop at the 13th International Semantic Web Conference (ISWC 2014), Riva del Garda, Italy, October 19, 2014, CEUR Workshop Proceedings, Vol. 1280, 2014, CEUR-WS.org, pp. 3–8, http://ceur-ws.org/Vol-1280/paper7.pdf.

[7] 

M. Comerio, A. Carenini, M. Scrocca and I. Celino, Turn transportation data into EU compliance through Semantic Web-based solutions, in: Joint Proceedings of the 1st International Workshop on Semantics for Transport and the 1st International Workshop on Approaches for Making Data Interoperable co-located with 15th Semantics Conference (SEMANTiCS 2019), Karlsruhe, Germany, September 9, 2019, Vol. 2447, CEUR-WS.org, 2019. http://ceur-ws.org/Vol-2447/paper6.pdf.

[8] 

L. Daniele, F.T.H. den Hartog and J. Roes, Created in close interaction with the industry: The smart appliances REFerence (SAREF) ontology, in: Formal Ontologies Meet Industry – 7th International Workshop, FOMI 2015, Berlin, Germany, August 5, 2015, R. Cuel and R. Young, eds, Proceedings, Vol. 225, Springer, 2015, pp. 100–112. doi:10.1007/978-3-319-21545-7_9.

[9] 

ETSI TS 103 410-7: SmartM2M; Extension to SAREF; Part 7: Automotive Domain, 2020, Technical Specification, ETSI, 2020, [Accessed July 2020]. https://www.etsi.org/deliver/etsi_ts/103400_103499/10341007/01.01.01_60/ts_10341007v010101p.pdf.

[10] 

D. Garijo, J. Geluk, M. Scharm, A. Ruiz-Iniesta, kartgk, A. Serafini, M. Poveda-Villalón, O. Corcho, M.A. Garcia, M. Lefrançois and J. Schneider, WIDOCO 1.4.13: Linking evaluation in documentation, Zenodo, 2020. doi:10.5281/zenodo.3605675.

[11] 

A. Haller, K. Janowicz, S.J.D. Cox, M. Lefrançois, K. Taylor, D.L. Phuoc, J. Lieberman, R. García-Castro, R. Atkinson and C. Stadler, The modular SSN ontology: A joint W3C and OGC standard specifying the semantics of sensors, observations, sampling, and actuation, Semantic Web 10(1) (2019), 9–32. doi:10.3233/SW-180320.

[12] 

S. Interface, Specification (SENSORIS) v. 1.1.1, Technical Specification, 2020, ERTICO – ITS Europe, 2020, [Accessed July 2020]. https://sensoris.org/presentations/.

[13] 

K. Janowicz, A. Haller, S.J.D. Cox, D.L. Phuoc and M. Lefrançois, SOSA: A lightweight ontology for sensors, observations, samples, and actuators, J. Web Semant. 56 (2019), 1–10. doi:10.1016/j.websem.2018.06.003.

[14] 

N. Kolbe, S. Kubler, J. Robert, Y.L. Traon and A.B. Zaslavsky, Towards semantic interoperability in an open IoT ecosystem for connected vehicle services, in: Global Internet of Things Summit, GIoTS 2017, Geneva, Switzerland, June 6–9, 2017, IEEE, 2017, pp. 1–5. doi:10.1109/GIOTS.2017.8016229.

[15] 

B. Lantow, OntoMetrics: Putting metrics into use for ontology evaluation, in: Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2016) – Volume 2: KEOD, Porto, Portugal, November 9–11, 2016, SciTePress, 2016, pp. 186–191. doi:10.5220/0006084601860191.

[16] 

A. Miles and S. Bechhofer, SKOS simple knowledge organization system reference, W3C recommendation, 2020, W3C, 2009, Accessed, http://www.w3.org/TR/skos-reference.

[17] 

Netherlands Knowledge Platform for Public Charging Infrastructure, Open Charge Point Interface (OCPI), 2020, [Online; version 2.2-d2 accessed July 2020]. https://github.com/ocpi/ocpi/releases/tag/2.2-d2.

[18] 

North American Bikeshare Association, General Bikeshare Feed Specification (GBFS), 2020. [Online; version 2.1-RC accessed July 2020]. https://github.com/NABSA/gbfs/blob/v2.1-RC/gbfs.md.

[19] 

Open Mobility Foundation, Mobility Data Specification (MDS), 2020, Online; version 1.0.0-rc1 accessed, https://github.com/openmobilityfoundation/mobility-data-specification/releases/tag/1.0.0-rc1.

[20] 

A. Perego, M. Lutz and P. Archer, ISA Programme Location Core Vocabulary, 2015. https://www.w3.org/ns/locn.

[21] 

M. Poveda-Villalón, A. Gomez-Perez and M.C. Suárez-Figueroa, OOPS! (OntOlogy pitfall scanner!): An on-line tool for ontology evaluation, International Journal on Semantic Web and Information Systems 10 (2014), 7–34. doi:10.4018/ijswis.2014040102.

[22] 

J.A. Rojas, P. Morlion, H. Tambuyzer, W. Baert, P. Colpaert and R. Verborgh, Velopark: A linked open data platform for bicycle parkings, in: Current Trends in Web Engineering – ICWE 2020 International Workshops, KDWEB, Sem4Tra, and WoT4H, Revised Selected Papers, Helsinki, Finland, June 9–12, 2020, Vol. 12451, Springer, 2020, pp. 53–64. doi:10.1007/978-3-030-65665-2_6.

[23] 

M. Scrocca, M. Comerio, A. Carenini and I. Celino, Turning transport data to comply with EU standards while enabling a multimodal transport knowledge graph, in: The Semantic Web – ISWC 2020 – 19th International Semantic Web Conference, Proceedings, Part II, Athens, Greece, November 2–6, 2020, Vol. 12507, Springer, 2020, pp. 411–429. doi:10.1007/978-3-030-62466-8_26.

[24] 

M. Sporny, D. Longley, G. Kellogg, M. Lanthaler, N. Lindström and P.-A. Champin, JSON-LD 1.1 – A JSON-based Serialization for Linked Data, 2020, W3C Recommendation, W3C, Accessed July 2020, https://www.w3.org/TR/json-ld11/.

[25] 

P. Vandenbussche, G. Atemezing, M. Poveda-Villalón and B. Vatant, Linked open vocabularies (LOV): A gateway to reusable semantic vocabularies on the web, Semantic Web 8(3) (2017), 437–452. doi:10.3233/SW-160213.

[26] 

G. Vetere and M. Lenzerini, Models for semantic interoperability in service-oriented architectures, IBM Systems Journal 44(4) (2005), 887–903. doi:10.1147/sj.444.0887.

[27] 

M.P. Villalón, A.F. Izquierdo and R.G. Castro, Linked Open Terms (LOT) Methodology, Zenodo, 2019. doi:10.5281/zenodo.2539305.

[28] 

D. Vrandecic, Ontology evaluation, in: Handbook on Ontologies, International Handbooks on Information Systems, Springer, 2009, pp. 293–313. doi:10.1007/978-3-540-92673-3_13.

[29] 

M. Yoo, P. Kolyvakis, D. Kiritsis, D. Werthmann and R. Hellbach, Semantic model for IoT-enabled electric vehicle services: Puzzling with ontologies, in: 4th IEEE International Conference on Future Internet of Things and Cloud, FiCloud 2016, Vienna, Austria, August 22–24, 2016, M. Younas, I. Awan and W. Seah, eds, IEEE Computer Society, 2016, pp. 387–392. doi:10.1109/FiCloud.2016.61.

[30] 

M. Zuccalà and I. Celino, Fostering innovation through coopetition: The E015 digital ecosystem, in: Engineering the Web in the Big Data Era – 15th International Conference, ICWE 2015, Rotterdam, The Netherlands, June 23–26, 2015, Proceedings, Vol. 9114, Springer, 2015, pp. 625–628. doi:10.1007/978-3-319-19890-3_44.