# Modeling Inhabited Smart Spaces to Support Interoperable IoT-Based Applications

Roberto Yus, Nada Lahjouji, Georgios Bouloukakis, Sharad Mehrotra, Nalini Venkatasubramanian

► To cite this version:

Roberto Yus, Nada Lahjouji, Georgios Bouloukakis, Sharad Mehrotra, Nalini Venkatasubramanian. Modeling Inhabited Smart Spaces to Support Interoperable IoT-Based Applications. The 26th IEEE International Conference on Mobile Data Management, Jun 2025, Irvine (CA), United States. hal-05066396

HAL Id: hal-05066396

https://hal.science/hal-05066396v1

Submitted on 13 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Modeling Inhabited Smart Spaces to Support Interoperable IoT-Based Applications

Roberto Yus†, Nada Lahjouji*, Georgios Bouloukakis§, Sharad Mehrotra*, Nalini Venkatasubramanian*

ryus@umbc.edu, {nlahjouj,sharad,nalini}@uci.edu, gbouloukakis@upatras.gr

†University of Maryland, Baltimore County, USA, *University of California, Irvine, USA, §University of Patras, Greece

**Abstract**—IoT deployments in smart spaces can enable the development of useful services for their inhabitants. However, the diversity of smart spaces and their sensor infrastructures makes it challenging to develop space-agnostic applications. Moreover, existing schemas addressing interoperability challenges often lack the vocabulary needed to represent the integration of smart space systems and their inhabitants. We present a schema to annotate inhabited smart spaces in support of inhabitant-oriented applications. Our schema integrates well-known ontologies to represent inhabitants, events/activities, and the space itself, along with their interconnections. It also supports the representation of uncertain information from IoT and mobile sensors (e.g., a person's location or occupancy/attendance at an event). Additionally, we introduce an annotation tool that uses an easy-to-use GUI to describe a smart space based on our schema. We demonstrate the potential of our approach through a series of SPARQL queries and a system deployed at the UCI campus that annotates sensor data to support a space-agnostic occupancy monitoring application.

**Index Terms**—Internet-of-Things, interoperability, schema

## I. INTRODUCTION

With the advent of the Internet of Things (IoT), our living and working spaces are becoming increasingly intelligent. Modern buildings, traditionally managed by building management systems (BMS) to optimize operations and occupant comfort, now incorporate various off-the-shelf IoT and mobile devices. For example, WiFi Access Points (APs), Bluetooth beacons, video cameras, and smartphones can localize occupants within a building [1], [2], [3], [4], thereby enabling from personalized thermal comfort [5], [6], [7], [8] to monitoring of adherence to regulations—including social distancing, occupancy limits, and contact tracing [9], [10], [11], [12], [13], [14]. In all cases, humans are integral to the operation of these smart spaces, and IoT systems thus pave the way for developing inhabitant-oriented smart space applications [15].

A major challenge in developing such applications is IoT data management and particularly semantic interoperability [16], [17], [18]. Smart spaces deploy diverse systems and sensors/actuators from various manufacturers, resulting in inconsistent data formats and a lack of uniform standards. This heterogeneity complicates the creation of space-agnostic applications that can seamlessly interoperate across different systems. Ontologies—particularly within the Semantic Web of Things framework [19]—offer a means to bridge the gap between manufacturers and systems in IoT environments [20]. Recent initiatives [21], [22], [23], [24] have proposed schemas to standardize the definitions of sensors and systems. However, they lack appropriate schemas and vocabularies that connect

inhabitants to the operational systems of these spaces, despite the goal of smart spaces being to benefit their occupants.

We propose a schema, INHAB, to facilitate the development of sensor-based, space-agnostic, inhabitant-oriented smart space applications. INHAB supports representations of inhabitants, activities, and spaces, along with their interconnections. Adhering to best practices for reusability and interoperability, we reviewed standard and popular ontologies, extending and aligning them with INHAB when necessary. INHAB introduces new vocabulary focused on two representations: 1) Detailed spatial metadata to model the hierarchical relationships among spaces (e.g., buildings within a campus, floors within a building). This facilitates efficient data flow, manipulation, and reasoning—e.g., by discarding sensor data from spaces that are not hierarchically connected to the space where the user of interest is located. 2) Information related to individuals and activities that may be uncertain, such as their location and attendance at events. This information is typically gathered automatically from sensors but remains uncertain due to the inherent imprecision of the raw data. In summary, the main contributions of this paper are:

* A schema that represents sensorized, inhabited smart spaces in a fine-grained manner, including inhabitants, events/activities, and the space itself.

* A vocabulary to capture uncertain information about smart space inhabitants—such as their location and activity attendance/occupancy—derived from underlying sensors.

* A set of sample SPARQL queries that leverage the schema to enable interoperable, inhabitant-oriented applications.

* An annotation support system that simplifies schema-based annotation and reduces potential errors.

INHAB enables inhabitant-oriented smart applications to be space-agnostic. For example, an application using such a schema to monitor occupancy could operate seamlessly in a smart city, office building, or home, regardless of the underlying sensor/system infrastructure. We demonstrate this through a system deployed on our campus built around a Knowledge Graph (KG) that contains data on: campus buildings, sensor deployments, activities, and WiFi connectivity data captured and annotated from hundreds of WiFi Access Points detecting smartphones carried by people. An application executes SPARQL queries on the KG to monitor occupancy across various buildings, floors, and regions. Additionally, we
present experiments that explore potential scale and perfor-
mance challenges to be faced in developing space-agnostic
applications for large smart spaces.

II. BACKGROUND AND RELATED WORK

**Semantic Web Technologies.** Ontologies [25] are essential for modeling semantic knowledge, sharing definitions, and achieving interoperability through a unified content annotation model. They comprise instances (objects), classes/concepts (hierarchical sets of instances), and properties/attributes (relationships). Ontologies are defined using formal languages like RDF [26], RDF-S [27], and OWL [28]—with RDF capturing basic resource information, RDF-S extending it with relationships (e.g., subclassing), and OWL providing additional expressiveness through constraints. They represent data as triples (s, p, o), where s is the subject (resource), p is the predicate (an aspect of the resource), and o is the object. SPARQL [29] is a standard language used to query and manipulate triples and RDF data.

**Related Work.** Several ontologies have been proposed to represent smart space information from general sensors and systems in buildings, to topological components of smart spaces. The Semantic Sensor Network (SSN) ontology [21] provides a vocabulary to describe sensors, their observations, actuators, and their association with features of interest. Its core is the SOSA (Sensor, Observation, Sample, and Actuator) ontology [30], a lightweight vocabulary that underpins these descriptions. Similarly, the Smart Applications REFerence Ontology (SAREF) [31] describes IoT sensor-based systems, where devices make measurements related to properties of features of interest. Extensions such as SAREF4BLDG [32] further include vocabularies to represent specific sensors in commercial buildings and their basic topologies, reusing the GEO ontology [33]. SSN and SAREF enable defining a smart space in terms of its sensor infrastructure, captured observations, and their relation to features of interest—whether spaces or inhabitants. Project Haystack [22] aims to standardize information from smart devices in buildings, focusing on automation, HVAC, and lighting. Its ontology defines buildings and spaces (with basic metadata), equipment (e.g., meters, boilers), points (sensors and actuators), and weather stations. Similarly, the Brick schema [24] describes building sensor infrastructures by detailing system installations (such as cameras, electrical systems, HVAC) and associating data points with specific locations (buildings, floors, or rooms). The Building Topology Ontology (BOT) [34] offers a lightweight schema for explicitly defining topological relations—such as containment, adjacency, and intersection—between zones (e.g., sites, buildings, storeys). BOT also enables linking to files or other ontologies that describe a zone’s 3D model, though it does not represent the actual geometry.

