# A Survey on Semantic Modeling for Building Energy Management

Miracle Aniakor  Vinicius V. Cogo  Pedro M. Ferreira

(LASIGE, Informática, Faculdade de Ciências, Universidade de Lisboa, Portugal)

###### Abstract

Buildings account for a substantial portion of global energy consumption.
Reducing buildings’ energy usage primarily involves obtaining data from
building systems and environment, which are instrumental in assessing and
optimizing the building’s performance. However, as devices from various
manufacturers represent their data in unique ways, this disparity introduces
challenges for semantic interoperability and creates obstacles in developing
scalable building applications. This survey explores the leading semantic
modeling techniques deployed for energy management in buildings. Furthermore,
it aims to offer tangible use cases for applying semantic models, shedding
light on the pivotal concepts and limitations intrinsic to each model. Our
findings will assist researchers in discerning the appropriate circumstances
and methodologies for employing these models in various use cases.

##  1 Introduction

Buildings are crucial for promoting sustainable resource consumption and eco-
friendly environment. However, they are responsible for approximately $40\%$
of the final energy use and $36\%$ of the total CO2 emissions in the European
Union [63]. Addressing these figures involves reducing non-renewable energy
consumption and enhancing buildings’ energy efficiency. The advent of
voluminous data from building systems and environment has given rise to
strategies aimed at improving building performance, leveraging advancements in
Information and Communication Technologies (ICT) topics, such as the Internet
of Things (IoT), Cyber Physical Systems (CPS), Artificial Intelligence (AI),
Context-Aware Systems [83], and Semantic Web Technologies (SWT).

Building Energy Management (BEM) is the concept and practice of managing a
building’s energy usage. Beyond achieving targets like energy efficiency, BEM
applications also focus on occupant comfort (e.g., thermal, acoustic,
lighting, and air quality), energy storage and flexibility, predictive
modeling, maintenance, and fault detection.

Meeting these objectives requires a cohesive strategy that prioritizes
sustainability along with occupant satisfaction. modeling the building
environment is challenging due to its complex and dynamic nature, influenced
by numerous factors including building equipment and envelope, thermal
conditions, weather, and occupancy activities. The lifecycle of a building is
marked by three major phases: design, construction, and operation. The first
two phases focus on the geometric representation of buildings, providing
_static_ information such as building orientation, building materials, and
other specifications, as illustrated in Figure 1(a). However, the operational
phase is _dynamic_ , overseeing the commissioning of the building to ensure
optimal performance, occupant comfort, energy consumption, and efficient
energy utilization. This phase gathers dynamic data such as CO2, weather
information, temperature, among others, as also depicted in Figure 1(a), which
is crucial for comprehending the building’s changing environment.

Building applications for energy management are often customized due to the
diversity in building types, building systems, and varying data formats. The
disparity in data formats arises from the distinct protocols employed by
various equipment manufacturers, which hinders the development of universally
applicable energy management applications.

To circumvent this issue, semantic modeling aims to standardize data and
consistent representation of entities within a domain. In the context of
buildings, semantic models can streamline data queries and enable the creation
of context-aware applications deployable across diverse buildings as shown in
Figure 1(b). For instance, this is achieved by harnessing contextual
information from semantic models, combined with AI techniques for predictive
maintenance [157], fault detection and diagnosis [96], and building operation
and control strategies [157].

Semantic modeling encompasses the representation of both physical and abstract
concepts within the context of building operations. Physical concepts pertain
to the tangible assets present in the building environment, while abstract
concepts encompass ideas, principles, and processes utilized to inform the
operational building state. The penetration of Building Energy Management
Systems (BEMs) necessitates features such as the interoperability of systems
and data, along with modeling the orchestration of computational tasks. These
tasks include orchestrating _key performance indicators (KPIs)_ ,
_assessments_ , and _services_. These features are crucial for enhancing the
self-awareness and adaptability of buildings to achieve optimal operating
conditions, along with the automation of computational tasks involved.

Prior efforts have aimed to represent these concepts; however, they have
typically been modeled independently. For instance, consider a scenario
involving a building with diverse occupants where the owners are dedicated to
reducing energy consumption, lowering operational costs, and upholding tenant
satisfaction. In instances where energy KPIs are modeled in isolation from
assessment and services, the KPI is monitored independently, focusing on
metrics such as energy consumption per square foot. While this approach
provides insights into energy usage, it lacks context on when and how
assessments are conducted and how specific building services impact energy
consumption over time.

This independent modeling approach restricts the potential for leveraging
data-driven analytics within the building environment, hindering the
comprehensive optimization of building operations. As a solution, this paper
proposes an innovative approach to interlinking these abstract concepts,
forming a more comprehensive ontology. This interconnected framework enhances
the applicability of context-aware applications for building energy
management. This survey paper looks into the semantic models relevant to
building operations to describe the critical physical and abstract concepts
they encompass, shedding light on their limitations, emerging trends, and
commonalities.

(a) Relationship among the buildings’ lifecycle phases and examples of the
respective (static or dynamic) data they manage.

(b) Steps for Context-Aware Decision Support Systems.

Figure 1:  BEM Applications Framework

The primary objective of this survey is to _comprehensively understand and
analyze the intricacies of semantic modeling and its diverse applications in
BEM, focusing on building operations_. More specifically, it aims to (_i_)
enlighten semantic modeling foundational concepts, methods, and tools; (_ii_)
review applications that actively employed semantic modeling in BEM, noting
their successes, challenges, and lessons learned; (_iii_) identify the best
practices from the analyzed studies and provide recommendations for future
implementation in similar scenarios, and (_iv_) highlight, based on the
reviewed literature, areas where current applications might be lacking and
identify opportunities for future research in this field. These efforts aim to
foster a holistic understanding of the role of semantic modeling and the
potential to revolutionize BEM, paving the way for more efficient,
sustainable, and intelligent infrastructures.

##  2 Research Methodology

This section outlines the research questions and describes the methodology
employed for selecting papers for this survey. The research questions we
intend to address with this survey are as follows:

  1. RQ1. What is the need for the applications of ontologies in building operations?

  2. RQ2. What were the different ontologies used in the building operation phase?

  3. RQ3. What examples of use cases were demonstrated in building ontologies?

  4. RQ4. What are the limitations of applying the existing ontologies in building operations?

Research question RQ1 is answered in Section 3 and aims to elucidate the
significance and benefits of semantic modeling in building operations. RQ2,
answered in Section 4, intends to illustrate the diverse ontologies integrated
into building operations. RQ3, detailed in Section 5, seeks to showcase an
example of the concrete application of ontologies in building operations.
Finally, RQ4 exposes in Section 6 the drawbacks of existing ontologies in
building operations.

To perform a thorough literature review on semantic modeling for BEM, a
strategic keyword search was initiated to identify studies that align with the
objectives of this research. The refined search string employed was:

