An Ontology Integrating the Open Standards of City Models and Internet of Things for Smart-City Applications

Smart city applications integrate the human, physical, and digital systems in a built environment with Internet of Things (IoT) resources, city models, and domain models. However, existing methods for the integration are suitable for individual applications and lack interoperability among application modules. This study analyzed existing integration strategies and developed an ontology for integrating the data modeling standards of the Open Geospatial Consortium (OGC) CityGML, IndoorGML, and SensorThings API. To cope with the broad definition of “things” in the IoT, the proposed ontology supports multiple views of things, including the a-building-as-a-thing, a-room-as-a-thing, an-opening-as-a-thing, and a-device-as-a-thing views. Thus, the proposed ontology relates information from these three standards and supports semantic queries. We demonstrated the proposed solution in smart home, smart security, smart health care, and fire evacuation systems. Overall, the proposed solution can facilitate the integration of standard-based IoT resources and city models to support smart city applications.


I. INTRODUCTION
A. Background C URRENTLY, over 50% of people worldwide live in urban areas. Increases in the urban population have placed considerable pressure on the infrastructure and environment of cities. Technological advances have led to increasing interest in smart cities in a variety of domains [1], [2]. Spatial information is a requirement for smart city services [3], and technologies for managing and processing spatial information are crucial components of smart city infrastructure [4]. Tasking and sensing capabilities supported by the Internet of Things (IoT) are crucial aspects of smart city infrastructure for capturing city dynamics and performing real-time actions [5]. IoT resources and spatial information are generally formulated as independent data sets or services through the use of various protocol standards or data models. Open standards provide interoperable solutions for describing and sharing IoT resources and spatial information. However, insufficient research has examined the linkages between these standards. Thus, the current study focused on the integration of IoT resources and spatial information.
A geospatial data set usually describes the location (i.e., geometries with 2-D or 3-D coordinates), attribute (i.e., textual, numerical, categorical, and ordinal characteristics), and temporal (i.e., creation time, sampling time, or valid time) information of features [7]. Geospatial features in a smart city should follow clearly defined semantic classes to express their inherited attributes, constraints, and functions [8], [9]. For instance, city features, such as buildings, roads, rooms, trees, and bodies of water, should be interpreted and analyzed differently according to their semantic meanings. Therefore, in recent years, standards have been introduced for defining semantic-rich city characteristics-for example, the Open Geospatial Consortium (OGC) CityGML [10], OGC IndoorGML [11], LandXML [12], and building information modeling (BIM) [13]. From following these open standards, city features can be represented and utilized in an interoperable manner.
On the other hand, the IoT provides access to the dynamic information of a city through sensors and actuators. According to the International Telecommunication Union (ITU), the IoT is "a global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies" [14]. The IoT has been used in various fields, such as in smart homes [15], e-health [16], intelligent transport systems [17], and smart factories [18].
The main challenge in IoT development is the heterogeneity issue [19], [20]. Specifically, existing IoT systems are usually produced according to different communication protocols and proprietary data models by different manufacturers. Although information can be transmitted in each integrated system, information usually cannot be shared directly across different proprietary systems. This heterogeneity issue is also called the IoT silos, which seriously hinder the development of the IoT [21]. This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ For example, an e-health service can access data from house environment sensors, human wearable devices, home automation appliances, and medical instruments to provide medical services on the basis of sensor observations. However, because these devices are produced by different manufacturers, the data from different devices follow different data models and are released through different protocols. Thus, data are essentially locked in individual closed systems, which are difficult to access and integrate with third-party applications [16]. To address the IoT heterogeneity problem, open standards can be followed for unifying IoT data models and communication protocols so that different IoT systems can easily exchange data and cooperate with each other.
To be specific, this study selected OGC SensorThings API [26] as well as CityGML [10] and IndoorGML [11] because they define semantic-rich and comprehensive data models for IoT resources and spatial information. However, applications usually require a customized design for integrating spatial information and IoT resources [6], which would result in redundant development and misunderstanding on the data sets. Therefore, this research aims on proposing a unified framework linking IoT resources and city models by their relationships that consequently supports various applications. To avoid possible misunderstanding, please note that the proposed idea can be applied to other suitable IoT and geospatial feature standards, such as the World Wide Web Consortium (W3C) Web of Things (WoT) [43], European Telecommunications Standards Institute (ETSI) smart applications reference (SAREF), ontology and extensions [44], and BIM.

