Building IoT based applications for Smart Cities: How can ontology catalogs help?

Abstract

The Internet of Things (IoT) plays an ever-increasing role in enabling Smart City applications. An ontology-based semantic approach can help improve interoperability between a variety of IoT-generated as well as complementary data needed to drive these applications. While multiple ontology catalogs exist, using them for IoT and smart city applications require significant amount of work. In this paper, we demonstrate how can ontology catalogs be more effectively used to design and develop smart city applications? We consider four ontology catalogs that are relevant for IoT and smart cities: READY4SmartCities, LOV, OpenSensingCity (OSC) and, LOV4IoT. To support semantic interoperability with the reuse of ontology-based smart city applications, we present a methodology to enrich ontology catalogs with those ontologies. Our methodology is generic enough to be applied to any other domains as is demonstrated by its adoption by OSC and LOV4IoT ontology catalogs. Researchers and developers have completed a survey based evaluation of the LOV4IoT catalog. The usefulness of ontology catalogs ascertained through this evaluation has encouraged their ongoing growth and maintenance. The quality of IoT and smart city ontologies have been evaluated to improve the ontology catalog quality. We also share the lessons learned regarding ontology best practices and provide suggestions for ontology improvements with a set of software tools.

I. Introduction

The Internet of Things (IoT) aims at interconnecting surrounding devices (e.g., thermometer) to the Internet in order to send and process data generated by them [1]. The report from Gartner¹ predicts that more than 20 billion devices, also called Things, will be in use in 2020. IoT plays an ever increasing role in enabling Smart City applications. Smart city infrastructures are expensive to design, create, deploy, and maintain. Interoperability is key to reduce cost, and is needed at multiple levels, including (1) the system, (2) architecture, (3) workflow to process IoT data, (4) applications and services, and (5) reasoning on data. A semantic approach, especially one that is enabled by the use of relevant ontologies, can help deal with the variety associated with IoT and relevant complementary data types, and support interoperability. However, there are multiple ontology catalogs that are relevant to IoT and smart cities, which in turn presents the challenge of selecting the proper catalog and ontologies.

Consider Spain’s Santander² smart city initiative that deployed more than 20,000 sensors to measure air quality, monitor parking spaces, manage electricity, optimize garbage collection, and regulate light intensity [2]. Smart city applications rely on the efficient utilization of data generated by these devices and cover a variety of domains such as water management and irrigation, healthcare, transportation, energy management, resource (e.g., parking space) utilization, etc. Those applications are redesigned continuously in various cities (e.g., parking availability applications, bike sharing availability applications). For example, the CityPulse project listed 101 applications³ and analyzed tens of them [3]. Those applications are frequently redesigned exploiting similar datasets. Smart city datasets are available on open source data portal platforms such as Comprehensive Knowledge Archive Network (CKAN)⁴. Such platforms encourage to reuse datasets and even link them with each other to follow Linked Data principles [4]. The main shortcoming of such portals is the lack of links between the datasets and the data model used to structure datasets. Reusing ontologies designed for smart city applications would increase semantic interoperability between systems and cities and could reduce development time of applications. For this reason, cities such as Santander are integrating semantic web technologies as already demonstrated in the context of the FIESTA-IoT EU 2020 project⁵ [5]. In France, more and more cities are releasing open data generated by sensors. OpenSensingCity⁶, a project funded by the French National Resaerch Agency (ANR), aims at unifying those datasets with the usage of semantic web technologies. For instance, we organized a hackathon⁷ to use datasets from five cities (Paris, Lyon, Nantes, Rennes, and Strasbourg) on different domains (pollution, weather, parking space, and bike availability) to build smart city applications.

This paper advocates the use of semantic web technologies for better data interoperability and integration in smart city applications. Ontologies allow developers to reuse and share application domain knowledge using a common vocabulary across heterogeneous systems, platforms, environments, etc. [6]. There is also a real need to encourage best practices when developing ontologies, in particular: (1) reusing existing ontologies as much as possible, and (2) aligning the ontologies to increase interoperability by reducing heterogeneity issues across models and to reduce development time.

Given that ontologies underpin semantic web technologies, an early step to consider is identifying a relevant ontology for reuse if one exists. Ontology is a set of concepts and categories in a specific domain to explicitly describe relationships between them [7]. Arumugam et al., in 2001, is one of the pioneering works encouraging on finding the most relevant set of ontologies for a given need [8].

In a more contemporary scenario, we advocate the reuse of models by investigating the usage of ontology catalogs, with a focus on OWL-based ontologies due to its broad adoption since it became a World Wide Web Consortium (W3C) recommendation in 2004.

The Semantic Sensor Networks (SSN) ontology [9] is one of the first initiatives to support semantic interoperability of data generated by sensors or devices. SSN became a W3C recommendation in October 2017⁸, extending and improving the SSN ontology published in 2011 [10]. However, there are some limitations such as real-time aspect and a lack of a taxonomy (i.e., a scheme of classification). There is a need of a taxonomy to classify measurement units, context, quantity kinds (measurement type such as temperature) and services provided by devices to expose sensor data. For this reason, developers still design new ontologies for their need to develop smart city applications. We could take inspiration from the software engineering communities providing online code sharing environment. Correspondingly, we could build an ontology catalog environment to encourage the reuse of the ontologies, not only the design but also their implementations by releasing the code online. To the best of our knowledge, the surveys regarding ontology catalogs do not report recent work and are not comprehensive for the IoT and smart city research field [11].

Ontology catalogs applied to the IoT and smart city domain are relevant for three user categories: (1) application developers to find, choose and reuse the ontologies that might fit their needs, (2) ontology developers to publish and share their ontologies for promoting reuse, and (3) developers and maintainers of the ontology catalogs.

A. Research Challenges

We address the following Research Challenges (RC):

• RC 1: Which methodologies can assist ontology developers in reusing existing IoT and smart city ontologies?

• RC 2: What methodology would help choose the ontology fitting our needs among a set of similar ontologies?

• RC 3: How the state of the art analysis could be shared in an innovative way to reduce the learning curve of investigating, studying and classifying it?

• RC 4: How to efficiently analyze exiting IoT and smart city ontologies?

• RC 5: What would be the set of criteria and best practices to compare ontologies and ontology catalogs?

• RC 6: How can developers collect the set of ontologies relevant for IoT and smart cities?

• RC 7: How can ontology designers stay updated with the latest ontologies designed for smart cities?

• RC 8: How could we guide developers and ontology engineers to evaluate ontologies?

B. Main Contributions

We enumerate our contributions. Each contribution is matched to the RCs presented above. Further, each contribution is matched to specific sections in the paper. The contributions and the novelty of this paper are as follows:

1. Designing ontology catalogs for smart cities: OpenSensingCity and LOV4IoT ontology catalogs address challenges RC 1, RC 3, RC 4, and RC 7 and are introduced in Section III.

2. A set of criteria and relevant tools to improve the quality of ontologies (explained in Section VI) addresses challenges RC 2, RC 5 and RC 8. Additional dissemination regarding semantic web methodologies, best practices and recommendations is needed to go beyond the IERC Cluster Semantic Interoperability Best Practices and Recommendations (IERC AC4) [12] by suggesting and integrating ontology quality tools.

3. A methodology to enrich ontology catalogs (explained in Section V), implemented within LOV4IoT, addresses the challenge RC 6.

4. The comparison of four ontology catalogs for IoT and Smart Cities (Ready4SmartCities, LOV, LOV4IoT and OpenSensingCity) explained in Section III addresses the challenge RC 6.

5. An analysis of most relevant ontologies for smart cities (Section IV) addresses the challenge RC 3.

6. An evaluation with users to evaluate the LOV4IoT catalog (explained in Section VI-C) addresses the challenge RC 8.

C. Structure of the Paper

The rest of the paper is structured as follows: Section II investigates related work of semantics-based smart city projects and ontology catalogs. Section III compares existing ontology catalogs for smart cities. Section IV describes smart city ontologies. Section V focuses on the methodology to enrich ontology catalogs. VI evaluates the LOV4IoT ontology catalogs and the quality of ontologies and provides a use case. Section VII concludes the paper and Section VIII shares our vision regarding future work. The paper has an appendix section with all figures, code examples, tables, etc.

II. Related Work

We review the related work of semantics-based smart cities in Section II-A. Section II-B is dedicated to schema catalogs. A focus on surveys for IoT and smart city ontologies is explained in Section II-C. Section II-D introduces work regarding semantic interoperability. Section II-E concludes the limitation of the existing literature.