“("Semantic modeling" OR "Semantic modelling" "Ontology" OR "Ontological
Framework" OR "Data Model")
AND ("Building" OR "BEMS") AND ("KPI" OR "Key Performance Indicator") AND
"Energy Management"”

This string was queried across six major databases: IEEE (27,816 results), ACM
(38 results), Web Of Science (3 results), Science Direct (197 results), Scopus
(129 results), and Google Scholar (830 results). In writing this survey paper,
the following numbers represent papers retrieved from each database. However,
these figures may vary over time. These databases were selected for their
comprehensive indexing of journals with documented impact factors and their
inclusion of international, multidisciplinary studies, ensuring an extensive
coverage of relevant literature. The quality of the papers was determined
according to the prestige of the publishing journal or conference (e.g.,
Scimago Journal Rank for journals and CORE rank for conferences). Studies
without detailed descriptions of building ontology for the operational phase
were excluded, focusing on those including detailed semantic models pertinent
to the operational phase and excluding those solely concerned with the design
and construction phases. Following a rigorous evaluation based on PRISMA
guidelines [116] (e.g., removing duplicate papers (5000 papers), title and
abstract screening (450 papers), applying eligibility criteria), a total of 50
papers were selected for an in-depth review.

##  3 Context and Background

This section explores the gradual evolution of the digitization of building
data from its nascent stage to its recent stage. It also discusses the essence
and the adoption of semantic modeling concepts for BEM on building operations.
Lastly, it details the basic semantic concepts required for ontologies to
represent for BEM.

###  3.1 Digitization of Building Data

The inception of digitizing building data stemmed from the development of
Building Information Models (BIMs). Introduced in the 1970s, BIMs have
significantly shaped the Architecture, Engineering, and Construction (AEC)
sector over the past few decades [138, 43]. The National Building Information
Model Standard (NBIMS) defines BIMs as a “digital representation of the
physical and functional attributes of a facility.” In this capacity, BIMs
serve as a collaborative knowledge repository, offering valuable information
about a facility that is a dependable foundation for decision-making
throughout its entire life cycle, starting from its initial stages and
extending onward [22]. BIMs find predominant application during the building’s
design and construction stages to foster improved stakeholder communication.
These digital tools generate extensive data from the planning, design,
construction, operation, maintenance, demolition/recycling processes. This
data is exchanged among stakeholders to enhance the building’s energy
efficiency [43, 117, 18]. However, using these tools presents a challenge due
to the vast array of disparate data types that are difficult to exchange and
handle, making knowledge extraction problematic for stakeholders with varying
backgrounds [118].

The BIM uses a standard data model known as Industry Foundation Classes [87].
The IFC data model enables users and software providers to consistently depict
building information under the defined specifications of the IFC schema. IFC
is primarily employed within BIMs to facilitate data exchange among various
BIM authoring tools, including Autodesk
Revit.111https://www.autodesk.com/products/revit/ This data interchange can be
accomplished using various file formats, including the IFC STEP Physical File
Format (IFC-SPFF) defined using the EXPRESS data specification language (ISO
10303) [124], the XML file format defined using the XML Schema Definition
Language (XSD) (ISO 10303-28) [90], and the Resource Description Framework
(RDF) file format defined by the Web Ontology Language (OWL) for IFC (ifcOWL)
[23].

Although IFC finds representation in multiple schemas, it exhibits limitations
in achieving interoperability, identified as Binding, Adaptability, and
Extensibility [120]. Binding emphasizes how the heterogeneous nature of IFC
translation and the binding process via each BIM authoring tool can result in
distorted and incomplete IFC models. Adaptability pinpoints how slow it can be
to change the IFC schema. It requires different industries and companies to
agree on what the IFC should look like and how it should work. Extensibility
implies that the IFC schema is not accessible to add new concepts, especially
for users who are not experts in the EXPRESS language used to define the IFC
model. Despite these limitations, Semantic modeling through semantic web
technologies offers a viable solution for facilitating interoperability in the
building operational phase and overcoming the barriers of the IFC data model.
This process involves adopting a linked data approach to link information from
diverse domains (e.g. BIM, sensor data, simulation data) into a unified web of
linked building data.

This section highlights the progressive digitization of building data, tracing
its inception from its nascent stages and evolution over time. It further
elucidates the technologies employed for data exchange in the building
industry, accentuating their advantages and limitations. Lastly, it spotlights
a prospective resolution to enhance semantic interoperability during the
building operation phase, with a comprehensive exposition presented in
subsequent sections.

###  3.2 The Advent of Semantic Modeling Technologies in Building’s Operation
Phase

The building operational phase encapsulates a wealth of data from the
operational systems and components, contributing to its daily functionality.
Devices are employed to gather insights from the building environment,
encompassing monitoring systems at both the building and urban scales.
Concurrently, models of the components interact synergistically with diverse
tools, such as simulations assessing building energy efficiency and occupancy
levels, to aid better decision-making for the enhancement of the built
environment. Hence, establishing adaptable mechanisms becomes imperative to
facilitate seamless data interchange among stakeholders involved at various
phases, fostering essential interoperability among data, tools, and devices.

The idea of semantic modeling via semantic web technologies aims to promote a
standardized data format across diverse heterogeneous data sources. Semantic
modeling embodies the substantial potential for advancing information linkage.
As a result, building information can be seamlessly connected across diverse
sources, comprehensible to computers, thereby enabling the execution of
increasingly sophisticated tasks.

The IFC open data standard was converted into an OWL ontology [4, 119]. This
transformation aimed to enable the incorporation of building data onto the
World Wide Web Consortium (W3C) [7], thus facilitating web-based data
exchanges. The IFC schema is notably intricate and encompasses an extensive
array of classes and attributes, a characteristic evident in the size of the
ifcOWL ontology. As a result of this intricacy, effectively querying the
ifcOWL ontology poses challenges in the usability and performance of
developing scalable building applications [148].

Moreover, this complexity results in difficulties when attempting to extend
the ifcOWL ontology, making it challenging to introduce or alter new
components without causing ripple effects across the entire structure. This
lack of modularity restricts the ability to selectively choose and incorporate
specific components or functionalities, limiting a pick-and-choose approach
commonly desired in software development. Consequently, due to the non-modular
nature of the ifcOWL ontology and its resemblance to the comprehensive IFC
schema, users and developers are constrained by the predefined structure and
scope of the ontology. The intricate interconnections within the ontology make
it challenging to tailor the ontology to specific application requirements
without considerable effort. This limitation hinders the flexibility and
adaptability often sought in data modeling.

Despite the limitations associated with the ifcOWL initiative, it laid the
groundwork for the emergence of the W3C Linked Building Data community and the
buildingSMART Linked Building Data working group [121]. These collectives are
dedicated to standardizing the presentation and interchange of building data
on the internet, thereby propelling the Architecture, Engineering,
Construction, and Operation (AECO) industry toward a heightened state of
technological advancement. Consequently, owing to these concerted endeavors,
various other undertakings strive to define a framework comprising more
compact, modular, and adaptable Linked Building Data (LBD) ontologies. These
ontologies aim to establish an ecosystem less reliant on IFC while
encompassing similar concepts.

Semantic modeling technologies, manifested as ontologies in the context of the
building operation phase, will be examined in detail within Section 4.1. This
examination will encompass a comprehensive exploration of the concepts
embedded in these ontologies and an in-depth analysis of their constraints.

###  3.3 Ontologies and Semantic Web

Semantic models, often called semantic or metadata schemas, encompass
information that elucidates the description and meaning of the underlying
data. These models serve as frameworks for organizing information,
facilitating a more nuanced understanding of data as comprehensibility is
crucial for developing intelligent building applications. These models’
complexity varies widely, and this variation is elaborated upon through a
hierarchical perspective.

At the foundational level, straightforward lists of terms (e.g., types of
sensors) offer basic categorizations without intricate relationships or layers
of meaning. These lists contribute to a fundamental information organization
but need more depth of analysis and contextual connections in more
sophisticated models. Progressing along the complexity continuum reveals the
emergence of taxonomies characterized by a structured approach to
classification. Data organizes itself into hierarchical categories in this
structure, mirroring the hierarchical control architecture observed in
Heating, Ventilation, and Air-Conditioning (HVAC) systems. This refers to an
organized structure that governs the operation of HVAC systems. Although
taxonomies are more intricate than simple lists, their primary emphasis is
categorizing rather than capturing relationships between concepts.

The pinnacle of complexity within semantic modeling is the facet of
ontologies. Ontologies transcend previous levels by introducing the
utilization of graph data structures. In an ontology, concepts are akin to
nodes within a graph. These nodes are interconnected through graph edges,
representing the relationships and associations between various concepts
[156]. This interconnection allows for a more holistic representation of
knowledge, capturing what concepts exist and how they are interrelated. This
nuanced depiction enables a richer understanding of the context and
significance of the data. Ontology is salient to support data readability and
machine reasoning [24]. The W3C suggests more modular and simple data formats
that can be interlinked and extended over time. Figure 2(a) shows the concept
of interconnected ontologies, and it can be seen that the domain-specific
ontologies can be separated as smaller graphs and linked with other
ontologies. Experts widely acknowledge that various communities loosely
categorize artifacts as ontologies [76]. Within information science,
ontologies constitute a formalized representation of knowledge encompassing
domain-specific concepts, relationships, classes, and attributes. An ontology
can be defined as a method for explicitly establishing concepts, classes,
objects, and their corresponding interrelations within a specified domain of
interest [75]. Another definition explains ontology as a “formal, explicit
specification of a shared conceptualization,” recognizing the importance of
achieving a shared understanding of the knowledge represented [144].

(a) The Interconnection of domain-specific ontologies.

(b) RDF Illustration.

(c) NGSI-LD Information Model.

Figure 2: Key components of semantic data modeling and interoperability in
smart environments.

The Semantic Web, an extension of the World Wide Web, was brought into being
by formulating standards by the W3C. Its primary objective is facilitating
machine-readable capabilities for internet-based data [150]. The inception of
linked open data (LOD) [10] aimed to reduce obstacles in disseminating,
sharing, and retrieving information online, fostering a worldwide data
environment. Using this method; data must be structured via the Resource
Description Framework (RDF) [39]. This concept lays the groundwork for the
renowned 5-star open data [7], which means organizing data based on the RDF
model and connecting it to other RDF data collections, leading to the
formation of the LOD cloud. The RDF data model represents data using subject-
predicate-object triple structures, as shown in Figure 2(b), which create
graph patterns. An RDF triple provides a framework for illustrating things and
their relationships. The predicate acts as the bridge connecting the subject
and the object. Essentially, this format allows any given subject to be
related to any object, indicating the nature of their relationship through the
predicate. The Web of Data consists of interconnected graphs using the triple
format to consistently depict information to ensure the data is comprehensible
and reusable for humans and computers.

An extra layer known as the New Generation Service Interface Linked Data
(NGSI-LD) [127] can be incorporated into the ontological representation of
entities in a given domain. The NGSI-LD is a way to digitally represent each
entity and relationship within an ontology so that computers can read and
identify it without ambiguity. This is done by assigning each entity a Uniform
Resource Locator [108] (URL) / Uniform Resource Name [8] (URN) that uniquely
identifies it, as shown in Figure 2(c). NGSI-LD is based on JavaScript Object
Notation for Linked Data [141] (JSON-LD), which introduces the concept of the
@context element to provide supplementary information allowing the computer to
assimilate information with better clarity and depth. The NGSI-LD has three
major building blocks: Context Broker, Context Producer and Context Consumer.
The context broker enables organizations to manage and share data in real-time
describing what is currently happening within their systems and organizations.
The context producers allow the publication of context information, while the
context consumer processes context information of interest.

The AEC domain predominantly depends on file-based exchange. While building
information modeling has been embraced, its utilization during the operational
phase remains relatively limited. This phenomenon owes to the intricate
characteristics of the IFC standard, primarily centered on geometric
representation, and its constrained capacity for effectively establishing
interconnections across diverse data domains.

Several ontologies and data models have been developed recently, primarily
with the support of the World W3C, to facilitate the representation of the
building environment in a manner compatible with the Semantic Web. This notion
encompasses the ontologies created by the W3C Linked Building Data (LBD)
Community Group [43]. These ontologies draw inspiration from the IFC data
model yet begin with a more straightforward and modular design. Ontologies
such as Building Topology Ontology (BOT) [129], Smart Applications REFerence
(SAREF) ontology [47], Semantic Sensor Network / Sensor, Observation, Sample
and Actuator (SSN/SOSA) [79], Brick Schema [20], among others. Next section
discusses each key ontology utilized in the building operational phase,
identifying the core concepts they cover.

###  3.4 Identifying Core Concepts in Building Operational Ontologies

Concepts determine the nature of an item (its type), properties provide
general details about the item, and relationships describe the item’s
association with other items (its function or role in a more extensive system)
[5]. Main concepts are needed to support the full functionalities of the BEM
process. These concepts can include, for instance, _Building_ , _Zone_ ,
_Space_ , _Building Envelope_ , _Control Device_ , _Building System and
Equipment_ , _Sensor and Actuator_ , and _Occupant_ , as partially identified
by [126].

Buildings’ architectural and functional intricacies involve many building
systems and equipment. Within these systems and structures exists a hierarchy
of devices, such as sensors, actuators, and controllers. These devices are
pivotal in automating and managing building operations within designated
physical or virtual spaces known as zones. These zones can range from tangible
spaces (e.g., rooms, floors, and staircases) to virtual segments devised for
some operational need.

Building topologies and their spatial configurations are incredibly varied,
encompassing structures like apartments, offices, residential buildings, among
others. Consequently, it is challenging to enumerate all components in
buildings, each with their unique attributes. Within this context, space
refers to any tangible area within a building structure. While zones may
represent a collective of these spaces or be abstract areas without physical
boundaries. Moreover, the building envelope is integral to the structure’s
design and function, which consists of components that demarcate indoor and
outdoor environments, such as walls, doors, and windows. The external data
refers to data that originates independently of the building, falling outside
the scope of the building’s systems and equipment. This encompasses data
beyond the building’s control, including weather conditions, grid price
signals, and other similar factors. Occupant refers to data that are used to
characterize the behavior of individuals in a building, helping to discern
their comfort satisfaction levels and energy usage.

Given the European Union’s emphasis on enhancing energy flexibility in
buildings, semantic modeling becomes crucial for seamlessly integrating data
from various energy resource entities essential to achieving this goal. This
survey further assesses ontologies that encompass aspects of managing both
non-renewable and renewable resources and examines their interaction with
buildings to enhance energy efficiency.

Understanding these fundamental concepts is crucial when modeling the
operational scenarios of buildings. These foundational ideas provide a
framework to decipher the functionalities and constraints of semantic models
used in building operations. By grasping these concepts, professionals can
better harness these models’ potential and be aware of their inherent
limitations.

##  4 Semantic Models

###  4.1 Core Semantic Models

This section focuses on semantic models and the concepts they embody within
building operations. Since their inception, ontologies like BOT, SAREF,
SSN/SOSA, and Brick have been embraced and put into practice through various
use cases. Hence, these ontologies are subject to a more thorough discussion
than others that have seen less adoption. While not extensively discussed due
to its limited application in existing studies, the PH ontology is
acknowledged in a comparative context, as outlined in section 5. Nonetheless,
its contribution is noteworthy for introducing the innovative concept of tags,
a feature incorporated into the Brick ontology. This research recognizes the
existence of various data models based on XML or UML. However, these models
have been excluded due to their limitations in aligning with linked data
methodologies, particularly their inability to incorporate semantics into
their specifications as delineated by the W3C [39, 81]. Table LABEL:tab:other-
ontology elucidates the main (and other) ontologies discussed in this survey
related to the building operational phase. These ontologies focus on various
scopes, such as Smart Building, Smart Home, Smart City, Smart Device, Smart
Energy, and Smart Grid. However, some of these ontologies are applied to
multiple scopes. Smart building refers to buildings that can adapt to their
environment by integrating various technological systems to meet the drivers
for building progression: energy and efficiency, longevity, and comfort and
satisfaction[21]. These buildings can be of various types, such as
residential, commercial, industrial, and others. On the other hand, smart
homes are confined to residential buildings equipped with smart technologies
to provide tailored services for users [105]. A smart city is a well-defined
geographical area that leverages the integration of high technologies such as
ICT, logistics, energy production and others to support users’ overall well-
being and environmental quality [34]. Smart Energy is defined as an approach
that facilitates the combination of thermal, electricity and thermal grid
utilizing storage technologies coordinated to attain an optimal solution for
each distinctive sector and the overall energy system [102]. Smart Grid is an
electricity network that efficiently delivers sustainable, economical and
secure electricity supplies via the intelligent integration of all users’
actions, including generators, consumers and those that do both [151]. Smart
devices are defined as those that autonomously collect data about users or
their surroundings to support context awareness or guide action by providing
insights into personal or environmental contexts [95].

####  4.1.1 BOT—Building Topology Ontology

The Building Topology Ontology (BOT) offers a streamlined and expandable
framework for depicting building structures, encompassing stores, spaces,
their elements, and their 3D geometrical designs. Introduced in 2019 by the
Linked Building Data Community Group (LBD CG) under the W3C Consortium, BOT
utilizes linked data and semantic web technologies. While lightweight, BOT
helps complementing other ontologies to cover concepts in product details,
sensor readings, IoT devices, intricate geometries, or project management
data, thus simplifying semantic interoperability. This mechanism aids web-
based data integration in the AECO sectors. Although BOT allows for
representing essential building topological concepts and the relationships
between its various components [128], it has not gained recognition as an
official W3C standard [74].

The BOT fundamentally centers around conceptualizing buildings’ structural and
spatial intricacies. This ontology examines the various configurations and
organizational patterns that buildings can possess, capturing their complex
spatial and relational characteristics. The primary objective of BOT is to
offer a comprehensive framework to model buildings and their internal
components in a structured manner, as depicted in Figure 3.

Figure 3: Representation of Building Topology by BOT (image from [128]).

BOT comprises a class taxonomy for zones (building site, buildings, store, and
spaces). In the BOT ontology, the zone class bot:Zone facilitates the nuanced
representation of distinct three-dimensional volumes within a building’s
topology. The conceptual framework of BOT pivots around an organized hierarchy
that can nest more specific, characterized areas within these spaces. A
meticulous exploration of the sub-classes provided by BOT unravels a versatile
set of tools to articulate a spectrum of spaces, each carrying distant spatial
functional attributes within a building’s architecture and function.

The BOT element class bot:Element represents concepts such as Envelope,
Building Systems and Equipment, Control Devices, and Sensors. The
incorporation of the interface class, identified as bot:Interface within BOT,
provides a medium to represent spatial intersections where zones and elements
converge or interact. This concept forms a networked spatial representation
wherein entities and their interfaces form a cohesive, interconnected web,
enabling the representation of a building as an interlinked system of spaces
and elements.

BOT establishes the relationships among instances of zones and elements based
on various properties within the ontology schema. Relationships among zones,
particularly those about their physical and spatial relationships, can be
structured using properties like bot:containsZone, bot:adjacentZone, and
bot:hasBuilding, among others. These properties facilitate the development of
a spatially coherent model where zones are not merely isolated entities but
part of an interconnected spatial ecosystem within the building structure.

BOT is a minimalist ontology aligned with other ontologies to meet the needs
of building operational use cases. Thus, it cannot be used alone to
semantically describe the building domain. Depending on the use case, it
collaborates with other ontologies, employing ontology alignments [136].

####  4.1.2 SAREF—Smart Applications REFerence Ontology and its Extensions

Initiated in 2013, The SAREF ontology is a reference for IoT applications
[62]. This project was a joint effort by the European Commission and the
European Telecommunication Standardization Institute (ETSI) to create a
unified ontology, working closely with the smart appliances industry [36].
Among a diverse array of IoT standards, platforms, and technologies spanning
various sectors [49, 48], SAREF serves as a universally agreed-upon model
facilitating communication between IoT devices from various producers using
distinct protocols and standards [35]. ETSI presents SAREF through a sequence
of technical specifications. At the time of this review, the SAREF ontology
includes a foundational core ontology tailored for IoT [62] and has 12 domain-
specific extensions, which covers areas like SAREF4ENER for Energy [53],
SAREF4ENVI for Environment [54], SAREFBLDG for Building [51], SAREF4CITY for
Smart City [57], SAREF4INMA for Industry and Manufacturing [55], SAREF4AGRI
for Smart Agriculture and Food Chain [56], SAREF4AUTO for Automotive [50],
SAREF4EHAW for eHealth/Ageing-well [52], SAREF4WEAR for Wearables [60],
SAREF4WATR for Water [59], SAREF4LIFT for Lift [58], and the recently added
SAREF4GRID for Smart Grid [61]. It also includes SAREF for Systems
(SAREF4SYST), previously an extension of SAREF. It now functions as a model
for illustrating how SAREF can be extended and applied to describe diverse
sets of application-specific information in various fields. In 2017, a
preliminary solution using SAREF was showcased and applied to current
commercial products in the energy domain [109]. Given the focus of this survey
on the building domain, the discussion will center on the relevant SAREF
extensions, including the core SAREF, SAREF4BLDG, SAREF4ENER, and SAREF4SYST.
The SAREF4GRID ontology, having been recently released, remains unexploited in
practical use-case scenarios. Consequently, a brief explanation of this
ontology will be provided. The SAREF core ontology encompasses 29 classes, 35
object properties, 4 data properties, and 10 named individuals. Table 1 shows
the number of classes, object properties, data properties, and named
individuals for SAREF and its extensions.

Table 1: SAREF and its extension’s ontological specification Ontology |  Classes |  Object Properties |  Data Properties |  Named Individuals
---|---|---|---|---
SAREF |  28 |  35 |  4 |  10
SAREF4SYST |  3 |  9 |  0 |  0
SAREF4ENER |  63 |  17 |  40 |  20
SAREF4BLDG |  72 |  179 |  83 |  0
SAREF4ENVI |  21 |  19 |  8 |  12
SAREF4CITY |  31 |  36 |  7 |  0
SAREF4INMA |  24 |  20 |  11 |  0
SAREF4AGRI |  26 |  13 |  5 |  7
SAREF4AUTO |  109 |  49 |  9 |  22
SAREF4EHAW |  50 |  37 |  52 |  28
SAREF4WEAR |  27 |  21 |  11 |  11
SAREF4WATR |  54 |  34 |  19 |  76
SAREF4LIFTS |  75 |  23 |  18 |  5
SAREF4GRID |  41 |  28 |  43 |  28

At its core lies the concept of saref:Device, representing a tangible object
capable of performing one or more saref:Function as shown in Figure 4. This
function denotes devices’ primary roles, such as temperature regulation by a
thermostat. Devices also operate in specific saref:State, giving insights into
their current mode, like being operational or on standby.

Figure 4: Overview of core SAREF ontology (image from [62].

The SAREF ontology introduces the concepts such as saref:Command and
saref:Service to facilitate interactions and operations with these devices.
Commands act as directives sent to devices, triggering specific actions or
changes, while services encapsulate a device’s operations or capabilities.
Underlying these interactions are saref:Task, specific sets of actions
assigned to a device. An essential consideration in this ontology is the
saref:Profile, which reflects the behaviors concerning power or energy
consumption patterns.

SAREF also focuses on procedure, command, and operation execution. The
saref:ProcedureExecution infers the act of carrying out a procedure performed
by a device. saref:CommandExecution illustrates the execution of a command and
relates to some feature of interest aspect, where the saref:FeatureofInterest
can be a tangible entity like temperature, and saref:OperationExecution
depicts the execution of an operation in a network. A saref:Commodity,
represents the main goods or products that may be consumed, produced, or
stored by some device or feature of interest such as energy. saref:Property,
denoting specific attributes of these features. saref:Observation then provide
quantified property values via a procedure to calculate the value of a
property of a feature of interest. The SAREF documentation provides a more in-
depth discussion [62].

The SAREF4BLDG is an extension of the SAREF ontology [62] dedicated to
buildings that incorporate elements from the IFC and BOT. While it draws
inspiration from models of building spaces and topology, its primary focus is
on devices within those buildings, meaning that while it can model the
physical structure of a building, its primary concern is on appliances and
systems. The s4bldg:Building and s4bldg:BuildingSpace classes in SAREF4BLDG
help define the physical layout and sections of a building. Generally, Zones
and Spaces are terminologies used to describe specific areas within a
building. The SAREF4BLDG specializes in generic device definition from
saref:Device to include building-specific devices. Examples are boilers
(s4bldg:Boiler) and cooling towers (s4bldg:CoolingTower). The SAREF4BLDG
extension introduces attributes to represent the location using the W3C’s
basic geo vocabulary [74]. This ensures a standardized representation of
location data. The relations s4bldg:hasSpace and s4bldg:isContainedIn
determine the physical relationships between spaces in buildings. The
SAREF4BLDG ontology class represents physical objects associated with
buildings and their components using s4bldg:PhysicalObject. Physical object
refers to an umbrella of items about walls, doors, windows, beams, and
potentially any tangible component within a structure.

The SAREF4SYST ontology is uniquely positioned within the SAREF framework,
delineating and modeling the complex web of device relationships, emphasizing
their connectivity and interaction dynamics. A noticeable hierarchy emerges
within complex systems, especially in smart environments, with devices linking
to form subsystems that connect to more comprehensive systems. This ontology
aims to capture these relationships with precision, documenting each device’s
placement and its links within a system or subsystem in detail.

SAREF4ENER is another extension of the SAREF ontology, developed in
collaboration with Energy@Home [45] and EEBus [44] to facilitate seamless
communication between smart appliances from different manufacturers that
integrates into any energy management system at the building or in the cloud.
The SAREF4ENER ontology concentrates on a specific aspect of energy
management, such as demand response scenarios. Demand response, in the context
of the Smart Grid, is an approach that encourages end-users or consumers to
modify their usual electricity consumption patterns in response to certain
triggers [139]. Within these demand response applications, the SAREF4ENER
introduces the concept of a Customer Energy Manager (CEM).

The SAREF4ENER establishes concepts such as s4ener:PowerProfile which is a
subclass of the profile class from the core SAREF saref:Profile. The
SAREF4ENER introduces classes that are necessary for smart energy management.
These classes are incorporated to schedule devices in specific modes and
preferred times using power profiles to optimize energy efficiency and
accommodate the customer’s preferences. Examples of these classes are
s4ener:PowerProfile, s4ener:AlternativeGroup, s4ener:Slot, and
s4ener:PowerSequence. A detailed examination of the SAREF4ENER structure is
available within its documentation [53].

The Smart Grid Ontology extends SAREF to provide a standardized representation
of general concepts for smart grid data oriented to the IoT field [61].

####  4.1.3 SSN—Semantic Sensor Network and SOSA—Sensor, Observation, Sample,
and Actuator

The SSN/SOSA ontology results from the fusion of two related ontologies: SSN
and SOSA. The W3C SSN Incubator Group created the SSN ontology, uniquely
describing sensors regarding their capabilities, measurement processes,
observations, and deployments, which aim to represent sensor-based systems
[29]. They offer a robust framework for modeling various building systems and
equipment. The SOSA emerged from a reconsideration of the SSN due to scope
changes, shifts in the target audience, technological advancements, and
lessons learned over the years [88]. Combining these two ontologies resulted
in a more comprehensive ontology, as depicted in Figure 5. This combined
ontology offers a semantic description of systems comprising sensors and
actuators, observations, measurement procedures, the subjects, and their
properties observed or acted upon, samples, and the sampling process [78].

Figure 5: Integrating Building Data with Observation and Sensor Data Utilizing
SOSA/SSN (image from [78]).

In SSN (ssn:System), modelers can capture various systems and equipment
present in a building, like the Air Handling Unit (AHU). Additionally, SSN
includes a property class (ssn:Property) to delineate the intrinsic
characteristics of the equipment.

SSN/SOSA goes beyond equipment representation and also encompasses control
devices. Systems can implement procedures that carry out actions based on
observation inputs. The core class, ssn:Sensor, and sosa:Actuator, in SSN/SOSA
are vital for modeling sensor and actuator devices. The sosa:Sensor class, a
sub-class of the SSN System, represents devices involved in or implementing a
sosa:Procedure.

Actuators, denoted as sosa:Actuator, are devices used by or implementing SOSA
procedures to alter the environment’s state. In SOSA, a class called
sosa:ActuatableProperty is introduced to help modelers characterize what
aspects of a sosa:FeatureOfInterest can be acted upon in the environment. For
instance, it can represent a window’s ability to be opened and closed by an
attached actuator.

Additionally, the ssn-system:SystemProperty class enables modelers to define
characteristics that represent a system’s ability to function for its primary
purpose. For instance, it depicts a sensor’s capacity to generate observations
or an actuator’s capability to actuate in a given environment.

####  4.1.4 Brick

The Brick Schema is an open-source, semantic data modeling framework for smart
buildings and building automation systems. Brick initially found its
description and application within the academic community, with its first
publication emerging in 2016 [2]. Brick encompasses an extensible dictionary
of terms and concepts within the building domain. It is an open-source
initiative that standardizes semantic descriptions of buildings’ physical,
logical and virtual assets and their relationships. Brick is an ontology-based
metadata schema that effectively represents buildings and their subsystems by
capturing their necessary entities and relationships, described in a machine-
readable format. The Brick ontology comprises five significant concepts:
Entity, Tag, Class, Relationship, and Graph.

From the standpoint of brick, an entity is an abstraction of actual things in
a building that can be physical, abstract, or logical. Physical entity refers
to any identifiable object or substance that exists in the physical world. It
has a tangible, measurable presence and can concretely interact with the
physical environment. Physical entities encompass various items, such as
mechanical equipment like HVAC systems, lighting systems, networked devices
like electric meters, thermostats and spatial elements like rooms and floors.
Virtual entities are digital constructs or representations within computer
systems, software applications, or virtual environments rather than having a
physical presence in the real world. Examples include temperature sensors,
energy consumption of a space heater, and actuation points, which are used to
observe the current state of the environment and infer changes when required.
Logical entities are entities or collections of entities defined by rules.
Examples are HVAC zones and lighting zones.

Tag is an attribute that characterizes an entity adopted from the project
haystack [80], which is further explained in Section 4.1.5. Tags can describe
physical, virtual or logical entities. For instance, the tags brick:AHU,
brick:Sensor, and brick:Lighting serve as examples for physical entities.
virtual entities are represented by tags such as brick:Setpoint, Energy Usage
Sensor. While tags like brick:Energy Zone, HVAC Zone, exemplify logical
entities.

A class represents a defined category with intentional meaning, serving as a
mechanism for categorizing entities. Organized into a hierarchical structure,
classes act as the types of entities, each being an instance of one or several
classes. Furthermore, classes possess an array of related tags, offering
valuable annotations that aid discovery. Brick exhibits a hierarchical design,
where Classes and Subclasses define varying levels of detail [26]. Within the
Brick model, although five classes exist, only three are predominantly used in
the building domain: brick:Location, brick:Equipment, and brick:Point. The
brick:Location class describes a physical or virtual space like a Zone.
Moreover, this class encompasses 10 subclasses with a hierarchical subclass
level. The brick:Equipment class represents devices that serve all or part of
a building and has 22 subclasses. The brick:Point class describes
measurements, setpoints, commands, parameters, alarm and device status from
varied devices, and it consists of 6 subclasses.

A relationship delineates the specific nature of the connection between two
interconnected entities. For instance, the placement of a temperature sensor
within a room inside a building can be expressed through the use of
brick:hasPart to define the relationship between the building and the room,
and brick:isPointOf to associate the temperature sensor with the room.

Brick utilizes a directed, labelled graph to represent its structure. Figure 6
depicts a graph representation of connections between various entities within
a building [103]. These entities are an AHU, two variable air volume boxes, a
thermal zone identified as HVAC zone, and a set of points and rooms.

Figure 6: Brick model representing an AHU, two VAVs, and a handful of points
and rooms (image from [20]).

The Brick ontology is built on design principles that include completeness,
expressiveness, usability, consistency, and extensibility [2] [3].
Completeness is the ability of an ontology to encompass all the information
required by building applications. Expressiveness indicates the ontology’s
capability to represent a wide range of entities and relationships prevalent
in buildings, which is crucial for crafting BEM applications. Usability
suggests that the ontology ought to be straightforward and user-friendly.
Consistency ensures that the modeling process remains uniform across various
users when employing the ontology. Extensibility guarantees that the ontology
can be effortlessly expanded to incorporate new concepts.

####  4.1.5 PH—Project Haystack

Project Haystack (PH) is a semantic data model designed to represent various
equipment and their relationships within automation, control, energy, HVAC,
and additional environmental systems [80]. This initiative aims to provide
standardized data to facilitate a seamless exchange of information and unlock
value from the vast amounts of data generated by smart devices in homes,
buildings, factories, and cities.

PH associates physical objects within buildings to entities, where an entity,
from PH’s perspective, represents an abstraction that could be a single site
(such as a building identified by an address), a specific piece of equipment
within a building (e.g., an HVAC system, an electric meter, or a variable air
volume box), or a sensor point (which includes digital or analog sensors
generating signals and data, e.g., temperature or pressure sensors and on/off
switches).

PH is fundamentally structured around the use of tags. Each tag specifies a
fact or attribute about an entity. For instance, assigning a site tag to an
entity signifies that the entity is recognized as a building with an address,
aligning with the definition of a site tag according to Project Haystack. It
also includes over 200 tags designed to standardize the description and
relationships of equipment, systems, and their associated data. This tagging
system is flexible, allowing for the application of tags pertinent to
particular applications relevant to specific applications.

In Project Haystack, Site, equip, and point are the three main tags for
defining an entity. Many tag types exist, including marker, string, reference,
among others. A marker tag is merely an annotation with no associated value to
identify an entity type. For example, applying the ahu tag to an entity
indicates that it is an air-handling unit. A string tag has an associated
value commonly used for human-readable descriptions. A string tag is
accompanied by a value, often utilized for descriptions that are readable by
humans.

###  4.2 Others

This section describes other ontologies covering certain BEM areas, as shown
in Table LABEL:tab:other-ontology. Some of these ontologies leveraged existing
ones by identifying specific gaps and introducing new concepts to extend them,
specified in the "Uses/Extends" column. This column represents domain-specific
ontologies in building operational phases used to develop new ontologies.
Ontologies that did not mention if they utilized other ontologies were
regarded as "None". The number of classes provided was counted manually on
those ontologies that explicitly listed them on their website. For those that
did not provide this information, the Protégé222https://protege.stanford.edu/
was utilized to count the number of classes by passing the ontology file into
the software. These ontologies can be aligned and integrated with other
ontologies to cover certain building concepts. Ontology alignment refers to
finding equivalent entities across two different ontologies [1]. Ontology
reuse explains when an ontology is based on another, meaning it extends or
derives its structure from an existing ontology [25]. While these concepts
seem similar, it is important to provide a clear distinction between the two
cases to comprehend when an ontology is reused or aligned with other
ontologies.

RealEstateCore is an ontology tailored for smart buildings developed from
well-established real estate and construction practices. It is modular,
consisting of a collection of data schemas that describe concepts and
relationships pertinent to the modeling of buildings and their systems, as
well as data derived from these systems [153]. It supports two main use cases:
energy usage analysis and optimizations, and presence analysis. Also, it
promotes the interaction between smart buildings and smart cities. The
ThinkHome ontology is specifically designed for smart home environments,
emphasizing the management of energy supply and consumption [130]. It
encompasses models that cover various aspects such as comfort, user behavior,
processes, energy, devices, external influences like weather, and the building
structure itself. The ThinkHome Ontology aims to create an extensive knowledge
base that encapsulates all the necessary concepts to facilitate the
development of energy-efficient and intelligent control mechanisms for home
environments. Energy Flexibility Ontology (EFOnt) aims to serve as a
standardized tool for knowledge co-development and streamlining energy
flexibility-related applications [98]. It provides a standardized
representation of energy flexibility resources in buildings. DogOnt Ontology
(modeling for Intelligent Domotic Environments) emphasizes the modeling for
all devices being part of IoT inside a smart environment [15]. It encompasses
a rule-based mechanism that automatically generates states and functionalities
for domotic devices. Mirabel delineates how devices can express their energy
flexibility by integrating the user preference with the device energy profile
[152]. The ontology-based power consumption model (PowerOnt) is tailored for
smart homes to represent concepts of power consumption pertinent to smart
devices [16].

A smart building ontology for ambient intelligence (BonSAI) is an ontology to
model aspects of service-oriented smart building system [143]. This refers to
a framework where various functionalities are provided as services. These
services include operations that the system can perform, inputs it can take,
output it can produce, the logic it uses to process information, parameters it
operates with, and the environmental conditions it monitors or controls. This
ontology is based on an upper ontology named Web Ontology Language for
Services (OWL-S) [106] for service description and the Context-Driven
Adaptation of Mobile Services (CoDAMoS) [125], which provides services
depending on the user and environmental context. The owl-s ontology is not
included in Table LABEL:tab:other-ontology because it is an upper ontology
alongside the CoDAMoS ontology as it is deprecated. SARGON (SmArt eneRGy
dOmain oNtology) defines semantic descriptions of the smart assets in building
and smart grid and their relationships [77]. This model is based upon the
SAREF4ENER ontology, extending it to include concepts relating to the
distribution of electrical grid and building energy automation. Flow Systems
Ontology (FSO) describes the energy and mass flow relationships between
building systems such as HVAC, building components and their compositions
[94]. Due to the limitations of FSO ontology to represent system components’
capacity and size-related properties, the Flow Properties Ontology (FPO) was
introduced to cover those concepts [92]. Building Automation and Control
Systems (BACS) represents physical devices of Building Automation Systems
(BAS) and their location in the building and connection to technical equipment
and appliances, alongside control behaviors [149]. BASont ontology proposed
integrating device descriptions on BAS devices and functional specification
with adjacent domains of BIM [123]. Smart Building ontology (SBonto) [158]
focuses on smart building (private or public), which defines concepts such as
device, state, architecture, environment, furniture and network.

Another smart building ontology (Onto-SB) was proposed to provide a structured
framework for modeling smart buildings and their environment [40]. It models
various concepts, including building actors, representing the inhabitants
living within the building. Also, it supports the reasoning process behind
mitigating building energy consumption.

The RESPOND ontology manages real-time optimal energy dispatching, considering
all energy on-site. It aims to deploy an interoperable energy automation,
monitoring and control solution to deliver demand response programs at a
dwelling, building and district level [46]. The Smart Energy Aware System
(SEAS) is an ontology designed to support the interoperability and efficiency
of smart energy systems [97]. It is a structured framework that defines a
common vocabulary for smart energy systems, including energy production,
consumption, conservation, and efficiency concepts. It can be aligned with
other domain-specific ontologies like SSN/SOSA. The Open Energy Ontology (OEO)
is a domain ontology for energy system modeling and analysis [17]. The Smart
Grid (SG1) Ontology was developed to describe a prosumer-oriented smart grid
to facilitate data integration and communication with buildings [72]. Another
Smart Grid (SG2) Ontology was designed to describe entities and their
interrelationships in smart grid systems to enable cyber attack identification
[147].

An Ontology-Based Information Model for Smart Grids (SSG) was developed to
enable semantic interoperability between heterogeneous smart grid components
to ensure grid interactive buildings [134]. It was based on the IFC data
model, mostly used in the building design phase. The Semantic Smart Grid
Information Model (SSGIM) is an ontology designed to integrate essential
information for demand response applications [160]. It is based on the
International Electrotechnical Commission’s Common Information Model standard
[28] to describe electrical equipment, DBpedia [37] to represent spatial,
organization, and infrastructure concepts, and it utilizes a weather data
model to encompass weather-related information [19].

[ caption = An overview of the analyzed key ontologies., label = tab:other-
ontology, remarkTable Note = In this table, the ontology names are linked to
where they are explained in more detail in the text and the numbers of classes
are linked to the repositories where the ontologies are publicly available on
the Internet., ] colspec = X[2.5]lXX[2.5]Xlll, cells = font = , rowhead = 1,
rowfoot = 2, hlines, stretch=0, rows=ht=, 2pt]- Ontology Ref. Year
Uses/Extends Classes Formats Scope Main Focus
2pt]-