B. Objective
In general, this research focused on the integration of IoT resources and city models for supporting smart city applications in an interoperable manner. Since open standards can enable the achievement of interoperability [25], IoT resources and city models should be integrated according to open standards.
This study adopted the semantic Web technology [27] to connect the classes and entities of city models and IoT resources [28] on the basis of an ontology [29]. The semantic Web can flexibly detail different relationships while retaining data source independence. Therefore, the present study developed an integration ontology to define the relationships among SensorThings API, IndoorGML, and CityGML for integrating IoT resources and city models. In particular, this study focused on the semantic integration of objects in indoor spaces, where geometric attributes (e.g., topological relationships) are not included. As displayed in Fig. 1, the proposed ontology integrates data from different resources to support various smart city applications. Furthermore, because "things" in the IoT have a flexible definition, ontologies are designed for various views of things to support different use cases.
The proposed ontology can be used to express the relationship between IoT resources and city models in resource description framework (RDF) format [30], enabling convenient querying through SPARQL Protocol and RDF Query Language (SPARQL) queries for supporting various applications. To examine the suitability of the proposed ontology, this research simulated different smart city applications.
In general, the contributions of this research are listed. 1) This research brings attention to the need of the linking standard-based IoT and city model and demonstrated it with different use cases. 2) Instead of creating proprietary classes for different use cases, this research follows only the classes from the chosen standards, which allows better interoperability.

3) As this research identified the relationships between IoT
and city model classes based on their general nature instead of specific use cases or scenarios, the proposed solution has a broader applicability. 4) Although this research chose a certain integration strategy, the identification and analysis of different strategies could be helpful for people deciding the strategy for their systems/applications. The following details the organization of the remaining sections of this article. Section II presents a review of studies on city models and IoT open standards and describes strategies for integrating these models and standards. Section III describes the proposed ontology for integrating SensorThings API, IndoorGML, and CityGML. Section IV provides the experimental results for the SPARQL queries used in the simulated smart city applications. Finally, Section V presents the research conclusions and suggestions for further investigations.

II. RELATED WORK
Integrating IoT resources and city models is essential for smart city applications. This section presents a literature review on the integration of IoT resources and city models and introduces the open standards of city models and IoT resources. Furthermore, it describes strategies for integrating open standards.

A. Integrating 3-D Models and IoT Resources for Smart City
Cities should integrate cross-disciplinary components to become smart cities [31]. Numerous researchers have examined the integration of IoT sensors and 3-D models. For instance, Wang et al. [23] integrated indoor route network information and indoor sensor information to perform a dynamic risk assessment for planning immediate evacuation routes. Wang et al. [22] integrated an OGC sensor observation service (SOS) Web service and a BIM house model in the application layer of a three-layer network architecture (which contained an application layer, a data service layer, and a data repository layer) for retrieving sensor observations from each room of the house. Chaturvedi et al. [32] integrated SOS services, CityGML, and historical solar energy observations to assess the solar radiation of building roofs and surfaces. In addition, the Dynamizer module proposed by [32] is being included in the CityGML 3.0 standard. Zhu et al. [24] integrated a spatiotemporal data series on air quality with a CityGML data set and an SOS service for visualizing air quality data with a city model.
However, the aforementioned studies did not consider interoperable standards and integrate resources in a customized manner for different applications. No study has provided a general solution for integrating IoT standards and city models.

