2. Background

2.1. Person-to-Place Interactions in Post COVID-19 Workplace Reopening Scenarios
The IoCT offers various use cases based on the digital monitoring of the physical world and humans using smart sensors that collect and deliver information. For this paper, we explored different COVID-19 transmission risks in miscellaneous workplace reopening scenarios. “Close contact” with a COVID-19 patient, which mostly occurs indoors, was one of the most common methods of COVID-19 transmission [4,25]. Based on our literature review, COVID-19 “close contact” was defined as contact occurring within a period of time longer than 15 min, and a physical distance of less than 2 metres in cases of face-to-face interaction [25]. When sharing the same space, viruses can spread via air, objects, or floor even after two to three days if protective equipment is not used, or disinfection carried out [4]. A digital timely proximity tracing system can effectively limit the spread of contagious diseases by collecting information about people or places that an individual (with confirmed or suspected infection) may have had close contact with or had been to [14]. If a person with COVID-19 was in close proximity to a place, those affected locations (e.g., businesses, public sites, or buses) would then be considered contaminated places (geospatial features). This geospatial information can be used to help in closing, disinfecting, alerting, and defining appropriate safe paths and neighborhoods. For example, if a location is popular with families or the elderly, additional facilities and organizations in the area may need to be alerted to possible exposure in their neighborhood. Health workers will receive timely and relevant alerts to close off and disinfect the actionable list of contaminated places to prevent further transmission. Moreover, organizations at each location can be provided with forms to send to their staff, customers, or visitors informing them of possible contamination, and requesting that they complete a contact trace survey for health authorities.
Three important questions in COVID-19 risk evaluation are: “Who was in close contact with the COVID-19 positive person?” and “What places did the COVID-19 positive person visit, and who else visited those places after that?” The first question can be automatically queried using person-to-person contact tracing. The second question addresses the main focus of this paper which is person-to-place contact tracing. If a COVID-19 positive person was in close proximity to a place, those affected locations (geospatial features such as businesses, or public sites, or buses) are considered to be potentially contaminated places. This information is useful for advising people on safety measures, self-quarantine, and for issuing cleaning alerts. As shown in Figure 1, both people and places, as well as duration of contact, play an important role in the pattern for COVID-19 spread.
The primary step when assessing the COVID-19 virus transmission scenarios is determining the factors affecting the risk of COVID-19 spread. According to [26], COVID-19 risk prevention and control depend on population flow. For this research, the epidemic risk status is assessed based on three levels of personnel flow strategies: (1) Staying at home, temperature monitoring, and traffic control; (2) Wearing a mask and restricting gatherings; and (3) Strengthening health management. Additionally, based on existing studies from both the World Health Organization (WHO) [27] and the Government of Canada website [28], the number of active virus particles in a place is considered to be the most critical factor in determining the risk of infection. Virus particles live for different lengths of time which vary depending on several factors, especially with regards to the composition of different surfaces. To identify and limit the risk pattern of COVID-19, a range of use cases can be considered that utilize the interactions of people, places, and available sensor information for a workplace. The following table (Table 1) sums up the office cleaning use case using person-to-place scenarios for post COVID-19 workplace reopening.