While these ontologies adequately model specific aspects
of smart spaces, their primary focus on sensor infrastructures
leaves a gap in describing interactions between people and
their environments. Moreover, a more fine-grained representa-
tion of spatial topology is necessary for applications that need

to understand the relationship between precise occupant loca-
tions and sensor coverage areas. INHAB, which aligns with all
the aforementioned ontologies (as detailed in Section III), pro-
vides a comprehensive schema for representing people, events,
detailed spatial topologies, and spatial-temporal events—such
as occupant locations and space occupancy—derived from the
underlying sensor infrastructure of smart spaces.

**Motivating Use Cases.** The following use cases illustrate the need to support space-agnostic inhabitant-oriented apps.

*Use Case 1: Occupancy monitoring* helps in optimizing the use of diverse smart spaces [35]. For example, a student might want to know how busy the library is before planning a study session, while the administrator of an office may need to determine if certain areas are underutilized. This was also useful during the COVID-19 pandemic to monitor adherence to occupancy regulations [36] and could be beneficial in future pandemics, as well as in everyday situations.

*Use Case 2: Privacy compliance* for smart spaces collecting personal data [37] may soon be required with evolving privacy regulations. A smart space application could assist inhabitants in exercising their privacy rights by leveraging knowledge about their interactions with the space. For example, it could help an admin determine which cameras in a smart shopping mall might have captured an individual’s image.

*Use Case 3: Human-centric building automation*, such as personalized thermal comfort optimization, can significantly reduce energy consumption and improve productivity [38]. However, HVAC adjustments require time to take effect and are only beneficial when people remain in the space. To optimize HVAC operation, an application must consider room schedules, real-time occupant locations, and attendance data [39]. Additionally, historical attendance patterns can help predict future building occupancy and improve planning [40].

The diversity of sensing infrastructures poses challenges for developing sensor-agnostic applications that work across different environments [41]. For instance, various IoT and mobile sensors—such as WiFi access points, Bluetooth beacons, motion sensors, and video cameras—can help track the presence of people in a space. Also, understanding the sensing infrastructure is not enough; applications need to obtain information such as spatial dimensions, pathways, occupancy levels, visited areas, and attended activities. To address this, applications require a common vocabulary that abstracts high-level information about spaces and human interactions. Moreover, a standardized vocabulary would facilitate cross-space analysis—enabling, for instance, comparisons of occupancy patterns in different smart spaces.

III. PROPOSED SCHEMA

INHAB (see Figure 1) centers around three fundamen-
tal and interrelated concepts in an inhabited smart space:
(i) Space/Location and its Geographical Features – empha-
sizing the hierarchical structure of spaces. (ii) People and
Their Profiles – representing the individuals interacting with
the space. (iii) Activities – describing events occurring within
the space. A fourth element, the IoT system and sensors, has
already been extensively addressed by existing ontologies. In our schema, activities occur in spaces and involve people, who, in turn, influence environmental phenomena detected by sensors. For instance, meetings take place in meeting rooms, and lunch happens in cafeterias. Employees visit these spaces for activities, which impacts occupancy levels.

Following Semantic Web and ontology engineering principles, we prioritize the reusability of well-established ontologies: 1) People: FOAF [42], DX-Prof [43] 2) Activities: RDFcal [44], OWL-time [45] 3) Locations: GEO [33], GeoSPARQL [46] Additionally, we align our schema with SSN, SAREF, Brick, and BTO ontologies (Section II). We use `owl:equivalentClass` to declare class equivalencies and `rdfs:subClassOf` to define hierarchical relationships. Moreover, we link concepts from our schema to external schemas as property ranges, enabling seamless federation of information across different ontologies. Subsequent sections detail each INHAB's module. Here we outline key relationships within INHAB and its alignment with prior ontologies.

<figure><img src="image_2.png" /><figcaption>Fig. 1: High-level specification of the INHAB ontology.</figcaption></figure>

People (`inhab:Person`) and Activities (`inhab:Activity`) are subclasses of Features of Interest in SOSA and SAREF. They are also Spatial-Temporal Things (`inhab:SpatialTemporalThing`), meaning they exist in a specific place and time. In contrast, sensors, equipment, and fixed infrastructure are Spatial Things with static locations.<fnref n="1" /> Spatial-Temporal Things have associated Spatial-Temporal Status (`inhab:SpatialTemporalStatus`), defining their position with certainty or uncertainty. For instance, a certain location defines fixed activity locations and an uncertain location represents sensor-detected positions (e.g., WiFi APs, Bluetooth beacons, cameras), accounting for sensor and inference uncertainty. Hence, a person might be located: in Building B with 100% confidence; on the 2nd floor with 100% confidence; in Room 201 (75%), or Room 202 (25%).

To ensure self-containment, our ontology includes `inhab:Sensor` and `inhab:Observation`, required for

defining sensor coverage areas (`inhab:isCoverageOf`) and observations supporting uncertain location data (`inhab:extractedFrom`). However, INHAB does not aim to redefine sensor schemas; instead, these classes are made equivalent to their counterparts in SSN/SOSA and SAREF, ensuring compatibility with existing sensor ontologies.

`inhab:Location` is aligned with Brick and BTO ontologies, which are themselves linked to other lightweight building topology ontologies, such as SAREF4Building [32], DogOnt [47], and ThinkHome [48]. Thus, INHAB seamlessly integrates into broader smart building knowledge graphs.

## A. Activity & People Representation

INHAB's Activity Module (see Figure 2) is designed to represent events and activities occurring in smart spaces. It includes metadata such as the event name, description, category, duration and date, and recurrence patterns. The module extends two standard W3C ontologies to describe activities: RDF Calendar Ontology (RDFcal) [44] – for calendar-based event metadata (e.g., descriptions, categories, comments, summaries). OWL-time Ontology [45] – for duration and time-related properties. Integration is achieved through the definition of an `inhab:Activity` class, equivalent to the `ical:vEvent` class in RDFcal which ensures compatibility with its rich event metadata.

<figure><img src="image_3.png" /><figcaption>Fig. 2: Activity module of the INHAB ontology.</figcaption></figure>

Recurring activities are particularly important for smart space optimization applications, for instance optimizing energy efficiency – by adjusting the HVAC based on when rooms are predicted to be empty. Despite prior research [49], [50], there is no widely accepted standard representation for recurring events. INHAB introduces the `inhab:RecurringActivity` class, incorporating repetition patterns (day of the week and interval between occurrences) and OWL-time ontology classes to express recurrence intervals (e.g., days, weeks, months, years).

INHAB's People Module (see Figure 3) enables the definition of inhabitant's metadata and their relationships to locations and activities. This module integrates: FOAF (Friend of a Friend) [42] – for defining metadata such as names and affiliations of individuals and relationships to groups

<footnote n="1">¹An exception can be made for mobile sensors by subclassing `inhab:SpatialTemporalThing` and `inhab:Sensor`.</footnote>
and organizations within a building. W3C Profiles Vocabulary (DX-Prof) [43] – for defining hierarchical profiles, e.g., Faculty (comprising assistant, associate, and full professors) and Building staff (security, maintenance, administration). The module includes properties to define their preferred locations (e.g., personal offices, common workspaces) and scheduled event participation (used to anticipate room occupancy [1]).

<figure><img src="image_4.png" /><figcaption>Fig. 3: People module of the INHAB ontology.</figcaption></figure>

## B. Location Representation