BOT [128] 2017 None 7 T Building topology

SAREF [62] 2015 None 28 $\ast$ Energy efficiency

SSN/SOSA [29, 88] 2019 None 19 T Sensors and measurements

Brick [2] 2016 PH 5 T Building entities

PH [80] 2014 None 479* N/A  Building info. from devices
2pt]- RealEstateCore [153] 2019 SSN/SOSA 141[153] R Buildings in cities

ThinkHome [130] 2010 None 1152 O Energy for homes

EFOnt [98] 2022 None 87 $\ast$ Energy-flexibility

DogOnt [15] 2008 None 1110 $\ast$ Devices

Mirabel [152] 2012 None 5[134] C Energy flexibility

PowerOnt [16] 2015 DogOnt 1070 O Energy efficiency

BonSAI [143] 2012 None 84 R X Ambient intelligence
SARGON [77] 2020 SAREF 169 T O Building entities

FSO [94] 2022 None 14 T Mass/energy flow

FPO [92] 2023 FSO 50[93] C HVAC components

BACS [149] 2017 BOT SSN/SOSA 9 O Automation and control

BASont [123] 2012 None N/A C Automation systems

SBonto [158] 2017 None N/A C Smart buildings

Onto-SB [40] 2019 None N/A C O Smart buildings