A. Semantics-based Smart City Projects

In this section, we review papers having the “smart city” keyword with an interest in integrating semantic web technologies. When the projects (CityPulse, KM4City, etc.) already designed the ontology, they are explained in Section IV-A.

Alkandari et al. provide a survey about smart cities [13]. However, we expect the classification of semantics-based smart city projects which is missing from the paper.

Zanella et al. design a proof-of-concept of the Italian Padova smart city [14]. The paper focuses on architecture, web services, data format (XML and EXI) but without employing semantic web technologies. It highlights heterogeneity issues (e.g., communications and devices) within the application layer, transport layer and link layer technologies from the OSI model. The paper highlights the main application domains for smart cities: (1) smart building, (2) waste management, (3) air quality, (4) noise monitoring, (5) traffic congestion, (6) city energy consumption, (7) smart parking, and (8) smart lighting. This paper demonstrates that smart city applications cover numerous domains.

SEN2SOC (SENsor measurements and SOCial interactions) project is based on the FP7 EU SmartSantander project which provides real sensor data. SEN2SOC integrates SmartSantander sensor data with social networks data (Twitter, Flickr, and Foursquare) [15] to add value to the data. The semantic data annotation is done on SmartSantander project side. The paper does not explain which ontologies are used for the semantic annotation neither referenced. Further, the real-time aspect is introduced, but no ontologies have been mentioned satisfying the real-time requirement. The work seems close to the “Cyber-Physical Systems (CPS)” research field, but the work is not compared with this research topic. Smart city applications such as heatmap for temperature have been build as a proof-of-concept.

Zhang et al. design a scalable framework to deal with variety, volume, and real-time data generated within smart cities [16]. The framework employs semantic web technologies combined with machine learning techniques. The semantics-based framework has been used for two use cases in smart cities: pollution detection and traffic pattern decision.

Open Agile Smart Cities (OASC)⁹ is an initiative towards designing a unified system for smart cities by focusing on: (1) a common API, (2) an open data platform, and (3) data models. This is precisely the focus of this paper: where can we find data models reusable for smart cities?

OntoPhil is an ontology matching algorithm specifically designed for smart cities [17] and had been evaluated with the Ontology Alignment Evaluation Initiative (OAEI) benchmark. OntoPhil is adapted to those requirements: modular ontology size and lightweight matching process. OntoPhil has also been used to match 39 agent ontologies that need to interact with the smart city SOFIA ontology. The main shortcoming of the work is that the ontology matching system has not been evaluated on smart cities ontologies, but with the ontologies from the OAEI initiative. It demonstrates the need for a benchmark for smart city ontologies.

Conclusion:

Finding existing semantics-based smart city projects and smart city ontologies is challenging and time-consuming. Mechanisms are missing to encourage the reuse and the evaluation of those ontologies. Frequently ontology must be improved before being able to load them with ontology quality or ontology matching tools. A deeper analysis of ontology for smart cities is done in Section IV¹⁰. This concise survey provides an overview of the main semantics-based smart city projects, but it is by no means comprehensive, as it is not the main focus of this paper.

B. Schema Catalogs

A survey of eleven ontology libraries from d’Aquin et al. was published in 2012 [11], including ontology libraries for domains other than IoT and smart cities. In our paper, we prefer to use instead the term ontology catalog. The survey from d’Aquin et al. does not mention any catalogs for IoT and smart cities, which makes the respective coverage (see Section III) a key contribution of this paper.

Ontology libraries are categorized as follows: (1) Purpose and coverage explains that ontologies can be limited to a particular domain and vary in size, and type of ontologies. (2) Library content explains how new ontologies are inserted within the library and what are the quality controls done before adding the ontology. (3) Size of the ontology library. (4) Ontology metadata provides ontology name, domain, creators, date of creation and modification, version, license, etc. In this paper, we count the number of ontologies referenced within each ontology catalog. We also encourage ontology metadata description to design automatic mechanisms such as discovery.

Schema.org is a schema catalog for use in structured data embedded in Web pages to describe locations, people, products, services, etc. [18]. The IoT Schema.org extension is under development¹².

BioPortal [19] is an ontology catalog for biomedical ontologies. It provides a friendly-user interface for users, and REST API for developers. Numerous functionalities are provided such as searching for a specific class, finding an ontology, and ontology statistics (the number of ontologies, the number of classes, etc.). BioPortal provides a set of tools: (1) Ontology Browser to browse the library of ontologies, (2) Search to look for a class in multiple ontologies, (3) Annotator to get annotations with specific ontologies, (4) Mapping between a selected ontology and all ontologies referenced within BioPortal, (5) Recommender for the most relevant ontologies, and (6) Resource Index to display all ontologies. Such ontology catalogs and its functionalities should be provided for smart cities and IoT. When we browse the BioPortal ontology browser with the “sensor’” keywords, only the SSN ontology is found. For the “IoT” keyword, 0 results are found.

AberOWL Repository¹³ references 570 biomedical ontologies [20].

WebProtégé¹⁴ is a collaborative ontology development tool which references ontologies that have been built with it [21]. WebProtégé provides functionalities to discuss and annotate ontologies. The critical requirement is to provide a simple way for users to make their ontology available on the Web so that other people can browse it without the need to install any software.

Ontology Design Patterns (ODPs)¹⁵ can be seen as a repository of ontologies [22]. Ontologies can be classified into the following categories: (1) Content ODPs, (2) Reengineering ODPs, (3) Alignment ODPS, (4) Logical ODPs, (5) Architecture ODPs, (6) Lexico Syntactic ODPs, and (7) Exemplary ODPs. It is hard to search for a specific keyword such as “city” or “IoT” to retrieve ontologies referenced within the catalog. For instance, a request done in October 2017 to look for the IoT domain returns only one ontology¹⁶.

Conclusion:

An analysis of IoT and smart city ontology catalogs has been lacking. Also missing is the lack of guidance regarding the demanding task of learning and reusing ontologies. In quite a few cases, the documentation is missing and not referenced within ontology libraries. We also expect the description of the methodology used to design ontology libraries, the way they have been automatized to update additional ontologies. A key contribution of this paper is to analyze four ontology catalogs (Ready4SmartCities, OpenSensingCity, LOV, and LOV4IoT) for IoT and smart cities (see Section III). These have not been studied in the ontology catalog/library surveys.

C. Existing Surveys for IoT and Smart City Ontologies

The Web of Things (WoT) [23] is considered as an extension of the IoT to easily send sensor data by exploiting Web technologies, and then exposing data to developers via websites and web services. Since sensor networks, IoT, and WoT technologies are considered as a basis to build smart cities, we introduce the existing surveys related to those topics in this section.

While the Semantic Sensor Networks (SSN) ontology specification [24] has been released as a W3C Recommendation in October 2017, several surveys related to sensor ontologies¹⁷ have used SSN as the basis. 23 ontologies have been compared: AEMET, aws, BCI, CF, DogOnt, Energy, iotlite, IoT-O, M3 Lite, OpenIoT, PEP-SSN Alignment, RAMI, SAN, SAO, SPITFIRE, VITAL, Geologic timescale IoT-O (SOSA), SAN (SOSA), FixO3, SEAS-SSN Alignment, and LSO Trajectory. Those ontologies have been compared according to the following criteria: (1) Imports SSN/SOSA, (2) Observations, (3) Actuations, (4) Samplings, (5) Features of Interest and Properties, (6) Results, (7) Procedures, and (8) Systems and their Deployments.

Further details regarding the survey of sensor ontologies can be found on the W3C SSN documentation. It is the continuation of the SSN ontology work published in 2012 [9]. A deep analysis of sensor ontologies¹⁸ has been done to build the SSN ontology V1 in 2012 explained in [25].

Within Szilagyi et al.’s survey [26], published in 2016, the authors design their own semantic web stack for IoT. The stack is interesting but not enough explained. Further, it seems the architecture is an extension from Barnaghi et al. [27] and Serrano et al. [28], but it is not clearly explained. An IoT namespace is introduced in the paper without mentioning where it originates: from an existing ontology or from their own. The paper does not provide an in-depth analysis of existing ontologies.

A survey on IoT ontologies from Bajaj et al. was published on ARXIV [29] in July 2017. An analysis of IoT ontologies as a classification of ontologies has been done and mainly focused on IoT ontologies since 2012 (after the first release of W3C SSN). They classified ontologies in the following categories: (1) sensor ontologies, (2) context-aware ontologies, (3) location ontologies, and (4) time-based ontologies. Each category is split into generic ontologies, and domain-specific ontologies. The need to evaluate ontologies has been highlighted and explained. What is missing is the explanation of the evolution of such ontologies and a deep comparison.