B. Integration Strategies
Most relevant studies have integrated city models and IoT resources at the application level without following any open standards. Only a few studies have adopted open standardbased data sets. However, the integration methods of these studies are usually customized according to the target applications. Although data can be linked using the aforementioned methods, the methods are insufficiently general for adoption in other applications. Before designing a general solution for integrating city models and IoT resources, we analyzed and categorized the integration strategies adopted in previous studies.
From a literature review, three types of integration strategies were identified (Table I): the 1) embedding; 2) external referencing; and 3) external joining strategies. These strategies are described as follows.
1) In the embedding strategy, one resource is embedded directly into another resource; for example, a time series of sensor observations are embedded into city model data, such as the CityGML 3.0 Dynamizer [32]. In this case, all the data are atomic. Nevertheless, the data size is large and inconvenient for updating dynamic information. 2) In the external referencing strategy, the relative or absolute path in one resource is used to retrieve another resource. For example, Kim et al. [33] derived the corresponding IndoorGML data set from a CityGML data set and then used a URI to back reference the IndoorGML data to the CityGML data. The external referencing strategy is more lightweight than the embedding strategy because every piece of information need not be embedded into one resource in the external referencing strategy. Moreover, dynamic information can be obtained through reference links in the external referencing strategy, such as the design in the OGC 3-D IoT platform for smart cities pilot [42]. This strategy also allows the referenced resources to be independent; thus, the referenced resources can be created and maintained as a single data set because they do not depend on any other resource. However, one minor drawback of the aforementioned strategy is that the data are not self-contained and may require connections to retrieve all the pieces of information. 3) In the external joining strategy, external data are created to describe and record the relationships between two resources. For example, Vilgertshofer et al. [34] defined a semantic linkage ontology and an RDF to integrate CityGML and industry foundation classes (IFC) data, as displayed in Fig. 2. To describe the relationships between resources, the URIs of specific IFC elements are mapped to the corresponding CityGML elements. This strategy allows all resources to be independent. The mapping relationships of these resources are relatively easy to update. The aforementioned strategy also enables the flexible processing of many-to-many mappings. However, one drawback of the aforementioned strategy is that it may be unable to find suitable linkages between resources because they are created independently. External joining is sometimes achieved by semanticbased approaches, and some studies have performed cross-domain integration based on semantic frameworks. For example, Kuo and Hong [35] constructed an interoperable cross-domain semantic and geospatial framework for automatically detecting changed objects and regions. Peng and Goswami [36] proposed a methodology in which an ontology is used to integrate home environment data (e.g., humidity and temperature) and health data (e.g., the blood glucose level) from heterogeneous services and devices for health management applications. Liu et al. [37] reviewed existing resource integration solutions, and their findings are presented in Table II. The aforementioned authors found that semantic Web technologies are the most suitable technologies for resource integration. Thus, the semantic-based approach has the potential to meet the requirements for storing, sharing, and connecting heterogeneous data sets.
In summary, in terms of development, extensibility, and maintenance, we believe that the external joining strategy and semantic-based approach are the most suitable methods for achieving comprehensive and extensible integration of city models and IoT open standards. This research aimed to integrate cross-domain resources from CityGML, IndoorGML, and SensorThings API; accordingly, an integration ontology that maps these resources is proposed in this article. In the proposed ontology, users can effectively query all the information across the aforementioned open standardbased resources to establish extensible and complete cyber infrastructure for smart cities.

III. METHODOLOGY
This study integrated the open standards of OGC SensorThings API, IndoorGML, and CityGML and utilized the advantages of these standards to construct a smart city framework. This section describes the aforementioned open standards and the proposed resource integration method.

A. OGC CityGML
OGC CityGML is a global open standard for city model information that represents the visual and geometric aspects of 3-D models of cities. The CityGML data model is sufficiently comprehensive and semantic rich for describing various thematic modules (e.g., bridges, tunnels, and buildings) and features (e.g., roofs, walls, windows, doors, and rooms) of a city. Moreover, five levels of detail (LoDs; from LoD0 to LoD4) are defined in the aforementioned model for various applications. Many city features, including the classes of building objects and relationships between each class, are defined in Fig. 3. As per the scope of this research, we focused on the citygml:Building class and its related classes. In particular, we examined the relationships between the classes of SensorThings API, IndoorGML, and CityGML LoD4.
The UML of CityGML includes the classes related to the citygml:Building class at LoD4 (e.g., citygml:Room, citygml:IntBuildingInstallation, citygml: BoundarySarface, citygml:BuildingFurniture, and citygml:Opening). The aforementioned classes are provided with geometric features to represent the geospatial information of objects, such as solid, multicurve, and multisurface. The UML diagram of CityGML also depicts the relationship between each class at LoD4 as well as the class's semantic information. For example, citygml:Building has interiorRoom citygml: Room, citygml:BuildingFurniture, has inte-riorFuniture of citygml:Room, citygml:Room is boundedBy citygml:BoundarySurface, citygml: Room has roomInstallation citygml:IntBuilding Installation, citygml:BoundarySurface has opening citygml:Opening. In addition, citygml:Door and citygml:Window inherit the class of citygml: Opening. According to the relationships proposed by CityGML, a data model with rich semantic relations was used in this research.
This research focused on the indoor space of buildings, including the objects inside the indoor space. Fig. 3  This class contains objects that are located inside a building and offer a special semantic meaning or function. In contrast to the objects of the citygml:Building Furniture class, the objects of the citygml: IntBuildingInstallation class are unmovable and inseparable from the building's structure. Objects in the citygml:IntBuildingInstallation class include railings, interior stairs, pipes, and radiators. The objects in this class are associated with objects from the citygml:Building or citygml:Room class.