Inhabitant-oriented applications require a finer-grained representation of locations. This includes geometrical details – GPS coordinates, floor plans, dimensions - and topological relationships – contiguity, containment, connectivity. INHAB extends traditional location modeling by incorporating the hierarchical structure of spaces (e.g., a room within a building), spatial relationships (e.g., adjacent, overlapping, or disconnected spaces), and connection properties (e.g., hallways linking rooms). Figure 5 depicts how INHAB models locations while Figure 4 provides a concrete example of a spatial hierarchy and connectivity within a smart space.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Example smart space to be represented: (a) Campus-Level, (b) Building-Level, (c) Floor-Level, and (d) Room-Level.</figcaption></figure>

**Representing Topological Relations.** Locations within a smart space have a hierarchical structure. For example, Figure 4 illustrates a nested spatial hierarchy for a building complex with three floors where one of the floors contains five rooms and a corridor, and one of the rooms contains eight cubicles and a corridor. Representing this structure enables applications to perform inferences based on it (e.g., if a room's occupancy is 42, then the occupancy of the floor/building where the room is located has to be at least 42).

INHAB includes vocabulary to explicitly define topological relationships: 1) The containment relationship property (`inhab:containsLocation`) defines a hierarchical structure where a space is contained within another. Using OWL $2^2$ capabilities we define this property as asymmetric (if A

<figure><img src="image_6.png" /><figcaption>Fig. 5: Location module of the INHAB ontology.</figcaption></figure>

contains B, B cannot contain A), irreflexive (a space cannot contain itself), and transitive (if A contains B, and B contains C, then A contains C). 2) The global root node (`inhab:Earth`) acts as a universal reference point for locations, ensuring consistency across domains. This also simplifies application development since applications can assume that the higher level of the hierarchy of any space where they operate is directly connected to the global root node.

By aligning `inhab:Location` with GeoSPARQL's `geo:SpatialObject` [46], our ontology supports topological relations from the ISO Simple Features standard [51], such as: Containment (`geo:sfContains`), adjacency (`geo:sfTouches`), overlap (`geo:sfOverlaps`), intersection (`geo:sfIntersects`), and disjointedness (`geo:sfDisjoint`). These relationships are useful for applications such as sensor coverage analysis, where a camera's field of view (as a spatial region) determines which areas it monitors.

**Extent of a Location.** INHAB enables the definition of implicit topological relations through the concept of an *extent*, which represents the spatial region associated with a location. To maintain flexibility and generality, each extent can be defined with different geometries and coordinate systems (e.g., GPS or Cartesian). Thus, each extent must be associated with two geometries representing: 1) The spatial region that the location occupies within its parent location, using the parent's coordinate system (referred to as the *area*, linked via the `inhab:hasArea` property). For example, building B has an area defined by the rectangle in Figure 4(a) (using GPS coordinates) that delineates its position within the campus. 2) The spatial region, along with its own coordinate system, in which the location's children are represented (referred to as the *boundary*, linked via the `inhab:hasBoundary` property). For building B, the boundary is shown as the bounding box in Figure 4(b) covering its three floors. A boundary is required only if the location changes the coordinate system relative to its parent (e.g., a building defined using GPS coordinates might require its floors to use a Cartesian system based on

<footnote n="2">²https://www.w3.org/TR/owl2-primer</footnote>
their floor plans)<fnref n="3" />. The boundary thus defines the range of coordinate values that any child space can assume (e.g., a floor may specify that rooms within it use a Cartesian system with a range from < 0, 0, 0 > to < 100, 100, 0 >).

Basic geometric shapes in INHAB (e.g., lines, polygons, and triangles) are defined using GeoSPARQL's vocabulary (in turn adopted from the standard Simple Features ontology [51]). A geometry is associated with a `inhab:Point` defined by coordinates in a specific coordinate system. INHAB includes the concepts of *Coordinate* and *Coordinate System* and introduces two basic examples that can be extended: `inhab:GPS` (used to define the area of a building relative to the earth) and `inhab:Cartesian` (used for floor plans of a specific floor in 2D - x,y -, building layouts in 2.5D - x,y,floor -, and precise room locations in 3D - x,y,z -).

When defining a location's geometry with respect to its parent (i.e., the area), the geometry must use the parent's boundary coordinate system. For instance, if the boundary of the building complex in Figure 4 is defined using a GPS coordinate system, then each building's area must also use GPS coordinates. In our model, the special instance `inhab:Earth` is associated with a GPS coordinate system, so any area defined as its direct child must use GPS coordinates. It is also not compulsory to define boundaries for every location; for example, cubicles in Figure 4(d) may have only an area defined relative to the room if further subdivision is unnecessary. To illustrate the above, the following triples show the definition of the building complex and building B2:

```
{
    (BuildingComplexA, inhab:hasExtent, ExtBCA)
    (ExtBCA, inhab:hasCoordinateSystem, inhab:GPS)
    (ExtBCA, inhab:hasArea, AreaBCA)
    ...
    (AreaBCA's GPS coordinates definition) ...
    (BuildingComplexA, inhab:containsLocation, B2)
    (B2, inhab:hasExtent, inhab:ExtB2) (ExtB2,
        inhab:hasCoordinateSystem, inhab:Cartesian) (ExtB2,
        inhab:hasArea, AreaB2)
    ...
    (AreaB2's GPS coordinates def. w.r.t. BCA) ...
    (ExtB2, inhab:hasBoundary, BoundB2) (BoundB2,
        inhab:hasTopLeftPoint, P1) (P1, inhab:hasCoordinate,
        C1) (C1, inhab:x, 100) (C1, inhab:y, 100) (C1,
        inhab:floor, 3)
    ...
```

Note that the building's definition uses a different coordinate system—Cartesian—than that of its parent, which uses GPS. Consequently, the definition includes an additional geometry specifying that the floors of B2 must be defined with respect to the bounding box < 0, 0, 0 > to < 100, 100, 3 >.

Finally, we introduce a special subclass of location, `inhab:Portal`, to represent travel paths across spaces. This addition is essential for enabling path planning and depicting potential trajectories of people within the smart space. Like any other location, a portal can have an associated extent to represent it relative to its parent. Moreover, the portal features a special property, `inhab:hasConnectedSpace`, which indicates the spaces it connects. For example, in Figure 4(c), portal `p1` connects room R4 with corridor `Col`.

### C. Spatial-Temporal Representation

The two main concepts in our inhabited smart space schema—people and activities—are, unlike most smart space sensor systems, tied to a specific location at a given time. This means a person may be located on a particular floor at one moment and move to another later, while an activity occurs in a room for a defined period. We model these scenarios by incorporating spatial-temporal concepts (see Figure 6). First, each spatial-temporal entity (person or activity) is associated with a `inhab:TemporalPosition`, a subclass of `time:TemporalEntity` from the OWL-time ontology [45] that provides properties for its beginning, end, and duration. Second, each spatial-temporal entity is linked to a location. We distinguish between a certain localization—defined through the `inhab:hasLocation` property—and an uncertain one. For example, while the location of an activity is usually certain, the location of a person obtained via building sensors might be uncertain. To model uncertainty, we introduce the class `inhab:UncertainLocation`, which includes an associated specific location, a confidence value representing the reliability of the computed localization, and the sensor(s) used.

<figure><img src="image_7.png" /><figcaption>Fig. 6: Spatial-temporal module of the INHAB ontology.</figcaption></figure>

For instance, consider that John is inside building B2 (Figure 4(a)) and is connected at a given time to the WiFi Access Point covering floor F2. Suppose John's cubicle is C2 in Figure 4(d). A localization algorithm (e.g., the one in [1]) might determine that John is probably in his cubicle with high confidence (e.g., 0.8). Representing this fact in the building's KB using our schema would allow applications to adjust, for example, the room's temperature accordingly. To represent this fact, we can define the following triples:

```
{
    (John, inhab:hasSTStatus, STS1) (STS1,
        inhab:hasTemporalPosition, TP1)
    (TP1, time:hasBeginning, TI1) (TI1,
        time:inXSDDateTimeStamp, ``2020-03-24T10:00:00Z``)
    (TP1, time:hasEnd, TP2) (TI2,
        time:inXSDDateTimeStamp, ``2020-03-24T10:00:00Z``)
    (STS1, inhab:hasUncertainLoc, UL1) (UL1,
        inhab:hasLocation, F2) (UL1, inhab:confidence,
        1.0) (STS1, inhab:hasUncertainLoc, UL2) (UL2,
        inhab:hasLocation, C2) (UL2, inhab:confidence, 0.8)
```

We establish the following correctness criteria for generating triples related to an individual's uncertain location. Given an uncertain state `s` of an individual at time `t`, there must be at least one location for which the localization confidence

<footnote n="3">³If no new coordinate system is defined, the location inherits its parent's, and no explicit triple is necessary.</footnote>
is 1.0 (in the worst case, the special instance `inhab:Earth`). Furthermore, for any location *l* in the KB, let *L* be the set of all directly contained locations (explicitly defined as the range of the `inhab:hasLocation` property when the domain is *l*). For *s* to be correct, the confidence values associated with all locations *l* related to *s* must sum to the confidence of all locations in *L*. In the previous example, John's localization on floor *F2* meets the first criterion with a confidence of 1.0. To satisfy the second criterion, one would need to explicitly specify the confidence of John being in each sub-location (e.g., within *F2* and *R4*). Under the open world assumption of Semantic Web languages like OWL, the absence of a statement does not imply a value of zero; even in closed world languages (such as SPARQL) missing values are treated as zero, thereby failing our criterion. Explicitly stating all facts required for a correct spatial-temporal status could quickly inflate the KB size depending on the scenario's complexity.

To mitigate this, we include vocabulary that reduces the number of triples by specifying probability distributions associated with different spaces. The property `inhab:hasDistributionProperty` indicates that a location has an associated probability distribution for a specific attribute such as occupancy or the location of people. We integrate the ProbOnto ontology [52], which catalogs over 150 univariate and multivariate distribution types, to represent the exact distribution. For example, consider the earlier scenario: the sensor-based algorithm determined that John is located in *F2* with probability 1.0, and we assume a simple uniform distribution for the localization of people within the floor. We can represent this fact using the following triples:

```
⟨F2, inhab:hasDistrProperty, DistLocF2⟩ ⟨DistLocF2, inhab:hasTypeProbDist, probOnto:StdUnif1⟩ ⟨R4, inhab:hasDistrProperty, DistLocR4⟩ ⟨DistLocR4, inhab:hasTypeProbDist, probOnto:StdUnif1⟩ ⟨John, inhab:hasSTStatus, STS1⟩ ⟨STS1, inhab:hasUncertainLoc, UL1⟩ ⟨UL1, inhab:hasLocation, F2⟩ ⟨UL1, inhab:confidence, 1.0⟩
```

An application interested in the probability of John being in cubicle C1 (see Figure 4) can use this information to compute that probability. The combination of the distribution representation and the `inhab:containsLocation` property enables the application to infer that the probability of being in room *R4* is 1/7 and that, if John is in *R4*, the probability of being in cubicle *C1* is 1/9. Hence, the overall probability of being in *C1* is $1/7 \times 1/9$. If, in addition to the 1.0 probability for being in *F2*, the algorithm determines that John has a 0.8 probability of being in his cubicle *C2* (and this fact is annotated using `INHAB`), then the probability of him being in *C1* would be $((1 - 0.8)/6) \times 1/8$.

Moreover, the `inhab:Distribution` associated with a specific location can also be tailored for specific individuals. This is modeled via the `inhab:hasAssociatedSPThing` property, which links a distribution to spatial-temporal entities (e.g., specific people). This feature is useful, for example, to represent that the probability of John being in his cubicle is particularly high when he is located in *R4*.

## IV. USAGE THROUGH SPARQL

We present sample SPARQL queries—motivated by the use cases in Section II—that extract useful information based on `INHAB`. While the queries are connected to the graphs in our experimental setup (see Section VI), they can be executed against any KB defined using `INHAB`. Hence, applications using them are portable across different smart spaces.

**Query 1.** Retrieve the occupancy of all regions for the last 10 minutes and their capacity. This query, motivated by Use Case 1, utilizes multiple graphs containing spatial-temporal information about people across different campus buildings. First, it retrieves individuals who were present on campus during the specified interval using built-in functions of the Virtuoso SPARQL endpoint in our experiments. It then processes each person's location, which may be either certain or uncertain, by employing the OPTIONAL clause. In both cases, the query retrieves the region (the highest granularity location in our experiments) where the individual is located. We differentiate between certain and uncertain localization to demonstrate that our model supports complex operations for uncertain data. For example, one could filter out triples with low confidence (as shown in Query 2) or count a person as a fraction (e.g., 0.5) when the confidence is 0.5 (as illustrated in Query 3). Finally, the query counts the number of distinct individuals in each region and appends data on region capacity as well as the floor and building containing the region, allowing occupancy computations at higher levels of granularity.

```sql
SELECT ?Region ?Capacity ?Floor ?Building
(COUNT(distant ?P) as ?numberPeople)
FROM <UCI-KB> FROM <DBH-KB> FROM <ICS-KB>
FROM <ICS2-KB> FROM <FRH-KB>
WHERE {
  # retrieve triples describing people's temporal status
  ?P rdf:type inhab:Person . ?P inhab:hasSTStatus ?PSTS .
  ?PSTS inhab:hasTemporalPosition ?PTS .
  ?PTS time:hasBeginning ?Pstart .
  ?Pstart time:inXSDDatetimeStamp ?start .
  ?ATS time:hasEnd ?Pend . ?Pend time:inXSDDatetimeStamp ?end .
  # retrieve people on campus in last 10 minutes
  FILTER (?start < now() &&
    ?end > bif:-dateadd('minute', -10, now())
  ).
  OPTIONAL { # if location of person uncertain
    ?PSTS inhab:hasUncertainLoc ?ULoc .
    # retrieve the region in which they are located
    ?ULoc inhab:hasLocation ?Region .
    ?Region rdf:type uci:Region .
    # retrieve metadata about the region
    ?Region inhab:hasCapacity ?Capacity .
    ?Floor inhab:hasLocation ?Region .
    ?Floor rdf:type uci:Floor .
    ?Building inhab:hasLocation ?Floor .
    ?Building rdf:type uci:Building . }
    OPTIONAL { # if location of person certain
      ?PSTS inhab:hasLocation ?CL .
      ?CL inhab:hasLocation ?Region .
      ?Region rdf:type uci:Region .
      ... } # same as in previous optional clause
  }
  GROUP BY ?Region ?Capacity ?Floor ?Building
```

<caption>Listing 1: SPARQL definition of Query 1.</caption>

**Query 2.** Retrieve all cameras that might have captured John. Let us consider that if John was within a camera's view frustum at any time, that camera might have captured his image. This query (see Listing 2), motivated by Use Case 2, first retrieves all cameras in the space (described using
Brick) and their coverage areas. It then fetches all spatial-temporal statuses for John, which may include certain or uncertain locations, using OPTIONAL to manage both cases. To minimize the number of images to analyze, the query filters uncertain locations to include only those with high confidence (e.g., above 0.7). Finally, the GeoSPARQL function `geof:sfContains` is applied to determine whether John's location (expressed either as a point or as a room) is contained within a camera's coverage area.