RESPOND [46] 2020 BOT SEAS SAREF 45 $\ast$ Energy dispatching

SEAS [97] 2017 None 293 $\ast$ Energy analysis

OEO [17] 2021 None 928 O Energy system analysis

SG1 [72] 2014 None N/A C T Real-time management

SG2 [147] 2023 None 75 O Vulnerability assessments

SSG [134] 2019 None N/A C O T Smart grid component

SSGIM [160] 2012 None N/A C O DR applications

SEPA’s SG [140] 2020 None 250[12] T Smart grid applications

OEMA [32] 2017 ThinkHome, SAREF4ENER, and SG1 24 $\ast$ Different energy
domains

DABGEO [33] 2020 OEMA 1965 O Different energy domains

DELTA [67] 2021 OpenADR
SAREF 59 $\ast$ DR energy market

SG-BEMS [135] 2016 None N/A C O T BEMS

CIM [142] 2015 None 39 O Model profile

(New) OSEIM[133, 132] 2019,21 None N/A C O Electrical energy consumption

BEM [101] 2019 SSN N/A C O Energy optimization

Digital
Buildings [73, 6] 2020 Brick PH 1308 R Buildings equipment

ICBMS [89] 2017 SAREF N/A C Thermal comfort analysis

EM-KPI [100] 2019 SSN ThinkHome 133 $\ast$ KPI for building performance

KPI [65] 2020 saref4city SAREF 17 $\ast$ KPI for building renovation

PF [30] 2015 SSN N/A C Building performance analysis

BOP [42] 2021 None 18 $\ast$ Building performance analysis

SBMS [91] 2018 SSN 25 O Building automation systems

SEMANCO [104] 2012 None 980 O Urban plan. and energy mgmt.

OpenADR [68] 2020 None 76 $\ast$ Demand-response

SESAME [64] 2010 None N/A C O N Energy Optimization

Home Appl. [137] 2011 None N/A C O Energy consumption
ONCOM [115] 2019 SSN/SOSA N/A C O Thermal Comfort
OP [66] 2020 SAREF 66 $\ast$ Building energy profiles
_Scopes_ : Smart  Device,  Home,  Building,  City,  Energy,  Grid

white]-

_Formats_ : T Turtle, R RDF, X XML, O OWL, J JSON-LD, N N-Triples, $\ast$ (3+)
formats, C Closed Source

white]-

The ontology created by the Smart Electric Power Alliance (SEPA) was designed
for building management. It encompasses the registration of energy
consumption, which serves as the foundation for Smart Grid applications[140].
The Ontology for Energy Management Applications (OEMA) represents energy
performance and contextual data from various energy domains [32]. It is based
on ThinkHome, SAREF4ENER, the prosumer smart-grid oriented ontology and an
energy use ontology which is currently deprecated. The Domain Analysis-Based
Global Energy Ontology (DABGEO) is the improved version of the OEMA ontology
that provides adequate control to energy management applications [33]. The
DELTA ontology aims at modeling concepts relating to demand response to
promote interaction between buildings and energy providers [67]. The Smart-
Grid Building Energy Management System (SG-BEMS) provides an abstraction layer
that enables the semantic representation of smart grids and buildings to
establish interactions for BEMS operations [135].

The Common Information Model (CIM) for smart grids developed by the Cerise-SG
project is an ontology to represent information related to smart grids [142].
The Ontological Solution for Energy Intelligent Management (OSEIM) and
NewOSEIM represent objects that relate to both internal and external home
environments [133, 132]. These objects can have an impact on electrical energy
consumption, and they provide a reasoning mechanism to achieve intelligent
energy management. A framework based on ontology was initiated for building
energy management (BEM) to identify the cause of a building’s energy
efficiencies and inefficiencies [101]. This framework allows for the inference
of proper control strategies when necessary.

Google digital buildings represent structured information and building-
installed equipment [73, 6]. The ICBMS (IoT, Cloud, Big-Data, Mobile,
Security) ontology extends upon the SAREF ontology, incorporating concepts
related to states, sensor measurements, and units to support building
applications such as thermal comfort [89].

The Energy Management Key Performance Indicator (EM-KPI) ontology facilitates
the exchange of key performance indicator information and data for districts
and buildings [100]. This provides a standardized structure to compare
building performance aspects to other buildings based on certain performance
metrics. A KPI ontology was introduced to represent metrics associated with
building renovation activities to conform to requirements of energy-efficient
buildings [65]. A Performance Assessment (PF) ontology was introduced to allow
building performance assessments at a granular level [30]. This stemmed from
the idea of evaluating building performance to support optimization. It is
based on three data models: the SSN model, the Simulation Domain Model
(SimModel), a data model for the building simulation domain [112], and the
ifcOwl ontology. The SimModel and ifcOwl ontology were not included in Table
LABEL:tab:other-ontology as they are not often used in building operations.
Another Building Performance Ontology (BOP) was initiated to facilitate a
homogeneous data environment used by complex building performance assessments
[42]. This method involved the integration of static and dynamic data points
for thermal comfort analysis. The Semantic BMS (SBMS) ontology was designed to
represent building automation systems and aid building operations analysis
[91]. It includes a unified model called SBIM, which describes building
information modeling elements and is utilized by the principal SBMS ontology.

Semantic Tools for Carbon Reduction in Urban Planning (SEMANCO) facilitates
access to diverse energy-related data from various organizations, supporting
the assessment of energy analysis across cities [104]. Open Automated Demand
Response (OpenADR) ontology is designed to standardize the representation of
demand response systems, thereby enhancing semantic interoperability within
the demand response domain. [68]. The SEmantic SmArt Metering (SESAME) is an
ontology-based model that enables the integration of smart metering, building
and rule-based reasoning to provide energy optimization for energy consumers
and providers [64]. This ontology was developed under the SESAME-S project.

