Knowledge-Based Smart City Service System

Abstract

A smart city can be defined as a city exploiting information and communication technologies to enhance the quality of life of its citizens by providing them with improved services while ensuring a conscious use of the available limited resources. This paper introduces a conceptual framework for the smart city, namely, the Smart City Service System. The framework proposes a vision of the smart city as a service system according to the principles of the Service-Dominant Logic and the service science theories. The rationale is that the services offered within the city can be improved and optimized via the exploitation of information shared by the citizens. The Smart City Service System is implemented as an ontology-based system that supports the decision-making processes at the government level through reasoning and inference processes, providing the decision-makers with a common operational picture of what is happening in the city. A case study related to the local public transportation service is proposed to demonstrate the feasibility and validity of the framework. An experimental evaluation using the Situation Awareness Global Assessment Technique (SAGAT) has been performed to measure the impact of the framework on the decision-makers’ level of situation awareness.

1. Introduction

As the term smart city gains wider and wider popularity, there is still confusion about what a smart city really is, and many different definitions have been proposed so far. In [1], Bakıcı et al., envision a smart city as a high-tech intensive and advanced city that connects people, information, and city elements through new technologies, with the aim of creating a sustainable, greener city, competitive, and innovative commerce, and an increased life quality.

Making a city smarter is a long and complex process since it requires deep innovation for all kinds of city infrastructures as well as of the habits of citizens and institutions. Several actors are thus involved: Governments, multinational companies, small- and medium-sized enterprises, universities, and research centers. In this context, public institutions must be the hub that connects and coordinates all these players. Along with this process, a smart city needs to face many daunting challenges, like crowded traffic, waste management, energy consumption, safety, and security, with the aim to make effective use of its resources and improve the life quality of its citizens [2,3,4]. To deal with this increasing complexity, a holistic approach to the management of the city is needed, as also suggested by Hidayat et al., in [5], in order to manage, adapt, and optimize all the services the city offers to its citizens. Recently, a vision of the smart city as a system of services is taking place [5,6]. In such a vision, the service is the underlying concept of a smart city: It is the element of interaction between the different stakeholders (citizens, government, organizations, etc.) and enables the development of the city via a mechanism of value co-creation. Indeed, the focal point of such a vision relies on the co-creation of value due to the direct involvement of the citizens in the processes of service development and delivery. According to Polese et al. [6], the value co-creation in the city is mainly achieved via the exchange of knowledge. Such a knowledge exchange is practically implemented by data sharing between citizens and city. The information sharing enables a virtuous circle in which the more data are shared, the better services can be provided; the more services are provided, the more data are produced. The resulting explosion of generated data represents a formidable asset for the city, if properly managed.

In this work, we propose a vision of the city according to the service science theory from a knowledge engineering perspective. The main contributions of this paper are hence as follows:

• A definition of a conceptual and technological framework, namely, the Smart City Service System (SCSS), which embeds all the principles of the service science in the smart city;
• A discussion of data sharing within the city infrastructure as the main element for bringing smartness to the city;
• A first, prototypical solution implementing the conceptual framework.

The implementation of the framework requires the adequate acquisition, representation, and management of the data created and shared within the city, while respecting the privacy of its citizens and organizations. Thus, adopting a knowledge engineering perspective, we defined an ontological model sustaining the entire framework. The ontological model, together with the technological infrastructure, provides the city government and decision-makers with a holistic, integrated view of the city. This common operational picture grounded on the city’s knowledge supports and increases the situation awareness of the decision-makers regarding the city dynamics. The situation awareness (SA) is the capability of understanding what is happening in a given environment so as to be able to predict its future evolution [7]. Having a good situation awareness is the key element for making good decisions. Our ontological framework aims at supporting the inference processes that make easier to have a deep comprehension of the situation and to predict its evolution, which is the prerequisite for making good decisions, thus leading to good governance of the smart city.

The framework is evaluated in two ways. First, a case study related to the Local Public Transportation (LPT) service is proposed to demonstrate the technical feasibility of the SCSS and to highlight the main advantages of this holistic vision of the city. Second, we evaluate the improvement in the situation awareness gained by the decision-makers when using the proposed framework in the context of a road transport company that shares its data with the city. We use the Situation Awareness Global Assessment Technique (SAGAT) [8], one of the most used methodologies, to objectively measure the level of situation awareness.

The rest of the paper is structured as follows. Section 2 analyzes the related works. Section 3 describes the conceptual framework of the Smart City Service System. Section 4 introduces the ontological model that sustains the framework. Section 5 presents the case study and the evaluation with SAGAT. Section 6 concludes the paper with some final remarks and future works.

2. Related Works

Considering the increasing and unprecedented level of urbanization along with the consequent challenges and opportunities, it comes with no surprise that the smart city field is attracting more and more researchers, as it is evident by the high number of publications and books on this topic [9]. In this section, we focus on two categories of related works: Those introducing a vision of a smart city as a service system and those proposing ontological approaches for sustaining the development of a smart city, considering that these are the two main topics of the framework.