B. OGC IndoorGML
CityGML focuses on the features of building components, including ceilings, roofs, walls, and floors, whereas IndoorGML [11] represents the indoor routing network between spaces (i.e., cells). In the IndoorGML data model, a cell is the basic space unit. Thus, IndoorGML offers a basic framework for representing the network, geometry, and semantics of cells within indoor spaces [39]. Indoor navigation applications, which are crucial smart city applications, can be realized with IndoorGML. Fig. 4 displays an example of an IndoorGML data set. In this figure, nodes and edges are used to form an indoor route network.
The UML diagram of the IndoorGML core module illustrates the relationships between individual classes as well as their semantic information. We used the navigation functionality based on an IndoorGML route network, which includes the indoorgml:State and indoorgml:Transition classes.
The indoorgml:State class represents nodes, such as the doors, corridors, and rooms within a building. The objects in the indoorgml:State class are represented geometrically as points in IndoorGML. The entities of the indoorgml:Transition class are edges that represent the connectivity or adjacency relationship between two indoorgml:State entities, such as doors, stairs, and elevators. The weight attribute of indoorgml:Transition indicates the status of connectivity. The entities of the indoorgml:Transition class are represented as curved primitive objects in the OGC Geography Markup Language.
The IndoorGML data model also includes the semantic information between classes; that is, an indoorgml: Transition entity connects two indoorgml:State entities. Because this research focused on the indoor space of buildings, rooms were regarded as indoorgml:State entities and doors and stairs were regarded as indoorgml: Transition entities.

C. OGC SensorThings API
OGC SensorThings API is an IoT open-standard Web service. A comprehensive model for IoT resources that contains numerous classes and attributes, including tasking and sensing capabilities, is defined by SensorThings API. Currently, the SensorThings API standard comprises two parts: part 1, which is related to sensing capabilities (Fig. 5), and part 2, which is related to tasking capabilities (Fig. 6). Each class in the SensorThings API standard is described in the following text.  For instance, if an entity of the sta:Thing class is capable of observing three properties, such as illumination, relative humidity, and air temperature, then this entity may correspond to three sta:Datastream entities, each of which groups the sta:Observation entities for one feature. 5) sta:Sensor: The entities of this class represent the instruments used to monitor a phenomenon or property. 6) sta:ObservedProperty: The entities of this class represent the monitored properties, including illumination, relative humidity, and air temperature.  Fig. 7. An entity of the sta:Thing class contains numerous attributes, including properties, a description, and a name. SensorThings API contains the aforementioned attributes as well as navigation links that connect related entities.
Generally speaking, SensorThings API is a comprehensive solution for an IoT Web service. A general and complete data model is defined in the aforementioned standard for IoT tasking and sensing. Moreover, to enable users to query targeted IoT resources, SensorThings API uses flexible query functions and the RESTful Web service style.
On the basis of the semantic information obtained from the SensorThings API data model, we constructed a lightweight ontology of SensorThings API, called the STA-LITE 1 ontology. The STA-LITE ontology describes semantic classes and the relationships between them. For example, the sta:Thing

D. Integration Strategy
This study adopted the semantic Web technology for integrating the SensorThings API, IndoorGML, and CityGML data models. The relationships between data from various domains can be flexibly and effectively described with the semantic Web technology.
"Things" can be defined differently according to the application, which creates a unique challenge in integrating city models and IoT resources. For example, the sta:Thing class can contain entities, such as doors, rooms, corridors, windows, appliances, and sensors. Therefore, different definitions of "things" should be considered during the integration of IoT resources and city models.
The semantic Web can express the relationships between resources and can integrate resources by linking their URIs; thus, independent data can be generated. An integration ontology capable of defining the relationships among the SensorThings API, IndoorGML, and CityGML data models is crucial for integrating IoT resources and city models. By developing such an integration ontology, data providers and users can determine the relationships between IoT resources and city models as well as perform cross-domain queries. In this research, three semantic Web standards were followed: ontology Web language (OWL), the RDF, and SPARQL.
The integration framework proposed in this study is shown in Fig. 8. A comprehensive data model with high extensibility and rich semantic information was used to individually record data from different resources in the RDF format according to their individual ontologies, such as the CityGML, IndoorGML-Lite, and STA-Lite ontologies. The following section details these ontologies. All the attributes and information of each piece of data (e.g., name, geometry, and observations) were completely recorded in an RDF file. The RDF describes relationships in the form of triples (i.e., subject-predicate-object).
According to the triples structure, the current study developed an integration ontology that characterizes the relationships between resources from the aforementioned three ontologies (Fig. 8).