Home appliance ontology encompasses the home energy management domain, and it
was developed to support energy consumption performance analysis of home
appliances [137]. Also, it extends the Suggested Upper Merged Ontology (SUMO),
which is a generic ontology for describing a myriad of computer information
processing system [111]. The ONCOM ontology introduced a wireless sensor
network approach to semantically represent sensor from the sensor network to
support emotional state analysis of building occupants, towards reaching
adequate indoor thermal comfort [115].

The Ontology Profile (OP) ontology was developed to represent occupancy
profiles in building spaces, detailing how occupant’s behavior impacts
building energy [66]. Another ontology was proposed to provide a standardized
representation of energy-related occupant behavior in buildings [85]. However,
since this model exclusively relies on the XML and occupant behavior XML
format (obXML) [84], it has not been included in Table LABEL:tab:other-
ontology.

##  5 Identifying Usecase Scenarios on the Application of Ontologies

This section identifies relevant use case scenarios for applying the ontology
described above to diverse building applications. It will be subdivided into
three categories: single, double, and multiple ontology use case scenarios.

Table LABEL:tab:usecase summarizes the use case scenarios, highlighting the
ontologies utilized, the concepts covered, and the classes employed for
concept representation. This summary does not consider the correspondence
between classes and concepts. Yet, the review acknowledges that multiple
classes might represent a single concept. Some of these ontologies used upper
ontologies, which are not limited to a specific domain, to define general
concepts such as time, units of measurement, and space positioning of
individuals [82]. These upper ontologies will not count as complementary
domain-specific models since they are general-purpose and are used across
multiple domains.

###  5.1 Single-Ontology Use Case Scenarios

Single ontology use case scenarios refer to data-driven applications that
employ a singular ontology to characterize the data and its contextual
meaning. The subsequent text outlines research endeavors that utilize a single
ontology for their applications.

A study focused on an in-depth analysis of physical systems within a generic
zone inside a building [11]. Their primary objective was to offer a
standardized depiction of the components within that system. By doing so, they
aimed to facilitate simulations that accurately mirror the dynamic environment
within a building, a crucial step in supporting the energy modeling processes.
This, in turn, allows for rigorous ongoing commissioning of a building’s
systems and creates an avenue for detecting and diagnosing faults. To achieve
this, the study leaned heavily on the SAREF ontology and its two extensions;
SAREF4BLDG, and SAREF4SYST. The research demonstrated how SAREF4SYST could be
employed to link data-driven models representing the dynamic behavior of
SAREFBLDG components such as s4bldg:BuildingSpace, s4bldg:SpaceHeater,
s4bldg:Valve, saref:Sensor, s4bldg:Controller, and s4bldg:Damper. This linkage
was accomplished using the s4syst:System, s4syst:Connection, and
s4syst:ConnectionPoint classes. It is worth noting that while the study’s
focus was on a singular zone within a building, the authors believe that the
methodologies they employed can be extrapolated and applied to entire
buildings.

SAREF ontology’s validity was tested by creating two SAREF implementations in
a smart home setting [154]. First, by mapping data from the smart home to a
knowledge graph using SAREF. The second one explores data sharing between
different devices using an interoperability framework. The validation of
success occurs when all information from the data source is accurately modeled
using SAREF, ensuring no loss of information. The experiment involved 33 smart
devices within an unidentified smart home, with an objective to transform the
data from these devices into a knowledge graph using the SAREF ontology. After
eliminating redundancies, nine unique data sources remained, which included
current temperature, CO2 levels, humidity, target temperature, and three
distinct occupancy indicators: last-time movement, first-time movement, and
the presence of occupants. The researchers executed a study to fine-tune room
temperature. Of the nine devices, a thermostat and a CO2 sensor were pivotal
to the experiment. These sensor data were mapped to the SAREF ontology using
specific classes, such as saref:Measurement, saref:UnitOfMeasure,
saref:TemperatureUnit, saref:Property, saref:FeatureOfInterest, saref:Device,
saref:Task, saref:Comfort, saref:WellBeing,
saref:Function, saref:SensingFunction, saref:Command, saref:State, and
saref:Service. However, they incorporated the OM1.8: Unit of Measure ontology
[131] as an upper ontology to instantiate the unit of measurement. For
example, using om:degreeCelsius to represent temperature. Finally, the
modeling of these concepts was used to facilitate the automation of room
temperature to enhance user comfort.

Another data modeling application was demonstrated using the Open Power System
Data (OPSD) [114] to execute data mapping [155]. This dataset comprises
information from 68 devices across 11 buildings, which include three
industrial buildings, two public buildings, and six residential households.
The study primarily focused on data from six residential households, employing
nine distinct devices that act as sensors for data extraction and mapping. The
devices used are as follows:

  * •

grid$\\_$import: Represents the energy imported from the public grid, measured
in kilowatt-hour (kWh).

  * •

grid$\\_$export: Signifies the energy exported to the public grid, quantified
in kWh.

  * •

pv: Captures the total energy generation from photovoltaic sources, gauged in
kWh.

  * •

dishwasher: Pertains to the energy consumption of the dishwasher, denoted in
kWh.

  * •

ev: Stands for the energy consumption during electric vehicle charging,
presented in kWh.

  * •

Refrigerator: Indicates the energy consumed by the refrigerator, ascertained
in kWh.

  * •

Freezer: Denotes the energy intake of the freezer, tabulated in kWh.

  * •

Circulation$\\_$pump: Specifies the energy consumption of the circulation
pump, expressed in kWh.

Although the OPSD household dataset captures information from various devices,
all measurements share a standard kWh unit. Furthermore, these devices were
represented using the following classes in SAREF, which includes
saref:Measurement, saref:UnitOfMeasure, saref:Property, saref:PowerUnit,
saref:Power, saref:FeatureOfInterest, saref:Device, saref:Meter,
saref:Appliance, saref:Task, saref:MeterReading, saref:Washing,
saref:WellBeing, saref:Comfort, saref:Function, and saref:MeteringFunction.
They also used the OM ontology to instantiate the unit of measurement as
om:kilowatt_hour. The study did not apply this data to any specific building
applications. Nevertheless, this data holds potential for building
applications, including energy management systems, demand response systems,
predictive maintenance, and solar energy forecasting.

A study aimed to evaluate long-term thermal comfort using portable and
reproducible application development techniques, leveraging a brick metadata
schema and a mortar data testbed [145]. The research utilized the mortar
testbed [69], encompassing over 25 buildings, to assess the generalizability
of the application’s performance. The evaluation employed air temperature-
based metrics, including the range outlier index, overcooling outlier index,
and overheating outlier index. The study employed the brick ontology to
represent building entities such as brick:Zone, brick:Room, brick:Floor,
brick:AHU, brick:Variable Air Volume Box and brick:Zone Air Temperature
Sensor. This ontological approach facilitated a disaggregated analytical
process at the zone, room, and equipment levels, allowing for precise
diagnosis of issues affecting long-term thermal comfort.

This research introduced an innovative approach to standardize the
representation of building data across its entire lifecycle by employing the
Brick metadata model to facilitate ongoing building maintenance [70]. Metadata
from various sources, corresponding to different stages of the building’s
lifecycle, were consolidated into a unified model through a central
integration server using the Brick model. This model encapsulated concepts
including brick:Air Handling Unit, brick:Power Meter, brick:Building Power
Meter, brick:Rooftop Unit, brick:VAV, brick:Chiller, brick:Absorption Chiller,
brick:Temperature Sensor, brick:Flow Sensor, brick:Return Air Flow Sensor. The
classes used to represent the relationships between the concepts are:
brick:hasPoint, brick:feeds, and brick:hasPart. The study aimed to gather
pertinent metadata throughout the building’s lifecycle to bolster data-driven
applications.

A study assessed how effectively three metadata schemas could represent
contextual, spatial, and functional connections among sensors in built
environments [9]. The schemas analyzed were PH, IFC, and Semantic Sensor Web
frameworks like SAREF and SSN. The evaluation involved three commercial
buildings and a broad spectrum of smart building applications. The criteria
for assessment included completeness, relationship-capturing ability, and
flexibility. Completeness was defined as the schemas’ capacity to encompass
all building sensor metadata. Furthermore, relationship capturing refers to
how well the schema could depict sensor connections with other building
entities, while flexibility is related to the schemas’ adaptability to new
building entities.

The study incorporated a tagging mechanism, initially mapping building
metadata to PH tags and creating new tags where PH was lacking. Regarding
completeness, PH, IFC, and Semantic Sensor Web scored 54%, 29%, and 11%,
respectively. For relationship-capturing ability, the scores were 77% for PH,
86% for IFC, and 41% for Semantic Sensor Web. However, none of the schemas
effectively handled new sensor information, indicating a gap in flexibility.
The study concluded that none of the investigated schemas could fully
represent all tags and semantic information in buildings. It noted the
excessive fragmentation of semantic web ontologies, limiting their practical
application.

In response to these findings, the subsequent study with the Brick ontology
sought to overcome some of these limitations [3]. While PH Haystack showed
proficiency in capturing building management system datapoints with its
tagging system, it lacked a formalized approach to tag usage. Brick adopted
PH’s tagging system but introduced a standardized and strict tag application
to characterize BMS datapoints. This approach was validated using eight
applications from the previous study and applied across six different
buildings. The findings revealed that the Brick ontology successfully captured
98% of data points in these buildings, demonstrating its efficacy in
facilitating query processes for the required information in various
applications. The brick ontology does not provide the percentage metric for
flexibility. These two studies were comparative analysis of how well these
metadata schemas could represent building information. However, they will not
be included in Table LABEL:tab:usecase since they do not provide the specific
tags and classes used to capture the BMS data points.

A study conducted an in-depth comparative analysis of ontologies to assess
their suitability for semantic interoperability in demand-side management
[38]. Eight distinct ontologies were meticulously evaluated based on essential
concepts such as spatial information, building energy systems, control and
topology, measurement setup, measurable properties, and grid interactivity.
The methodological basis for this comparative study was the metadata quality
metrics [113]. Each ontology was measured by its capacity to represent the
vital concepts, ensuring they possessed the semantic depth necessary for
delivering robust, context-aware demand-side management. Generally, this
evaluation showed that none of the models could completely model all the
concepts presented. However, Brick and SAREF emerged as the most suitable
ontologies for covering most data needed in a demand-side management
application. The authors suggest that implementing demand-side management
through an ontology-based architecture can enhance energy flexibility,
efficiency, operating costs, and environmental comfort by utilizing
intelligent, adaptive, and responsive control strategies. This study is also
excluded from Table LABEL:tab:usecase as they do not provide the classes and
tags used to describe these concepts.

This research showcased the practical implementation of SAREF in mapping
various devices from different manufacturers, essential for enhancing the
efficiency of energy consumption and production across all household
appliances through communication with a cloud-based energy management system
[71]. The investigation drew from the Dutch pilot of the H2020 InterConnect
project, where the energy manager served as a system for coordinating energy
supply and demand, proving to be an effective instrument for analyzing and
planning energy flexibility. SAREF and SAREF4ENER were employed as the
benchmark frameworks to encapsulate the pertinent data from these devices.
However, since the specific classes utilized were not disclosed, this analysis
is not included in Table LABEL:tab:usecase.

A different application of SAREF took place within a Greek pilot of the H2020
InterConnect project, aiming to convert residential buildings into smart homes
through the installation of energy meters and sensors [71]. In this context,
SAREF, alongside SAREF4BLDG and SAREF4ENER, served as the unified data model
showcasing the smooth information exchange between four distinct service
providers. Due to the absence of detailed information on the classes employed
for modeling the concepts, this study has been omitted from Table
LABEL:tab:usecase.

###  5.2 Two-Ontology Use Case Scenarios

This identifies the use cases that incorporate the use of two separate
ontologies to represent relevant building concepts. This can also be done via
extension, creating a new ontology by extending and merging with another
ontology to identify new concepts.

A hybrid inference system was proposed to infer indoor environmental
conditions within a building [89] by processing real-time data streams sourced
from a Building Automation System (BAS) located in the Researcher Hotel of
Alto University, Espoo, Finland. The primary objective of the research was to
assess the internal thermal comfort of individual apartments based on key
parameters, including temperature, humidity, occupancy status, and CO2
concentration. The inference system utilized a dataset of 4199 data points,
encompassing various aspects such as HVAC, indoor/outdoor temperature,
illuminance, and other environmental properties. To facilitate this
comprehensive data analysis, the authors proposed an ontology known as the
ICBMS (IoT, Cloud, Big-Data, Mobile, Security) ontology.

The ICBMS extends SAREF’s ontology via the sensor class to include sensor
types and their units of measurement. It also extends SAREF’s state class to
model different types of state information for a building space. The classes
employed in this study include saref:Sensor, saref:Device, icbms:CO2Sensor,
saref:TemperatureSensor, saref:HumiditySensor, saref:State,
icbms:ThermalComfortState, icbms:HotState, icbms:WarmState,
icbms:SlightlyWarmState, icbms:NeutralState, icbms:SlightlyCoolState,
icbms:CoolState, icbms:ColdState, icbms:OccupancyState, icbms:OccupiedState,
icbms:VacantState, and saref:BuildingSpace. The classes used to interlink
these concepts are icbms:hasThermalComfortState, icbms:hasOccupancyState,
icbms:hasNumberOfPeople, icbms:hasObjectid, icbms:hasPMV, icbms:hasPPD,
saref:contains, saref:isMeasuredIn, saref:hasValue, saref:isUsedFor,
saref:hasModel, and saref:isLocatedIn. Additionally, the ICBMS ontology
incorporated upper ontologies such as Time ontology [31] and the Ontology of
Units and Measure [131] to model concepts relating to time and units of
measurements associated with sensor data. The study deduced thermal metrics
such as Predicted Mean Vote (PMV) and Predicted Percentage Dissatisfied (PPD)
[146] using sensor data stored within the ontology. This comprehensive
approach aimed to enhance the building’s understanding and management of
indoor environmental conditions.