Polese et al. [6] recently proposed a framework that conceptualizes the smart city as a service system in line with the recent service theories. The framework identifies the most adequate organizational layout to foster resources exchange, value co-creation, and co-learning. Although the conceptual vision of the smart city is similar to the one proposed in this paper, we also put forward a technological view of the smart city as a service system and enable it via an ontological model. Hidayat et al. [5] propose a vision of the smart city as a service system too. The authors adopt a system engineering perspective to define architecture based on microservices for the implementation of the smart city as a service system. Such an approach is quite interesting and can be considered as complementary to our framework. Indeed, the perspective of the authors is more oriented to the real deployment of the services in the city, whereas our approach is more focused on the data representation and exploitation in order to sustain the government and decision-making processes, regardless of the services that have produced or consumed such data. Another service-oriented reference architecture for the smart city is the one proposed by Clement et al., in [10], which encapsulates different aspects of the service-oriented approach in the already existing systems of a city, in order to support the organic growth of the smart city. An interesting and widely-adopted approach is the one proposed by IBM in [11], which gives a comprehensive view of a smart city highlighting its main foundations. Specifically, it recognizes the role of data coming from heterogeneous sources for the optimization of city services. The city is thus foreseen as a set of domains (water, energy, transport, etc.) that usually work separately. Such domains should be interconnected at the city control level and at the decision level in order to have an integrated view of the city itself. Based on this vision of the city, in this work we consider such a model from a service science perspective, especially with the introduction of the concept of the value co-creation, and we extend and enable it by means of an ontological model.

Many approaches foresee the use of ontological models as a means to overcome the interoperability issues between different services and technologies used in the smart city and to support knowledge representations and exploitation. Espinoza-Arias et al. [12] realized a comprehensive survey of the main ontological models for smart city data. The authors observed that, despite the high number of proposed ontologies, many of them are not available or not well-documented and therefore cannot be easily reused. Other ontologies, instead, are models adapted to specific needs, which makes it difficult to increase the interoperability among such models and other ones as well as the applicability of these models to other cities. In order to find ontologies for a smart city, specialized ontology catalogs are available. In particular, the smartcities.linkedata.es catalog [13], developed in the READY4SmartCities EU FP7 project, collects ontologies about smart cities, energy, and related fields. Most of the available ontologies are specific to one or few domains. Another interesting ontology catalog for the smart city is the Linked Open Vocabularies for Internet of Things (LOV4IoT) [14], which mainly contains ontologies for the Internet of Things that can also be used in the context of a smart city. A critical analysis of these and other catalogs for smart city has been proposed by Saint-Eitenne et al., in [15].

Some authors have proposed the use of ontological models for the Internet of Things as the main model for representing smart city data [16,17,18]. It is the case of the FIESTA-IoT [19], the Sensor Cloud Ontology [20], the SEAS ontology [21], and the VITAL ontology [22]. Other ontologies are related to one or few smart city domains, like STAR Ontology [23] which proposes an ontological model for traffic; the BIM ontology for the buildings [24]; or ontology for the transportation network [25].

An ontological model that seems quite general to be applied to different cities is the Km4City ontology [26]. This model has been developed in the context of the KM4City research project. As also observed by Espinoza-Arias et al. [12], it is the model that covers the highest number of domains and specifically administration, city objects, event, public services, topology, measurements, and sensors, by integrating different existing ontologies. In this work, we consider the Km4City ontology as the main model. We extend this ontology with other models to cover further important aspects of the Smart City Service System framework, as detailed in Section 4.

3. Knowledge-Based Smart City Service System: The Conceptual Framework

The Smart City Service System (SCSS) is a conceptual framework that considers the smart city as a service system in accordance with the Service-Dominant Logic (SDL) theory. This means that it is a “configuration of people, technologies, organizations, and shared information, able to create and deliver value to providers, users, and other interested entities, through services” [27]. Coherently with the principles of the SDL [28,29] and service science [30], the focus of the SCSS is on the co-creation of value achieved through the collaboration and participation of all actors of the smart city, that is, citizens, governors, stakeholders, and organizations. For instance, let us suppose that the citizens anonymously share some of their personal data with the city (e.g., their agenda); the organizations collect such data to optimize their services (e.g., organizing events according to the commitments of the citizens); the city can offer personalized services according to the events scheduled by the organizations and to the needs of the citizens; as a result, the citizens will receive an improved service, thanks to the data they shared. As underlined in this example, the co-creation of value in the SCSS leads to a virtuous circle: As more data are shared by the actors of the SCSS, better services can be offered to the community and better decisions can be made at the government level. As better services are offered to the city and its stakeholders, more information will be generated by the actors, thus leading to new improved services, and so on. All the data should be collected, represented, managed, and put at the disposal of the different entities that require it to provide services and make decisions, by always respecting the privacy of all the actors. The privacy of the actors can be preserved by anonymizing all the data and by working only on aggregated data that cannot allow the identification of a single actor. Data sharing is achieved via two main elements: (i) An infrastructure that enables data collection from the different actors and that makes it available to the different operating centers of the city (e.g., water control center; transportation command and control room, etc.) and to the highest decisional level (e.g., to the government of the cities); and (ii) a shared data model that enables the integration of all the information produced in the city. To enable a holistic view of the city, there is a need for [11]:

• Instrumentation that is able to capture live real-world data through sensors (both digital and virtual), personal devices, applications, cameras, smartphones, web, etc.;
• Integration of the information obtained by the instrumentation across multiple processes, systems, and organizations;
• Intelligence, which means the use of complex analytics, modeling, optimization, and visualization to improve the decision-making processes.

As pointed out by Harrison et al., in [11], these three foundational concepts enable all the services in the SCSS to be adapted to the behavior of the inhabitants, thus leading to the optimal use of resources and infrastructures.