1) Properties of the Resources in the Integration Ontology Framework:
In the proposed integration ontology, the relationship between sta:Observation and sta:TaskingCapability (i.e., observes and hosts, respectively) is described according to the Semantic Sensor Network Ontology 2 published by the W3C in 2017. W3C published another ontology called building topology ontology (bot) in 2019. The predicate of the bot (i.e., containsElement) is applied to the relationship that a zone or space (such as a room or building) contains an entity or element (e.g., a device or node). The CityGML ontology 3 was developed by Métral et al. [41]. We also constructed the indoorgmllite 4 ontology to describe the relationships between the indoorgml:State and indoorgml:Transition classes of IndoorGML (i.e., connects) as well as the indoorgml:State and indoorgml:MultiLayer Garph classes of IndoorGML (i.e., interConnects). The presented STA-LITE ontology describes the essential relationships between the classes of SensorThings API, such as hasTaskingCapability, hasDatastream, hasObservation, and hasObservedProperty.
In addition, we constructed suitable ontologies for defining relationships that are not described in existing ontologies, which is represented with the prefix cgis. 5 The defined relationships include isThing, isState, isTransition, isMultiLay-erGraph, happensIn, withinCellspaceOf, and enables. These predicates are introduced in the following sections.

2) Multiple Definitions of Things in IoT:
The relationships between the classes of the SensorThings API, IndoorGML, and CityGML data models can be expressed with the proposed integration ontology. Depending on the application, different views of sta:Thing entities should be considered, including the a-device-as-a-thing, an-opening-as-a-thing, a-room-as-a-thing, and a-building-as-a-thing views. In Figs. 9-12, CityGML, IndoorGML, and SensorThings API classes are displayed in blue, lavender, and yellow, respectively. a) A-device-as-a-thing view: Fig. 9 illustrates the adevice-as-a-thing view, in which the sta:Thing class in SensorThings API is mapped to the citygml: BuildingFurniture class. A CityGML resource can be directly linked with the sta:Thing class through the isThing predicate if the resource directly corresponds to an entity of the sta:Thing class. Additionally, the proposed integration ontology supports the relationships between a sta:Thing entity and a CityGML feature (which hosts the sta:Thing feature), such as citygml:BoundarySarface, citygml:Room,  citygml:IntBuildingInstallation, indoorgml: Transition, and citygml:Opening, even if there is no sta:BuildingFurniture feature directly mapped to the sta:Thing entity.
With regard to the relationship between the citygml: Room and indoorgml:State classes, an entity of the citygml:Room class can be represented as one node (i.e., isState) or several nodes (i.e., containsElement). The current research considers indoorgml:State as the entity of a cell; thus, when an entity of the sta:Thing class is located within the space of an entity of the indoorgml:State class, sta:Thing is with-inCellspaceOf indoorgml:State. Moreover, citygml: Opening enables indoorgml:Transition (i.e., a door or a window).
b) An-opening-as-a-thing view: Fig. 10 depicts the anopening-as-a-thing view, in which an entity of the citygml: Opening class (i.e., an entity of the citygml:Window or citygml:Door class) is an entity of the sta:Thing class. In the aforementioned view, sta:Thing can be recognized as a node (i.e., indoorgml:State) or an edge (i.e., indoorgml:Transition) according to the class definitions in IndoorGML. In the an-opening-as-a-thing view, an entity of the sta:Datastream class, which corresponds to an entity from the sta:Thing class, is capable of recording the state (e.g., closed or open) or additional information (e.g., the passage size) of the citygml:Opening class. The entities of the sta:TaskingCapability class represent the controllable actions that can be performed by a window or door actuator. The proposed ontology can also describe the relationships between the entities of the sta:Thing class and other CityGML entities.
c) A-room-as-a-thing view: Fig. 11 depicts the a-roomas-a-thing view. In the aforementioned view, an entity of the sta:Observation class observes a phenomenon that occurs in a room. The room is represented as a sta:Thing entity within the zone space that contains some indoorgml: State entities. The sta:Datastream entities comprise a set of sta:Observation entities for a certain sta: ObservedProperty entity.
Regarding the IndoorGML classes, a sta:Tasking Capabiltiy might also happensIn a indoorgml:State or indoorgml:Transition (e.g., locking or unlocking a door). For the relationships between the CityGML and IndoorGML classes, a citygml:Room entity may contain some indoorgml:State entities that cover a small geometrical space.
In particular, a sta:Thing entity may contain various entities (e.g., a thermometer, a buzzer, a door, a window, or the room) with sensing or tasking capabilities in the room. Thus, sta:TaskingCapabilities (e.g., turning an alarm on or off or changing the illumination) also happensIn the entities, and sta:Observations (e.g., relative humidity and air temperature) observes those entities.
d) A-building-as-a thing view: Fig. 12 illustrates the abuilding-as-a-thing view, in which buildings comprise numerous components (e.g., citygml:Opening, citygml: BuildingFurniture, and citygml:Room). The concept of a building containing numerous components and rooms has similarity with the a-room-as-a-thing view, in which several entities constitute the sta:Thing class. Therefore, in the a-building-as-a-thing view, a sta:Observation of a sta:Thing observes a phenomenon that could occur in a room, the building, or any entity of the building. Moreover, a sta:TaskingCapability happensIn a specific entity of the building (e.g., a room, a door, or an air conditioner). The relationships between the sta:TaskingCapability and sta:Datastream classes in the a-building-as-a-thing view are similar to those in the a-room-as-a-thing view.
Furthermore, entities of the indoorgml:MultiLayer Garph class, which represent different types of spaces in a building, can correspond to different building features. Entities from the indoorgml:MultiLayerGarph class can form a group of space layers in different domains. For simplicity, this research theorizes that an entity of the citygml: Building class can represent an entity of the indoorgml: MultiLayerGarph class (i.e., isMultiLayerGraph).
The proposed integration ontology is saved in RDF format. When this ontology is applied, IoT resources and city models can be integrated and presented in RDF format. Information obtained from different providers can be stored independently in a uniform manner on the basis of open standards. Furthermore, the semantic Web technology's flexibility allows the incorporation of the relationships in multiple sta:Thing views into the same data set, thus providing support for additional smart city applications.