Another research introduced a middleware layer designed to enrich data from
building automation systems with additional semantic layers, support facility
benchmarking and assess facility performance to achieve efficient, economical,
and sustainable operations [91]. A novel semantic model termed the SBMS
ontology, which extends the SSN ontology, is proposed to offer a more domain-
specific description of building automation system data points. The underlying
concept was to differentiate specific domain individuals from the more general
entities described in SSN. For instance, the ssn:FeatureOfInterest is refined
by the sbms:FeatureOfInterest to specifically represent sites, buildings,
floors, rooms, or devices. This ontology contains a simplified model to
describe BIM elements using the namespace sbim. The study showcases two use
case scenarios focused on room environment and energy consumption analysis
employing the SBMS ontology. Key classes leveraged in their analysis include
sbms:Address, sbms:Datapoint, sbms:Input, sbms:Property,
sbms:FeatureOfInterest, sbms:SensingDevice, sbms:Sensing, and
sbms:Observation. Fundamentally, this approach seeks to equip developers with
user-friendly and dynamic querying tools for BMS or BAS, supporting the
development of analytical applications dedicated to building operation
analysis.

A diagnostic tool guided by the air handling unit performance assessment rules
was introduced to identify operational faults in ventilation units equipped
with heat recovery systems [110]. Semantic modeling techniques were deployed
to enhance the tool’s portability and ensure its scalability across various
AHU systems. Integrating the PH and BRICK models facilitated the
representation of entities associated with the AHU unit, utilizing metadata
(tags) designated by human experts. For the accurate characterization of a
data point, three specific tags are required: the quantity it represents, its
associated location, and its regulatory role, such as a sensor or required
value. This approach facilitated a comprehensive description of each data
point’s diagnostic relevance.

The study underscored the limitation that neither the PH nor the Brick
ontology alone could fully encapsulate the semantic data within an air
conditioning system, driving the necessity for a collaborative endeavor
towards developing a unified ontology. Although this work did not detail the
specific tags employed for modeling entities in their case study, leading to
its omission from Table LABEL:tab:usecase regarding use case scenarios, it
accentuated the effectiveness of semantic modeling strategies in achieving a
satisfactory detection rate across a broad spectrum of AHUs.

This study introduced an architectural methodology illustrating the
integration of semantic sensor networks, semantic web technologies, and
reasoning [122]. This integration aimed to facilitate the development and
implementation of sophisticated models for analytical tasks, such as
prediction and diagnosis, in real-world scenarios. A semantic framework was
developed for fault detection and diagnosis, utilizing a diverse array of
sensors within IBM’s technology campus in Dublin. A specific case study
involved a single office room equipped with a temperature sensor, occupancy
sensor, cooling actuator, and setpoint with the addition of a virtual sensor
to derive a diagnostic model for sensor anomalies. The SSN ontology described
sensor and space monitoring concepts, notably through the classes ssn:Sensor
and ssn:FeatureOfInterest. However, existing limitations in modeling concepts
like physical processes, which elucidate the cause-effect relationships among
sensors, necessitated an extension of the SSN ontology. This extension
introduced new classes with a namespace “phy”, which includes
phy:PhysicalProcess, phy:FeatureLink, phy:Anomaly, phy:Property, and phy:Cause
to encompass these concepts. The findings underscore the utilization of
semantic techniques and the adapted SSN ontology in automating analytical
tasks within buildings, demonstrating their capability to pinpoint causes and
anomalies in building systems and devices effectively.

###  5.3 Multiple-Ontology Use Case Scenarios

Multiple ontology use case scenarios pertain to data-driven applications that
employ several ontologies to depict the data underlying their analytical
processes. This approach includes integrating additional ontologies to augment
standalone ones, which may struggle to describe certain data elements within a
building context accurately. The following text will detail studies
implementing this methodology for their applications.

This work presented an ontology-based method to standardize the automatic
calculation of KPIs to aid the energy evaluation of diverse buildings [159].
This method integrates building information such as BIMs, energy consumption
and environmental data collected from sensors, which are classified into
static and dynamic categories. They presented a case study to validate the KPI
calculation approach using two office buildings in Shanghai, China. For the
two buildings, sensors were installed on each floor to collect electricity
consumption in total and per each item, including lighting, sockets, and air
conditioning, over a 15-minute interval.

The developed KPI ontology captures concepts essential for KPI calculations
using the following classes, which include kpi:Input, kpi:Result, kpi:Formula,
kpi:Parameter, and kpi:Operator. It is further enhanced by incorporating BOT
and SOSA classes to encompass static and dynamic data concepts such as
bot:Building, bot:Space, bot:Zone, sosa:Platform, sosa:Sensor,
sosa:Observation, sosa:FeatureOfInterest and sosa:Property.

The study highlighted that collecting data for KPI calculation in an isolated
manner is labor-intensive. Integrating linked data can automate and streamline
this process, allowing for a more efficient and iterative approach. It was
emphasized that while the type of building and the variations of sensors from
a different manufacturer may influence the KPI calculations for evaluating a
building’s energy performance, the analysis of the two buildings provided
results that closely mirrored their actual consumption performance. This
suggests that the methodology adopted can be effectively applied to evaluate
other buildings within the city, indicating a scalable and adaptable approach
for broader building energy assessments within the same city.

Another study examined semantic models for knowledge representation and
reasoning across various building applications, which proposed a semantic
infrastructure and techniques that utilize established domain-specific
ontologies and upper ontologies [41]. Domain-specific ontologies, including
BOT for illustrating building topology with features like bot:adjacentZone,
and Brick for the representation of equipment and systems with brick:HVAC
Zone, brick:Supply Air Temperature Sensor, brick:VAV, brick:AHU, brick:Cooling
Valve, brick:Mixed Air Temperature Sensor, brick:Exhaust Fan were employed.
The SOSA ontology was utilized to describe sensing and actuation processes
with sosa:madeObservation, sosa:resultTime, and SAREF4BLDG to depict building
spaces with s4bldg:BuildingSpace.

The upper ontologies supplemented this framework, with QUDT addressing units
of measurement through entities like units and quantities, as well as Time
Ontology [31] providing concepts such as time:TimeInterval, time:endsAt, and
time:beginsAt. The efficacy of this method was demonstrated through the
application of semantic rules designed to delineate inference mechanisms
applicable to a broad spectrum of building applications, which ranged from
semantic representation, fault detection, and diagnostics to spatial and
temporal reasoning, as well as asset management, maintenance, and context-
aware control.

A methodology for linking data was proposed to combine various data sources,
supporting digital twin applications [107]. A tool was developed to enable
this integration, employing multiple ontologies to characterize static and
dynamic data domains. The static domain encompasses building topology, while
the dynamic domain pertains to sensor data. The IFC data model initially
represented static building information from the design phase. However, due to
its complexity, non-modular nature, and rigid schema structure [120], it was
converted into the BOT ontology using the IFC-to-LBD converter [14] to address
these limitations. For this research, the BOT ontology, along with three
additional ontologies, were employed. The BOT detailed building topological
concepts, the Brick ontology depicted dynamic data, and the Building Element
Ontology (BEO) described building elements like walls, doors, and roofs.
Furthermore, the Building-Related Properties (PROPS)
333https://github.com/maximelefrancois86/props ontology was utilized to model
properties specific to building elements or equipment. The BEO and PROPS
ontology were not previously discussed because they focus on building design
and construction phases. This research was applied to a real-world case at the
Technical University of Crete, focusing on a three-story building with en-
suite student rooms and a communal kitchen on each floor. The spaces were
equipped with split air conditioners for heating and cooling, thermostats for
climate control, and occupancy sensors. Key classes from the mentioned
ontologies were employed to describe these building entities, including
bot:Space, bot:adjacentElement, brick:Space, brick:Thermostat, brick:Zone Air
Temperature Set Point, brick:timeseries, and beo:Window. This study
demonstrated the effectiveness of using the linked data modeling technique as
an integration approach to develop an efficient querying mechanism for
retrieving static and dynamic data and potentially support various digital
twin use cases in buildings.

In an extensive analysis of ontologies and metadata frameworks, the study
assessed 40 different schemas, each designed for specific sectors like
building design, energy modeling, and building operations [126]. Within this
extensive collection, the study identified five notable ontologies for a more
comprehensive evaluation. This study presents an office building with an HVAC
system that serves different spaces. The aim was to model the building
information using pre-existing ontologies for three use cases: energy
auditing, automatic fault detection and diagnosis, and optimal control of
building systems. The chosen ontologies included SAREF, SSN/SOSA, BOT, Brick,
and REC. They demonstrated this experiment using an office room within an
office building connected to building systems and equipment such as the HVAC.
Using a single ontology to capture all the concepts needed for the
aforementioned three use cases was impossible. Hence, these ontologies were
combined to complement each other in areas they fail to cover. The classes
utilized include: brick:VAV, core:Device, s4bldg:Flow Terminal, ssn:System,
s4bldg:BuildingObject, s4bldg:BuildingSpace, bldg:VirtualBuildingComponent,
brick:HVAC Zone, brick:Room, bot:Space, bldg:Office, core:Room. There are
situations whereby multiple ontologies could model a concept. Hence, selection
would depend on the researcher. Despite the significance of these five
ontologies, the research underscored some inherent limitations in each. Across
the board, these ontologies exhibited gaps or omissions in certain concepts,
impacting their overall efficacy in the specified use cases. The study
highlighted that while these ontologies have merits, none singularly
encompasses all essential concepts. Thus, augmenting these ontologies to cater
to specific applications is imperative.

This section examined the landscape of use case scenarios in ontology
applications, shedding light on their relevance across various domains. A
detailed analysis of the studies discussed shows that the application of
ontologies offers promising prospects for addressing complex challenges and
fostering semantic interoperability in BEM.

[ caption = Usecase Scenarios on the Application of Ontologies., label =
tab:usecase, ] colspec = XX[2]X[2]X[2], cells = font = , rowhead = 1, rowfoot
= 1, hlines, 2pt]- Usecase Concepts Classes Description
2pt]- Data Integration for building energy analysis [11] Building Space,
Building system and components, CO2 sensor and controller Uses SAREF, S4BLDG,
S4SYST BuildingSpace SpaceHeater Valve Sensor Controller

DamperSystemConnectionConnectionPoint

SAREF ontology was incorporated to model a single zone system.

Data Integration in Smart Homes [154] Current temperature, CO2 sensor, First
time movement detected, Last time movement detected, Motion detected, Presence
detected, Humidity, Smart switch actuator, Target temperature Uses SAREF
Measurement UnitofMeasure TemperatureUnit Property FeatureOfInterest Device
Task Comfort WellBeing Function SensingFunction Command State Service SAREF
does not possess a class specifically designed to model the unit of
measurement for CO2, nor a property class for measuring CO2levels.
Nonetheless, it can be easily extended to include these features

Data Integration with OPSD Household Data set [155] Energy imported/exported
from/to the public grid, Total Photovoltaic energy generation, Electric
Vehicle Charging energy, Appliances and Circulation pump energy consumption
Uses SAREF Measurement UnitOfMeasure Property PowerUnit Power
FeatureOfInterest Device Meter Appliance Task MeterReading Washing WellBeing
Comfort Function MeteringFunction The SAREF ontology was incorporated to map
building data using the OPSD Household data set

Long-term Thermal Comfort Evaluation with Brick Schema [145] Air Handling
Unit, Variable Air Volume box, Zone Air Temperature, Room and Floor Uses Brick
Zone Room Floor AHU Variable Air Volume Box Zone Air Temperature Sensor

Floor

The Brick ontology was employed to formalize specific building entities to
analyze thermal comfort evaluation.

Data integration for data-driven analytics [70] Building system and equipment,
Data points Uses Brick Air Handling Unit Power Meter Building Power Meter
Rooftop Unit

VAVChillerAbsorption ChillerTemperature SensorFlow SensorReturn Air Flow
Sensor

Brick served as a unified model for integrating metadata from different data
sources

2pt]-

Energy and Thermal Comfort Analysis [89] Thermal Comfort State, Number of
occupants, Occupancy State, Building Space, Humidity and CO2Sensor, PMV and
PPD values Uses ICBMS

CO2SensorTemperatureSensorHumiditySensorStateThermalComfortStateHotStateWarmStateSlightlyWarmStateNeutralStateSlightlyCoolStateCoolStateColdStateOccupancyStateOccupiedStateVacantStateBuildingSpace

Extends SAREF Sensor State ICBMS ontology extends the SAREF ontology and
introduces more specific concepts relating to sensor and state information

Data integration for building operational analysis [91] Data Points, Sensing,
Source, Property, and Feature of Interest Uses SBMS Address DataPoint Input
Property FeatureOfInterest SensingDevice Sensing Observation
Extends from SSN SensingDevice Observation Property FeatureOfInterest

The SBMS ontology represents information available for building operational
analysis. It is an extension of SSN ontology introducing the concept of data
points.