Figure 1 proposes a conceptual view of the SCSS framework, which is obtained by extending the model of the smart city proposed in [11], relied on the principles of the SDL and service science and consisting of the three foundational concepts aforementioned. At the basis of the model, we have the individuals that work and live together in families, communities, enterprises, which are labeled as organizations. Individuals and organizations belong to the city and act in it, producing data, offering, and consuming services. The city is also composed of (limited) resources that allow vital services to be offered to the citizens. IBM [11], as well as other authors, identify these as city domains. Specifically, each city should have at least five domains: Water, energy, transportation, public safety, and buildings. Each of these domains has its rules, its operations, its services and poses different challenges. According to this, each domain has its own operational systems that allow for performing the required peculiar operations (e.g., water distribution, bus lines scheduling, etc.). At the top of each domain, there is a control and operation center, specific to that domain, in which the resources are controlled, the operations are managed, the services are configured and monitored, and the decisions are made. However, to achieve a comprehensive view of the city, as foreseen by the SCSS framework, the different domains and operational and decisional systems should be interconnected and integrated. This interconnection can be realized at the managerial level thanks to the integration and correlation of the data produced in each specific domain. At the top of the domain-specific control center, there is a cross-domain operation center. Here the integrated information is analyzed to provide a common operational picture that represents the current situation of the city. Such a situation can be identified by means of inference and classification processes applied to all data coming from the domain-specific control center. It is the capability to integrate heterogeneous data and to show only the relevant information that adds value to the decision-making process. This allows the governors, policymakers, and decision-makers to identify trends that can help predict future situations and to make coherent and informed decisions for improving the smart city, thus offering new services and realizing innovative projects. Such activities need to be sustained by an integrated view of the available data. Let us underline that the individuals share their data with the city via the organizations in which they act. This level of indirection allows to further anonymize the data shared with the city. Indeed, the organizations may decide to share only aggregated data with the city. Another important aspect is that part of the data of the organization could be already public or generally available to everyone, and therefore no new privacy issues emerge in those cases. For instance, if we consider the case of a university as an organization, there are data regarding the individuals (professors, students, staff) that are already public: Information on exams and the number of participants; date and participants to board meeting, etc. Such information can be easily shared with the city, without harming the privacy of the individuals, but with enormous advantages from the perspective of improved services for the university and the city. Another example of organizations can be restaurants or cinemas. Such organizations do not have to share information on their customers, but only aggregated information, as the number of current customers or potential reservations. This could help the city in tailoring some public services, like the optimization of public transport or energy management.

Consequently, the practical implementation of the SCSS conceptual framework poses some technological challenges that should be addressed.

The first challenge is the need to foster information sharing to support and increase the growth of knowledge within the city. The information is produced and shared via the use of services and systems. Such services and systems produce data in heterogeneous formats. Furthermore, different services may use the same symbol to represent a completely different concept, leading to problems of interpretation of its meaning. In such cases, interoperability issues between the services and the systems of the city arise that can be adequately addressed by defining a shared data model. In the next section, we propose the use of an ontological model to address the aforementioned challenges.

4. An Ontology-Based Implementation of the Smart City Service System

The Smart City Service System (SCSS) conceptual framework is implemented as an ontology-based system supporting decision-making processes at the tactical and strategical levels through reasoning processes applied to data shared by citizens and organizations. In this case, ontologies are used to deal with the heterogeneity of data [31] and, therefore, to overcome the syntactical and semantic interoperability issues. In particular, the definition of an ontological model supports the integration of data coming from different sources with different data formats. Furthermore, if compared to traditional data models like relational databases, an ontological schema has the undoubted advantage of being easily extended to encompass new concepts and properties when needed. This flexibility is needed to support the rapid development of new services. Lastly, having a formal and shared representation of the data allows us to execute reasoning processes in order to sustain data-driven decision-making, as shown in the case study in Section 5.1.

The proposed ontology-based system supports the entire service system through the three main processes depicted in Figure 2: (i) the gathering process $\mathsf{\Theta }$; (ii) the reasoning/classification process $\mathsf{\Gamma }$; and (iii) the decision-making process $\Delta$.

The gathering process $\mathsf{\Theta }$ performs the acquisition of data generated by the actors of the service system (e.g., citizens, organizations, sensors, information systems, etc.). Specifically, each actor $A_j\in A,j=(1\dots n)$ shares its data within the city in order to receive some customized services back. Often the actors belong to some kind of organization (e.g., the sensors of a building; the workers of an enterprise; etc.). In this case, the data can be shared within this organization, which can use, anonymize, and aggregate it and then can decide to share (part of) the data with the city to get back some services. Thus, the gathering process can be split into three phases:

• $\mathsf{\Theta }.1$: Each actor $A_j\in A$ shares its data with the organization $O_k\in O,k=(1\dots m)$ to which it belongs. A set of instruments is used to produce and gather the data, such as physical sensors, information systems, web, applications, etc.;
• $\mathsf{\Theta }.2$: Each organization $O_k\in O$ receives the data and may filter it (e.g, it can clean data, filter sensitive data, etc.) and then shares the data. The data is represented as a set of variables $v_u\in V,u=(1,\dots ,z)$;
• $\mathsf{\Theta }.3$: Each variable is mapped to a specific concept of the ontological model. A mapping function is used to map each variable to one of the classes, properties or values of the ontological model. The obtained semantic data are stored in the city data layer.

The reasoning/classification process $\mathsf{\Gamma }$ is applied to the data contained in the city data layer, elaborates and classifies the data therein contained, and infers new knowledge. The process consists of three phases:

• $\mathsf{\Gamma }.1$: Retrieving and extracting the data from the city data layer;
• $\mathsf{\Gamma }.2$: Processing the extracted data and classify/cluster the data in different classes $C{l}_p\in Cl,$$p=(1\dots t)$;
• $\mathsf{\Gamma }.3$: If needed, further processing the data of each class using ontology reasoning. For instance, the data of class $C{l}_p$ can be further split into subclasses $S_l\in S,l=(1\dots q)$.