IV. IMPLEMENTATION RESULTS
To verify the suitability of the proposed ontology, we adopted use cases requiring queries that link IoT resources and city models. In the proposed integration ontology, users can adopt SPARQL queries to obtain data. The use cases adopted for a smart health care system and a fire evacuation system are described in the following sections to prove the concept.

A. Testing Data Set of 3-D City Model
The data set of the R3 building in National Central University, Taiwan was adopted as the testing data set in this study. This research constructed the entities of the building and the indoor route network for the city model (Figs. 13 and 14), including the features defined in the CityGML, IndoorGML, and SensorThings API data models and integrated RDF data. 6

B. Use Case Implementation
To illustrate the importance of integrating city models and IoT resources, we implemented several simulated use cases in which the role of CityGML was to provide geospatial information (i.e., the geometry of objects, such as a room, door, or window). In addition, IndoorGML forms indoor route networks that support navigation applications. Furthermore, the tasking and sensing capabilities of a SensorThings API service are used for remotely controlling and monitoring features, respectively.   In the simulations, data integration was realized through the adoption of external RDF data obtained using the proposed integration ontology. The integration results of this study were verified with SPARQL queries.
1) Smart Health Care: In the smart health care use case, a patient' wearable device is considered a sta:Thing entity, which could also be seen as the patient. The wearable device on the patient produce three sta:Datastream entities from a heart rate sensor, an oximeter, and a radio frequency identification (RFID) tag. The heart rate sensor and oximeter record and monitor the physiological conditions of the patient. The RFID tag helps in recording the location of the patient (e.g., room name).
Query 1 retrieves the latest observation results of the heart rate sensor and oximeter (Table III)  FILTER regex(str(?AED), "AED") 7 } that a smart health care system can assist medical care personnel in monitoring the physiological condition of patients. Moreover, if the condition of a patient is abnormal, a smart health care system triggers a query to retrieve the location of the patient and activates a buzzer (i.e., an alarm) near the patient.
Query 2 searches for the latest RFID location of the patient (Table IV). Lines 14-18 are related to connecting the RFID location to a citygml:Room entity and an indoorgml:State entity as well as searching for a buzzer in the citygml:Room entity. The example result in Table IV indicates that the location of the patient "Simon" was near citygml:Room "R3-205" and indoorgml:State "Node-92" at 00:11 on May 11, 2020. The aforementioned table also indicates the sta:Tasking Capability entity of a buzzer that can help trigger an alarm. Finally, the indoorgml:State can help navigate medical care personnel to the patient while continuously monitoring physiological information.
In addition, for emergency situations, the smart health care system can help retrieve the positions of automated external defibrillators (AEDs). From a search for the indoorgml: State entities of AEDs (Query 3 and Table V), the shortest path from the patient (i.e., Node-92) to an AED can be calculated with the route network.  2) Fire Evacuation System: In the fire evacuation system use case, IoT devices can provide real-time smoke density and temperature observations and city models can provide spatial information and indoor navigation routes. To construct an effective fire evacuation system, city models and IoT resources must be integrated. Query 4 retrieves real-time observations of smoke density and temperature and checks if the results are abnormal. Lines 10 and 19 set thresholds for the observation results. If the smoke density is higher than 2000 ppm or the temperature is higher than 50 • C, then the fire evacuation system considers the situation to be an emergency. SPARQL Query 4 returns the data to the system if any result meets the thresholds. Table VI displays a situation in which the smoke density and temperature results meet the thresholds. In this case, the system triggers an SPARQL query to retrieve the corresponding sta: TaskingCapability entities of sprinklers and ventilation systems.
Lines 8 and 9 in Query 5 find the room associated with the sta:Thing entity that hosts the temperature sensor that obtains high readings. Lines 10-13 search for the indoorgml:State entity that represents the aforementioned room and other indoorgml:State entities that connect with this room to expand the query area for finding alarms. Lines 14-16 search for the sta:TaskingCapability entity of  ventilation systems, and buzzers can be retrieved through SPARQL queries (Tables VII and VIII).
The simulated fire evacuation system demonstrates the capabilities of real-time environment monitoring and emergency response. Although navigation functionalities were not examined in the use case of the fire evacuation system, safe evacuation routes can be identified on the basis of IndoorGML route networks and sensor observations. By integrating city models and IoT resources, fire evacuation systems can efficiently identify the disaster status and effectively assist evacuation-related decision-making.
Overall, the use cases adopted in this study indicate that the proposed integration ontology provides a uniform and effective method for integrating city models and IoT resources. In the proposed integration ontology, data can be created independently and various views of sta:Thing can coexist in the integrated RDF. Thus, because the semantic Web technology is flexible, this ontology is capable of integrating IoT resources and city models in an interoperable manner for various smart city applications.