Smart building diagnosis [122] Process, Observation, Properties, Environment
New classes using namespace PHY

PhysicalProcessFeatureLinkAnomalyPropertyCause

Extends from SSN FeatureOfInterest Property Stimulus Sensor Observation This
custom ontology utilised the SSN ontology and extended it to model physical
and cause-effect relationships between sensors to support building
applications to automatically derive complex models for analytics tasks such
as prediction and diagnostics.

2pt]-

Energy Analysis [159] Building Basic Information, Geometry and Topology,
Energy Consumption, Environment Condition Uses BOT, SOSA, and a custom KPI
ontology Input Result Formula Parameter Operator Building Space Zone Platform
Sensor Observation FeatureOfInterest Property This linked data model was used
to connect data silos to evaluate building’s energy consumption efficiency

Semantic modeling of building operations [41] Equipment and Systems, Sensing
and Actuation, Building Topology, Unit Of Measurement, Temporal Information
Uses SAREF4BLDG, SOSA, BOT, and Brick adjacentZone HVAC Zone Supply Air
Temperature Sensor VAV AHU Cooling Valve Mixed Air Temperature Sensor Exhaust
Fan madeObservation resultTime BuildingSpace It emphasized on the semantic
representation of building assets with inference mechanisms for building
applications ranging from fault detection and diagnostics, asset management
and maintenance and context-aware control

Data integration for delivering data-driven application [107] Dynamic data,
Sensor tags, Building topology, Systems equipment, Building elements, Product
properties Uses BOT, Brick, BEO, and PROPS adjacentElement Space Thermostat
Space Zone Air Temperature Set Point timeseries Window

The linked data was adopted for data integration between multiple diverse data
sources to facilitate the development of digital twin applications

Ontologies for Building Energy Applications [126] Zones and Spaces, Envelope,
Building Systems and Equipment, Control Devices, Sensors and Actuators Uses
BOT, Brick, SSN/SOSA, SAREF, and REC VAV Device Flow Terminal System
BuildingObject VirtualBuildingComponent HVAC Zone Room Space Office

Comparative analysis of five distinct ontologies for modeling an office
building to support tasks such as energy audits, AFDD, and optimal control

_Legend:_ saref: s4bldg: s4syst: icbms: bot: sosa: kpi: brick: sbms: ssn: phy:
other

2pt,white]-

##  6 Discussion on Identified Limitations and Forthcoming Steps

This survey highlights a notable trend within the semantic modeling domain:
the fragmentation of the ontology development landscape resulting from the
creation of numerous smaller ontologies. Researchers often encounter
situations where an existing ontology does not encompass specific entities
needed for their application. They develop extensions or entirely new
ontologies rather than collaborating to refine and expand the existing
ontology. This practice leads to an ever-increasing number of ontologies, each
with slight variations. Such proliferation could have been mitigated through
enhanced collaboration and integration efforts within the ontology development
community.

The survey identifies the necessity for a more unified methodology in
developing ontologies. To ensure the effectiveness and utilization of these
semantic tools, their extension and modification must be managed to preserve
compatibility and minimize duplicate efforts. A systematic approach is
required to maintain the coherence of ontologies, avoiding excessive
fragmentation. This approach should involve creating systems or protocols that
facilitate the efficient tracking and integration of various ontology
extensions. By doing so, the ontology community can work towards a more
cohesive and comprehensive, universally applicable semantic framework. For
example, the Unified Medical Language System (UMLS) integrates many biomedical
standards and vocabularies in the bioinformatics domain to promote the
development of more interoperable and more effective biomedical information
systems and services [13].

Implementing such a coordinated approach would enable the harmonious growth of
ontology libraries, ensuring that they evolve in a manner that is beneficial
for individual research needs and conducive to broader community goals. It
would foster an environment where ontological resources are expanded,
strategically refined, and aligned with existing frameworks. This, in turn,
would enhance the effectiveness of ontologies in various applications,
providing a robust foundation for semantic interoperability and data
integration across diverse domains.

The European Union’s increasing emphasis on advancing energy flexibility
within buildings to promote decarbonization delegates the need for
comprehensive and efficient implementation strategies [27]. Central to these
strategies is proper communication and coordination among diverse distributed
energy resources and energy stakeholders. In this context, semantic modeling
technologies are essential for standardizing data representation across
various sources related to energy flexibility. However, the application of
semantic modeling, particularly in areas such as demand response, has not been
thoroughly investigated. Although existing ontologies partially address these
concepts, the challenge persists in comprehensively modeling the extensive
range of energy flexibility resources identified in the literature [99]. These
resources, each with unique physical properties, are represented through
various models at differing levels of detail, often developed on an ad-hoc
basis using disparate software or tools. Such models lack interoperability,
complicating comparison and scalability. This review advocates for developing
an ontological framework that standardizes the representation of energy
flexibility resources. Given the complexity of modeling all resources, this
framework should also provide a robust and agnostic approach for extending
ontologies to incorporate these concepts. This strategy aims to establish a
common practice and enhance semantic interoperability, supporting broader
adoption and integration of energy flexibility solutions.

This survey brings to light another critical trend: the absence of a clear
philosophical framework guiding the modeling of building entities with its
requirements. The philosophical motivations of semantic models need to be
reviewed [86]. This gap results in diverse and inconsistent methods of
modeling the same concepts. Such variability undermines the fundamental
purpose of semantic modeling, which is to foster a shared understanding of
concepts, thereby enhancing semantic interoperability.

The lack of a unified modeling philosophy leads to ambiguity and confusion
when applying ontologies. This hinders effective communication between
different systems and applications. For semantic modeling to be truly
effective, there must be a consensus on the principles and practices guiding
the representation of entities. This would ensure that when a concept is
modeled, it is done so in a manner that is universally recognizable and
interpretable within the context of the building operations domain. For
instance, in BEM, the concept of a zone often carries a broad definition. This
can lead to varied interpretations creating ambiguity and affecting the
modeling of this concept. The BOT ontology describes a zone as any entity
existing within the physical world[128]. However, while the Brick ontology
shares some conceptual overlap with BOT regarding zones (viewing them as
combinations of physical spaces), it separates the concept between physical
spaces and zones. In Brick’s framework, a zone is associated with spaces
designated for specific assessments [20]. Nevertheless, the types of
assessments are not confined solely to those outlined in the Brick ontology.
They do not mention that a zone can be within a single physical space, as
there can be a need to model such scenarios. This often leads researchers to
provide their ways of modeling certain concepts based on their interpretation
of how the ontology defines the concept. For example, the SAREF ontology does
not explicitly define a zone class for modeling such concepts. Yet, some
researchers suggest that zones can be represented using the BuildingSpace
class within SAREF4BLDG [126]. This highlights the many variations in modeling
certain concepts, with less specific details on how they can be modeled and
applied in different scenarios. This also applies to modeling concepts
relating to building systems and equipment, sensors, and actuators. A
formalized way of representing concepts should be enforced to explicitly
provide requirements that need to be attained to model these concepts
successfully, such as clearly defining the data properties, object properties,
relationships and, if needed, systems and equipment composition strategies.

Zones are a crucial basis for abstracting and covering various assessments
within a specific part of a space or a larger area. Zone concepts are
typically confined to the topology of buildings. Yet, they extend beyond this
to function as a critical instrument for analyzing building operations during
the building operational phase, which typically encompasses computing systems
and IoT devices. With the ongoing evolution of these computing systems, it is
challenging to find a comprehensive ontology capable of modeling the vast
array of building systems and devices. While some ontologies address certain
device and system concepts, limited studies focus on modeling the
computational processes linked to these computing systems. Therefore, it is
essential to model the information derived from these devices and systems and
capture the computational tasks for conducting specific assessments within a
building. These computational tasks, such as _KPIs_ , _assessments_ , and
_services_ , are vital for deriving functions that prompt changes in the
building’s environment to meet predetermined objectives.

While individual studies have explored these concepts, they often lack an
integrated approach. A limitation in current studies is that the approach for
evaluation is independent for each concept, which limits the automation of
energy management processes within buildings. The EM-KPI ontology, tailored
for multi-level energy performance tracking, includes a standardized way of
computing KPIs but falls short in linking how these _KPIs_ are regularly
_assessed_ [100]. Also, the KPI ontology, defined for building renovation
activities [65], does not align properly with the devices’ computational
aspect and the associated workflows. While the PF ontology focuses on
_assessing KPIs_ (such as evaluating energy usage and thermal comfort) [30],
there remains an isolation between possible _services_ and information from
the _assessed KPIs_.

Also, this survey has unveiled a disparity between the theoretical abundance
of information surrounding these semantic models and their actual application
in real-world scenarios. While both domains have recognized and extensively
explored the potential of semantic modeling, there is a pressing need to
bridge this knowledge with practical applications. Driving this transition
would require technical advancements and the development of user-friendly
platforms that seamlessly integrate these models into BEMs.

This survey aims to promote collaboration within the ontology community,
develop an integrated approach for modeling computational tasks and workflows,
and promote more practical applications. These efforts are intended to
demonstrate the effectiveness of semantic modeling in improving BEM.

##  7 Conclusions

This survey thoroughly explores semantic modeling technologies within building
energy management. It emphasizes the evolution and significance of semantic
web technologies, particularly ontologies, and their increasing adoption by
the building community, specifically focusing on their application in the
building operation phase. Key concepts within the building domain were
identified to gauge the capacity of these semantic models to capture relevant
information. Furthermore, this survey made an in-depth discussion of five
prominent ontologies applied for building operation analysis, along with other
ontologies that are under utilized.

This survey outlined scenarios where single, double, and multiple ontologies
are applied in diverse building application contexts. These scenarios formed
the foundation for an in-depth analysis of trends, strengths, and limitations
associated with semantic models and their applications. The discussion
highlighted key aspects that could enhance the use of semantic modeling in BEM
applications. It underscored the imperative for increased collaboration within
the ontology development community to address the issue of fragmentation and
the proliferation of numerous smaller ontologies. It further discussed the
urgent requirement to model a variety of distributed energy resources for
energy flexibility, which can act as a crucial facilitator in achieving the
energy objectives of the European Union. The survey emphasized the importance
of a clearly defined philosophical approach to modeling, which would improve
adaptability in representing various building concepts. It advocated for a
more cohesive approach to modeling computational tasks and workflows in
building operations and encouraged the practical application of these models
to demonstrate their efficacy. Despite the identified challenges and
limitations, the survey posited that semantic modeling possesses substantial
potential to facilitate smarter, more efficient, and sustainable building
operations. This aligns with global initiatives aimed at enhancing energy
efficiency and environmental sustainability.

##### Acknowledgements.