Conclusion:

A survey regarding ontology-based smart city projects is lacking. For this reason, one of the contributions of this paper is to introduce the most popular ontologies used within smart city projects which is done in Section IV. The focus of our paper is also to disseminate and encourage best practices and ontology improvement which is done in Section VI-A.

D. Semantic Interoperability

The semantic interoperability survey from Ganzha et al. [30] discusses the following popular ontologies: IoT, sensor ontologies, (e/m) Health, and port transportation/logistics. The main shortcoming of the paper is that the authors do not introduce the existing ontology catalogs for IoT and smart cities. They claim more work is needed to achieve semantic interoperability. From our point of view, there is a need to define a set of best practices for ontologies. No tools have been provided to facilitate the access to all ontologies. A set of tables to compare ontologies within the same domain according to the concepts covered is also missing.

A set of best practices and recommendations for semantic interoperability designed by the European Research Cluster on the Internet of Things (IERC) AC4 was released in March 2015 [12]. The needs to overcome the following challenges are mentioned: (1) a unified model to semantically annotate IoT data, (2) reasoning mechanisms, (3) linked data approach, (4) horizontal integration with existing applications, (5) design lightweight versions for constrained environments, and (6) alignment between different vocabularies.

Conclusion:

IERC AC4 does not reference tools encouraging: (1) semantic web best practices, (2) the use of methodologies to ensure interoperability among ontology-based IoT applications, and (3) reuse of the domain knowledge already designed. For this reason, a set of concrete tools is provided in Section VI-A2.

E. Limitations of Current Approaches

Our detailed analysis of the related work demonstrates the need for the following:

• An analysis of ontology catalogs since the last survey has been published in 2012. The analysis is explained in Section III.

• A focus on ontology catalogs for IoT and smart cities is explained in Section II-B.

• The comparison between existing ontology catalogs for smart cities is explained in Section III.

• There is a lack of synthesis regarding existing smart city ontologies. We introduce those ontologies in Section IV.

• There is a lack of methodologies to enrich ontology catalogs with new semantics-based projects. We design a methodology explained in Section V.

• We expect to retrieve all semantics-based smart city projects referenced within the related work section available within ontology catalogs. LOV4IoT ontology catalog is being updated as explained in Section V-B.

• Guiding ontology designers in reusing popular IoT or smart cities ontologies is explained in Section VI by defining a set of criteria to evaluate ontologies.

• Facilitating the task of ontology designers in making better ontologies to encourage semantic interoperability is explained in Section VI. We suggest a set of easy-to-use tools to improve ontologies.

III. Ontology Catalog Analysis for Smart Cities

We describe and compare four ontology catalogs relevant for IoT and smart cities in Section III-A, and compare them in Section III-B.

A. Ontology Catalog Description

We describe and compare four ontology catalogs relevant for IoT and smart cities: Ready4SmartCities, OpenSensingCity, LOV, and LOV4IoT. Figure 4 provides an interactive mindmap, available online¹⁹, to explore more ontology catalogs and semantic search engines. MindMap offers numerous benefits such as fast thinking and learning [31]. Due to the overloaded information, mindmaps can help newbies to discover ontology catalogs in an interactive way and as a playground.

We surveyed ontology catalogs based on OWL ontologies since OWL is a W3C recommendation. Further, we selected ontology catalogs supporting the activity of ontology reuse. Our criteria to compare ontology catalogs are as follows (see Table I within Annexe Section X):

• Ontology number counts the number of ontologies referenced within the catalog.

• Maintenance of the system which can be automatic, semi-automatic or manual.

• Ontology quality evaluates ontologies referenced within ontology catalogs.

• Ontology collection explains the way ontologies have been integrated within the catalogs.

• Ontology metrics counts the number of classes or properties.

• Datasets structured according to ontologies.

• Integration with tools which improves the reusability of ontology. For instance, automatic ontology documentation, ontology visualization, and ontology alignment can be provided.

Ready4SmartCities was an FP7 EU project providing a catalog of ontologies for building smart cities [6] [32]. The Ready4SmartCities catalog focuses on seven domains: energy, climate, weather, environment, building, occupancy, user behavior, and characteristics. It also provides five transversal domains: temporal, organizational, statistical, spatial and measurement. The project also includes the alignment of such ontologies. Unfortunately, the project does not seem maintained anymore, with the website indicating “latest revision July 2015”. The project classifies ontologies according to the following criteria: (1) ontology name, (2) online availability (RDF, HTML), (3) open license, (4) ontology language, (5) syntax, (6) domain, and (7) natural language (e.g., English).

The ontology collection has been done by reviewing the literature, standards, looking up ontology catalogs and search engines (LOV, Watson, and Swoogle), dataset investigation and stakeholders (contributors through an online form, populators to include new ontologies within the catalog and metadata curators to review and improve ontologies).

The Ready4SmartCities ontology catalog designed an ontology to classify all ontologies. The ontology employs concepts and properties from several ontologies (VOAF, OMV, DC, and VANN) to describe ontology metadata. This ontology catalog integrates the OOPS ontology validation tool to improve ontology quality.

The OpenSensingCity catalog²⁰ has been designed for the ANR-funded OpenSensingCity project which aims at fostering the usage of real-time open data in the context of smart cities by providing operating tools including an ontology catalog for smart cities. OpenSensingCity aims at helping application developers to take advantage of open data streams. The Smart City Artifacts (SCA) web portal²¹ collects information about smart cities and provides web applications to visualize the list of existing projects, ontologies, and datasets. The SCA ontology has been designed to classify and describe smart city projects and artifacts [33]. A SPARQL endpoint is provided to query the RDF dataset developed according to the SCA ontology. The SCA ontology also reuses external ontologies: DC, DOAP, Prov-O, FOAF, sc, muto, fabio, dbowl, and OMV. The catalog references 124 ontologies as depicted in Table I. 59 domains are provided to classify ontologies (e.g., energy, geography, sensors, transportation, tourism) and tags²². When clicking on an ontology, statistics are provided (number of classes and properties, etc.). Ontologies can be automatically visualized with WebVOWL. The ontology syntax can be validated with TripleChecker and the ontology design with OOPS.

Linked Open Vocabularies (LOV) is an ontology catalog referencing more than 648 vocabularies (as of May 2018), but few of them are referenced for IoT and smart cities. We are focused on the IoT tag²³ which has been added to the LOV catalog [34] upon request by the LOV4IoT team that we are part of. In May 2018, 27 ontologies with this tag have been referenced. A tag such as smart cities would be relevant to easily retrieve such ontologies. For instance, when we request the city keyword within LOV²⁴, only 4 ontologies have been found: km4city, gci, turismo, and iso37120. LOV provides an interface for contributors to suggest ontologies. A bot is checking some requirements such as ontology metadata [35] to allow the insertion of a new ontology.

Linked Open Vocabularies for Internet of Things (LOV4IoT)²⁵ references 448 ontologies (in May 2018), most of the projects are referenced when they are related to an IoT application domain exploiting sensors and semantic web technologies. In this paper, we are focused on IoT ontologies and smart cities ontologies. LOV4IoT classifies ontologies according to the best practices as well. It provides a keyword search (browser search functionality) and navigation mechanism (by domain) in a manually gathered collection of ontologies. Web services are also offered to select ontologies per domain to query the LOV4IoT RDF dataset. The target audience is people involved in designing IoT and smart city applications or any domains already referenced within the catalog (e.g., building automation, healthcare). The main difference with other ontology catalogs is that it provides the publications to highlight the context of the ontology and ontology best practices status. According to the ontology library survey from d’Aquin et al. “the libraries where administrators are the only ones making decisions on what to include, usually do not have well-defined requirements”. Within LOV4IoT, we decided to insert all ontologies that have been mentioned within publications from IoT and smart city topics, but we also classify ontologies according to their best practices learned from the LOV community.

B. Ontology Catalogs Comparison

We compare four ontology catalog since they are referencing IoT and smart city ontologies. One of the contributions of this paper is to enrich the survey from [11] with a focus on IoT and smart city. Another way to find ontologies would be semantic search engines such as Swoogle, Watson, etc.