Both in $\mathsf{\Gamma }.2$ and $\mathsf{\Gamma }.3$, ontology reasoning (e.g., based on Description Logic) and rule-based reasoning (e.g., based on SPARQL/SPIN (https://www.w3.org/Submission/spin-overview/) and SWRL (https://www.w3.org/Submission/SWRL/) can be used. This process of classification and reasoning identifies the current situations of the environment. These situations determine the cross-domain operational picture, which highlights the correlation and integration of relevant data coming from the different domain-specific operation centers. A suitable visualization of such data is crucial for improving the level of awareness of the decision-makers, but such kind of visualization depends on the specific decision-making tasks.

Finally, the decision making process $\Delta$ processes the data inferred by process $\mathsf{\Gamma }$ to provide the decision-makers with suitable visualizations (e.g., trends, graphs, tabular data, etc.) that make evident the current situation of the smart city. The $\Delta$ processes can be different according to the specific decisions that should be made. In any case, it is possible to identify at least three phases for such a family of processes:

• $\Delta .1$: Some tasks are performed on the subclasses S identified by the process $\mathsf{\Gamma }$ (e.g., count elements, compute statistical measures, find specific events, make a recommendation to the decision-makers, etc.)
• $\Delta .2$: The decision-makers evaluate the results of $\Delta .1$ to make a decision;
• $\Delta .3$: The decision-makers complete their decisions and perform some actions that will cause changes in the SCSS (e.g., modification of some services, delivery of new services, etc.) that should be visible by the actors and organizations that have shared their data in process $\mathsf{\Theta }$.

4.1. The Knowledge Representation Model

The ontological model at the heart of the SCSS framework contains the semantic representation of the main elements of a smart city (e.g., infrastructures, administration, services, physical objects, locations, events, etc.), thus enabling a cross-domain view of the smart city.

The model has been defined using the NeOn [32] methodology for ontology engineering. NeOn is a scenario-based methodology for building ontologies based on the reuse of available knowledge resources, both ontological and non-ontological resources. The methodology consists of nine scenarios for building ontologies and some methodological guidelines for performing processes and activities of ontology engineering. Specifically, we refer to Scenario 3 “Reusing Ontological Resources”and Scenario 5 “Reusing and Merging Ontological Resources”for building the SCSS ontological model. This choice is also driven by the principle of reusing existing schemas, which is vital to the realization of a new ontology aimed at also supporting the Linked Data (http://linkeddata.org/) initiative. Indeed, it recommends reusing rather than redefining new ontological concepts to implement a vision of an integrated semantic space. Following NeOn Scenario 3, we perform the subsequent activities.

4.1.1. Activity 1: Ontology Search

Many candidate ontological resources exist in the context of smart cities. The EU FP7 project Ready4SmartCities has collected a set of ontologies about smart cities (http://smartcity.linkeddata.es/). However, many such ontologies are too specific and are usually related to just one domain (e.g., energy, water, or building). The others, instead, are too generic and can be defined as Upper Ontologies, like DOLCE [33] and SUMO [34], and so they cannot be directly used to represent a smart city. The most promising ontologies for our purposes are the SCRIBE Ontology [35] defined in the context of the IBM Smarter Planet project and the Km4City [26], which describes different domains of a city and the services they offer. However, since neither ontologies are sufficient in itself to represent the elements of the SCSS conceptual framework, we also selected a set of more specific ontologies, like ontologies for sensor networks (SSNO), services (OWL-S), events (EventOntology), and time (OWL Time). All the selected ontologies have been evaluated and compared in the following activities.

4.1.2. Activity 2: Ontology Assessment

In this activity, we have analyzed the ontologies found in the previous phase and discarded the ones that did not satisfy the requirements of the SCSS framework. Specifically, we discarded the ontologies that were either too specific (representing only one domain, or a specific city), and the ones that were too broad in their scope, like the upper ontologies. Specifically, we discarded the ontology SUMO and DOLCE. Moreover, we considered if the available ontologies are service-oriented, as this is an important requirement for the conceptual framework. This means that the ontologies should have the concepts necessary to represent the services offered by the city.

4.1.3. Activity 3: Ontology Comparison

The ontologies selected in the previous phase were compared. Some ontologies were discarded due to the low quality of the model, as well as in terms of the clarity of the code and documentation, which makes difficult their reuse. Specifically, in this phase, we decided to discard the SCRIBE ontology, since it seems no longer supported/developed and not clearly documented.

4.1.4. Activity 4: Ontology Selection

The ontologies to reuse were selected. Specifically, we selected Km4City as the ontology for representing the main elements and services of a smart city; EventOntology (http://motools.sourceforge.net/event/event.html) to represent the events, extending the representation of events defined in Km4City; OWL-S [36] to support the description of services; and SSNO [37] to extend the representation of sensors and sensor data.

4.1.5. Activity 5: Ontology Integration

The different ontological resources were integrated. In the case study (see Section 5.1), further details about the integration are reported.

Since the selected ontologies have some common concepts and relationships, the integration has not been always straightforward. For this reason, we adopt the Scenario 5 “Reusing and Merging Ontologies”of the NeOn methodology to merge the different ontological schemas in case of overlapping. This scenario foresees two activities: (i) Ontology alignment, wherein similar concepts of two ontologies are aligned; and (ii) ontology merging, wherein the alignments made in the previous activity are merged to obtain novel resources.

A high-level, conceptual view showing the main modules of the ontological model with their alignment is depicted in Figure 3. The Km4City ontology consists of six modules: Administration includes classes related to the public administrations; Street represents the road system of the city; Transportation includes classes related to the local public transport like buses, companies, time schedules; Time represents the temporal aspects of events and services extending the OWL-Time ontology; Sensor represents data gathered by sensors like pollution, weather, and traffic; and Point of Interest includes all services, activities, and elements of the city (like monuments and buildings), useful for citizens [38]. The SSNO ontology was integrated for representing sensing devices and observations. Although Km4City has a module representing sensors, we decided to import SSNO because this scheme is much more detailed, allowing us to describe a sensing device in detail (together with the platform and deployment information) with information regarding the observations and the measurement procedures. The ontological model also includes the OWL-S [36] ontology to describe services in terms of their interface (e.g., input, output, and conditions), the process implementing the services, and the implementation details. Lastly, we aligned the module point of interest of Km4City with the EventOntology. This ontology enables the description of events (e.g., concerts, sports events, and exhibitions) hosted in the city. It adds temporal information to the events, which instead is missing in the point of interest module of the Km4City ontology.

The defined model contains the main concepts which are sufficiently generic for being used in every smart city. In case of specific services that a city could offer, the ontology can be extended using the NeOn methodology. In Section 5.1, we present a case study in which the ontology has been extended and instantiated to support services able to adapt the local transportation schedules to fit with the personal calendars of the worker of an organization.

5. Evaluation

The evaluation of the SCSS is accomplished using three different approaches. First, in the next subsection, we present an illustrative example related to a case study in the Public Transportation domain. The scope of the case study is to demonstrate all the capabilities of the SCSS framework in a realistic scenario for supporting decision-making processes. Then, the ontology of the SCSS framework is evaluated with a well-known ontology evaluation approach, namely OOPS! (OntOlogy Pitfall Scanner) [39], in Section 5.2.

Lastly, we evaluated the capability of the SCSS framework of supporting the decision-making processes by improving the situation awareness of the decision-makers. Specifically, we implemented a system for the management of a fleet of vehicles which is based on the SCSS framework. The system gathers and processes data collected from the vehicles in order to identify critical situations and provide the decision-makers with a common operational picture of the traffic in the city. The system is used to measure the improvement in the levels of SA of a group of decision-makers who have been involved in the experiment. The SAGAT methodology [40] has been used to measure the SA.

5.1. Case Study: Local Public Transportation

The Local Public Transport (LPT) is one of the most important services in a smart city. A high-quality, efficient LPT system is the only answer to the increasing transport demand that major cities are facing [41]. In this case study, we show how a holistic view of the city provided by the SCSS framework, sustained by the ontological model, can support the real-time adaptation of the LPT service according to the needs of the citizens. This leads to different advantages: A more efficient and thus cheaper LPT system, a less congested road system, reduced pollution, and more satisfied citizens.

The scenario is the following. The citizens of a smart city share their personal e-calendars with the city. This does not mean that everyone can see the e-calendar of a citizen, but that the shared data are anonymized and aggregated in order to support decisions on a government level. The aggregated calendar data provides a huge amount of realistic and updated information regarding the movements of thousands of people. We use such data to adapt the LPT system, by adding or removing transportation means, or by modifying the timetable/routes of buses/trams/trains to fulfill the needs of citizens.

In this scenario, we suppose that there is a concert in the city. By aggregating the calendar data about the participants, it is possible to optimize the LPT service to allow people to reach the concert venue and to come back (for instance, by adding some buses or modifying the timetable). More formally, let J be an event hosted in the place Y. By analyzing e-calendars $C_j,j=(1,\dots ,N)$ of each person $P_j,j=(1,\dots ,N)$, the aim is to approximately estimate how many people are going to the event J from a given starting point $X_i$, with $i=(1,\dots ,L)$. To this aim, the city is divided into L cells, each containing a starting point $X_i$. The city transportation officer would like to know which public transportation lines are more overloaded and thus which lines’ schedules must be strengthened due to the event J.

5.1.1. Gathering Process

The gathering process $\mathsf{\Theta }.1$ collects the e-calendars data by the organizations $O_k$ to which the citizens belong to (e.g., the company they work for). The organizations clean up the sensitive information and transmit only the aggregated and anonymized information to the City Data Layer (phase $\mathsf{\Theta }.2$). The data shared by the organizations is mapped to the ontological model (phase $\mathsf{\Theta }.3$). The mapping of the data regarding the event and the e-calendars with the classes of the ontology is shown in 

Table 1. Mapping between variables and ontology classes performed in process $\mathsf{\Theta }.3$.

Variable	Class
Event J	event:Event
Place Y	km4c:Place
Place $X_i$	km4c:Place
Organization $O_k$	foaf:Organization
Person $P_i$	foaf:Person
Calendar $C_i$	ecal:ECalendar

.

The ontology classes for representing the e-calendars are not present in the selected ontologies for the SCSS framework. Since we do not find a suitable ontology for the e-calendar that satisfies all the requirements of this case study, we defined a new ontological model for representing the e-calendar, whose main classes and properties are depicted in Figure 4. An e-calendar is represented by the class ecal:ECalendar and is linked to its owner via the property ecal:hasCalendar whose domain is foaf:Person. The Ecalendar class is a sub-class of owls:Service class since it is considered as a service used by the citizens. The e-Calendar is made by days, represented as instance of a class ecal:Day. The property ecal:onThe links the ecal:Ecalendar to the different days of which it is made. Each day consists of several items, which are the appointments and tasks the person has added to his/her calendar. Each item is an instance of the ecal:ECalendarItem, and the property ecal:hasCalendarItem links the instances of days with the calendar items. Its reverse object property is ecal:refersToDay. The calendar item may have an event connected to it, as depicted in Figure 5. This information is represented by the property ecal:hasEvent which has ecal:ECalendarItem as domain and event:Event as the range. The inverse property is ecal:isLinkedToECalendarItem. An event can take place in a specific location, which is described by the property schema:location with domain Event and range Place. The inverse property is ecal:hosts.

5.1.2. Classification Process

The classification process $\mathsf{\Gamma }$ starts with capturing the information linked to each e-calendar available in the City Data Layer (phase $\mathsf{\Gamma }.1$), limited to the time span of interest (e.g., the current day, the next week). Phase $\mathsf{\Gamma }.2$ exploits the retrieved information in order to infer new knowledge. In order to deduce how many people are going to the event J, we add a new class EventOfInterest as a subclass of Event. In the case study, this represents the event of interest J. Next, we define a class GoingToJwhich will contain all citizens $P_i$ that are going to the event of interest. To this aim, GoingToJ is obtained via the following class restriction, defined in Description Logic (DL):

$$\begin{array}{cc}\hfill GoingToJ\equiv & (\exists hasEvent.EventOfInterest)\hfill \\ \hfill & \sqcap (\exists refersToTheDay.DayOfInterest)\hfill \end{array}$$

(1)

This means that GoingToJ contains all the e-calendars items linked to some individuals of the EventOfInterest class via the object property hasEvent and that what happens on the day of the event J is represented by DayOfInterest. The following illustrative example shows how this restriction can be used to automatically classify the item of the e-calendar as belonging to the class GoingToJ.

Let $ci1$, $ci2$ be two individuals of the ECalendarItem, as depicted in Figure 6 defined using Protégé (https://protege.stanford.edu/). Both items are linked to the event $e_j$ but in different days: $ci1$ on 12 November, and $ci2$ on 13 November. Only 12 November is an individual of the DayOfInterest class. The result of the reasoning process is depicted in Figure 7. Only c1 is correctly classified as an individual of GoingToJ class.

In phase $\mathsf{\Gamma }.3$, we define the subclasses $S_i,i=(1,\dots ,L)$ where $S_i$ contains all the instances belonging to GoingToJ leaving form the starting point $X_i$ to reach the event place Y. It is reasonable to suppose that the starting point of each person which would like to attend J is the place of the previous e-calendar item with respect to the item related to the event of interest J. For this reason, first we identify the e-calendar item prior to GoingToJ using the object property ecal:next which links an e-calendar item to the subsequent, by means of the following class restriction:

$$PreviousECalendarItemForJ\equiv (\exists next.GoingToJ).$$

(2)

Continuing with the previous illustrative example, we consider other two e-calendar items, $ci3$ and $ci4$. The item $ci1$ comes next to the item $ci3$, while $ci2$ next to $ci4$, as depicted in Figure 8. After the reasoning process, only the item $ci3$ is classified as an individual of PreviousECalendarItemForJ, according to Equation (2), since it comes before an item that has been classified as an individual of GoingToJ.

The place where the previous e-calendar item happens should be identified, as this is assumed to be the starting point $X_i$ to reach the event place Y. To this aim, a subclass of Place is defined, namely StartingPointForJ. The starting points can be defined by the following class restriction:

$$\begin{array}{c}\hfill StartingPointForJ\equiv \\ \hfill (\exists hosts.(\exists isLinkedToTheECalendarItem\\ \hfill .PreviousECalendarItemForJ\left)\right).\end{array}$$

(3)

The starting points are identified by considering the places that host some events and that are linked to the e-calendar items belonging to the PreviousECalendarItemForJ.

Considering again the previous example. We add an event $e1$ to the individual $ci3$. The event $e1$ takes place in the location $x1$, specified with the property schema:location. According to the restriction of Equation (3), the location $x1$ is classified as StartingPointForJ (as depicted in Figure 9), since the item $ci3$ is the previous item of the $ci1$, which was classified as GoingToJ.

The classification process is ended by constructing the subclasses $S_i,i=(1,\dots ,L)$ and by giving them the names ComingFromX1, ComingFromX2, etc. The SPARQL query in Listing 1 defines L classes, each one named $X_i$, $i=(1,\dots ,L)$, constructed as subclasses of StartingPointForJ and populated by adding the Place instance $x_i$ as its individual.

Listing 1. SPARQL query to define the locations X_i.

CONSTRUCT {

 km4c:Xi rdfs:subClassOf

  km4c:StartingPointForJ.

 ?xi rdf:type km4c:Xi

}

WHERE {

 ?xi km4c:hasID xsd:Xi

}

Lastly, the ComingFromXi classes, where $i=(1,\dots ,L)$, is defined as a subclass of GoingToJ and by the following class restriction:

$$\begin{array}{cc}\hfill ComingFromXi\equiv (\exists & hasPreviousECalendarItem.\hfill \\ \hfill & (\exists hasEvent.(\exists location.Xi\left)\right))\hfill \end{array}.$$

(4)

It contains the e-calendar items whose previous e-calendar items have some events linked to places belonging to the X1 class. Returning to the previous example, the individual $ci1$ is classified as $ComingFromX1$ as depicted in Figure 10 according to Equation (4).

5.1.3. Decision-Making Process

Figure 11 depicts the decision-making process supported by the SCSS framework in the case study. Phase $\Delta .1$ receives as input the subclasses $S_i$ classified by the process $\mathsf{\Gamma }$ and produces as output some recommendations to the officer regarding the optimization of the LPT system. Specifically, Figure 11 shows a detail of this phase.

First, in phase $\Delta .1.1$, the number of individuals of each subclass $S_i$ is determined. Moreover, the number of individuals coming from $Xi$ to the event is added to the location Xi with the datatype property km4c:hasNumber with the query in Listing 2.

Listing 2. SPARQL query to define the number of individuals coming from X_i to the event.

CONSTRUCT {

 km4c:xi km4c:hasNumber ?no_calendaritem.

}

WHERE{

 SELECT (COUNT(?calendarItem)

       AS ?n_calendaritem)

 WHERE{

    ?calendaritem rdf:type

            km4c:ComingFromXi.

 }

}

In $\Delta .1.2$, for each starting point $Xi$, the best routes to the destination Y both by car and by LPT are identified and the fastest route is identified. If it is by car, a message is sent to the officer to let him know about the lack of public service related to that route. Each local public transportation path is represented as an individual of the LPTPath class that we have defined in the ontological model depicted in Figure 12. A path is available for a specific day and in a specific time slot. Moreover, a path is made of different sections that connect two points/stops (e.g., two bus stops). In this way, it is possible to know which sections are more crowded, for which stops are needed more transportation means, and so on.

Accordingly, in $\Delta .1.3$, for each selected LPT path, the number of individuals that will use that path (computed by using the values calculated in $\Delta .1.1$), together with the time slots in which the path will be used, is determined. In $\Delta .1.4$, the potential traffic flow that will overload each considered LPT path is considered. If a line will be overcrowded due to the potentially high number of citizens that will use it to reach the event, a recommendation is sent to the traffic officer.

Lastly, in phase $\Delta .2$ the officer evaluates each recommendation regarding the paths that are overloaded and decides if some modifications regarding the routes and the schedules should be made. If this is the case, the decisions are applied to the city service system (in phase $\Delta .3$) by means of some specific actions that will reach the LPT through the operational systems of the city and through the transportation domain pillar (see Figure 1).

This illustrative case study showed that the ontological model is a powerful asset that could be used to enable a service system vision of the smart city. The flexibility, together with the formal representation of data, given by the ontology, allowed us to easily implement other kinds of adapting services, both in specific city domains as well as cross-domain services. The data shared by the citizens, in this case through their e-calendars, could be exploited both at the organization and city level, to better the services offered by the city. This co-creation of value is the lever that the governing bodies should use to make a city really smarter and able to face the daunting challenges of modern society.

5.2. Ontology Evaluation with OOPS

The definition of an ontology is an iterative and incremental process. Multiple iterations are needed in order to obtain a stable and complete model for the considered domain. In all these iterations, it is important to validate the ontology in order to identify and possibly correct eventual pitfalls and errors. Many different approaches and tools have been proposed to validate ontological models, like generic quality evaluation framework [42,43,44], approaches based on criteria and metrics [45], or based on patterns [46].

To validate the ontological model for SCSS defined using the NeOn methodology, we adopted the OOPS! approach (OntOlogy Pitfall Scanner) [39]. The OOPS! approach consists of a catalog of common bad practices of the ontology building process. It also consists an online tool (http://oops.linkeddata.es/) that automatically detects most of them. Such a catalog of bad practices has been used both to revise the defined ontological model during its definition and to finally evaluate the model. However, we observed that the methodological guidelines of the NeOn methodology are useful to avoid incurring such pitfalls. For instance, the careful alignment and integration of the ontologies, foreseen by NeOn, ensures that no equivalent classes between ontologies are missing, which is one of the most common pitfalls in ontology engineering. Thanks to this approach, the only pitfalls identified by OOPS! are related to the existing ontologies that we have integrated. Specifically, the pitfall “P07 Merging different concepts in the same class”, is due to some classes of the Km4city ontology, like Tatoo_and_Piercing; Weapons_and_ammunition, and UtilitiesAndSupply. However, these classes are not used very often in the context of the SCSS, thus this is not a serious pitfall. The same happens for the pitfall “P11 Missing domain or range in properties”. Among all the properties, just three object properties have only the range defined, and four properties have both the domain and range missing. These seven properties belong to the imported ontologies and are useless in the SCSS model.

5.3. Evaluation of the Situation Awareness Using SAGAT

In this section, we measured the improvement of the Situation Awareness (SA) of the decision-makers thanks to the proposed Smart City Service System framework. We evaluated the situation awareness of the decision-makers rather than the effects of their final decisions. An improvement in the SA supports decision-makers in reaching better decisions [7]. In fact, the SA is the main prerequisite for a correct and coherent decision: It is not possible to make a good decision without a complete understanding of what is happening in the observed environment [47].

The Situation Awareness Global Assessment Technique (SAGAT) [8] was adopted to measure the SA during real-time simulations. SAGAT has been proved to be one of the most reliable and objective technique to measure SA [40]. SAGAT evaluates the SA across three levels: Perception, comprehension, and projection. This methodology foresees the execution of an experiment involving the users of a system. A number of multiple-choice questions were posed during each trial with the system to measure the three levels of SA of each participant. Each question was submitted to the participant by freezing the system during the trial to probe the real-time situation awareness. Each question aimed at probing one of the three levels of SA. The percentage of correct answers gave an indication of the SA gained by the participants on each of these three levels.

5.3.1. Experimental Setting

The SAGAT methodology requires that the participants use a system in order to effectively measure the SA in a real environment. In each trial with the system, the participant has a goal to achieve by completing a given task. For this experiment, we designed and implemented a prototypical system based on the Smart City Service System framework. It is a Decision Support System (DSS), used by logistic managers to monitor and control a fleet of goods transport vehicles. The dashboard of the DSS is depicted in Figure 13. The DSS gathers data from multiple sources like vehicles, drivers, traffic services, weather forecasting services, and the management information system. The aim is to support the logistic manager in reducing cost and environmental impact of the transportation. Further details on this system are in [48,49].

In this experiment, we used the data gathered by the DSS to provide the city governors with an operational picture of the traffic in the city. According to the SCSS framework, the data gathering process $\mathsf{\Theta }$ collects all the data through the instrumentation and maps such data to the ontologies of the city data layer. In the reasoning process $\mathsf{\Gamma }$, starting from data of the city data layer, we used SPARQL and SWRL rules to identify the current situations [48]. In the decision process $\Delta$, the situation identified in the previous step was used to show only the relevant information to the city governors.

The experiment was conducted by involving 15 people (10 men and 5 women, with an average age of 31 years ± 7). They have been trained for using the system. To probe the effectiveness of the framework in terms of SA, we designed and implemented two versions of the system: Mode A) the DSS does not show the results of the inference of the reasoning process $\Delta$ on the data gathered from the organization, which means that we are not using the capabilities of the SCSS framework and mode B) the DSS shows all the results of the inferences applied on the data gathered from the organization, which means that we are using the capabilities of the SCSS framework. In such a way, we can compare the difference in the SA of the participants under the two modalities and thus evaluate the advantage given by the SCSS framework used in mode B. The goal of the subject is to optimize the routes of the trucks by considering the current traffic conditions, weather, road works, and destinations of the trucks. At a random time the system will freeze and a question is presented to the subject in order to probe his/her SA. The subject answers the SAGAT questions by recalling information from the system, like the current position of the trucks, the condition of the traffic, etc. After a short time interval (usually 10 s), the question disappears and the simulation continues. The questionnaire consists of 15 questions, with different questions for each SA level. After the experiment, the percentage of correct answers is calculated for each SA level and each modality.

5.3.2. Results

Table 2. Mean correct rates, with Standard Deviations (SD), of SAGAT questions under the two modalities: (A) Without inference and no collected data and (B) with inference on collect data.

	Mode A Mean % (SD%)	Mode B Mean % (SD%)
SA Level 1	70.52 (13.88)	82.47 (9.24)
SA Level 2	68.13 (13.62)	78.27 (10.39)
SA Level 3	64.73 (19.73)	78.07 (9.56)
SA Overall	67.79 (11.19)	79.60 (5.27)

shows the correct rates of SAGAT questions under the two versions of the system. In the table, M is the mean value of correct answers, and SD is the standard deviation, in percentage. The correct rates are reported according to each level of SA and as overall SA (given by the mean on the three levels). It is evident the advantage given by the exploitation of the data collected by the SCSS framework and used to support the decision making processes, at all the levels of SA, with an average increase of the SA of 12 percentage points, and up to 14 points at level 3 of SA (projection). This is particularly important for deciding since level 3 SA gives the capability of anticipating what will happen in the given environment to anticipate the most correct decision.

Analysis of Variance (ANOVA) was used to evaluate the difference between the two versions of the system on the three levels of SA. The results showed that the difference in using the mode B of the system was significant. Indeed, at SA level 1, the F-test statistic $F(1,28)=7.69$ with significance probability $p=0.01$; at SA level 2 $F(1,28)=5.25$ with $p=0.03$; and at SA level 3 $F(1,28)=5.55$ with $p=0.025$. This sustains our hypothesis that the use of the SCSS could support the situation awareness assessment of the users of a system in complex decision-making tasks.

6. Conclusions

The Smart City Service System (SCSS) defines a city as a complex system of services that demands a holistic view of all its components (i.e., citizens, organizations, infrastructures, and services) to face the increasing challenges of modern cities. The framework emphasizes the key role of value co-creation enabled by the data sharing among citizens and organizations. This supports the definition of new kinds of services for the city and the citizens, thus leading to better use of resources. The SCSS relies on an ontological model defined using the NeOn methodology by integrating existing ontologies, that allows for the rapid development and adaptation of the services by exploiting the data shared by the citizens. A case study related to the local public transportation system demonstrated the validity of the approach and the easiness of exploiting the available data for adapting critical services within the city. An experiment conducted with SAGAT showed the capability of the framework to improve the SA of the decision-makers as well. This supported our hypothesis that a holistic view of the city using a knowledge engineering perspective is useful for supporting the government of this complex system. The ontological model is a valid approach to support the representation and exploitation of the knowledge generated within the city, which is currently the most valuable resource of a smart city. Ontologies are however not exempt from drawbacks. One of the main disadvantages is related to the computational aspects: Reasoning processes may require a long time to be completed and this may be incompatible with the pace at which data is generated within the city. Furthermore, the ontology engineering is a time-consuming process that involves both domain experts and knowledge engineers.

In future works, we will explore semi-automatic approaches for the ontology definition through machine-learning techniques able to extract useful patterns (e.g., association rules) that can be used to enhance the ontology with additional knowledge [18,50]. Inspired by Hidayat et al. [5], we will also investigate the use of the microservices paradigm as valid architecture for the deployment of the main processes of the framework. Lastly, one of the main issues that needs to be considered when deploying systems that collect data from citizens and organization, is to take care of their privacy. We are already working on improving the anonymization features of data-gathering processes with great attention to privacy issues. Moreover, regarding the proposed case study of Local Public Transportation, we are implementing a personal calendar in which citizens can explicitly decide which kind of events they want to share with the organization they belong to (providing their explicit consent to share their data, according to the current regulations and laws on privacy) and which one they want to maintain as private.