This work was partially supported by the European Commission through the SATO
project, ref. H2020-IA-957128 (https://doi.org/10.3030/957128), and SMART2B
project, ref. H2020-IA-101023666 (https://doi.org/10.3030/101023666), and by
the Fundação para a Ciência e Tecnologia (FCT) through the LASIGE Research
Unit, ref. UIDB/00408/2020 (https://doi.org/10.54499/UIDB/00408/2020) and ref.
UIDP/00408/2020 (https://doi.org/10.54499/UIDP/00408/2020).

## References

  * [1] Fatima Ardjani, Djelloul Bouchiha and Mimoun Malki  “Ontology-alignment techniques: survey and analysis”  In _Int. Journal of Modern Education and Computer Science_ 7.11 Modern EducationComputer Science Press, 2015, pp. 67
  * [2] Bharathan Balaji et al.  “Brick: Towards a unified metadata schema for buildings”  In _Proc. of the 3rd ACM Int. Conference on Systems for Energy-Efficient Built Environments_ , 2016, pp. 41–50
  * [3] Bharathan Balaji et al.  “Brick: Metadata schema for portable smart building applications”  In _Applied energy_ 226 Elsevier, 2018, pp. 1273–1292
  * [4] Jakob Beetz, Josef P Leeuwen and Bauke Vries  “An ontology web language notation of the industry foundation classes”  In _Proc. of the 22nd Conference on Information Technology in Construction (CIB W78)_ , 2005, pp. 193–198
  * [5] Harry Bergmann et al.  “Semantic interoperability to enable smart, grid-interactive efficient buildings”, 2020
  * [6] Keith Berkoben, Charbel El Kaed and Trevor Sodorff  “A Digital Buildings Ontology for Google’s Real Estate”  In _Industry track of the 19th Int. Semantic Web Conference (ISWC)_ , 2020, pp. 392–394
  * [7] Tim Berners-Lee, James Hendler and Ora Lassila  “The semantic web”  In _Scientific american_ 284.5 JSTOR, 2001, pp. 34–43
  * [8] Tim Berners-Lee, Larry Masinter and Mark McCahill  “Uniform resource locators (URL)”  RFC Series, 1994
  * [9] Arka Bhattacharya, Joern Ploennigs and David Culler  “Short paper: Analyzing metadata schemas for buildings: The good, the bad, and the ugly”  In _Proc. of the 2nd ACM Int. Conference on Embedded Systems for Energy-Efficient Built Environments (BuildSys)_ , 2015, pp. 33–34
  * [10] Christian Bizer, Tom Heath and Tim Berners-Lee  “Linked data: The story so far”  In _Semantic services, interoperability and web applications: emerging concepts_ IGI global, 2011, pp. 205–227
  * [11] Jakob Bjørnskov and Muhyiddine Jradi  “An ontology-based innovative energy modeling framework for scalable and adaptable building digital twins”  In _Energy and Buildings_ 292 Elsevier, 2023, pp. 113146
  * [12] José Miguel Blanco, Bruno Rossi and Tomás Pitner  “A Comparison of Smart Grids Domain Ontologies”  In _Proc. of the 17th Int. Conference on Web Information Systems and Technologies (WEBIST)_ , 2021, pp. 115–123
  * [13] Olivier Bodenreider  “The unified medical language system (UMLS): integrating biomedical terminology”  In _Nucleic acids research_ 32.suppl_1 Oxford University Press, 2004, pp. D267–D270
  * [14] Mathias Bonduel et al.  “The IFC to linked building data converter: current status”  In _Proc. of the 6th Linked Data in Architecture and Construction Workshop (LDAC)_ 2159, 2018, pp. 34–43
  * [15] Dario Bonino and Fulvio Corno  “Dogont-ontology modeling for intelligent domotic environments”  In _Proc. of the 7th Int. Semantic Web Conference (ISWC)_ , 2008, pp. 790–803
  * [16] Dario Bonino, Fulvio Corno and Luigi De Russis  “PowerOnt: An Ontology-Based Approach for Power Consumption Estimation in Smart Homes”  In _Internet of Things. User-Centric IoT_ , 2015, pp. 3–8
  * [17] Meisam Booshehri et al.  “Introducing the Open Energy Ontology: Enhancing data interpretation and interfacing in energy systems analysis”  In _Energy and AI_ 5 Elsevier, 2021, pp. 100074
  * [18] André Borrmann, Markus König, Christian Koch and Jakob Beetz  “Building information modeling: Why? what? how?”  Springer, 2018
  * [19] Braeckel  “Weather Data Models” Accessed on April 16, 2024, 2016  URL: https://wiki.ucar.edu/display/CSSWX/Weather+Data+Models
  * [20] Brickschema.org  “Brick Schema Ontology” Accessed on April 16, 2024, 2016  URL: https://brickschema.org
  * [21] Alex H Buckman, Martin Mayfield and Stephen BM Beck  “What is a smart building?”  In _Smart and Sustainable Built Env._ 3.2 Emerald Group Publishing Limited, 2014, pp. 92–109
  * [22] National Institute Building Sciences  “NIMBS Committe National Building Information Modeling Standard” Accessed on April 16, 2024, 2007  URL: https://buildinginformationmanagement.files.wordpress.com/2011/06/nbimsv1_p1.pdf
  * [23] buildingSMART International  “ifcOWL” Accessed on April 16, 2024, 2020  URL: https://technical.buildingsmart.org/standards/ifc/ifc-formats/ifcowl/
  * [24] Björn Butzin, Frank Golatowski and Dirk Timmermann  “A survey on information modeling and ontologies in building automation”  In _Proc. of the 43rd Annual Conference of the IEEE Industrial Electronics Society (IECON)_ , 2017, pp. 8615–8621
  * [25] Enrico G Caldarola and Antonio M Rinaldi  “An approach to ontology integration for ontology reuse”  In _Proc. of the 17th IEEE Int. Conference on Information Reuse and Integration (IRI)_ , 2016, pp. 384–393
  * [26] Victor Charpenay, Sebastian Käbisch, Darko Anicic and Harald Kosch  “An ontology design pattern for iot device tagging systems”  In _Proc. of the 5th Int. Conference on the Internet of Things (IOT)_ , 2015, pp. 138–145
  * [27] European Commission  “Flexibility markets” Accessed on April 16, 2024, 2022  URL: https://energy.ec.europa.eu/topics/research-and-technology/flexibility-markets_en
  * [28] International Electrotechnical Commission  “CIM Standards” Accessed on April 16, 2024, 2018  URL: https://web.archive.org/web/20180409033852/https://www.iec.ch/smartgrid/standards
  * [29] Michael Compton et al.  “The SSN ontology of the W3C semantic sensor network incubator group”  In _Journal of Web Semantics_ 17 Elsevier, 2012, pp. 25–32
  * [30] Edward Corry et al.  “A performance assessment ontology for the environmental and energy management of buildings”  In _Automation in Construction_ 57 Elsevier, 2015, pp. 249–259
  * [31] Simon Cox and Chris Little  “Time Ontology in OWL” Accessed on April 16, 2024, 2022  URL: https://www.w3.org/TR/owl-time/
  * [32] Javier Cuenca, Felix Larrinaga and Edward Curry  “A Unified Semantic Ontology for Energy Management Applications”  In _Joint Proc. of the Web Stream Processing workshop (WSP) and the 2nd Int. Workshop on Ontology Modularity, Contextuality, and Evolution (WOMoCoE), co-located with 16th Int. Semantic Web Conference (ISWC)_ , 2017, pp. 86–97
  * [33] Javier Cuenca, Felix Larrinaga and Edward Curry  “DABGEO: A reusable and usable global energy ontology for the energy domain”  In _Journal of Web Semantics_ 61 Elsevier, 2020, pp. 100550
  * [34] Renata P. Dameri  “Searching for smart city definition: a comprehensive proposal”  In _Int. Journal of Computers & Technology_ 11.5, 2013, pp. 2544–2551
  * [35] L Daniele et al.  “Study on ensuring interoperability for demand side flexibility”  In _European Commission_ , 2018
  * [36] Laura Daniele, Frank Hartog and Jasper Roes  “Created in close interaction with the industry: the smart appliances reference (SAREF) ontology”  In _Proc. of the 7th Int. Workshop on Formal Ontologies Meet Industry (FOMI)_ , 2015, pp. 100–112
  * [37] DBpedia  “Global and Unified Access to Knowledge Graphs” Accessed on April 16, 2024, 2007  URL: https://www.dbpedia.org/
  * [38] Flavia De Andrade Pereira et al.  “Towards semantic interoperability for demand-side management: a review of BIM and BAS ontologies”  In _Proc. of the European Conference on Computing in Construction (EC3)_ 3, 2022, pp. 1–8
  * [39] Stefan Decker et al.  “The semantic web: The roles of XML and RDF”  In _IEEE Internet computing_ 4.5 IEEE, 2000, pp. 63–73
  * [40] Houssem Eddine Degha, Fatima Zohra Laallam and Bachir Said  “Intelligent context-awareness system for energy efficiency in smart building based on ontology”  In _Sustainable computing: informatics and systems_ 21 Elsevier, 2019, pp. 212–233
  * [41] Parastoo Delgoshaei, Mohammad Heidarinejad and Mark A Austin  “A semantic approach for building system operations: Knowledge representation and reasoning”  In _Sustainability_ 14.10 MDPI, 2022, pp. 5810
  * [42] A Donkers, D Yang, B Vries and N Baken  “Building Performance Ontology” Accessed on April 16, 2024, 2021  URL: https://w3id.org/bop
  * [43] Charles M Eastman  “BIM handbook: A guide to building information modeling for owners, managers, designers, engineers and contractors”  John Wiley & Sons, 2011
  * [44] EEBUS  “Empowering the digitalisation of Energy transition” Accessed on April 16, 2024, 2015  URL: https://www.eebus.org/
  * [45] Energy@home  “Energy@home” Accessed on April 16, 2024, 2011  URL: http://www.energy-home.it/
  * [46] Iker Esnaola-Gonzalez and Francisco Javier Díez  “RESPOND Ontology” Accessed on April 16, 2024, 2020  URL: https://respond-project.github.io/RESPOND-Ontology/
  * [47] ETSI  “SAREF Ontology Portal” Accessed on April 16, 2024, 2014  URL: https://saref.etsi.org
  * [48] ETSI  “SmartM2M; IoT LSP use cases and standards gaps” Accessed on April 16, 2024, 2016  URL: https://www.etsi.org/deliver/etsi_tr/103300_103399/103376/01.01.01_60/tr_103376v010101p.pdf
  * [49] ETSI  “SmartM2M; IoT Standards landscape and future evolutions” Accessed on April 16, 2024, 2016  URL: https://www.etsi.org/deliver/etsi_tr/103300_103399/103375/01.01.01_60/tr_103375v010101p.pdf
  * [50] ETSI  “SAREF: Smart Application REFerence ontology extension for the Automotive Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341007/01.01.01_60/ts_10341007v010101p.pdf
  * [51] ETSI  “SAREF: Smart Application REFerence ontology extension for the Building Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341003/01.01.02_60/ts_10341003v010102p.pdf
  * [52] ETSI  “SAREF: Smart Application REFerence ontology extension for the eHealth/Ageing-well Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341008/01.01.01_60/ts_10341008v010101p.pdf
  * [53] ETSI  “SAREF: Smart Application REFerence ontology extension for the Energy Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.01.02_60/ts_10341001v010102p.pdf
  * [54] ETSI  “SAREF: Smart Application REFerence ontology extension for the Environment Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341002/01.01.02_60/ts_10341002v010102p.pdf
  * [55] ETSI  “SAREF: Smart Application REFerence ontology extension for the Industry and Manufacturing Domains” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341005/01.01.02_60/ts_10341005v010102p.pdf
  * [56] ETSI  “SAREF: Smart Application REFerence ontology extension for the Smart Agriculture and Food Chain Domains” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341006/01.01.02_60/ts_10341006v010102p.pdf
  * [57] ETSI  “SAREF: Smart Application REFerence ontology extension for the Smart Cities Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341004/01.01.02_60/ts_10341004v010102p.pdf
  * [58] ETSI  “SAREF: Smart Application REFerence ontology extension for the Smart Lifts Domain” Accessed on April 16, 2024, 2020  URL: https://etsi.org/deliver/etsi_ts/103400_103499/10341011/01.01.01_60/ts_10341011v010101p.pdf
  * [59] ETSI  “SAREF: Smart Application REFerence ontology extension for the Water Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341010/01.01.01_60/ts_10341010v010101p.pdf
  * [60] ETSI  “SAREF: Smart Application REFerence ontology extension for the Wearables Domain” Accessed on April 16, 2024, 2020  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341009/01.01.01_60/ts_10341009v010101p.pdf
  * [61] ETSI  “SAREF: Smart Application REFerence ontology extension for the Smart Grid Domain” Accessed on April 16, 2024, 2023  URL: https://www.etsi.org/deliver/etsi_ts/103400_103499/10341012/01.01.01_60/ts_10341012v010101p.pdf
  * [62] ETSI  “SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping” Accessed on April 16, 2024, 2024  URL: https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/03.02.01_60/ts_103264v030201p.pdf
  * [63] European Commission  “In focus: Energy efficiency in buildings” Accessed on April 16, 2024, 2023  URL: https://commission.europa.eu/news/focus-energy-efficiency-buildings-2020-02-17_en
  * [64] Anna Fensel et al.  “SESAME-s: Semantic smart home system for energy efficiency”  In _Informatik-Spektrum_ 36.1 Springer, 2013, pp. 46–57
  * [65] Villalón Feria  “Key Performance Indicator ontology” Accessed on April 16, 2024, 2020  URL: https://bimerr.iot.linkeddata.es/def/key-performance-indicator/
  * [66] Villalón Feria and Castro  “Occupancy Profile ontology” Accessed on April 16, 2024, 2020  URL: https://bimerr.iot.linkeddata.es/def/occupancy-profile/
  * [67] Alba Fernández-Izquierdo, Andrea Cimmino and Raúl García-Castro  “Supporting Demand-Response strategies with the DELTA ontology”  In _Proc. of the 18th IEEE/ACS Int. Conference on Computer Systems and Applications (AICCSA)_ , 2021, pp. 1–8
  * [68] Alba Fernández-Izquierdo et al.  “Openadr ontology: Semantic enrichment of demand response strategies in smart grids”  In _Proc. of the 3rd Int. Conference on Smart Energy Systems and Technologies (SEST)_ , 2020, pp. 1–6
  * [69] Gabe Fierro et al.  “Mortar: an open testbed for portable building analytics”  In _Proc. of the 5th Conference on Systems for Built Environments (BuildSys)_ , 2018, pp. 172–181
  * [70] Gabe Fierro et al.  “Shepherding metadata through the building lifecycle”  In _Proc. of the 7th ACM Int. Conference on Systems for Energy-Efficient Buildings, Cities, and Transportation (BuildSys)_ , 2020, pp. 70–79
  * [71] Raúl García-Castro, Maxime Lefrançois, María Poveda-Villalón and Laura Daniele  “The ETSI SAREF ontology for smart applications: a long path of development and evolution”  In _Energy Smart Appliances: Applications, Methodologies, and Challenges_ Wiley Online Library, 2023, pp. 183–215
  * [72] Syed Gillani, Frederique Laforest and Gauthier Picard  “A Generic Ontology for Prosumer-Oriented Smart Grid”  In _Proc. of the Workshops of the EDBT/ICDT Joint Conference_ 1133, 2014, pp. 134–139
  * [73] Google  “Google Digital Buildings Ontology” Accessed on April 16, 2024, 2020  URL: https://github.com/google/digitalbuildings/
  * [74] W3C Semantic Web Interest Group  “Basic Geo (WGS84 lat/long) Vocabulary” Accessed on April 16, 2024, 2003  URL: https://www.w3.org/2003/01/geo/
  * [75] Thomas R Gruber  “A translation approach to portable ontology specifications”  In _Knowledge acquisition_ 5.2 Elsevier, 1993, pp. 199–220
  * [76] Michael Gruninger et al.  “Ontology Summit 2007-Ontology, taxonomy, folksonomy: Understanding the distinctions”  In _Applied Ontology_ 3.3, 2008, pp. 191
  * [77] Maliheh Haghgoo, Ilya Sychev, Antonello Monti and Frank HP Fitzek  “SARGON–Smart energy domain ontology”  In _IET Smart Cities_ 2.4 Wiley Online Library, 2020, pp. 191–198