```sql
SELECT ?cam ?startTS ?endTS
WHERE {
  # get cameras and their coverage
  ?cam rdf:type brick:Camera . ?L inhab:isCoverageOf ?cam .
  ?L inhab:hasExtent ?ExtL . ?ExtL inhab:hasGeometry ?camGeo .
  # get person's locations
  uci:John inhab:hasSTSSatus ?STS .
  OPTIONAL { # if location of person uncertain
    ?STS inhab:hasUncertainLoc ?ULoc .
    # discard locations with low confidence
    ?ULoc inhab:confidence ?conf . FILTER(?conf >= 0.7) .
    # check if extent of the user's location is
    # contained in the camera's coverage
    ?ULoc inhab:hasLocation ?UL . ?UL inhab:hasExtent ?ExtUL .
    ?ExtUL inhab:hasGeometry ?johnUGeo .
  FILTER (geof:sfContains ( ?camGeo , ?johnUGeo ) . )
  OPTIONAL { # if location of person certain
    ?STS inhab:hasLocation ?CL . ?CL inhab:hasExtent ?ExtCL .
    ?ExtCL inhab:hasGeometry ?johnGeo .
  FILTER (geof:sfContains ( ?camGeo , ?johnGeo ) . ) }
```

<caption>Listing 2: SPARQL definition of Query 2.</caption>

**Query 3.** Compute attendance per profile for each seminar in a recurring seminar series. We assume that an individual attended a seminar if they were present in the event's location at any point during its duration. This query (see Listing 3) is motivated by Use Case 3, which deals with the scheduling of HVAC systems based on historical attendance. The query first retrieves all seminars in the series along with their locations and start and end times. It then filters individuals who were present in the building during the event and retrieves their (certain/uncertain) spatial-temporal statuses. If an individual's presence in the seminar location is certain, they are counted as a whole for their profile (e.g., professor or student). Otherwise, the query uses the associated confidence value as the count, so that a confidence of 0.5 contributes “half” an attendance.

## V. ANNOTATION SUPPORT SYSTEM

INHAB supports the creation of complex, fine-grained smart space models. The more detailed the spatial description, the greater the schema's potential (as illustrated by the previous functions). However, manual fine-grained annotation can be challenging and error-prone, especially for locations, since multiple elements must be correctly defined (e.g., coordinate systems, extents, hierarchy, and inter-element relationships). To address this, we developed an annotation support system as a web application that allows users to fill out forms for metadata and to draw locations on maps or floor plans. The tool (see Figure 7) consists of three components:

(1) **Hierarchy Definition Component** used to define the space's hierarchical containment structure as a tree. The tool displays the root node (`inhab:Earth`), which is uneditable and pre-defined in INHAB along with any existing annotations

```sql
SELECT ?A ?AL SUM(?occFaculty) SUM(?occStudent)
WHERE {
  # get activity's location and timestamp
  ?A inhab:isPartOfRecurringAct buildA:Seminar11 .
  ?A inhab:hasSTStatus ?ASTS . ?ASTS inhab:hasLocation ?AL .
  ?ASTS inhab:hasTemporalPosition ?ATS .
  ?ATS time:hasBeginning ?Astart . ?ATS time:hasEnd ?Aend .
  # get person's location
  ?P rdf:type ?inhab:Person . ?P inhab:hasSTStatus ?PSTS .
  ?PSTS inhab:hasTemporalPosition ?PTS .
  ?PTS time:hasBeginning ?Pstart . ?ATS time:hasEnd ?Pend .
  # check if person is in the building at activity's timestamp
  FILTER ( ?Pend > ?Astart && ?Pend <= ?Aend || ?Pstart >= ?Astart && ?Pstart < ?Aend ) .
  OPTIONAL { # if location of person uncertain
    ?PSTS inhab:hasUncertainLoc ?ULoc .
    # account for the confidence associated with
    # location and profile of the user
    ?ULoc inhab:hasLocation ?AL .
    ?ULoc inhab:confidence ?conf .
    BIND ( IF(?P inhab:hasProfile buildA:Professor, ?conf, 0) as ?occFaculty) .
    BIND ( IF(?P inhab:hasProfile buildA:Student, ?conf, 0) as ?occStudent) . }
  OPTIONAL { # if location of person certain
    ?STS inhab:hasLocation ?AL .
    BIND ( IF(?P inhab:hasProfile buildA:Professor, 1, 0) as ?occFaculty) .
    BIND ( IF(?P inhab:hasProfile buildA:Student, 1, 0) as ?occStudent) . }
```

<figure><img src="image_8.png" /><figcaption>Fig. 7: Screenshot of the annotation GUI.</figcaption></figure>

in the connected KB. Users can add, edit, or delete nodes under Earth and its descendants. This component facilitates the visual analysis of locations and their relationships, and it controls data flow to the other components. For example, when the user clicks add or edit, changes are propagated to both the Extent and Metadata components, either displaying existing editable data or enabling the addition of new information.

(2) **Extent Definition Component** used to graphically define geometries associated with a space—its area and boundary (see Section III-B). By default, INHAB supports geometries in two coordinate systems (GPS and Cartesian). Thus, the module offers two background options: (a) a real map using OpenStreetMap<fnref n="4" />, which provides GPS coordinates for selected points, and (b) a white canvas or an uploaded image (e.g., a floor plan) that yields Cartesian coordinates. Figure 7 shows the Donald Bren Hall building selected on the map (in blue), while Figure 8 displays an uploaded floor plan with a room drawn on it and a view of all rooms on Floor 2 of DBH with the selected room highlighted (in blue).

<footnote n="4">⁴https://www.openstreetmap.org</footnote>
When a space is selected in the tree, the module determines the appropriate interface by examining the coordinate system of the parent space's boundary. For example, if the campus boundary in Figure 7 is defined using GPS coordinates, selecting a building will trigger a map interface for defining its area. The tool then allows users to draw points, rectangles, circles, or polygons on the chosen background. If the selected space already has an associated area, the tool displays it for editing. Figure 8 illustrates a case where a room within a floor is selected, and the tool renders that room along with its sibling spaces (i.e., other rooms on the same floor).

<figure><img src="image_9.png" /><figcaption>Fig. 8: Screenshot of the Cartesian elements in the Extent component.</figcaption></figure>

**(3) Metadata Definition Component**, implemented as a form, allows users to specify a location's metadata (e.g., name, type, coordinate system of its boundary, capacity, additional data properties). When a space is selected in the hierarchy tree, its associated metadata is retrieved from the KB and displayed in the form. Drop-down menus control certain elements (e.g., types of spaces—subclasses of `inhab:Location`—and coordinate systems—instances of `inhab:CoordinateSystem`). A special option available is the definition of a sensor's coverage area. When this option is selected, the component retrieves from the KB the list of all sensors (i.e., instances of `inhab:Sensor`) and allows the user to choose one.

## VI. EXPERIMENTAL EVALUATION

**Experimental Setup.** We built a system based on INHAB to demonstrate its feasibility. The system annotates our smart campus (modeled on the UCI campus) by capturing information about its buildings (including their geographic representations) and spatial-temporal events representing campus inhabitants' locations derived from WiFi connectivity data.

We deployed Virtuoso<fnref n="5" /> as triple store and connected it to the data annotation tool, the occupancy monitoring application, and a script that generates spatial-temporal events. Using the annotation tool, we annotated the UCI campus and 154 buildings (with floor details). For buildings with accessible WiFi APs, we also defined triples indicating the containment of AP coverage areas within various floors (the coverage areas for more than 350 APs are being annotated in an ongoing effort). Within Virtuoso, we created one KB for the campus (UCI-KB), which defines the boundaries of

the campus and includes campus-wide metadata and people (represented via WiFi-connected devices), and one KB for each building containing detailed building information and spatial-temporal events (e.g., DBH-KB for the Donald Bren Hall building). ICS-KB, ICS2-KB, NS-KB, and FRH-KB describe their respective buildings and floors, whereas DBH-KB includes, in addition, the definition of each room (360 rooms across 6 floors) and AP coverage areas.