Ontology catalogs compared in Table I provide human-readable and machine processable formats. Catalogs are published as HTML web site for humans. HTML interfaces exploit in the back end the RDF datasets. RDF is a format processable by machines thanks to the URI discovery mechanism which enables browsing datasets. None of the four ontology catalogs provide the automatic inclusion of the ontology. All catalogs prefer a manual checking before inserting new ontologies. To address RC 7: How ontology designers can stay updated with the latest ontologies designed for smart cities?; The users can check the year of the publications (e.g., 2017 or 2018) on the LOV4IoT HTML interface to be aware of the latest insertions. We also provide the web service to query smart city ontology URLs²⁶.

Table II provides for each ontology catalog: (1) its name, (2) the year of creation, (3) the scientific publications describing the catalog, and (4) the ontology catalog GUIs URL. Table III provides ontology URL designed for each ontology catalog referenced above. Finding each ontology designed for each ontology catalogs is challenging because the links are not easy to find through the portals.

C. Lessons Learned

LOV4IoT is innovative in the way that it provides a structured state of the art as a tool for IoT and smart city ontology practitioners. LOV4IoT references much more ontologies, and could be updated with any ontologies from OpenSensingCity and Ready4SmartCities that are not referenced on LOV4IoT yet. As already explained, LOV4IoT has a huge impact because it is an ontology incubator to assist ontology designers in following best practices in various communities not familiar yet with ontology quality, and to later reference their ontologies on LOV. Best practices are encouraged through the complementary PerfectO²⁷ project [36].

In the next section, we investigate and introduce the most popular smart city ontologies. When we discover new smart city ontologies, we update the LOV4IoT catalog. Meanwhile, we extract a methodology from it which is explained in Section V. We evaluate the quality of smart city ontologies in Section VI-A1.

IV. Ontologies for Smart Cities

We investigate existing smart city ontologies in Section IV-A. We define a set of criteria to compare ontologies in Section IV-B. We found those ontologies either on ontology catalogs presented previously, or by investigating the literature.

A. Existing Ontologies for Smart Cities

In this section, we investigate existing smart city ontologies. We encourage the readers to use the LOV4IoT and OpenSensingCity ontology catalogs to get the ontology URL. Table V summarizes smart city ontologies and provides ontology or documentation URL to get more technical details.

KM4City (Knowledge Model for City), an Italian national project, modeled an ontology designed for aggregating static or dynamic smart city data [37]. The authors reuse ontologies such as OWL-Time, DC Terms, FOAF, WGS84, GoodRelations, and Ontology Transportation Networks (OTN). The project is scalable since they handle 81 million triples with a growth of 4 million triples per month. It provides a linked data graph, visualization and exploration tool and service map applications exploiting the aggregated data.

STAR-CITY (Semantic Traffic Analytics and Reasoning for CITY), an IBM project, is deployed in four smart cities: Dublin, Bologna, Miami, and Rio de Janeiro [38]. The project is focused on designing ontologies to diagnose and predict road traffic congestions. Data processing exploits six heterogeneous sources: (1) road weather conditions, (2) weather information, (3) Dublin bus stream, (4) social media feeds, (5) road works and maintenance, and (6) city events. SWRL rules have been designed to define rules such as heavy traffic flow.

FIESTA-IoT (Federated Interoperable Semantic Internet of Things (IoT) testbeds and applications) is an H2020 European project [5]. The FIESTA-IoT ontology [39] is designed to unify existing IoT-related ontologies to structure data generated by testbeds. The Smart Santander city or even smart buildings are testbeds producing real data, which is semantically annotated according to the ontology.

VITAL, an FP7 European project, designed an ontology to deal with heterogeneous data streams generated by devices within smart cities [40]. The ontology models sensors and their measurements (based on the SSN ontology V1), for IoT systems and services, and for smart city applications. VITAL is innovative since it provides an operating system for IoT to deal with service creation, orchestration, and protocols. VITAL provides the following characteristics: virtualization, modularity, standards-based (RDF and JSON-LD) and loosely coupled, and open-source.

CityPulse, an FP7 European project, provides the Stream Annotation Ontology (SAO) to unify smart city datasets [41], [42]. SAO has been designed to address real-time aspects.

Smart City Ontology (SCO) is an ontology published in 2015 by Komninos et al. [43]. It reuses some ontologies such as SKOS, but it does not reuse the SSN ontology and lacks of best practices. For instance, the ontology is not shared in a proper way.

Smart city SOFIA2 ontology does not extend SSN ontology but reuses IoT.est ontology [17].

PRISMA project designed an ontology [44] which reuses WGS81, NeoGeo, and Collections ontologies. However, it mentions neither the use of data generated by devices nor the usage of SSN ontology. The ontology is mainly designed to unify heterogeneous data: (1) GeoData from the Geographic Information System (GIS), data on lines and stops of the public transport bus system (REST web service in JSON format). (2) Public lighting system for the maintenance of the city (XML file). (3) State of the roads, sidewalks, signs and markings (Microsoft SQL Server database). (4) Historical data on municipal waste collection (Microsoft Excel file). (5) Historical data on the urban fault reporting service (MySQL Server database). The project provides the LODView tool for an HTML representation of RDF resources and the LODLive tool to browse the RDF graph. The paper does not focus on the description of the ontology, but introduces the need of this ontology to provide Linked Open Data and implements web services, SPARQL endpoints, browsable features, and visualization on top of it.

SCOnt (Smart City Ontology) has been designed by Beseiso et al. and used in a semantic-based framework to manipulate smart city data [45]. However, the ontology has not been shared online [45] which hinders interoperability of smart city systems and the reuse of the ontology. The ontology reuses a population ontology, a geo-location ontology and the DBpedia ontology. Descriptions regarding the design of the ontology and semantic mapping are missing. The novelty in this work compared to existing smart city projects is not obviously explained. SCOnt is used to manipulate smart city data in an architecture comprising four layers: (1) Data scraping layer gathers and refines data since duplication and incompletion of meta-information and missing values issues are faced. (2) Data adaptation layer provides ontology modeling and semantic mapping. (3) Data management layer stores and indexes data within a NoSQL database. Semantic Web services are mentioned but neither link nor descriptions are provided or referenced. (4) Applications layer provides dashboards and APIs.

Conclusion:

We demonstrated in this section that smart city ontologies are regularly redesigned which hinders semantic interoperability. More ontologies related to smart cities can be found on the LOV4IoT and OpenSensingCity ontology catalogs, as explained in Section III. To encourage the ontology reuse, we define a set of criteria to compare smart city ontologies in the next section.

B. Criteria to Compare Smart Cities and IoT Ontologies

Based on our analysis of smart city ontologies in Section IV-A, we define a set of criteria to compare smart city ontologies which can also be applied to IoT ontologies. Those criteria are mainly focused on the reusability of the ontologies. We take as a basis some criteria explained in [46] and we add additional criteria as follows:

• Ontology goal should be clearly explained. Usually, the ontology is designed for a project or an application.

• Ontology size shows the depth of the ontology. Small or lightweight ontologies would be easier to reuse.

• Ontology documentation reduces the learning curve to understand and integrate the ontology, and encourage its reusability. A popular practice is to provide an online HTML documentation. A publication, deliverable or any documentation is necessary to explain in detail the ontology and its impact.

• Ontology availability is strongly encouraged. Ontology should be shared on the web to encourage semantic interoperability. Ontology designers should make an effort in integrating previous ontologies and being aware of the ontology limitations.

• Ontology popularity demonstrates the impact of the ontology and its genericity when the ontology is used in other projects.

• Ontology maintenance needs to be achieved. Usually, when the projects are finished, the ontology is not maintained. However, ontology designers might be responsive in case they continue to work on the same research topic.

• Ontology metadata is preconized by [6], [36], [35]. It is mainly required for building automatic mechanisms. To assist IoT and smart cities ontology developers, Listing 1 shows an example of vocabulary description. See Table X for the list of ontology namespace required to implement ontology metadata.

All the namespaces are those available at http://prefix.cc/. Table X is a reminder for the most popular ontologies.

Conclusion:

We analyzed smart city ontologies and defined criteria to compare them. In the next Section V, we provide a methodology to enrich smart city catalogs with the new ontologies found.

V. Generic Methodology to Update Ontology Catalogs

We explain the methodology to enrich ontology catalogs in Section V-A. The methodology is used in our LOV4IoT catalog in Section V-B.

A. Methodology

Hereafter, we designed a generic methodology to enrich the ontology catalog with new ontology-based projects and the desired knowledge to deduce meaningful information from sensor data. This methodology encourages interoperability among applications by reusing ontologies. We have defined the following steps to update ontology catalogs as depicted in Figure 1 within Annexe Section X.