V. CONCLUSION AND FUTURE WORK
This work introduces an approach to effectively supporting and integrating interoperable inter-data set queries between IoT resources and open standard-based city models for smart city applications. Specifically, this research designed an integration ontology that characterizes the relationships between the SensorThings API, IndoorGML, and CityGML data models in an indoor space with consideration of different views of "things" in the IoT. This integration ontology can be used to integrate data from various resources for supporting different smart city applications.
To demonstrate the necessity and potential benefits of integrating IoT resources and city models, this research simulated two use cases, including a smart health care system and a fire evacuation system. Data from different resources can be retrieved through SPARQL queries through descriptions of the integration relationships in RDF format with the proposed ontology. The simulation results indicate that the proposed ontology successfully integrates IoT sensing and tasking capabilities with city models. Such integration can serve as an essential aspect of the cyber infrastructure of a smart city.
For achieving more comprehensive integration, future studies can incorporate additional semantic-rich open standards of city models and IoT resources, such as the BIM and W3C WoT standards, into the integration ontology. Because some relationships may be missing in the proposed integration ontology, additional relationships, such as geometrical relationships or relationships between "things," can be identified and described in future studies. Moreover, because the semantic Web technology is flexible and extensible, cross-domain integration can be efficiently, effectively, and continuously improved. The proposed ontology could also be presented to the OGC community for extending it as an OGC standard. The proposed integration ontology involves manual integration. Future studies can design approaches to automate this process. In addition, implementing the integration with new technologies, such as blockchain, fog computing, AI, would also be interesting discussions. Finally, the proposed ontology could serve as the foundation of a "digital twin" infrastructure to support real-world smart city applications and use cases.