To annotate spatial-temporal events for people's localization, we leveraged an existing system at UCI [53] that captures WiFi connectivity events using network Syslog [54]. These events are tuples of *<mac address, timestamp, wap>* representing a device's MAC address, connection time, and the WiFi AP it connected to. The system stores these events in a log after applying privacy measures (e.g., allowing users to opt out and using salted hashing of MAC addresses to *de-link* events; see [53] for details). Since APs are fixed, these events can be used to infer that a device is within the AP's coverage area.

An annotation script periodically fetches connectivity events and converts them into spatial-temporal events. For each event, the script generates triples associating a `inhab:SpatialTemporalStatus` with the corresponding `inhab:Person` (identified by its MAC address) and sets the `inhab:UncertainLocation` to the instance of `inhab:Location` representing the AP's coverage. Note that we equate devices to people, as we do not have information on device owners. Also, because the data capture engine changes the MAC address salt periodically, the same device might have different hashed IDs over time. Both issues can impact the precision of occupancy counts; however, algorithms to adjust for over-counting are outside this paper's scope.

Additionally, we developed a script to annotate building activities. We manually extracted event information from the UCI website for the experiment period and stored the annotated events in the appropriate building KB.

**Developing an Occupancy Monitoring App.** The web application (see Figure 9) is useful for monitoring adherence to fire code regulations, detect events on campus, and/or even monitor adherence to pandemic regulations (see Use Case 1 in Section II). The app can run in any smart space offering a SPARQL endpoint with information defined using INHAB.

The application first retrieves the locations defined in the KB. In our deployment, these include buildings, floors, and rooms. According to INHAB's location model, the application renders these spaces on OpenStreetMaps if the coordinate system is GPS (e.g., buildings as shown in Figure 9a) or on a Cartesian viewer if the coordinate system is Cartesian (e.g., rooms as shown in Figure 9b). SPARQL queries compute each location's area and occupancy (similar to Query 1 in Section IV), and the application colors locations to indicate occupancy levels. For example, Figure 9b displays occupancy levels on one floor, showing both rooms (in gray when occupancy it cannot be computed) and WiFi AP coverage regions—one of which is red, indicating high occupancy.

<footnote n="5">⁵https://virtuoso.openlinksw.com</footnote>
<figure><img src="image_10.png" /><figcaption>(a) Campus view.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>(b) Floor view.</figcaption></figure>

<caption>Fig. 9: Occupancy monitoring application developed using INHAB.</caption>

## A. Experimental Results

We evaluate the performance of the system and app in terms of KB size, growth, and query execution times. We choose two one-week data snapshots of inhabitant interaction with the smart space—pre and post campus partial closure due to COVID-19 (early and late March 2020, respectively). The selected period enables comparing the differences in the system and app performance during everyday interactions vs. a situation in which those interactions change drastically.

**Size of the KB.** The majority of triples in a INHAB-defined KB describe the space, its topology, and sensor-generated spatial-temporal events. Table I presents statistics for the various KBs in our deployment. On average, a building annotated only with the data needed for occupancy computation (at the building/floor/coverage level) requires 834 triples—about 19 triples per individual space—with similar averages for DBH-KB. In the UCI-KB, the number of triples representing people was ≈ 2M pre-closure and ≈ 600K during closure. (People triples are omitted from building KBs since people are represented solely in UCI-KB.) Note that these do not correspond exactly to actual people, as they are based on WiFi-enabled devices whose MAC addresses are hashed with a changing salt. In total, ≈ 100K and ≈ 30K unique device IDs were connected to the network in our pre- and during-closure datasets, respectively. Activities were annotated only for two buildings, DBH-KB and FRH-KB, and required 21 and 105 triples, respectively (21 triples/event on average).

The number of spatial-temporal triples per building is proportional to its size and inhabitants. DBH is the largest building (6 floors), followed by FRH (5 floors), ICS (4 floors), and ICS2 (2 floors); this ranking also reflects inhabitant counts. Table I further shows that, during campus partial closure, the

<table><caption>TABLE I: Triples per KB. pre-campus closure<sup>†</sup>, during closure<sup>§</sup>.</caption><thead><tr><th>#triples</th><th>UCI-KB</th><th>DBH-KB</th><th>ICS-KB</th><th>ICS2-KB</th><th>FRH-KB</th></tr></thead><tbody><tr><td>space</td><td>379</td><td>8,731</td><td>124</td><td>193</td><td>289</td></tr><tr><td>activity</td><td>-</td><td>21</td><td>0</td><td>0</td><td>105</td></tr><tr><td>people<sup>†</sup></td><td>2,255,778</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>people<sup>§</sup></td><td>584,052</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>spat-temp<sup>†</sup></td><td>-</td><td>5,192,778</td><td>1,013,339</td><td>713,543</td><td>2,796,318</td></tr><tr><td>spat-temp<sup>§</sup></td><td>-</td><td>2,487,957</td><td>283,925</td><td>69,809</td><td>949,746</td></tr><tr><td>total</td><td>135,609</td><td>7,689,466</td><td>1,297,388</td><td>783,545</td><td>3,746,353</td></tr></tbody></table>

spatial-temporal triples dropped to 47% (DBH), 32% (FRH), 28% (ICS), and 10% (ICS2) of their pre-closure values.

**Size vs. time.** We further analyzed the generation of spatial-temporal triples over time. We observed that certain devices connect very frequently (approximately every 2 minutes). To address this, we developed an optimization which combines connectivity events from the same device and AP when gaps between events are less than 10 minutes. In such cases, the script compresses these events into a single event spanning from the first to the last timestamp.

Figure 10 shows the hourly distribution of spatial-temporal triples (in thousands, using a base-2 logarithmic scale) for all buildings combined and for DBH individually, with and without compression. The figures plot one weekday in the pre-closure period (PC) and during the closure period (DC). The X-axis represents one-hour intervals starting from 12AM (e.g., “1” for 12AM–1AM). Two series are shown: the per-hour triple count (blue) and the cumulative triple count (orange). A distinct spike occurs during midday (hours 10–17, corresponding to 9AM–5PM) for both all buildings and DBH, reflecting peak campus activity due to classes. This pattern is still visible during the closure, albeit at a reduced scale. Note that, outside these hours (especially at night), some triples still appear. This is due to two factors: first, our simple annotation script does not filter out connectivity events from static devices (e.g., printers, desktops) that remain connected at night; and second, the privacy mechanism that changes the MAC address hashing salt every 30 minutes leads to duplicate entries.

The compression algorithm reduced the overall number of triples by ≈ 65% pre-closure and ≈ 85% during closure for all buildings. Nonetheless, some static devices still produce a significant number of triples because (1) their connectivity gaps exceed 10 minutes, and (2) a single static device may appear with different MAC addresses within an hour due to the changing salt. A more sophisticated algorithm to detect static devices and further compress events—outside the scope of this paper—could reduce these numbers further.

**Query performance.** We evaluated the performance of a query that retrieves people's locations within the smart space (a component of all queries described in Section IV). The query was executed with cumulative hourly increments to illustrate the impact of KB size on performance. Four snapshots were selected: pre/during closure for both all buildings and for the largest and more detailed building (DBH). Each query was executed five times, and the running times were averaged. Figure 11 shows the query performance (in seconds) per cumulative hour interval. For pre-closure data, the query execution time increased steadily with additional hours. There
<figure><img src="image_12.png" /><figcaption>Fig. 10: Number of triples to represent spatial-temporal events w.r.t. time for pre-closure (PC) and during closure (DC) periods.</figcaption></figure>