1. STEP 1: Investigating a new IoT application Domain. A new application domain can be integrated into the catalog if needed. For instance, we investigated the “energy”, “agricultural” and “smart city” domains for the needs of the projects that we are involved in. All projects having these keywords or synonyms that have already designed ontologies are being studied by browsing search engines (e.g., Google) or research papers catalogs (e.g., Google Scholar, IEEE library, ACM library, LNCS library).

2. STEP 2: Updating the dictionary to add the new domain. When a new domain needs to be added, we manually insert it within the M3 dictionary²⁸ implemented as an ontology. We also have mechanisms to automatically integrate a new domain as demonstrated here²⁹, but a manual checking is preferred to handle synonyms, etc. LOV4IoT users can also suggest their ontologies through a suggestion form³⁰ where they can indicate a new domain. The application domain classification is a cornerstone component to automatically retrieve all ontologies, or compute the number of ontologies for a specific domain.

3. STEP 3: Updating RDF ontology catalog dataset. The repository is updated with a new RDF instance (See Listing 2).

4. STEP 4: Updating HTML ontology catalog. Both the HTML web page and the RDF dataset are updated with a new project. The authors of the paper are also contacted thanks to the bot sending emails to encourage them to share the domain knowledge on the Web (e.g., ontologies, rules, etc.). The ontologies can be classified and visualized with a table view.

5. STEP 5: Applications based on the ontology catalog datasets. Applications can be developed to validate ontologies referenced within the catalog, or visualized automatically. Other applications enable the making of statistics such as computing the number of ontologies per domain.

B. Use Case: Methodology applied to LOV4IoT

The methodology mentioned above has been used to design Linked Open Vocabularies for Internet of Things (LOV4IoT) ontology catalog. LOV4IoT enables reusing background knowledge and facilitating semantic-based IoT application development. The LOV4IoT methodology has been implemented and provides a set of tools. Section V-B1 explains the main reason why this ontology catalog has been built. Section V-B2 highlights that LOV4IoT is an extension of the LOV catalog. Section V-B3 describes the LOV4IoT HTML user interface. Section V-B4 explains the way LOV4IoT is being maintained. Section V-B5 provides explanations of the RDF dataset to build any applications to recommend ontologies or research projects. Section V-B6 provides an example to query the RDF dataset which is used to build some of our user interfaces.

1). The design of the LOV4IoT catalog:

We pursued a deeper analysis of domain knowledge involving sensors and semantic web technologies and came up with the following research questions:

1. Which sensors or actuators are employed?

2. What domains do sensors use?

3. Which ontologies exist that cover each domain?

4. What reasoning exits that covers each domain to interpret sensor data?

5. Is the ontology publicly accessible (e.g., downloadable from a website)?

6. Which technologies are used to implement the ontology or rules?

7. Does the ontology follow the semantic web best practices?

8. Which projects could be reused and combined with other projects?, and (9) Which security mechanisms are used in the project?

LOV4IoT is a structured literature survey which references more than 440 ontology-based works (in May 2018) related to sensors in more than 20 domains: smart energy, activity recognition, weather, sensor networks, emotion, music, environment, fire, health care, building automation, food, agriculture, tourism, security, transportation, smart city, IoT, Semantic Sensor Network (SSN), robotic, unit, etc. More than 200 ontologies are now online and theoretically, could be easily reused. We discover, identify, study and reference these IoT projects because:

1. Sensors and their measurements are described.

2. Projects can be used to design new cross-domain use cases (e.g., traffic jam related to weather conditions).

3. Projects designed ontologies.

4. Projects designed rule-based systems to deduce meaningful information from data.

5. Domain experts published the research work and the project in conferences or journals.

6. Projects explained why they integrate semantics.

7. Publications described how ontologies are evaluated.

8. Ontology or dataset code could be used to implement new applications.

We analyze these works to reuse their ontologies and reasoning mechanisms. Most of the ontologies have been designed with semantic web standard languages such as RDF, RDFS and OWL. Moreover, frequently, the Semantic Web Rule Language (SWRL) has been used for the reasoning.

2). LOV4IoT, an extension of the LOV catalog:

LOV4IoT is an extension of the LOV catalog [34], because the ontologies that we classified do not meet the requirements preconized by the LOV catalog. The ontologies that we referenced in this dataset are not necessarily shared online, but we would like to utilize the knowledge expertise mentioned in the publications. Requirements preconized by the LOV community are not enough followed. Requirements can be ontology metadata or adding labels and comments to each concept and property. We contributed to the LOV community, to spread their best practices and encourage the approach of sharing and reusing domain knowledge. We have experienced that convincing authors to improve their ontologies is a time-consuming task.

This limitation could be overcome by improving ontology editors to encourage people to add labels and comments, an important feature for ontology matching tools. Recently, a beta version of ProtegeLOV³¹ [47] has been released. It is an extension of a popular ontology editor which suggests preferred ontologies referenced in the LOV catalog when you are designing a new concept or a new property.

The users can directly reuse the concept or integrate owl:equivalentClass or owl:equivalentProperty links. However, this plugin does not encourage users to add ontology metadata or labels and comments as preconized by the LOV community. In our LOV4IoT dataset, we describe the ontology status according to the LOV criteria.

3). The LOV4IoT user interface:

We have chosen to classify and share the ontologies as a tool in an HTML table³². It encourages the reusability and can benefit other people interested in such ontologies.

Within the table, the first column is dedicated to authors and the second to the publication date of the work. The third column provides related publications. The fourth column links the ontology URL if provided. The fifth column describes technologies used and the sixth column gives sensors used in the project. Finally, the seventh column offers the reasoning mechanism employed in the projects (e.g., if foggy then safety devices are fog lamp, ESP, and ABS).

Further, each row in the table references a project which is colored according to the ontology status: (1) the ontology is lost or confidential (in red), (2) the authors have been contacted to get the implementation of their ontologies and rules (in white), (3) the authors will soon publish the ontology (in orange), (4) the ontology is shared online but does not meet the requirements preconized by the LOV catalog (in yellow), and (5) the ontology is shared online and is even referenced on the LOV catalog since they follow the required best practices (in green). Users such as developers, research engineers or domain experts can surf on this web page to search ontologies according to a specific domain.

4). Updating LOV4IoT Automatically:

To update the LOV4IoT dataset, a new row must be added within the HTML web page and a new instance within the RDF dataset. To improve its impact, we could find additional background knowledge by connecting LOV4IoT to semantic search engines and ontology catalogs. At the beginning of this work, we started to use ontology catalogs such as Linked Open Vocabulary (LOV) [34] since it provides web services. Unfortunately, when we were experimenting with this, we realized that most of the ontologies designed for IoT were not referenced on such tools yet.

5). LOV4IoT RDF dataset:

Initially, the LOV4IoT RDF dataset has been designed to automatically compute: (1) the total number of ontology-based projects, (2) the number of ontologies per domain, and (3) the number of ontologies according to their status (online, lost, publishing process online, referenced on LOV and contacting authors). The dataset also enables dealing with projects covering several domains (e.g., smart home and weather).

The LOV4IoT RDF dataset³³ is available online and hosted on Google App Engine which ensures sustainability of this dataset. An extract of the LOV4IoT dataset in RDF/XML is depicted in Listing 2 (see Annexe Section X). Users such as developers, research engineers or domain experts can make statistics on this dataset or filter ontology-based projects by ontology status or by domain. The dataset also enables automatically building a table in the HTML web page, to display a subset of the LOV4IoT dataset according to their needs. Machines can navigate on the LOV4IoT RDF dataset to retrieve the domain knowledge fitting their needs.

6). LOV4IoT GUI built by querying the RDF dataset:

We designed a generic mechanism to query the LOV4IoT RDF dataset transparently to provide various functionalities: (1) writing a SPARQL query to interact with the LOV4IoT RDF dataset, (2) designing the web service to execute the SPARQL query, (3) querying the web service with Ajax, and (4) parsing the result returned by the web service with JavaScript in an HTML web page.

Listing 4 (see Annexe Section X) is the Java code to execute the SPARQL query with the JENA ARQ engine to query all domains referenced within the LOV4IoT RDF dataset. Listing 3 (see Annexe Section X) provides the SPARQL query to request all domains referenced within the LOV4IoT RDF dataset. The Jena ARQ engine executes the SPARQL query on the RDF dataset within a web service. This Web service is requested using the Ajax technology to display the results which are parsed in JavaScript and displayed in a drop-down-list (see Figure 2 within Annexe Section X). The drop-down-list displays all rdfs:label. The tooltips display rdfs:comment.

