Urban IoT ontologies for sharing and electric mobility

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 worldwide33 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),44 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 project55 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,66 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.77 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) consortium88 as city stakeholders. The JSON specifications of the models are based on the FIWARE Data Models99 and were developed taking into account also the IoT Big Data Harmonised Data Models developed by the GSM Association,1010 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 Generator1111 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.org1212 and a set of additional concepts defined in the Velopark Vocabulary.1313 Moreover, the Open Mobility Vocabulary1414 (MobiVoc) was reused. This ontology, developed with the support of industrial partners, is mainly based on Datex II,1515 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)1616 group of the European Commission ISA2 Programme on Interoperability for public administrations. The defined e-Government Core Vocabularies1717 include the following modules: Location, Business, Person and Public Organisation. Each of these vocabularies can be further specialised through the definition of national profiles.1818 The Location [20] module offers a generic abstraction for geographical data that can be implemented using the well-adopted GeoSPARQL [2] and Basic Geo Vocabulary1919 based on WGS84.

It is also worth mentioning the ongoing Ciudades Abiertas2020 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 system2121 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.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.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,2222 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,2323 as well as from their previous efforts to generate Linked Open Data.2424

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, SharingCities2525 defining useful scenarios and KPIs, and eMoticon2626 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.

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,2727 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. 2828

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.

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.3030

Fig. 2.

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 Ontology3131 and the Dublin Core3232 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.

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.

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.

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, Mobivoc3333 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.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 checker3434 the developed ontologies conformed to the OWL2 DL and OWL2 RL profiles.3535

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 repository3636 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).

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.4141 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

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.4242

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

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.4343 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

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