is a noticeable spike starting at hour interval 9 correlated with the midday peak in spatial-temporal triples (see Figure 10). By that point the average execution time to find the location (i.e., region of the building) in which all inhabitants are located is ≈ 5 seconds for DBH and ≈ 20 seconds for all buildings. This execution time, which increases approximately linearly with the number of triples, becomes ≈ 20 and ≈ 80 seconds, respectively, by the end of the day. Keep in mind that this query involves reasoning based on the spatial-temporal observations and topological information of the space. Nevertheless, as we will discuss next, this execution time might be excessive for real-time applications. As expected, a significant drop in execution time was observed during closure for both all buildings and DBH, again due to reduced triple counts.

<figure><img src="image_13.png" /><figcaption>Fig. 11: Query execution time in seconds per hour interval.</figcaption></figure>

**Discussion.** The previous results confirm that, as expected, using a highly granular INHAB annotated KG significantly increases the number of triples, which in turn degrades query performance. Although INHAB ’s flexible and rich vocabulary offers opportunities to reduce the number of triples, query execution times may still be challenging for real-time applications when all triples are stored in a single graph. This challenge is not due to limitations in our schema, but is a common trade-off in knowledge graphs [55] for achieving truly interoperable, space-agnostic applications. Several mitigation strategies exist

that users can adopt when annotating and storing their data. This include: storing only the most current triples (e.g., from the last day) in the operational KG while archiving older data in a separate historical graph; or using a more efficient RDF storage solution [55], [56] or graph database [57] to improve query performance. Although these strategies are beyond the scope of this paper, they represent promising avenues for addressing scalability challenges in highly granular smart space representations using INHAB.

## VII. CONCLUSIONS

Vocabularies for describing systems and IoT sensors in smart spaces—such as HVAC systems in smart buildings—are gaining popularity. However, a smart space is more than just its systems, sensors, and data points; it is inhabited by people. We introduced a vocabulary that represents concepts of an inhabited smart space not addressed by existing IoT ontologies. Aligned with SSN, SAREF, Brick, BOT, and other standard ontologies, our schema supports the definition of people, activities, fine-grained spatial representations, and sensor-derived spatial-temporal events (e.g., the locations of people). We also presented applications that benefit from our schema, enabling space-agnostic semantic interoperability, as demonstrated by SPARQL query examples and a campus-deployed occupancy monitoring application. Future work will focus on developing additional tools to facilitate the annotation of inhabited smart spaces using our schema and exploring the trade-off between portability and efficiency.

## ACKNOWLEDGMENT

This work is partially supported by the HPI Research Center in Machine Learning and Data Science at UC Irvine, NSF Grants No. 1952247, 2245372, 2420846, 2133391, 2008993, 2008993, 1952247, 2032525, and the Horizon Europe project PANDORA (grant agreement No. 101135775).
REFERENCES

[1] Y. Lin, D. Jiang, R. Yus, G. Bouloukakis, A. Chio, S. Mehrotra, and N. Venkatasubramanian, "LOCATER: cleaning wifi connectivity datasets for semantic localization," *Proc. VLDB Endow.*, vol. 14, no. 3, 2020.

[2] M. Xue, W. Sun, H. Yu, H. Tang, A. Lin, X. Zhang, and R. Zimmermann, "Locate the mobile device by enhancing the wifi-based indoor localization model," *IEEE Internet Things J.*, vol. 6, no. 5, 2019.

[3] A. K. Das, P. H. Pathak, J. Jee, C. Chuah, and P. Mohapatra, "Non-intrusive multi-modal estimation of building occupancy," in *15th ACM Conf. on Embedded Network Sensor Systems, SenSys*, 2017.

[4] M. Mohsen, H. Rizk, and M. Youssef, "Privacy-preserving by design: Indoor positioning system using wi-fi passive TDOA," in *24th IEEE International Conference on Mobile Data Management, MDM*, 2023.

[5] E. Shin, R. Yus, S. Mehrotra, and N. Venkatasubramanian, "Exploring fairness in participatory thermal comfort control in smart buildings," in *4th ACM Int. Conf. on Systems for Energy-Efficient Built Environments, BuildSys*, 2017.

[6] M. Feldmeier and J. A. Paradiso, "Personalized hvac control system," in *Int. Conf. on the Internet of Things, IOT*, 2010.

[7] V. L. Erickson and A. E. Cerpa, "Occupancy based demand response hvac control strategy," in *2nd ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Building, BuildSys*, 2010.

[8] W. Zhang, W. Hu, and Y. Wen, "Thermal comfort modeling for smart buildings: A fine-grained deep learning approach," *IEEE Internet Things J.*, vol. 6, no. 2, 2019.

[9] M. August, C. Davison, M. H. Diallo, D. Ghosh, P. Gupta, C. T. Graves, S. Han, M. Holstrom, P. Khargonekar, M. Kline, S. Mehrotra, S. Sharma, N. Venkatasubramanian, G. Wang, and R. Yus, "A privacy-enabled platform for COVID-19 applications," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[10] E. Cecchet, A. Acharya, T. Molom-Ochir, A. Trivedi, and P. Shenoy, "Wifimon: a mobility analytics platform for building occupancy monitoring and contact tracing using wifi sensing," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[11] Y. Tachibana and N. Segawa, "Physical distance monitoring system for COVID-19 using raspberry pi and a monocular camera," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[12] Y. Yin, P. Li, X. Yang, F. Yan, Q. Niu, and P. Chen, "COVID-19 tracer: passive close-contacts searching through wi-fi probes," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[13] K. Yoshida, A. Sato, and S. Sannomiya, "Contact analysis on COVID-19 using a campus network," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[14] A. Arun, A. Gupta, S. Bhatka, S. Komatineni, and D. Bharadia, "Bluble, space-time social distancing to monitor the spread of COVID-19," in *18th ACM Conf. on Embedded Networked Sensor Systems, Sensys*, 2020.

[15] M. Alaa, A. A. Zaidan, B. B. Zaidan, M. Talal, and M. L. M. Kiah, "A review of smart home applications based on Internet of Things," *J. Netw. Comput. Appl.*, vol. 97, 2017.

[16] M. Noura, M. Atiquzzaman, and M. Gaedke, "Interoperability in internet of things: Taxonomies and open challenges," *Mob. Networks Appl.*, vol. 24, no. 3, 2019.

[17] M. Noura, A. Gyrard, S. Heil, and M. Gaedke, "Automatic knowledge extraction to build semantic web of things applications," *IEEE Internet Things J.*, vol. 6, no. 5, 2019.

[18] R. Yus, G. Bouloukakis, S. Mehrotra, and N. Venkatasubramanian, "The semiotic ecosystem: A semantic bridge between iot devices and smart spaces," *ACM Trans. Internet Techn.*, vol. 22, no. 3, 2022.

[19] F. Antoniazzi and F. Viola, "Building the Semantic Web of Things through a dynamic ontology," *IEEE Internet Things J.*, vol. 6, no. 6, 2019.

[20] A. Gyrard, A. Zimmermann, and A. P. Sheth, "Building IoT-Based applications for smart cities: How can ontology catalogs help?" *IEEE Internet Things J.*, vol. 5, no. 5, 2018.

[21] M. Compton, P. Barnaghi, L. Bermudez, R. García-Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor, "The SSN ontology of the W3C semantic sensor network incubator group," *J. Of Web Semantics*, vol. 17, 2012.

[22] ([Online; accessed May-2025]) Project Haystack. [Online]. Available: https://project-haystack.org

[23] K. Schutte, H. Bouma, J. G. M. Schavemaker, L. Daniele, M. Sap-pelli, G. Koot, P. Eendebak, G. Azzopardi, M. Spitters, M. de Boer, M. Kruithof, and P. Brandt, "Interactive detection of incrementally learned concepts in images with ranking and semantic query interpre-tation," in *13th Int. Workshop on Content-Based Multimedia Indexing, CBMI*, 2015.