VI. Evaluation: Ontology Quality and Ontology Catalog

This section evaluates ontology quality. A second methodology focusing on the ontology quality is described in Section VI-A. Section VI-B demonstrates the need for ontology catalogs and improved ontology quality in several projects. Finally, the LOV4IoT ontology catalog evaluation with users demonstrates its impact, as explained in Section VI-C.

A. Evaluation: Ontology Quality Methodology

A methodology has been designed to evaluate ontology quality in Section VI-A1. The tools used to implement the methodology are introduced in Section VI-A2. Those tools have been applied to a set of IoT ontologies within Section VI-A3.

1). Ontology Quality Methodology:

To validate ontologies, we conceived the ontology quality methodology (as depicted in Figure 3, see Annexe Section X), which is comprised of the following criteria:

1. Serialization supports the OWL ontology format because it is a W3C recommendation.

2. Syntactic validation is necessary during the compilation to load the ontology. It is an important step for the ontology quality methodology due to the fact that all ontologies must be proceeded by tools.

3. Interlinking enhances interoperability, integration, and browsing among ontologies.

4. Documentation encourages the understandability of the ontology. We designed the ontology documentation mindmap, available online³⁴, to explore ontology documentation tools as depicted in Figure 5.

5. Visualization eases the learning phase by providing a fast understanding of the ontology which encourages the re-usability of the ontology.

6. Availability advocates sharing the resource on the web. Developers might not have time, resources and administrative skills to manage the server. Ideally, an ontology catalog server could host any ontologies and provide the right URL. Sharing the ontology code and documentation on the web would encourage ontology reuse.

7. Discoverability improves the dissemination of ontologies in ontology catalogs and semantic search engines. Depending on the application domain (e.g., healthcare, smart city), several ontology catalogs are available.

8. Ontology Design detects numerous ontology pitfalls.

2). Studies on Validation Tools to Evaluate Ontologies:

Our research goal is to automatically evaluate ontology quality with a set of tools introduced in the tables explained below, which were recently published in [48].

For each criterion explained above and in Figure 3, we classify in Table VI tools that we have already tested to evaluate ontologies. The OWL Manchester tool or the Jena framework can be used for serialization. The Triple Checker tool can be used for syntactic validation. The LogMap³⁵ ontology matching tools can be employed. Parrot and LODE have been chosen because they provide web services to generate documentation automatically. The WebVOWL tool can be used to provide an automatic ontology graph visualization. Dereferenceable URI can be tested with the Vapour tool. The Oops tool improves the ontology design because it detects numerous ontology pitfalls.

In Table VI, the first column is dedicated to the tool name, the second column to the criteria satisfied, the third column to explain if the tool is maintained or not, and the last column is dedicated to the research publication. We have considered the tools reusable when they provide Web services, APIs, code, and documentation. The web services are simpler to integrate when developing the methodology, but the implementation depends on the reliability of the Web and on the maintenance of the web services. There can be times when the servers hosting the web services are down. Also, when new versions are released, it might have an impact on the implementation of our methodology. When the tools are open-source, we can avoid such dependencies, but it is more time-consuming to set up the tool using multiple languages and technologies. This is another reason that demonstrates the need to help non-experts in the ontology quality process.

In Table VI, within the maintained column, High means that the community behind the tools is reactive when issues arise such as servers down, fixing bugs, answering questions or adding new functionalities. Medium means that the tool might be often down, due to server issues. Table VII provides all GUIs URL for each tool.

Table VIII provides all URLs for web services or APIs for each tool mentioned above. Table VIII has been used to integrate the tools³⁶ and automatically evaluate ontologies from the LOV4IoT catalog. Table IX is dedicated to the programming language used for each tool and provides the URL of the source code, when available, on GitHub or BitBucket.

3). Results:

A detailed evaluation has been completed with 26 IoT or smart cities ontologies referenced within the LOV4IoT ontology catalog. Those ontologies have been tested with 6 validation tools mentioned in the tables (Parrot, WebVOWL, Oops, TripleChecker, LODE, and Vapour). The evaluation is accessible online³⁷, and in Table XI within Annexe Section X. The evaluation demonstrates that there are no ontologies which can be successfully loaded with all of the tools, and shows that numerous errors are encountered. The LODE tool is preferred compared to the Parrot tool because more ontologies can be automatically documented.

B. Use Cases

We highlight use cases which benefit from our methodology, which is explained in this paper: (1) LOV ontology catalog, (2) IoT-O ontology, (3) CityPulse 101 scenarios, and (4) National and European smart city projects designing ontologies.

1). LOV ontology catalog:

As already explained in Section III-C, LOV4IoT is an ontology incubator to later assist ontology designers in following best practices, and to reference their ontologies on LOV. The LOV4IoT tool is referenced in the LOV web site³⁸ and the LOV community highly acknowledges the work on disseminating best practices to other communities [34].

2). IoT-O ontology:

IoT-O ontology [49] [50] follows the methodology presented here. IoT-ontology unifies existing IoT ontologies and is compliant with semantic web best practices explained in [36].

3). CityPulse 101 scenarios:

CityPulse EU project introduced in Section IV contains 101 scenarios³⁹ [3] covering a broad variety of smart cities application domains including air pollution monitoring, wind farms, smart meters, smart orchards, smart cars, parking management, traffic management, smart elderly care systems, mobile fitness applications, etc. The LOV4IoT covers more than 20 domains associated with these use cases including (a) the Ambient Assisted Living (AAL) domain that is relevant to design the smart elderly care system and (b) the smart metering domain. The web page⁴⁰ matches CityPulse scenarios to any ontology-based project referenced within LOV4IoT.

4). National and European smart city projects designing ontologies:

We have been involved in National and European smart city projects where IoT ontologies have been developed. These include projects such as OpenSensingCity, Smart Energy Aware Systems (SEAS)⁴¹ and FIESTA-IoT. The LOV4IoT catalog has been used to analyze IoT ontologies [51] to design the FIESTA-IoT unified ontology [39]. FIESTA-IoT ontology reuses and aligns a set of ontologies evaluated above: SSN V1, IoT-lite, and M3-lite. The ontology quality evaluation has been applied to the ontologies for IoT and smart city as presented in Section IV (e.g., VITAL, KM4city) and was a cornerstone step to design the FIESTA-IoT ontology. The result is provided in Table XI. Based on those experiences acquired during those projects, we shared the expertise to continuously enrich the LOV4IoT ontology catalog with more knowledge implemented as ontologies within projects.

C. Evaluation of the LOV4IoT Catalog with Users

The LOV4IoT ontology catalog has been employed by users to evaluate its usability and effectiveness. We designed an evaluation form⁴² which is available on the LOV4IoT project web site⁴³. The evaluation result has been previously published in [52], but we are still accepting answers to evaluate the ontology catalog with more and more users. The updated evaluation result summary is available as well⁴⁴.

The survey has been filled out by 39 volunteers who employed LOV4IoT. We published results of 35 volunteers. The survey form demonstrates that the classification work of ontology-based IoT projects is useful not only for other developers and researchers, but also for the IoT research community. The ontology catalog helps users for their state of the art ontologies or finding and reusing the existing ontologies. The LOV4IoT evaluation form contains the following questions:

• Who are you?

• What domain ontologies are you looking for?

• How did you find this tool?

• Do you trust the results since we reference publications?

• In which information are you interested?

• Do you use this web page for your literature survey?

• Do you think you will use this web page again in your further IoT application developments?

• In general, do you think this web page is useful?

• Would you recommend this web page to other colleagues involved in ontology-based IoT development projects?

This evaluation demonstrates that LOV4IoT is relevant for the IoT community. The results are encouraging to update the dataset with additional domains and ontologies. Moreover, according to Google Analytics, the LOV4IoT HTML web page has been seen more than 10,390 times (7,530 unique pages views) since August 2014. The average time spent on the web page is 3 and a half minutes. It means that visitors return to this dataset which demonstrates its usability.

VII. Conclusion

Firstly, we analyzed four ontology catalogs for IoT and smart cities (Ready4SmartCities, LOV, LOV4IoT, and OpenSensingCity). Secondly, we studied the most recent ontologies to build smart cities based on IoT technologies. Thirdly, we designed a methodology to enrich ontology catalogs, which is implemented within the LOV4IoT ontology catalog. OpenSensingCity and LOV4IoT ontology catalogs are a tremendous work but an essential step to encourage the reuse of existing ontologies and to foster semantic interoperability among ontology-based smart city applications. Fourthly, we defined a set of criteria and tools to improve the quality of ontologies. Finally, we evaluated the LOV4IoT ontology catalog with users. Those contributions aim to help developers in reusing existing smart city and IoT ontologies to build future applications.