2.2. Interoperability Using the OGC SensorThings API
Interoperability is a major challenge for the IoT. The real potential of IoT lies in the “systems of IoT systems” rather than with disparate IoT silos [29,30]. An interoperable IoT system of systems provides a uniform way for sharing, finding, and accessing IoT sensing and tasking capabilities, the Internet, and different applications [31]. Interoperability requires layers of standards in order to address the heterogeneity issues amongst sensors, data, and networks [32]. Data and sensor interoperability refer to the ability to exchange and understand data formats, protocols, and sensor models. Network interoperability has no value if the bits and bytes are delivered but cannot be interpreted, i.e., if the data being exchanged over the network cannot be understood by machines a priori. Further, various levels of interoperability include synthetic, semantic, and cross-domain interoperability which mean the standardization of conceptual models, practices, and policies from disparate systems.
The OGC SensorThings API (OGC STA) [22,25] is an OGC and United Nation’s International Telecommunication Union Telecommunication (ITU-T) standard that defines a data model and an API for IoT sensing and tasking interoperability. The OGC STA is part of the well-established OGC Sensor Web Enablement (SWE) suite of open international standards [23]. SWE standards are in use by many large-scale organizations such as the Department of Homeland Security (DHS) [33], National Aeronautics and Space Administration (NASA), National Oceanic and Atmospheric Administration (NOAA), United States Geological Survey (USGS) [34], Natural Resource Canada (NRC), the World Meteorological Organization (WMO), and many others, including private sector companies [29,35,36]. The previous generation of SWE standards, such as the Sensor Observation Service (SOS), are heavyweight when it comes to running applications in edge devices with limited resources [37]. OGC STA represents the new generation of SWE standards that was specifically designed for IoT applications and is thus efficient and lightweight, e.g., it uses the REpresentational State Transfer pattern (RESTful) and the efficient JSON encoding. The OGC SensorThings API follows the ODATA (Open Data Protocol) for managing the sensing resources. As a result, it has a REST-like API and supports the Hypertext Transfer Protocol (HTTP) create, read, update, and delete operations (i.e., GET, POST, PATCH, DELETE) and ODATA query options (select, expand, filter, orderby, top, skip) for data retrieval [38]. In addition to supporting HTTP, the OGC SensorThings API has an extension for supporting Message Queuing Telemetry Transport (MQTT) for the creation and real-time retrieval of sensor Observations [39].
The OGC STA enables interoperability for two layers: (1) Service interface, and (2) Data model [40]. With regards to the service interface layer, the STA defined a RESTful pattern, based on the OASIS OData standard, that allowed different STA services to exchange and filter entities defined by the STA data model. As for the data model aspect, the STA data model was based on the International Organization for Standardization (ISO) and OGC Observation and Measurement standard model [41]. As a result, the data model can interoperate and is backward compatible with the OGC Sensor Observation Service (SOS) Web service. The following UML diagram describes the entities of the STA data model. In the OGC STA, every Thing can have zero or more locations in space or time ((Figure 2). Furthermore, each Thing can have zero or more “Datastreams”. A Datastream is a collection of “Observation” entities grouped by the same “ObservedProperty”. An Observation is an event performed by a “Sensor”, that is a process producing a result with a value that estimates the ObservedProperty of a “FeatureofInterest”.
The OGC STA provided an interoperable framework with which to build the proposed IoCT. STA’s O&M-based data model and query functions have been shown to work for a very wide range of IoT systems from simple weather stations to complex drone systems. By using the OGC STA, we were able to develop an IoCT that interconnects heterogeneous IoT devices, data, and applications over the Web. In order to deal with the pandemic’s fast-changing requirements, IoT developers need an established working architecture that will work not only for today, but also for future, COVID-19 applications. In addition, healthcare applications are often near real-time and need to be scalable and performant, i.e., able to accommodate a very large number of devices that are sending high frequency data simultaneously without sacrificing performance. The goal for the IoCT is to build an interoperable foundation for future expansion and integration using various existing and new COVID-19 IoT applications.

2.3. Interior Space Modelling Using IndoorGML
Indoor spaces differ from outdoor spaces in many aspects. Basic concepts, data models, and standards of spatial information need to be redefined in order to meet the requirements of indoor spatial applications. The proper representation of indoor spaces is a key issue for indoor spatial information modelling and analytics. In recent years, the topic of 3D geospatial indoor modelling has been the focus of attention for location-based services and indoor navigation [42,43,44]. As the risk of COVID-19 virus transmission is higher in indoor environments, indoor space modelling is an important topic that facilitates the interoperability between different indoor and outdoor data collection methods and builds a consistent framework for collaborative research and development of the IoCT.
Aggregating different sensor observations for each room is essential for estimating the room’s COVID-19 risk and cleaning requirements. The visualization of Interior Space Risk State is another task which requires interior modelling. In order to represent the risk of infection and to identify which specific areas of a building require the most cleaning, the status of individual floors should be able to be viewed separately from other floors in the building. The risk of infection for various parts of each floor should be represented in a map with different ways of representing the data that is necessary for determining the risk in each area. Moreover, in order to visualize trajectories for contact tracing and to quickly identify the location of infection spreading behavior within an indoor space, the buildings should be visible as a 3D construct on the map. Therefore, in order to analyze the IoCT multi-sensors system and visualize it in indoor scenarios, an interoperable 3D building modelling standard, such as the “CityGML” Level of Detail 4 [45], “OGC IndoorGML” [46], building construction standards (e.g., “Building Information Modelling” (BIM), or “Industry Foundation Classes” (IFC) [47]), is necessary. The main concern for using those models is their fit and how often they are updated. Construction features of indoor spaces are not a major focus of COVID-19 workplace reopening scenarios. Instead, the aggregation of sensors in each room, and the connectivity between the rooms, is fundamental for risk assessment and tracing. Thus, the OGC IndoorGML is used for the IoCT indoor modelling. According to Ryoo et al. [43], the OGC IndoorGML can be used more effectively than CityGML or any other geometric representations of space for analyzing the trajectories of people inside buildings. This allows for more accurate appraisal of the types of intersection of trajectories, contact, and exposure for infection risk evaluation. Applications such as cleaning risk assessments for COVID-19 workplace reopenings that need to operate efficiently together with indoor scales, various sensors, and objects that are moving and changing over time would benefit from using the OGC IndoorGML. 3D geometry can be included in an IndoorGML document, and the overlap with other standards (e.g., OGC CityGML) can be addressed by adding external references.
There were no specific standards in the field of indoor geospatial modelling until the OGC standard IndoorGML was introduced in 2014. The OGC IndoorGML intentionally focused on modelling indoor spaces using connected dual graphs for navigation purposes whilst considering various semantics [46]. OGC IndoorGML standard specifies an open data model and Extensible Markup Language (XML) schema for indoor spatial information [46]. Indoor space is comprised of connected constructs such as rooms, corridors, stairs, and elevators, all of which can be considered “Cells”. This sets it apart from other standards in the field of 3D modelling, such as CityGML or IFC, as they model the building features (e.g., walls, windows) instead of the indoor space itself. They also do not consider the connectivity and semantics of indoor spaces.
As shown in Figure 3, the nodes of the IndoorGML graph in this paper are considered the smallest organizational or structural units for the building and are called Cells [19]. Every Cell has an identifier (e.g., room number) and a location (x, y, z) to provide more precise location details. Cells are connected and have a common boundary with other cells but do not overlap with them. “Geometric” features and “Topological” relationships, such as adjacency and connectivity, amongst indoor cells can be defined by an IndoorGML graph [48]. The topological relationships in IndoorGML are explicitly described using the xlink concept of XML provided by Geography Markup Language (GML) and the referencing is realized with the use of href attributes (xlink:href). Semantics are also an important characteristic of the Cells in the IndoorGML. “Semantics” allow us to define cells which can be important for cleaning risk assessment. For example, the most commonly used areas are public rooms, corridors, and doors, and thus present higher risk. For this paper, an indoor space is represented as a topographic cellular space comprised of rooms, corridors, and stairs. At the same time, it is also represented as different cellular spaces with beacon or camera coverage Cells.
Each semantic interpretation layer creates a different indoor model, and each model forms a separate dual graph layer (e.g., connectivity, sensor) for the same cellular space. This multi-layered space model (Figure 3), is an aggregation of the space layers and inter-layer connections or relations. The Indoor GML for the implementation of the structure space model is shown in Figure 4.