[24] B. Balaji, A. A. Bhattacharya, G. Fierro, J. Gao, J. Gluck, D. Hong, A. Johansen, J. Koh, J. Ploennigs, Y. Agarwal, M. Berges, D. E. Culler, R. E. Gupta, M. B. Kjærgaard, M. B. Srivastava, and K. Whitehouse, "Brick: Towards a unified metadata schema for buildings," in *3rd ACM Int. Conf. on Systems for Energy-Efficient Built Environments, BuildSys*, 2016.

[25] T. R. Gruber, "A translation approach to portable ontology specifica-tions," *Knowledge Acquisition*, vol. 5, no. 2, 1993.

[26] F. Manola, E. Miller, B. McBride et al., "RDF primer," W3C recommendation, vol. 10, no. 1-107, 2004.

[27] D. Brickley and R. V. Guha, "RDF vocabulary description language 1.0: RDF schema," W3C recommendation, 2004. [Online]. Available: https://www.w3.org/2001/sw/RDFCore/schema/200212bwm/

[28] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, and S. Rudolph, "OWL 2 web ontology language primer," W3C recommendation, 2009. [Online]. Available: https://www.w3.org/TR/owl2-primer/

[29] E. Prud'hommeaux and A. Seaborne, "SPARQL Query Language for RDF," W3C Recommendation, 2008. [Online]. Available: http://www.w3.org/TR/rdf-sparql-query/

[30] K. Janowicz, A. Haller, S. J. Cox, D. Le Phuoc, and M. Lefrançois, "SOSA: A lightweight ontology for sensors, observations, samples, and actuators," *J. of Web Semantics*, vol. 56, 2019.

[31] L. Daniele, F. T. H. den Hartog, and J. Roes, "Created in close interaction with the industry: The smart appliances reference (SAREF) ontology," in *7th Int. Workshop on Formal Ontologies Meet Industry, FOMI*, 2015.

[32] M. Poveda-Villalón and R. García-Castro, "Extending the SAREF ontology for building devices and topology," in *6th Linked Data in Architecture and Construction Workshop LDAC*, 2018.

[33] D. Brickley, "Basic Geo (WGS84 lat/long) Vocabulary," W3C recommendation, 2003. [Online]. Available: https://www.w3.org/2003/01/geo

[34] M. H. Rasmussen, M. Lefrançois, G. F. Schneider, and P. Pauwels, "BOT: the building topology ontology of the W3C linked building data group," *Semantic Web*, vol. 12, no. 1, 2021.

[35] K. K. Qin, M. S. Rahaman, Y. Ren, C. Cheng, I. Cole, and F. D. Salim, "A system of monitoring and analyzing human indoor mobility and air quality," in *24th IEEE International Conference on Mobile Data Management, MDM*, 2023.

[36] A. Zaidi, R. Ahuja, and C. Shahabi, "Differentially private occupancy monitoring from wifi access points," in *23rd IEEE International Conference on Mobile Data Management, MDM*, 2022.

[37] P. Pappachan, M. Degeling, R. Yus, A. Das, S. Bhagavatula, W. Melicher, P. E. Naeini, S. Zhang, L. Bauer, A. Kobsa, S. Mehrotra, N. M. Sadeh, and N. Venkatasubramanian, "Towards privacy-aware smart buildings: Capturing, communicating, and enforcing privacy policies and preferences," in *37th IEEE International Conference on Distributed Computing Systems Workshops, ICDCS Workshops*, 2017.

[38] R. Z. Freire, G. H. Oliveira, and N. Mendes, "Predictive controllers for thermal comfort optimization and energy savings," *Energy and buildings*, vol. 40, no. 7, 2008.

[39] J. Ma, D. Panic, R. Yus, and G. Bouloukakis, "Co-zybench: Using co-simulation and digital twins to benchmark thermal comfort provision in smart buildings," in *IEEE International Conference on Pervasive Computing and Communications, PerCom*, 2024.

[40] A. Chio, D. Jiang, P. Gupta, G. Bouloukakis, R. Yus, S. Mehrotra, and N. Venkatasubramanian, "Smartspec: A framework to generate customizable, semantics-based smart space datasets," *Pervasive Mob. Comput.*, vol. 93, 2023.

[41] P. Gupta, S. Mehrotra, S. Sharma, R. Yus, and N. Venkatasubramanian, "Sentaur: Sensor observable data model for smart spaces," in *31st ACM International Conference on Information & Knowledge Management, CIKM*, 2022.

[42] D. Brickley and L. Miller, "The Friend Of A Friend (FOAF) vocabulary specification," 2007. [Online]. Available: http://xmlns.com/foaf/spec/

[43] R. Atkinson and N. J. Car, "The profiles vocabulary," W3C recommendation, 2019. [Online]. Available: https://www.w3.org/TR/dx-prof
[44] D. Connolly and L. Miller, "RDF Calendar - an application of the Resource Description Framework to iCalendar Data," W3C recommendation, 2005. [Online]. Available: https://www.w3.org/TR/rdfcal

[45] S. Cox and C. Little, "Time Ontology in OWL," W3C candidate recommendation, 2020. [Online]. Available: https://www.w3.org/TR/owl-time

[46] R. Battle and D. Kolas, "Enabling the geospatial semantic web with parliament and GeoSPARQL," *Semantic Web J.*, vol. 3, no. 4, 2012.

[47] D. Bonino and F. Corno, "Dogont - ontology modeling for intelligent domotic environments," in *7th Int. Semantic Web Conf., ISWC*, 2008.

[48] C. Reinisch, M. J. Kofler, F. Iglesias, and W. Kastner, "Thinkhome energy efficiency in future smart homes," *EURASIP J. on Embedded Systems*, 2011.

[49] L. Anselma, P. Terenziani, S. Montani, and A. Bottrighi, "Towards a comprehensive treatment of repetitions, periodicity and temporal constraints in clinical guidelines," *Artif. Intell. Medicine*, vol. 38, no. 2, 2006.

[50] V. A. Carriero, A. Gangemi, A. G. Nuzzolese, and V. Presutti, "An ontology design pattern for representing recurrent events," in *10th Workshop on Ontology Design and Patterns, WOP*, K. Janowicz, A. A. Krisnadhi, M. Poveda-Villalón, K. Hammar, and C. Shimizu, Eds., 2019.

[51] OGC, "Geographic information — simple feature access — part 1: Common architecture," ISO 19125-1:2004, 2004. [Online]. Available: https://www.iso.org/standard/40114.html

[52] M. J. Swat, P. Grenon, and S. Wimalaratne, "ProbOnto: ontology and knowledge base of probability distributions," *Bioinformatics*, vol. 32, no. 17, 2016.

[53] S. Ghayyur, P. Pappachan, G. Wang, S. Mehrotra, and N. Venkatasub-ramanian, "Designing privacy preserving data sharing middleware for internet of things," in *3rd Workshop on Data: Acquisition To Analysis, DATA*, 2020.

[54] R. Gerhards et al., "The syslog protocol," RFC 5424, March, Tech. Rep., 2009.

[55] T. Neumann and G. Weikum, "The rdf-3x engine for scalable manage-ment of rdf data," *The VLDB Journal*, vol. 19, 2010.

[56] C. Weiss, P. Karras, and A. Bernstein, "Hexastore: sextuple indexing for semantic web data management," *Proceedings of the VLDB Endowment*, vol. 1, no. 1, 2008.

[57] M. Besta, R. Gerstenberger, E. Peter, M. Fischer, M. Podstawski, C. Barthels, G. Alonso, and T. Hoefler, "Demystifying graph databases: Analysis and taxonomy of data organization, system designs, and graph queries," *ACM Computing Surveys*, vol. 56, no. 2, 2023.