VIII. Future Work

As a future work, the methodology can be refined to easily support additional IoT applicative domains such as manufacturing, Industry 4.0, robotic, Wireless Body Area Networks (WBANs), etc. Indeed, we are now involved in healthcare IoT-based projects related to asthma, obesity, and depression, but also IoT-based disaster projects using semantic web technologies. Another future work is to examine the design of the evaluation of ontology quality. It will encourage the reuse of ontologies and improve semantic interoperability. Unifying and aligning ontology catalogs would enable to update all catalogs with new ontologies automatically. Another challenge is to automatically improve and fix ontologies. Finally, we could design an ontology ranking algorithm to recommend ontologies to reuse.

X. Annexe: Tables, Figures, Mindmaps and LOV4IoT Evaluation

1. Ontology Catalogues Analysis for Smart Cities - Tables

2. Smart city projects and ontologies - Tables

3. Reusable Tools to improve ontology quality

4. Section Ontologies for Smart Cities - Table

5. Section Ontologies for Smart Cities - Listing

Listing 1.

Ontology Metadata description example

1 <owl:Ontology rdf:about=“&m3;”> 2 <rdf:type rdf:resource=“&voaf;Vocabulary”/> 3 <dc:title xml:lang=“en”>The Machine−to−Machine Measurement (M3) Ontology</dc:title> 4 <dc:description xml:lang=“en”>M3 Ontology is a language, nomenclature, dictionnary which unifies IoT data.</dc:description > 5 <dc:creator> 6 <foaf:Person rdf:about=“mailto:amelie.gyrard@emse.fr“> 7 <foaf:name>Amelie Gyrard</foaf:name> 8 </foaf:Person> 9 </dc:creator> 10 <dcterms:modified rdf:datatype=“http://www.w3.org/2001/XMLSchema# date”>2017−06−09</dcterms:modified> 11 <dcterms:issued rdf:datatype=“http://www.w3.org/2001/XMLSchema# date”>2013−02−21</dcterms:issued> 12 <owl:versionInfo rdf:datatype=“http://www.w3.org/2001/XMLSchema# decimal”>0.7</owl:versionInfo> 13 <rdfs:comment xml:lang=“en”>M3 Ontology is a language, nomenclature, dictionnary which unifies IoT data.</rdfs:comment > 14 <vs:term_status>Work in progress</vs:term_status> 15 <vann:preferredNamespacePrefix>m3</vann:preferredNamespacePrefix> 16 <vann:preferredNamespaceUri>http://sensormeasurement.appspot.com/ m3#</vann:preferredNamespaceUri> 17 </owl:Ontology>

F. Section Methodology - Figure and Listing

Listing 2.

An extract of the LOV4IoT dataset

1 @prefix m3: <http://sensormeasurement.appspot.com/m3#>. 2 @prefix rdfs: <http://www.w3.org/2000/01/rdf−schema#>. 3 <m3:M2MApplication rdf:about=“Consoli2015”> 4 <m3:hasContext rdf:resource=“&m3;IoT”/> 5 <m3:hasContext rdf:resource=“&m3;City”/> 6 <rdfs:label xml:lang=“en”>Smart City PRISMA ontology</rdfs:label> 7 <rdfs:comment xml:lang=“en”>A Smart City Data Model based on Semantics Best Practice and Principles [Consoli et al. WWW Companion 2015]</rdfs:comment> 8 <lov4iot:hasOntologyStatus rdf:resource=“&lov4iot;Online”/> 9 <dcterms:issued rdf:datatype=“http://www.w3.org/2001/XMLSchema# date”>2017−07−27</dcterms:issued> 10 <dcterms:modified rdf:datatype=“http://www.w3.org/2001/ XMLSchema#date”>2017−08−17</dcterms:modified> 11 <m3:hasUrlOntology rdf:resource=“http://www.ontologydesignpatterns .org/ont/prisma/ontology.owl”/> 12 </m3:M2MApplication>

Listing 3.

Query all domains referenced within the LOV4IoT dataset

1 @prefix m3: <http://sensormeasurement.appspot.com/m3#>. 2 @prefix rdfs: <http://www.w3.org/2000/01/rdf−schema#>. 3 4 SELECT DISTINCT 5 ?domainURL 6 ?domainLabel ?domainComment 7 WHERE{ 8 ?projectOntology m3:hasUrlOntology ?ontologyURL. 9 ?projectOntology m3:hasContext ?domainURL. 10 11 OPTIONAL{ 12 ?domainURL rdfs:label ?domainLabel . 13 FILTER(LANGMATCHES(LANG(?domainLabel), “en”)) 14 } 15 16 OPTIONAL{ 17 ?domainURL rdfs:comment ?domainComment . 18 FILTER(LANGMATCHES(LANG(?domainComment), “en”)) 19 } 20 }

Fig. 1.

Overview of the methodology to update ontology catalogs

Listing 4.

Web Service to query all domains referenced within the LOV4IoT dataset

1 @GET 2 @Path(“/getAllDomainFromLOV4IoT/”) 3 @Produces(MediaType.APPLICATION_XML) 4 public Response getAllDomainFromLOV4IoT() { 5 6 System.out.println(“LOVIoT Web service called: /perfectoOnto/ getAllDomainFromLOV4IoT/”); 7 8 Model model = ModelFactory.createDefaultModel(); 9 10 //load the LOV4IoT dataset into the model 11 ReadFile.enrichJenaModelOntologyDataset(model, Var. LOV4IOT_DATASET_PATH); 12 ReadFile.enrichJenaModelOntologyDataset(model, Var. M3_ONTOLOGY_PATH); 13 //M2MAppGeneric m2mappli = new M2MAppGeneric(model); 14 15 //SPARQL query 16 ExecuteSparql sparqlQuery = new ExecuteSparql(model, Var. ROOT_SPARQL_LOV4IoT + “getAllDomainLOV4IoT.sparql”); 17 18 //no variable to replace in the SPARQL query 19 ArrayList<VariableSparql> var = new ArrayList<VariableSparql>(); 20 21 String resultSparqlsenml = sparqlQuery.getSelectResultAsXML(var); 22 23 return Response.status(200).entity(resultSparqlsenml).build(); 23 }

TABLE I.

Ontology catalog comparison (last analysis done in May 2018)

Ontology Catalog Name/Features	Ready4SmartCities	LOV	OpenSensingCity	LOV4IoT
Number of ontologies	70 ontologies	27 ontologies with the IoT tag 4 ontologies with the city keyword	124 ontologies	448 ontologies 24 ontologies for cities 47 ontologies for IoT other are relevant for IoT domains (e.g., healthcare, building)
Maintained	Project finished	Highly maintained (Bot and human)	Maintained	Highly maintained
Quality	Yes (OOPs tool)	Yes (Validation tools) and disseminate best practices	No	Yes (with Perfecto) and disseminate best practices
Ontology collection	review literature standardizations look up ontology catalogs	suggest interface and bot and manual check	review literature review literature	review literature contributors, LOV
Ontology Metrics (number class, properties)	No	Yes	Yes	No
Dataset	HTML + RDF	HTML + RDF	HTML + RDF	HTML + RDF
Integration with tools to improve the reusability	oops ontology alignment API	OOPS, triplechecker webvowl, parrot, vapour	OOPS, triplechecker, webvowl	OOPS, triplechecker, webvowl parrot, vapour, LODE

TABLE II.

Ontology catalog creation and related publications

Ontology Catalog Name	Year of Creation	Publications	URL GUI
Ready4SmartCities	2014	[6]	http://smartcity.linkeddata.es/
OpenSensingCity	2016	[33]	http://opensensingcity.emse.fr/scans/ontologies
LOV4IoT	2015	[53], [54], [52]	http://sensormeasurement.appspot.com/?p=ontologies
LOV	2011	[35], [34]	http://lov.okfn.org/dataset/lov/

TABLE III.

Ontologies used to design ontology catalogs

Ontology Catalog Name	Ontology Name	URL ontology
Ready4SmartCities	Ready4SmartCities	http://smartcity.linkeddata.es/rdf/ontologyRDF.ttl
OpenSensingCity	SCA (Smart City Artifact)	https://github.com/OpenSensingCity/Smart-City-Artifacts-Ontology
LOV4IoT	LOV4IoT	http://sensormeasurement.appspot.com/ont/m3/lov4iot#
LOV	VOAF (Vocabulary of a Friend)	http://lov.okfn.org/vocommons/voaf/v2.3/

TABLE IV.

Ontology-based Smart City Projects and their impact

Smart City Project	Publications	Project Impact
KM4City	[37]	National Project (Italian)
STAR-CITY	[38]	Industrial Project (IBM)
FIESTA-IoT	[39] [5]	European H2020 Project
VITAL	[40]	European FP7 Project
CityPulse	[41] [42]	European FP7 Project
SCO (Komninos et al.)	[43]	Not found yet
SOFIA2	[17].	Not found yet
PRISMA	[44]	National Project (Italian)
SCOnt (Beseiso et al.)	[45]	Not found yet

Fig. 2.

Drop-down-list displaying the result provided by the web service and the SPARQL result.

G. Section Methodology - GUI Figure

H. Ontology Quality Methodology

I. Evaluation Form Results

The survey has been filled by 39 volunteers who employed LOV4IoT ontology catalog.

• Who are you? Users are either: 41% semantic-based IoT developers, 41% IoT developers, 24% others, 12.5% ontology matching tool experts and 10% domain experts. It means that the dataset is mainly used by the IoT community. Among domain experts, we had feedback from security and IoT experts.

• Domain ontologies that you are looking for? 53% of users are interested in smart home ontologies, 34% in health ontologies, 26% in weather ontologies, 26% in transportation ontologies, 24% in security ontologies, 18% in food-related ontologies, 13% in emotion, 9% in tourism, and 3% in agriculture. It means that users are interested in most of the domains that we cover. According to the answers of the users, we updated the form and the catalogs with more domains such as IoT generic ontologies.

• How did you find this tool? 43% found the LOV4IoT tool thanks to search engines, 31% thanks to emails that we sent to ask people to share their domain knowledge or to fill this form, 17% thanks to research articles, and 14% thanks to people who recommended this tool. Everybody can find and use this tool, not necessarily researchers.

• Do you trust the results since we reference research articles? 55% of users trust the LOV4IoT tool since we reference research articles, 42% are partially convinced. It means they consider this dataset as a reliable source.

• In which information are you interested? 70% of users are interested in ontology URL referenced, 65% of users are interested in research articles, 41% in technologies, 32% in rules and 24% in sensors used. The classification and description of each project is beneficial for our users.

• Do you use this web page for your state-of-the art? 36% of users answered yes frequently, 33% yes, and 31% no. Thanks to this work, users save time by doing the state of the art on our dataset.

• In your further IoT application developments, do you think you will use again this web page? 53% of users answered yes frequently, 42% yes, and 5% no. This result is really encouraging to maintain the dataset for domain and IoT experts.

• In general, do you think this web page is useful: 63% of users answered yes frequently, 34% yes, and 3% no. This result is really encouraging to maintain the dataset and add new functionalities.

• Would you recommend this web page to other colleagues involved in ontology-based IoT development projects? 82% of users answered yes frequently, 16% yes, and 3% no. This result is really encouraging to maintain the dataset and add new functionalities.

TABLE V.

Smart City Projects and their ontology

Smart City Project	Ontology URL (HTML documentation or code)	Comments
KM4City	http://www.disit.org/km4city/schema	Dead Ontology URL October 2017
STAR-CITY	https://www.dropbox.com/s/xkvlb7a1fnibo4w/STAR-CITY-Ontologies.zip	ZIP file (bad practice)
FIESTA-IoT	http://ontology.fiesta-iot.eu/ontologyDocs/fiesta-iot.html http://ontology.fiesta-iot.eu/ontologyDocs/m3-lite.html	- -
VITAL	http://vital-iot.eu/ontology/ns/ontology.owl	-
CityPulse	http://iot.ee.surrey.ac.uk/citypulse/ontologies/sao/sao (SAO ontology) https://mobcom.ecs.hs-osnabrueck.de/cp_quality/ (Quality ontology)	- -
SCO (Komninos et al.)	https://www.dropbox.com/s/q7tz39jjeeibhzl/2015-SMART%20CITY%20ONTOLOGY-V01.owl?dl=0	Hosted on dropbox (bad practice)
SOFIA2	Not found yet	PDF ontology documentation
PRISMA	http://wit.istc.cnr.it/prisma/webcontent/ontology.html	-
SCOnt (Beseiso et al.)	Not found yet	-

TABLE VI.

Reused tools for the implementation of Perfecto

Tools	Validation Requirement	Maintained	Paper
Jena	Serialization - Syntactic	Yes - High	Yes [55]
Oops	Ontology Design	Yes - High	Yes [56]
Triple Checker	Syntactic	Yes - High	Not found
LOV	Discoverability	Yes - High	Yes [34]
Parrot	Documentation	Yes	Yes [57]
LODE	Documentation	Yes	Yes [58]
WebVOWL	Visualization	Yes - High	Yes [59]
Vapour	Discoverability	Yes - Medium	Yes [60]
OWL Manchester	Syntactic	Medium	Not found

TABLE VII.

Tools and GUIS used to improve ontologies

Tools	GUI URL
Jena	https://jena.apache.org/
Oops	http://oops.linkeddata.es/
Triple Checker	http://graphite.ecs.soton.ac.uk/checker/
LOV	http://lov.okfn.org/dataset/lov/
Parrot	http://ontorule-project.eu/parrot/parrot
LODE	http://www.essepuntato.it/lode
WebVOWL	http://vowl.visualdataweb.org/webvowl.html
Vapour	http://linkeddata.uriburner.com:8000/vapour
OWL Manchester	http://visualdataweb.de/validator/

TABLE VIII.

Tools and Web service to automatically improve ontologies

Tools	Web Service or API URL
Jena	Jena libraries: https://jena.apache.org/download/index.cgi
Oops	Web service: http://oops.linkeddata.es/response.jsp?uri=
Oops	RESTFul Web Service documentation: http://oops-ws.oeg-upm.net/
Triple Checker	Web Service: http://graphite.ecs.soton.ac.uk/checker/?uri=
LOV	Web Service API Documentation: http://lov.okfn.org/dataset/lov/api
Parrot	Web Service: http://www.ontorule-project.eu/parrot/parrot?documentUri=
LODE	Documentation: http://www.essepuntato.it/lode/
WebVOWL	Web service: http://vowl.visualdataweb.org/webvowl/#iri=
Vapour	Web service: http://linkeddata.uriburner.com:8000/vapour?uri=
OWL Manchester	Not found yet

TABLE IX.

Reused tools for the implementation of Perfecto

Tools	Programming Language	Code Available
Jena	Java	GitHub: https://github.com/apache/jena
Oops	Not found yet	Not found yet
Triple Checker	PHP	GitHub: https://github.com/cgutteridge/TripleChecker
LOV	GUI with Javascript	GitHub: https://github.com/pyvandenbussche/lov
LOV	Back end with Java	GitHub: https://github.com/pyvandenbussche/lovScripts
Parrot	Java	Bitbucket: https://bitbucket.org/fundacionctic/parrot/wiki/Home))
LODE	Java	GitHub: https://github.com/essepuntato/LODE
WebVOWL	JavaScript	GitHub: https://github.com/VisualDataWeb/WebVOWL
Vapour	Java	BitBucket: https://bitbucket.org/fundacionctic/vapour/wiki/Home
OWL Manchester	PHP	GitHub: https://github.com/rollxx/OWL

TABLE X.

Ontologies frequently re-used to add ontology metadata

Ontology Name	Prefix	URL ontology
Vocabulary of a Friend (VOAF)	voaf	http://purl.org/vocommons/voaf#
Friend of a Friend (FOAF)	foaf	http://xmlns.com/foaf/0.1/
A vocabulary for annotating vocabulary descriptions (VANN)	vann	http://purl.org/vocab/vann/
DCMI Metadata Terms	dc	http://purl.org/dc/elements/1.1/
DCMI Metadata Terms	dcterms	http://purl.org/dc/terms/
SemWeb Vocab Status ontology	vs	http://purl.org/vocommons/voaf#
Ontology Web Language	owl	http://www.w3.org/2003/06/sw-vocab-status/ns#
Resource Description Framework	rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
RDF Schema	rdfs	http://www.w3.org/2000/01/rdf-schema#

Fig. 3.

Ontology quality methodology

Fig. 4.

Interactive Online MindMap: How to find ontologies?

Fig. 5.

MindMap: Tools to document ontologies

Fig. 6.

MindMap: Semantics-based Smart City Projects

TABLE XI.

Evaluation: Smart City Ontologies with tools