Available via license: CC BY-NC-ND 4.0
Content may be subject to copyright.
Computer Science and Information Systems 00(0):0000–0000 https://doi.org/10.2298/CSIS123456789X
SBEO: Smart Building Evacuation Ontology1
Qasim Khalid1, Alberto Fernandez1, Marin Lujak1⋆, and Arnaud Doniec2
2
1CETINIA, Universidad Rey Juan Carlos, Mostoles (Madrid), Spain3
qasim.khalid@urjc.es, alberto.fernandez@urjc.es, marin.lujak@urjc.es4
2IMT Nord Europe, 59500 Douai, France5
arnaud.doniec@imt-nord-europe.fr6
Abstract. Semantically rich depiction of the concepts for context-aware indoor7
routing brings appealing benefits for the safety of occupants of smart spaces in8
emergency evacuation. In this paper, we propose Smart Building Evacuation Ontol-9
ogy (SBEO3), a reusable ontology for indoor spaces, based on three different data10
models: user, building, and context. We provide a common representation of indoor11
routing and navigation, describe users’ characteristics and preferences, grouping12
of individuals and their role in a specific context, hazards, and emergency evacu-13
ation. Among other characteristics, we consider abilities of individuals, safety and14
accessibility of spaces related to each person, intensity, impact, and severity of an15
emergency event or activity. SBEO is flexible and compatible with other ontologies16
of its domain, including SEAS, SSN/SOSA, SEMA4A, and empathi. We evalu-17
ate SBEO based on several metrics demonstrating that it addresses the information18
needs for the context-aware route recommendation system for emergency evacua-19
tion in indoor spaces. In the end, a simulation-based application example exploits20
SBEO using Context-Aware Emergency Evacuation Software (CAREE)4.21
Keywords: ontology, linked data, smart building, hazard detection, emergency evac-22
uation, indoor route recommendation, navigation.23
1. Introduction24
Ambient Intelligence (AmI) represents a responsive electronic environment that reacts25
to the actions of each person and the physical objects within itself. It has been growing26
fast as a multi-disciplinary field with a high impact on society for the last three decades27
[44]. It can be used to combine hazard detection and disaster management [5], crowd28
management [33], and route recommendation [9] in smart spaces [65] to obtain real-29
time information and aid decision making in dynamically changing emergency evacuation30
scenarios in large smart buildings with multitudes of occupants.31
The objective of both outdoor and indoor navigation systems is to find a path for each32
user from their initial to target location that optimizes one or more of given performance33
indicators (e.g., distance, time and/or difficulty) [14]. Dynamic context-aware adaptation34
of the evacuation route and its communication to each evacuee are required for efficient35
evacuation (see, e.g., [23]). While outdoor navigation systems use Global Positioning Sys-36
tem (GPS) receivers, indoor navigation cannot rely on them due to the overlapping of the37
⋆Corresponding author.
3SBEO can be accessed at: https://w3id.org/sbeo
4https://github.com/qasimkhalid/CAREE
2 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
signal through the storeys of the building. Thus, other technologies must be employed1
for positioning (see, e.g., [46]). For example, Proximity-based Systems, WiFi-Based Sys-2
tems, Ultra Wide-band Systems.3
It becomes challenging and complex to handle indoor navigation in real time when vari-4
ous objectives are combined along with the localization of people. This is the case in the5
recommendation of routes to users based on their physical abilities and preferences during6
everyday or emergency scenarios. There are multiple reasons for its complexity. First, in-7
door location of persons is not entirely precise, always leaving a margin of error. Second,8
the (close to) real-time processing and fusion of data coming from heterogeneous sensors9
into a consistent, accurate, and useful information describing the evacuation context is a10
prerequisite for getting around the effects of possible emergency setbacks.11
Here, we use ontologies to describe concepts and relationships between entities as a12
formal way of conceptualizing the domain knowledge. Ontologies are a key compo-13
nent of the semantic web [61] that is used to represent data, and provide a domain-14
specific knowledge for the representation of the metadata [48]). Previously, various on-15
tologies and data models for indoor navigation, routing, and emergency and crisis man-16
agement, were proposed for conventional buildings and spaces without ambient intelli-17
gence [4,27,58,15,28,40].18
In [31], a semantically-enriched distributed architecture for context-aware and real-time19
evacuation guidance in indoor smart spaces was proposed. The architecture uses a multi-20
agent system for the coordination of the evacuation where each agent is responsible of21
the semantic reasoning concerning the safety of its assigned physical space and uses an22
ontology for indoor emergency evacuation. As a continuation of the previous work, in23
this paper, we propose an ontology for smart space context-aware route recommendation24
to evacuees with smart devices. We name the proposed ontology Smart Building Evacua-25
tion Ontology (SBEO). SBEO is composed of three modules: User Model, describing the26
characteristics (i.e., physical abilities) and preferences of an evacuee; Building Model that27
considers the routing, and geometry, devices and elements other than structural compo-28
nents of the building; and the Context Model, which illustrates the contextual information29
about the building and the evacuees.30
The SBEO ontology is inline with terminologies used in the domain of indoor route rec-31
ommendation and navigation. It is compatible with several other state-of-the-art ontolo-32
gies and systems such as, SEAS [29], SOSA/SSN[24], SEMAA4a [40], Indoor Naviga-33
tion Ontology (INO) and User Navigation Ontology (UNO)[26,58], and General User34
Model Ontology (GUMO)[21]. It was implemented using OWL 25and the Prot´
eg´
e6de-35
velopment environment. SBEO is available at https://w3id.org/sbeo# and holds a GPL-3.036
license.37
To the best of our knowledge, this is the first work that combines the concepts of smart38
spaces with context awareness, route recommendation and hazard detection consider-39
ing users’ relevant evacuation characteristics and preferences. The main contributions40
of SBEO are expressiveness, which provides a hierarchical description of the concepts41
5https://www.w3.org/TR/owl2-overview/
6https://protege.stanford.edu/
SBEO: Smart Building Evacuation Ontology 3
in indoor emergency routing in smart buildings. In addition, as sharing and reusability1
are considered the fundamental concepts in the ontology engineering field [41], the pro-2
posed ontology is also reusable. Here, reusable refers to the adaptation of SBEO accord-3
ing to the need of the user and application. In other words, we can extend the models4
of SBEO individually. For example, people with impairments not covered thus far might5
also be described using the same ontology if needed. Consequently, concepts associated6
with such people might also be extended accordingly. Similarly, in terms of buildings,7
although SBEO covers the concepts for both conventional buildings and smart buildings,8
if any new type of buildings or related concepts is introduced, the ontology can easily be9
broadened. It also improves the automation, accountability, real-time context awareness,10
information sharing, and personalised routing in smart space evacuation.11
The rest of the paper is organized as follows: In Section 2, we highlight related work in12
emergency management, user and crowd modeling, smart environments, and indoor rout-13
ing. We describe the followed methodology in the development of SBEO together with the14
ontology audience and scope in Section 3. Section 4 states the competency questions and15
formal requirements to be met by the proposed ontology. SBEO is presented in Section 5.16
In Section 6, the proposed ontology is evaluated using various metrics found in the liter-17
ature. In Section 7, a simulation-based application example of SBEO is described using18
Context-Aware Emergency Evacuation (CAREE) system. A task-based evaluation is per-19
formed using a hazard context. We conclude the paper with some proposed improvements20
and future work in Section 8.21
2. Related Work22
This section provides an overview of related state-of-the-art ontologies together with the23
positioning of SBEO.24
2.1. Ontologies for emergency and crisis management25
A general ontology for emergency response by Li et al. proposed in [30] includes the26
concepts of response preparation, emergency response, emergency rescue and aftermath27
handling and relevant properties and relations that connect these concepts.28
The ontology for massive crisis management proposed in [50] covers the concepts related29
to the allocation of resources and the crisis impact related to the time and place of the30
crisis occurrence. An ontology-based proactive approach to enhance the response time31
during both natural (such as earthquake, tsunami, etc) and anthropic (such as terrorist32
attack, kidnapping, etc) events in [12] covers the concepts of the context, impact, and the33
services provided during an incident.34
Sicilia and Santos [52] described Basic Formal Infrastructure Incident Assessment Ontol-35
ogy (BFiaO) to represent the adverse effects of incidents. BFiaO connects the concepts36
related to incidents, their causes and evolution, and their possible outcomes. Santos et al.37
[49] broadened BFiaO and made it more consistent with Coordination of Emergencies38
and Tracking of Actions and Resources (CESAR) data model to minimise the aftereffects39
of an incident. They modelled the concepts for the identification of events, mission, and40
4 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
resources and developed a set of rules to anticipate possible chain events connected with1
the existing/past events, such that the first response officers could prioritise their tasks to2
avoid jeopardy.3
Recently, Gaur et al. [19] presented a rich ontology7for emergency management and4
planning during hazard crises including concepts related to emergency response, hazard5
type, impact, phase, events, involved individuals, and provided services.6
In terms of notification services during emergency scenarios, Malizia et al. [35] proposed7
an ontology to express the concepts of emergency notification messages with respect to8
various kinds of users. They developed a class named EMEDIA (Emergency and ME-9
DIA technologies) that provides the concepts and relations about emergency and com-10
munication devices and technologies. They integrated that class with other existing on-11
tologies that describe accessibility guidelines, and users’ profiles and action capabilities.12
Afterwards, Onorati et al. [40] extended their work by introducing some new concepts13
to express personalised routes based on the users’ physical abilities, familiarity with the14
environment, preferences, location, available media for notification, and characteristics of15
the surrounding.16
Bitencourt et al. [8] developed a formal domain ontology to describe the emergency re-17
sponse protocols of fire in buildings considering incident details, information about the18
victims, possible actions, planning, and operational phases. Related to gathering and med-19
ical emergency response, Haghighi et al. [20] presented Domain Ontology for Mass Gath-20
ering (DO4MG) considering the concepts related to gathering types, venue details, fea-21
tures of the crowd, environmental factors and general mass gathering plans.22
One of the most comprehensive, general-purpose light-weight ontologies that can be used23
in Internet of Things and smart spaces is Sensor, Observation, Sample, and Actuator24
(SOSA) ontology [24]. SmartEnv ontology [3] covers various aspects of a smart envi-25
ronment such as sensing, networking, event, and topology, while Smart Energy Aware26
Systems (SEAS) ontology [29] couples the concepts related to energy and grid, and con-27
ceptualises city and building structures, time, weather, and user comfort.28
2.2. Ontologies for spatial modeling, indoor navigation and routing29
Rasmussen et al. [45] presented a core vocabulary named Building Topology Ontology30
(BOT) to describe the topology of buildings, along with its storeys and spaces. The BOT31
ontology is completely compatible with other ontologies in the domain such as SOSA and32
SSN8.33
For navigational and routing purposes, Br¨
uckner et al. [27] proposed an indoor-outdoor34
ontology-based data model for both robots and humans to develop a routing graph with35
the help of spatial information. Similarly, Yang and Worboys [64] also presented an onto-36
logical model for both outdoor and indoor navigation.37
7https://w3id.org/empathi/
8https://www.w3.org/TR/vocab-ssn/
SBEO: Smart Building Evacuation Ontology 5
Indoor Navigation Ontology (INO) [58] covers concepts of navigation in indoor spaces1
and the geometry of buildings including multiple floors, elevators, points of interest9,2
corridors, exits, etc. The ontology for indoor routing based on American Disability Act3
(ADA) standards [15] deals with the geometry of a building in such a way that its con-4
nections can be represented as horizontal and vertical paths for routing purposes.5
In the Ontology Crowd Simulation (ONTOCS) [10], the concepts of an indoor environ-6
ment together with its geometry are modelled in the context of emergency evacuation in7
terms of the routes, travel time and distance.8
2.3. Ontologies for user and crowd modeling9
One of the pioneer works in the domain of user modeling has been carried out by Heck-10
mann et al. [21]. They developed General User Model Ontology (GUMO) to describe the11
basic attributes of users such as demographics, abilities, proficiencies, states (emotional,12
physiological, mental), role, and so forth.13
Later on, Kikiras et al. [26] developed User Navigation Ontology (UNO) on the basis of14
multiple wayfinding theories related to cognitive science, psychology, sensor abilities and15
physical characteristics of human beings. UNO covers the concepts related to users’ nav-16
igation in indoor environments based on their demographics, cognitive characteristics,17
sensor- and motor- abilities, and navigational and interface preferences. Subsequently,18
Kritsotakis et al. [28] broadened the concepts of UNO and presented a User tracking On-19
tology (UTO) to describe the concepts for context awareness and tracking of users. On the20
other hand, Dudas et al. [15] also modeled the users in their ontology based-on American21
Disability Act (ADA) standards, in which they conceptualize users’ preferences, familiar-22
ity with the building, and disabilities.23
Similarly, Boje and Li [10] also modeled the information about the crowd in their simu-24
lated framework. They named it Crowd Simulation Information Model (CSIM) that covers25
the concepts related to persons, such as preferences, exit choices, and speed.26
Whilst the above-mentioned works are interesting and provide the concepts about the27
geometrical information of the buildings, user characteristics, and routing and navigation28
in indoor environments, some of them are not available online, hence cannot be reused.29
In addition, the existing works do not provide sufficient information about the context30
awareness of the building and persons, especially in emergency management context. By31
comparison, SBEO aims to conceptualize context-aware indoor route recommendation32
and emergency evacuation. The proposed ontology not only describes the concepts related33
to building topology, routing and navigation, classification of users with respect to their34
abilities and preferences, but also conceptualizes context awareness, such as detection of35
any hazard, intensity, severity and impact of activities and events, evacuation action plan,36
social groups, movement of people, and people notification. Furthermore, SBEO has been37
published online and made available for public after being developed using state-of-the-38
art methodologies found in the literature.39
9A point of interest is defined as any object or physical space that might be of importance or useful for the
occupants of the building. For example, an (emergency) exit, location (or space) where a person is located
subject to specific criteria, fire safety devices such as fire extinguisher, firehouse, fire door.
6 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
3. Design Methodology1
To date, several methodologies have been proposed for building ontologies, e.g., Methon-2
tology is a methodology to build ontologies from scratch [18], On-To-Knowledge[56],3
Digilent[42], Neon[54], and Ontology development 101[38]. In order to develop SBEO,4
we selected Methontology framework because it allows to develop the ontology from5
scratch, and also recommends to reuse the concepts from the existing meta-ontologies. In6
addition, as the ontology development is an on-going process due to the evolving proto-7
type life cycle nature of this methodology, it permits the ontology authors to update the8
ontology from any of its phases.9
Methontology proposes a process consisting of six steps: specification, where the pur-10
pose of the ontology, intended audience, scenarios of its use, scope and requirements are11
taken into account; knowledge acquisition, where several techniques can be used to get12
the specific and detailed knowledge about the topic of the ontology; conceptualization,13
where all the useful or potentially usable domain knowledge is brought together to create14
a conceptual model, and that model is compared with the existing ontologies to check its15
scope, completeness and reusability; integration and implementation, where to support16
the reuse of definitions, the concepts of the proposed conceptual model are scrutinized17
with the existing ontologies as per their scope, and then implemented the filtered concepts18
using one of the standard languages; evaluation, where the each activity of the ontology19
development process is verified and validated using various methods and metrics; and20
documentation, where each phase of the ontology development process is documented in21
natural language available on the Web or in the scientific literature.22
Knowledge acquisition. Knowledge acquisition is a primitive stage for ontology devel-23
opment that is also considered as an on-going process. In the same way, we also reviewed24
the literature to acquire relevant knowledge and to get a broader view of the needs and re-25
quirements for the creation of an ontology (i.e., SBEO). In particular, the studies reported26
in: [58,15,28,40,10,32,7,2,37], represent the systems and/or models for indoor route rec-27
ommendation during emergency evacuation; [1,55,11], depict crowd management and28
grouping during hazardous situations using simulated environments; [25], discuss indoor29
routing for people with special needs; [29], describes building geometry using an ontol-30
ogy; [65,63], define the smart spaces, together with its requirements, and [34,16], discuss31
some case studies related to the user behaviour during an emergency evacuation in a smart32
indoor environment.33
Scope and Audience. SBEO offers a data model for building geometry, devices and34
elements not only regarding structure, route sets based on building topology, users’ char-35
acteristics and preferences. It also considers the context awareness of both buildings (e.g.,36
hazard detection, the status of spaces and evacuation routes in terms of availability and37
occupancy, severity and impact of activities and events, and safety of spaces) and an38
user/occupant (e.g., route tracking, coordination with their evacuation group, adaptation39
of an evacuation route in terms of fitness and accessibility to spaces). Hence, the pro-40
posed ontology has an ample scope to couple the information about a building with its41
occupants in order to use it for indoor localization, detection of a hazard or disaster, and42
SBEO: Smart Building Evacuation Ontology 7
preference-based routing during emergency evacuation. The target audience of SBEO is1
building occupants (e.g., visitor, resident, worker), building managers, civil engineering2
specialists, indoor designers, and architects involved in building design and development,3
but also researchers in building evacuation safety.4
4. Ontology specification5
From the requirements engineering point of view, we set two goal-level requirements that6
should be fulfilled by the proposed ontology. First, formal requirements, which are used7
to express the needs of the domains covered by the ontology, including preference-based8
route recommendation and context awareness in smart buildings; and Second, functional9
requirements, in the form of specific competency questions which must be answered by10
the ontology.11
4.1. Formal Requirements12
In terms of formal requirements, SBEO must be able to represent the concepts related13
to the users (i.e., occupants), the buildings, and the context related to both users and the14
building. These are as follows:15
Users:16
–Demographics of a person (e.g., age, name, individual and group identity numbers,17
and family members).18
–Physical abilities (e.g., mental, spatial, sensor, mobility).19
–Navigational and routing preferences (e.g., avoidance of stairs or crowded areas,20
fastest route, simplest route with least turns).21
–Level of involvement (i.e., role) while performing a specific activity (e.g., either a22
person is dependent or responsible for others during immediate egress from an area).23
–Type of an impairment of the person (if it exists).24
Buildings:25
–Structural elements (e.g., stairs, elevators, corridors, rooms).26
–Devices installed in the building, which are not a part of the building structure (e.g.,27
sensors, equipment for safety and access control).28
–Representation of a building as a traversable graph (i.e., for routing purposes).29
–Classification of routes (e.g., shortest path and simplest path [14]);30
Context related to the users and buildings:31
–Individuals’ fitness status (e.g., fit, injured).32
–Motion status (e.g., running, walking, standing).33
–Deviation status (e.g., classification of persons based on the34
8 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
–Frequency of deviations from their provided route).1
–Safety level of spaces concerning each person.2
–Availability and accessibility of spaces (where the availability of space states that3
either space is usable or not, the accessibility of space, on the other hand, refers to a4
specific person or type of persons, either it is accessible for him/her/them or not).5
–Intrinsic concepts related to activities and events (e.g., type, starting and ending time),6
along with their effects. For example, Intensity which refers to the magnitude, severity7
which relates to the specific persons and varies accordingly, and Impact, that refers to8
their effects on users.9
–Comprehensive concepts, such as time taken by an individual and role of an individual10
while performing an activity (e.g., responsible, visitor, group leader).11
4.2. Functional Requirements: Competency Questions12
For functional requirements, we use competency questions. A competency question (CQ)13
is a question in a natural language that is supposed to be answered by an ontology. Usually,14
it has a specific pattern [60]. Ren et al. [47] defined some patterns using a feature-based15
modelling method to describe competency questions.16
In this study, we adopted the same patterns to determine the scope of the proposed ontol-17
ogy. Table 1 includes some competency questions the proposed ontology should answer.18
The motivation for choosing these competency questions is based on our previous work19
(see, e.g., [31], [33], and [32]), where not only the concepts related to both buildings and20
users were limited, but it also lacked the contextual information of these entities. In this21
regard, most of these questions are explicitly shaped to answer the specific attributes of22
buildings, users, and the relevant context. Nevertheless, the potential ontology user may23
develop their own set of customized competency questions concerning the application24
type within the scope of the ontology. On the other hand, these competency questions25
might also be used as a metric to evaluate each ontology module such that their answers26
could be used in the typical application scenarios the ontology is aimed at, like the task-27
based evaluation mentioned in Section 6 and the application described in Section 7.28
Table 1: Some sample competency questions to be asked by SBEO.
Module Type Competency Questions
User Model
Characteristics 1. Who is not capable of running?
2. How many families are located in the building?
3. Who has a bad quality of hearing ability (in the building)?
4. What are the types of people concerning their physical characteristics?
Preferences 5. What are the route preferences (for emergency evacuation, e.g., simplest path, shortest path)
of each person?
6. What are the notification preferences (in terms of description, e.g., audio, textual) of each
person?
Building Model
Continued on next page
SBEO: Smart Building Evacuation Ontology 9
Table 1 – continued from previous page
Spatial 7. What is the relative occupancy ratio of all corridors?
Information 8. How many points of interest are located on each floor of the building?
9. Which other spaces are adjacent to a specific space (e.g., kitchen) in the building?
10. Which space (e.g., a specific building block) is a sub-part of which space (e.g., building)?
11. What is the area of all corridors (it can be of any shape, such as, rectangular, circular,
trapezoidal or triangular)?
12. Which spaces are excluded (due to any reason such as limited access on account of mobil-
ity impairment or privacy policy of spaces, e.g., hotels) for which person?
Route Graph 13. How many nodes and edges are there in the graph-based representation of the building?
14. What is the type of each route in terms of its graph-based representation (e.g., Shortest
Path or Simplest Path)?
15. What is the travel time of all exit routes for each person (the starting and ending points of
each exit route are considered as origin and destination, respectively)?
Devices 16. Who is using a hand-held device, and of what type?
17. Which sensors are installed in each space of a specific type (e.g., office)?
18. How many fire protection devices are installed on the same floor where a specific person
is located?
Context Model
Building 19. Which activities (e.g, visit, evacuation, shopping) are being done in the building?
20. What is the availability status (i.e., Available or Unavailable) of each space?
User 21. Where is each person located in the building?
22. What is the role of each member within any group?
23. How many times a person has deviated from the provided path?
24. What is the fitness status (i.e, Exhausted, Fit, or Injured) of each person?
25. Which route is assigned to whom of which group (refers to a number of people that are
classified together, e.g., a family)?
26. What is the motion state of each person (refers to the movement of a person, e.g., walking,
standing, running, rolling, or scooting)?
27. What is the navigational state of each person (refers to the state while following a path to
check whether a person is following the provided path or deviating from it)?
Event (e.g., 28. Is there an incident in the building?
Emergency 29. At what time an incident occurred?
Evacuation) 30. What is the availability status of the spaces that are a part of emergency evacuation routes?
31. How many groups are still in the process of evacuating the building?
32. What is the impact of activities on persons having the mild quality of seeing ability?
33. What is the severity of the incidents for mobility-impaired persons (of all types)?
34. What are the intensities (refers to the magnitude or strength) of the events occurred?
35. Who has evacuated the building successfully (refers to the activity status of a person who
completes his/her provided exit route)?
1
The table is divided into three information models: user, building and context. The first2
column expresses a module type for each information model, and the second column3
states the list of competency questions which cover the aforementioned information model4
and module type.5
In the information model, firstly, User model represents the occupants (of any category6
such as visitor, resident, worker) of the building, along with its two modules to indicate7
their demographics and preferences. Secondly, Building model portrays the indoor spaces8
(and only those outdoors ones which are used to connect indoor ones), together with its9
module types and relevant competency questions. Lastly, Context model denotes context10
awareness of the aforesaid information models, hence its module types—user and build-11
ing. The event module type is also added in this model as per the scope of the ontology.12
10 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
5. Ontology Description1
This section describes SBEO based on the knowledge acquired from the literature and2
the specification mentioned in the previous sections. SBEO reuses various concepts from3
the existing ontologies such as FOAF10, Semantic Sensor Network Ontology11, The Or-4
dered List Ontology12, and SEAS Building Ontology13 . On the contrary, some ontologies5
e.g., Indoor Navigation Ontology (INO)[58], User Navigation Ontology (UNO)[58], User6
Tracking Ontology (UTO)[28], are not available online. Therefore, the relevant concepts7
are borrowed by sbeo namespace.8
Fig. 1 shows the Smart Building Evacuation Ontology (SBEO) in a nutshell. SBEO en-9
compasses three main parts, (i) User model, for specifying characteristics and relations of10
buildings’ occupants; (ii) Building model, for describing buildings topology and infras-11
tructures installed in them; and (iii) Context model, for representing the dynamic changing12
state of buildings and occupants.13
Fig. 1: Smart Building Evacuation Ontology (SBEO) in a nutshell
Fig. 2 shows the core concepts of Smart Building Evacuation Ontology (SBEO). In the14
following, we describe each of the models in more detail.15
5.1. User Model16
The User Model is used to represent the demographics, physical abilities, and people pref-17
erences (e.g. type of route or notification means). The demographics part includes the ba-18
sic information about a person using object (acquaintanceOf and responsibleTo)19
and/ data properties (e.g. foaf:firstName,foaf:lastName,foaf:gender,fo20
af:age, and id).21
A route or even a route element (e.g., space in the route) may not be appropriate for a22
specific person (or group of persons). Thus, it is crucial to model the physical abilities23
10 http://xmlns.com/foaf/spec/
11 https://www.w3.org/TR/vocab-ssn/
12 http://purl.org/ontology/olo/20100723/orderedlistontology.html
13 https://w3id.org/seas/BuildingOntology-1.0
SBEO: Smart Building Evacuation Ontology 11
Fig. 2: Core concepts and relationships of Smart Building Evacuation Ontology (SBEO).
12 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
of individuals for personalized route selection. Ontologies like User Navigation Ontol-1
ogy (UNO)[26] and General User Model Ontology (GUMO)[21], provide a core knowl-2
edge base for users and their characteristics by modeling the abilities such as mental3
abilities, mobility capabilities, along with their quality. In the same way, the physical4
abilities of users are conceptualized in SBEO based on UNO and GUMO. Furthermore,5
we know that we can only describe a binary relation (i.e., either between two individu-6
als or an individual and a value) in Semantic Web languages (e.g., RDF or OWL). As7
a solution, we may use n-ary design pattern to link an individual to more than one in-8
dividual or even a value. A potential reader may consult [39] for further information.9
Thus, we also exploit n-ary relations to make use of the aforementioned concepts to as-10
sociate them with a user. A new concept, PersonAbility, is also introduced to ex-11
press the ability (using hasAbility property ) of each person, together with its qual-12
ity (using hasQuality property. Note that the Ability class is similar to UNO and13
GUMO. Under this parent class, other sub-classes are introduced to mention different14
types of abilities such as MentalAbility,SpatialAbility,SensorAbility15
and MobilityAbility.16
In terms of navigational preferences, three relations–hasNavigationalType,route17
Preference, and meansOfNotification–are used. For example, hasNavigati18
onalType relation is used to express what type of navigation is provided to (or per-19
formed by) a person. The possible types of navigation can be AssistedNavigation,20
AutonomousNavigation,CollborativeNavigation or MultiObjective21
Navigation. In AssistedNavigation, a person is assisted by another person or22
a machine to perform a specific activity. In AutonomousNavigation, a person plans23
and executes their path without any human or machine intervention. In Collaborat24
iveNavigation, two or more persons are involved that may or may not have same25
objectives. Lastly, in MultiObjectiveNavigation, there can be various tasks to be26
done in it, such as visiting numerous points of interest, picking up multiple dependent27
persons.28
Similarly, an individual may use routePreference relation to specify their route29
preference, such as shortest path and simplest path[14]. meansOfNotification prop-30
erty is used to choose the method for notifying a person about any piece of information31
related to space, route, activity, event, or any route element (e.g., door, stairs, waiting32
zone, assembly point, entrance, exit). An instance of user model is given in Fig. 3.33
5.2. Building Model34
In this model, concepts related to the geometry (or structure) of the building are described.35
Other spatial information about the building is also taken into account, such as sensors,36
fire safety equipment.37
Geometrical elements. Geometrical elements are mentioned with the help of Space38
concept that represents any physical space. The type of a building and the specific site of39
any building can be described using seas:Building and seas: SiteOf Building40
respectively. All other atomic parts of a building (e.g., room, hall, door, stairs) are men-41
tioned as the sub-classes of seas:BuildingSpace. These atomic elements use locat42
SBEO: Smart Building Evacuation Ontology 13
Fig. 3: User modelling
edIn property to mention where these are located in a specific building, whereas partOf1
property is use to mention which building or an atomic part of the building belongs to2
which other building. If any space is connected or adjacent to any other space, connecte3
dTo and adjacentTo properties are respectively used to express that relation between4
them. Similarly, as each space, e.g., seas:Corridor,seas:Hall,seas:Escalat5
or, has a specific shape, data properties such as length,width,height,base,6
radius, and area, are defined. Additionally, accommodation Capacity property7
is used to express the accommodation capacity of a space in terms of persons where as,8
another data property named relativeOccupancyRatio is introduced that states the9
ratio of occupied to total usable (accommodationCapacity) space. Congestion10
can also be expressed using a boolean property named as hasCongestion. An instance11
of building geometry model is given in Fig. 4 that represents a Kids Area, along with the12
properties as mentioned in this paragraph.13
Fig. 4: Building space and sensor modelling
14 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
Routes. A route is sequence of connected spaces which is used to go from a starting point1
to a destination. We can also represent the geometry of a building as a graph, consisting2
of nodes and edges, such that it can be used for routing purposes. The existing approach3
in RDF vocabulary for specifying sequences (e.g., a route in this case), i.e. rdf:list, is4
not efficient because finding or accessing any specific element in the sequence is tiresome.5
To be precise, it doesn’t allow to access an element with an index. As a solution, Ordered6
List Ontology (OLO) provides a simple data structure to express the ordered lists, that7
can also be used to represent the routes. Moreover, the elements of the routes can also be8
accessed easily.9
In this regard, Route is conceptualized as a sub-class of olo:OrderedList, and10
RouteElement is introduced to represent the nodes and edges of a graph based on the11
information about the building structure. The edges and the nodes of a graph are repre-12
sented with the help of Passage (e.g., corridor, door, elevator, stairs) and RoutePoint13
(e.g., entrance, exit, waiting zone, assembly point) concepts respectively. It is a choice of14
an ontology user how he/she wants to express the routes. For example, e.g., either us-15
ing nodes or edges. In terms of usage,Route is allocated to any SocialUnit using16
assignedRoute relation.17
In terms of travel time, TravelTime class is defined with the help of n-ary relation. In18
this class, the time (using hasValue) from one point to another point (using origin19
and destination properties respectively, e.g., Room,Door,AssemblyPoint,Exit)20
can be mentioned for a specific person (i.e., forPerson).21
Elements other than the building structure. Device concept is used to express the el-22
ements that are not a part of building structure. It includes IncidentProtectionDev23
ice,Displayscreen,Telephone, etc. In addition, some concepts and properties24
are reused from SOSA ontology [24], to express the sosa:Sensor and its values. In25
terms of relations, installedIn property is used to mention the location of the space26
where a device is located (either permanently or movable), where as uses property is27
used to state who is using a specific device. An instance of a sensor is shown in Fig 4.28
5.3. Context Model29
The context model describes the concepts related to the situation of building and its oc-30
cupants.31
Activity and Event. By definition, activities are different from events. Because an ac-32
tivity is the happening that is being done by someone, for example visiting a museum,33
whereas an event is the happening of something, for example a fire in a museum. Due to34
this reason, Event and Activity concepts are stated separately. To cover the temporal35
dimension of them, hasTimeDuration,endedAtTime, and startedAtTime are36
used, respectively, to express the total time duration, ending time, and starting time, of37
any activity or event.38
Some particular events are also defined in SBEO. For example, an Incident that ex-39
presses an unexpected event or occurrence that may result in property damage or may40
SBEO: Smart Building Evacuation Ontology 15
cause a serious injury or illness to people. Furthermore, it has also been classified in some1
evacuation-related concepts, such as Congestion and Panic (including Stempeding).2
In addition, activities may also be divided into different categories, such as Navigation,3
EmergencyActivity,Visit, whereas a social unit who is involved in a specific ac-4
tivity is linked with it using performedBy relation.5
SBEO also conceptualizes intensity, severity, and the impact of an event or activity. As we6
know that the impact and the severity of an event or activity may differ for each person,7
we created n-ary relation to express these concepts in the ontology. On the other hand,8
the intensity of any event or activity remains the same for everyone. Thus, it is expressed9
using a class Intensity, along with a hasIntensity relation. Fig. 5 shows a fire10
event (i.e., :Fire1) and and evacuation activity (i.e., :Activity1), along with their intensity,11
severity, and impact.12
Fig. 5: Activity and event modelling
State and status of individuals. Various states and statuses of individuals related to13
their motion, navigation, fitness, and deviation, are also described in SBEO. For example,14
the state of their motion is expressed with the help of motionState property whose15
range can be either of the instances of MotionState class. These instances are explic-16
itly enumerated as Standing,Walking,Scooting,Running, and Rolling (e.g.,17
persons who use a manual wheelchair). The state of the navigation of the individuals using18
hasNavigationState whose range can be either of instances of Navigational19
State class (i.e., DeviatingFromPath or FollowingPath). The deviation is fur-20
ther divided into multiple types using hasDeviationState relation, whose range can21
be one of the individuals of DeviationState class, i.e., NoDeviate,RareDeviate,22
OftenDeviate , or TooOftenDeviate.23
In terms of status, hasActivityStatus relation is used to express the instantaneous24
information about an activity being performed by an individual whose range can be one25
of the instances of ActivityStatus class, for example Evacuating,Evacuated,26
16 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
Visiting,PickingUpDependents. Furthermore, hasFitnessStatus property1
states the fitness status of a person that can be either Fit,Exhausted or Injured.2
Group and role in a context. Two or more persons can be expressed as a Group if they3
are involved in any common activity (e.g, Evacuation,Visiting,PickingUpDep4
endents), having family- or friend- ties or an acquaintance, or sharing a common space5
(e.g., located in the same building, room or building floor). In addition, hasMember6
and size properties state the members and the size of a group respectively. If a person7
becomes responsible or a leader of a social unit (e.g, person or even a group), he/she can8
also be expressed with the help of responsibleTo property.9
In terms of role, RoleInContext concept is introduced based on n-ary design pattern.10
It consists of three properties named role,player, and context, to express the in-11
formation about a role of a person, the person identity, and a context (e.g., Activity,12
Event or SocialUnit) in which a person is playing that role, respectively.13
Space safety and accessibility. The safety of a particular space tells us how safe the14
space is, for a specific person (or types of persons). On the contrary, the accessibility15
of a space tells us how accessible the space is, for a specific person (or types of per-16
sons). Due to this reason, as the safety and the accessibility of a particular space may17
differ from one person (or types of persons) to another, two different parameters are in-18
troduced; SpaceSafety and PersonAccessibility. Both of these concepts are19
linked with the specific space using ofSpace property whose safety/accessibility is re-20
quired to mention, while hasValue and forPerson properties are used to express the21
safety/accessibility value of that particular space and the relevant persons associated with22
that value respectively. These concepts can be seen in Fig. 6, along with their usage. Note23
that the range of hasValue property of each parameter is taken as a fraction because24
it is a choice of the ontology user that how he or she wants to exploit it in a specific25
application.26
Fig. 6: Space safety and accessibility modelling
In the context model, some other information related to building spaces is also described27
using various properties. It is as follows:28
1. relativeOccupancyRatio - expresses the ratio of occupied to total usable (i.e.,29
capacity) space.30
SBEO: Smart Building Evacuation Ontology 17
2. accompanying - a relation to mention who is accompanying whom in a particular1
space.2
3. speedFactor - a value bound to any space (if applicable) that may affect the speed3
of individuals while passing through it. By default, it is equal to unity, but can be4
changed depending on various factors, such as Congestion,relativeOccupan5
cyRatio.6
4. hasAvailabilitystatus - states the availability status of any device, space or7
route as one of the instances of AvailabilityStatus class (i.e., Available8
or UnAvailable).9
5. excludedFor - mentions any specific space that is not preferred (or incapable of10
accessing) by a person.11
Potential Inferences. Inference in Semantic Web is a method of discovering new relation-12
ships between resources based on the existing data from the vocabulary. In this regard,13
some relationships are also inferred in SBEO based on the existing relationships among14
the individuals (instantiation) of the concepts. These are as follows:15
– Functional: hasAbility, hasAvailabilityStatus, hasDeviationS16
tate, hasFitnessStatus, hasImpact, hasIntensity, hasSever17
ity, hasValue, hasQuality, hasMotionState, hasNavigationa18
lState, foaf:age, foaf:gender, accommodationCapacity, rel19
ativeOccupancyRatio, hasCongestion, startedAtTime, endedA20
tTime, hasXTimesDeviated, area, base, height, length, rad21
ius, size, speed, width, olo:ordered list, olo:next, desti22
nation, origin, upper, lower23
– Inverse Functional: olo:previous, upper, lower24
– Transitive: accompanying, installedIn, leadsTo, partOf25
– Symmetric: leadsTo, accompanying, acquaintanceOf, adjacent26
To, connectedTo27
– Asymmetric: responsibleTo, locatedIn28
– Reflexive: acquaintanceOf29
– Disjointness: adjacentTo and connectedTo, endedAtTime and sta30
rtedAtTime31
– Inverse: lower and upper, olo:next and olo:previous, olo:or32
dered list and olo:slot33
6. Evaluation34
Turchet et al. [59] mentioned that ontology designing is somehow a matter of subjectivity35
similar to the implementation of an algorithm, which is an interpretation of the computer36
programmer. Hlomani and Stacey [22] discussed several approaches, methods and metrics37
to evaluate an ontology. They found out that there are two major perspectives which are38
needed to evaluate any ontology; quality and correctness. Accordingly, SBEO is evaluated39
18 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
using various formal methods and approaches, and metrics, to find out its quality and1
correctness.2
Ontology Metrics. Fernandez et al. [17] proposed twelve different measures to evaluate3
the ontology in terms of its generality and performance. In this study, we have shortlisted4
some of these metrics that fit the scope of SBEO. These metrics give an insight to the5
potential user of the ontology in terms of concepts and their relationships, popularity (i.e.,6
current usage), and reliability (or availability).7
Table 2 shows a comparison of these ontology metrics of SBEO with other ontologies in8
the field and which are cited in the related works section. In the table, the number of prop-9
erties is further divided into two sub-columns; object properties and data properties. As10
for the proposed ontology, there are 191 classes and 83 properties (both object and data)11
described in it in which 40 classes are reused from other ontologies, and the remaining12
151 classes are created from scratch. The term direct popularity means how many existing13
ontologies are importing the given ontology, whereas inverse popularity [59] means how14
many concepts and properties are imported from existing ontologies to develop the given15
ontology. In this regard, as SBEO has been developed recently, its direct popularity is low.16
On the other hand, in terms of indirect popularity, concepts and properties from various17
four existing ontologies (i.e., seas, olo, sosa, foaf) are used in sbeo.18
Ontology No. of classes No. of properties No. of individuals Direct popularity Indirect popularity
Data Object Ontology Imports
(Direct, Indirect) Classes Properties
SBEO 191 31 52 33 low 0, 0 21% 18%
SEAS
(Building) 102 3 32 5 low 1, 8 34% 85%
SOSA 16 2 21 1 high 0, 0 0% 0%
SSN 23 2 36 2 very high 1, 1 21% 58%
empathi 237 98 171 10 low 9, 0 31% 98%
BOT 10 1 16 5 medium 0, 0 30% 0%
Table 2: A comparison of SBEO with other ontologies in the field using ‘Knowledge
coverage and popularity measures’ proposed by Fernandez et al. [17]
Oops! Pitfall Scanner. We have evaluated SBEO using a tool named Oops! Pitfall Scan-19
ner [43] that assesses an ontology qualitatively by checking its quality across three various20
dimensions, namely: structural, functional and usability-profiling. In addition, it also ex-21
amines the consistency, completeness and conciseness of an ontology.22
Among 41 pitfalls (i.e., checking points), 3 minor (i.e., P08, P13,and P22) and 2 impor-23
tant (i.e., P11 and P30) pitfalls have been identified due to: (1) missing annotations; (2)24
the absence of inverse relationships; (3) naming convention other than CamelCase; (4)25
missing domain/range; (5) some concepts seem equivalent. As regards, first, third and26
fourth points, depends on the concepts we have reused from the existing ontologies (i.e.,27
SBEO: Smart Building Evacuation Ontology 19
SEAS, SOSA/SSN, OLO, FOAF) in SBEO. For the second point, most of the properties1
are either n-ary relations or do not support an adequate converse term, therefore these are2
exempted from this rule [62]. The justification of fifth point is, all of these concepts have3
different meanings in the proposed ontology, hence they will be kept in their current form.4
The results from this tool imply that the quality of the proposed ontology meets the best5
practices. Consequently, critical problems related to modelling and reasoning might be6
avoided, such as logical inconsistencies or undesired inferences.7
Reasoners to find any inconsistency. Three different reasoners—FaCT++ (version 1.6.5)8
[57], Pellet (version 2.2.0) [53], HermiT (version 1.4.3.456) [51]—have been used to9
check the logical consistency of SBEO, and no inconsistencies have been found in it. It10
implies that the SBEO classes may have instances (OWL individuals), and useful knowl-11
edge can be inferred from it.12
Answering Competency Questions (CQs). The competency questions (CQs) are an13
important part to evaluate an ontology. In this regard, SPARQL-based queries are used to14
answer the competency questions stated in section 4. Due to the space issue, the answer15
to each CQ can be found here14.16
MIRO: Minimum Information for the Reporting of an Ontology Matentzoglu et al. in17
[36], defined some guidelines named Minimum Information for Reporting an Ontology18
(MIRO). According to them, MIRO guidelines provide a better level of completeness19
and consistency to an ontology documentation. Hence, SBEO is described using MIRO20
guidelines. The report15 can be found on Github repository.21
Task-based Evaluation - A Use-case Task-based evaluation is one of the methods to22
evaluate an ontology by measuring the quality of the results a specific application delivers23
[48]. In this regard, a simple scenario is described where SBEO is used to define the24
semantics for a smart building evacuation system. Due to the lack of the space the use-25
case of the scenario16 can be found on Github repository.26
7. Application example: CAREE27
In this section, we describe a Context-Aware Emergency Evacuation (CAREE)17 sys-28
tem, which uses SBEO ontology for knowledge representation. CAREE uses complex29
event processing and semantic stream reasoning technologies for analysing streams of30
data coming from sensors installed in a smart building, identifying emergency conditions31
(e.g. hazardous situations that can be dangerous for the safety of the occupants of the32
building) and proposing safe and efficient individual evacuation routes to the occupants33
14 https://github.com/qasimkhalid/SBEO/blob/master/Competency%20Questions.md
15 https://github.com/qasimkhalid/SBEO/blob/master/MIRO%20Evaluation.md
16 https://github.com/qasimkhalid/SBEO/blob/master/Examples/SmallOfficeSpace/Documentation/
SBEO TaskBasedEvaluation SmallOfficeScenario.docx
17 https://github.com/qasimkhalid/CAREE
20 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
of the building according to the context (status of the building and people’s characteris-1
tics).2
Figure 7 shows a block diagram of CAREE architecture. The raw data from sensors (raw3
events) are annotated using SBEO and organised in several data streams according to their4
type (e.g., locations of people, temperature, humidity, and smoke).5
Fig. 7: The architecture of Context-Aware Emergency Evacuation (CAREE) software
The Data Processing Module aims to generate contextual information by processing6
data streams and static knowledge (i.e., building topology, user information). We use C-7
SPARQL[6]), an engine for processing continuous streams of RDF data. C-SPARQL18
8
queries are attached to specific data streams to identify patterns in the data and generate9
pieces of contextual information (e.g. movement of people, fire detection, etc.). The con-10
textual information is generated using SBEO ontology and is stored in an RDF repository11
on a real-time basis. For example, if Sensor1 detects PersonA, and Sensor1 is installed in12
Office1 then the triple (PersonA sbeo:locatedIn Office1) is added to the context repository.13
The Decision Making Module processes the information from Domain Data Events and14
the knowledge base running SPARQL queries. If a building evacuation is needed, it com-15
municates with the Route Planning Module to get the optimal routes for each person. The16
Route Planning Module calculates available, safe and accessible routes to the persons17
depending on their physical characteristics and preferences, as well as the instantaneous18
situation of the building. Lastly, the Decision Making Module generates relevant Action19
Events according to the predefined criteria.20
The actions events are then fed to the Physical World Controller such that specific actions21
could be performed as remedies to these events, such as assigning routes to persons, mak-22
ing hazardous spaces unavailable, and informing persons about the Points of Interest. The23
Physical World Controller works as a bridge between the system and the physical world24
(Actuators, i.e. IoT devices).25
We have developed an agent-based simulated environment to test CAREE, where each26
person is considered a separate agent in a common and shared environment. We used Java27
18 C-SPARQL language is a variation of the SPARQL query language for RDF, including stream processing
characteristics such as windows and continuous processing
SBEO: Smart Building Evacuation Ontology 21
and SPARQL languages for its development. Also, we have exploited Apache Jena and1
C-SPARQL frameworks to extract and update the SBEO-based data model. The simula-2
tor replicates the free-flow movements of people between two nodes that share a common3
arc and generates the values of Temperature, Smoke, and Humidity sensors, in a custom4
format. These simulated values are then fed into CAREE in the form of data streams after5
a customized time interval (e.g., one second). This simulated environment is determin-6
istic in nature, and a scheduler is used to carry out the movement of each person in the7
building that gets updated after every timestep (e.g., one second). As soon as, any hazard8
is detected and the evacuation process is set off, the evacuation route (i.e., a path from9
a person’s location to the nearest and feasible exit) is calculated in terms of timesteps10
and updated in the scheduler. Later on, the scheduler simulates the movement of the per-11
sons on each timestep until they reach their destination (i.e., exit). Once, a person reaches12
his/her destination, he/she is eliminated from the scheduler. Listing 1 shows a snapshot of13
the output of the simulator. This is updated after every timestep.14
//Edge
(node#, node#) | cost | safety value | capacity
(node1, node2) 10 0.5 2
(node1, node3) 15 0.3 3
(node2, node3) 20 0.1 1
//Node
node# | safety value | capacity | No. of persons positioned at a node
node1 0.0 14 2
node2 1.0 10 1
node3 0.4 10 0
node4 0.6 16 3
//Person
person# | location of a person
person1 node1
person2 node2
person3 node1
//Inaccessible edges list
person# | list of edges that are not apt for evacuation
person1 {} //empty set
person2 {(node1, node3)}
person3 {(node2, node3)}15
Listing 1: Simulator output after every timestep.
According to the scope of the paper, we ran a simple scenario of a building floor in16
our simulated environment, as shown in Figure 8. Each entity, such as space, floor exit,17
and fire extinguisher, is represented using Smart Building Evacuation Ontology (SBEO).18
Also, specific attributes of spaces, such as accommodation capacity, connections with19
other spaces, and the distance between the connected spaces (e.g., cost of each Origin-20
Destination (O-D) pair), are expressed.21
In addition, the building floor is further represented as a graph G= (N,A), as seen in Fig-22
ure 9, with 17 nodes, where each node in Nrepresents an entity shown in Figure 8, e.g.,23
closed space, junction19, point of interest, or entrance or emergency exit. On the other24
hand, Arepresents the arcs between the connected nodes. We also assume that each node,25
as seen in Figure 8 with a diamond symbol, is equipped with four types–Temperature,26
19 A junction is an imaginary route element that connects multiple corridors or other route elements (i.e., nodes).
22 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
Fig. 8: A building floor plan with an entrance (which may also be an exit), an emergency
exit and some closed spaces
Fig. 9: Network modelling from a smart building floor plan. Nodes are labelled as names
and Ids, and Arcs between two connected nodes are expressed as lines.
SBEO: Smart Building Evacuation Ontology 23
Smoke, Humidity, and Human Detection–of sensors and modelled using SBEO. In the1
end, we also modelled ten persons (including their demographics and physical character-2
istics) using SBEO, in which two of them are mobility impaired.3
The access to a specific space is determined with the help of a sbeo:hasSafetyValue4
in SBEO. For this particular application scenario, it ranges between 0 and 1, which ex-5
press the minimum and maximum safety, respectively. During the usual conditions, the6
safety of all spaces is 1, as the temperature and humidity are equal to 25 degrees Centi-7
grade and 40%, respectively. On the other hand, we assume that the critical safety for both8
arcs and nodes is 0.5. Thus, the space whose safety is less than 0.5 is not apt for evacua-9
tion for mobility-impaired persons, whereas if it is equal to 0 is not apt for evacuation for10
anyone.11
For the sake of simulation purposes, a fire event is triggered if the following conditions12
are met for a particular space altogether:13
1. The temperature rises to 60 degrees Centigrade.14
2. Humidity is less than 20%.15
3. Smoke exists.16
Here, we describe the results of the simulation-based experimental setup mentioned above.17
Initially, as we described earlier, at timestep t0, the temperature (temp) of each space was18
25 degrees Centigrade, the humidity (h) was 40%, and the smoke (s) was not detected.19
After each time interval (i.e., one second in this experiment), the temperature value of20
each sensor was randomly updated within the range of temptx−1+ 5 and temptx−1
−2,21
where xis an integer that increases after each timestep, t. Based on the temperature value22
of a sensor, the humidity and safety values of the same sensor are also updated. For exam-23
ple, at timestep t4,Office1 (i.e., Node 7) had a safety value of 0.87, and one person was in24
it. Similarly, the corridor (i.e., arc) between Office1 and Office2 (i.e., (Node 7, Node 5))25
had a safety value of 0.88. It implies that every person can access Office1 and the corridor26
between Office1 and Office2. Furthermore, Person6 is located in Office1 (i.e., Node 7).27
Suddenly, at timestep t18, fire event is detected on the arcs between POI1 and J1 (i.e.,28
(Node 17, Node 16)) and OpenHall2 and OE4 (i.e., (Node 4, Node 9)). Subsequently,29
their safety values are also reduced to 0.44 and 0.47. As a result, the Decision Making30
Module updates the safety of these arcs not to be apt for evacuation to mobility-impaired31
people and sets off the evacuation process.32
Once the evacuation process starts, the details of accessible space nodes depending on33
the allowed safety values concerning the type of each evacuee, along with the location of34
each person, are sent to the Route Planning Module. This module calculates feasible, and35
shortest paths using Dijkstra’s Algorithm [13] for each person to evacuate the building by36
reaching either of the exits (i.e., FE1 and FE2) from their current locations. We assume37
that one unit cost equals one timestep. For example, if a cost of an arc between two nodes38
is five units, it takes five timesteps to traverse that arc. Thus, the total cost of a path is39
equal to the cumulative cost of all the arcs involved. In this regard, each person evacuated40
the building (i.e., reached one of the safe exits) corresponding to the time equal to the cost41
of the complete route found and assigned to him or her by the algorithm.42
24 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
8. Conclusion and Future Work1
In this paper, a light-weight, but comprehensive, ontology was proposed for route rec-2
ommendation in smart buildings during both normal and emergency conditions. The pro-3
posed data model provides the concepts and relationships for an efficient route planning in4
smart buildings. It includes the information about users, buildings and the context aware-5
ness.6
The creation of the ontology is motivated by the need for facilitating the interoperability7
of smart gadgets and IoT-enabled buildings. The ontology is developed using a well-8
known methodology (i.e., METHONTOLOGY), and design patterns recommended by9
W3C. Furthermore, the ontology was evaluated using various metrics and methodolo-10
gies, found consistent, and considered applicable in its domain. The proposed ontology11
is compatible and integrated with some popular ontologies such as SOSA, FOAF, SEAS,12
etc.13
As a future work, we plan to integrate SBEO with the digital twin of a smart building14
in order to test its applicability and reliability. Afterwards, we will discuss the acquired15
results with the emergency response officers such that we might compare these results16
with the real data captured by them. That will allow us to evolve and evaluate the ontology17
based on the potentially expected real-world use-cases.18
Acknowledgments. This work has been partially supported by the Spanish Ministry of19
Science, Innovation, and Universities, co-funded by EU FEDER Funds, through grant20
RTI2018-095390-B-C31/32/33 (MCIU/AEI/ FEDER, UE), and by the AGROBOTS Project21
of the Rey Juan Carlos University funded by the Community of Madrid, Spain.22
References23
1. Akinwande, O.J., Bi, H., Gelenbe, E.: Managing crowds in hazards with dynamic grouping.24
IEEE Access 3, 1060–1070 (2015)25
2. Al-Nabhan, N., Al-Aboody, N., Al Islam, A.A.: A hybrid iot-based approach for emergency26
evacuation. Computer Networks 155, 87–97 (2019)27
3. Alirezaie, M., Hammar, K., Blomqvist, E.: Smartenv as a network of ontology patterns. Se-28
mantic Web 9(6), 903–918 (2018)29
4. Anagnostopoulos, C., Tsetsos, V., Kikiras, P., et al.: Ontonav: A semantic indoor navigation30
system. In: 1st Workshop on Semantics in Mob. Env. (SME05), Cyprus (2005)31
5. Augusto, J.C., Liu, J., Chen, L.: Using ambient intelligence for disaster management. In: In-32
ternational Conference on Knowledge-Based and Intelligent Information and Engineering Sys-33
tems. pp. 171–178. Springer (2006)34
6. Barbieri, D.F., Braga, D., Ceri, S., Della Valle, E., Grossniklaus, M.: C-sparql: Sparql for con-35
tinuous querying. In: Proceedings of the 18th international conference on World wide web. pp.36
1061–1062 (2009)37
7. Billhardt, H., Dunkel, J., Fern´
andez, A., Lujak, M., Hermoso, R., Ossowski, S.: A proposal for38
situation-aware evacuation guidance based on semantic technologies. In: Multi-agent Systems39
and Agreement Technologies, pp. 493–508. Springer (2016)40
8. Bitencourt, K., Dur˜
ao, F.A., Mendonc¸a, M., SANTANA, L.L.B.D.S.: An ontological model for41
fire emergency situations. IEICE Trans. on Inf. and Sys. 101(1), 108–115 (2018)42
SBEO: Smart Building Evacuation Ontology 25
9. Blache, F., Chraiet, N., Daroux, O., Evennou, F., Flury, T., Privat, G., Viboud, J.P.: Position-1
based interaction for indoor ambient intelligence environments. In: Aarts, E., Collier, R.W., van2
Loenen, E., de Ruyter, B. (eds.) Ambient Intelligence. pp. 192–207. Springer (2003)3
10. Boje, C., Li, H.: Crowd simulation-based knowledge mining supporting building evacuation4
design. Advanced Engineering Informatics 37, 103–118 (2018)5
11. Chu, M.L., Parigi, P., Law, K.H., Latombe, J.C.: Simulating individual, group, and crowd be-6
haviors in building egress. Simulation 91(9), 825–845 (2015)7
12. De Nicola, A., Melchiori, M., Villani, M.L.: Creative design of emergency management sce-8
narios driven by semantics: An application to smart cities. Inf. Sys. 81, 21–48 (2019)9
13. Dijkstra, E.W., et al.: A note on two problems in connexion with graphs. Numerische mathe-10
matik 1(1), 269–271 (1959)11
14. Duckham, M., Kulik, L.: “simplest” paths: automated route selection for navigation. In: Inter-12
national Conference on Spatial Information Theory. pp. 169–185. Springer (2003)13
15. Dudas, P.M., Ghafourian, M., Karimi, H.A.: Onalin: Ontology and algorithm for indoor routing.14
In: 2009 Tenth International Conference on Mobile Data Management: Systems, Services and15
Middleware. pp. 720–725. IEEE (2009)16
16. Fang, Z., Song, W., Zhang, J., Wu, H.: Experiment and modeling of exit-selecting behaviors17
during a building evacuation. Physica A: Stat. Mech. and its Appl. 389(4), 815–824 (2010)18
17. Fern´
andez, M., Overbeeke, C., Sabou, M., Motta, E.: What makes a good ontology? a case-19
study in fine-grained knowledge reuse. In: Asian Semantic Web Conference. pp. 61–75.20
Springer (2009)21
18. Fern´
andez-L´
opez, M., G´
omez-P´
erez, A., Juristo, N.: Methontology: from ontological art to-22
wards ontological engineering. American Asociation for Artificial Intelligence (1997)23
19. Gaur, M., Shekarpour, S., Gyrard, A., Sheth, A.: Empathi: An ontology for emergency manag-24
ing and planning about hazard crisis. In: 2019 IEEE 13th International Conference on Semantic25
Computing (ICSC). pp. 396–403 (2019)26
20. Haghighi, P.D., Burstein, F., Zaslavsky, A., Arbon, P.: Development and evaluation of ontol-27
ogy for intelligent decision support in medical emergency management for mass gatherings.28
Decision Support Systems 54(2), 1192–1204 (2013)29
21. Heckmann, D., Schwartz, T., Brandherm, B., Schmitz, M., von Wilamowitz-Moellendorff, M.:30
Gumo – the general user model ontology. In: Ardissono, L., Brna, P., Mitrovic, A. (eds.) User31
Modeling 2005. pp. 428–432. Springer Berlin Heidelberg, Berlin, Heidelberg (2005)32
22. Hlomani, H., Stacey, D.: Approaches, methods, metrics, measures, and subjectivity in ontology33
evaluation: A survey. Semantic Web Journal 1(5), 1–11 (2014)34
23. Huang, H., Gartner, G.: A survey of mobile indoor navigation systems. In: Cartography in35
Central and Eastern Europe, pp. 305–319. Springer (2009)36
24. Janowicz, K., Haller, A., Cox, S.J., Le Phuoc, D., Lefranc¸ois, M.: Sosa: A lightweight ontology37
for sensors, observations, samples, and actuators. Journal of Web Semantics 56, 1–10 (2019)38
25. Karimi, H.A., Ghafourian, M.: Indoor routing for individuals with special needs and prefer-39
ences. Transactions in GIS 14(3), 299–329 (2010)40
26. Kikiras, P., Tsetsos, V., Hadjiefthymiades, S.: Ontology-based user modeling for pedestrian41
navigation systems. In: ECAI 2006 Workshop on Ubiquitous User Modeling (UbiqUM), Riva42
del Garda, Italy. pp. 1–6 (2006)43
27. Krieg-Br¨
uckner, B., Frese, U., L¨
uttich, K., Mandel, C., Mossakowski, T., Ross, R.J.: Specifi-44
cation of an ontology for route graphs. In: International Conference on Spatial Cognition. pp.45
390–412. Springer (2004)46
28. Kritsotakis, M., Michou, M., Nikoloudakis, E., Bikakis, A., Patkos, T., Antoniou, G.,47
Plexlousakis, D.: Design and implementation of a semantics-based contextual navigation guide48
for indoor environments. J. of Amb. Int. and Smart Environments 1(3), 261–285 (2009)49
29. Lefranc¸ ois, M., Kalaoja, J., Ghariani, T., Zimmermann, A.: SEAS Knowledge Model. Deliver-50
able 2.2, ITEA2 12004 Smart Energy Aware Systems (2016), 76 p.51
26 Qasim Khalid, Alberto Fernandez, Marin Lujak, and Arnaud Doniec
30. Li, X., Liu, G., Ling, A., Zhan, J., An, N., Li, L., Sha, Y.: Building a practical ontology for1
emergency response systems. In: Computer Science and Software Engineering, International2
Conference on. vol. 4, pp. 222–225. IEEE Computer Society (2008)3
31. Lujak, M., Billhardt, H., Dunkel, J., Fern´
andez, A., Hermoso, R., Ossowski, S.: A distributed4
architecture for real-time evacuation guidance in large smart buildings. Computer Science and5
Information Systems 14(1), 257–282 (2017)6
32. Lujak, M., Giordani, S.: Centrality measures for evacuation: finding agile evacuation routes.7
Future Generation Computer Systems 83, 401–412 (2018)8
33. Lujak, M., Ossowski, S.: Intelligent people flow coordination in smart spaces. In: Multi-Agent9
Systems and Agreement Technologies, pp. 34–49. Springer (2015)10
34. Ma, Y., Li, L., Zhang, H., Chen, T.: Experimental study on small group behavior and crowd11
dynamics in a tall office building evacuation. Physica A: Statistical Mechanics and its Applica-12
tions 473, 488–500 (2017)13
35. Malizia, A., Onorati, T., Diaz, P., Aedo, I., Astorga-Paliza, F.: Sema4a: An ontology for emer-14
gency notification systems accessibility. Exp. Sys. with App. 37(4), 3380 – 3391 (2010)15
36. Matentzoglu, N., Malone, J., Mungall, C., Stevens, R.: Miro: guidelines for minimum informa-16
tion for the reporting of an ontology. Journal of biomedical semantics 9(1), 6 (2018)17
37. Morales, A., Alcarria, R., Martin, D., Robles, T.: Enhancing evacuation plans with a situation18
awareness system based on end-user knowledge provision. Sensors 14(6), 11153–11178 (2014)19
38. Noy, N.F., McGuinness, D.L., et al.: Ontology development 101: A guide to creating your first20
ontology (2001)21
39. Noy, N., Rector, A., Hayes, P., Welty, C.: Defining N-ary Relations on the Seman-22
tic Web, W3C Working Group Note, 12 April 2006. https://www.w3.org/TR/23
swbp-n- aryRelations/, [Online; accessed September 13, 2022]24
40. Onorati, T., Malizia, A., Diaz, P., Aedo, I.: Modeling an ontology on accessible evacuation25
routes for emergencies. Expert Sys. with Appl. 41(16), 7124–7134 (2014)26
41. Pˆ
aslaru-Bontas¸, E.: A contextual approach to ontology reuse: methodology, methods and tools27
for the semantic web. PhD Thesis, Universit¨
at Berlin, Germany (2007)28
42. Pinto, H.S., Staab, S., Tempich, C.: Diligent: Towards a fine-grained methodology for dis-29
tributed, loosely-controlled and evolving engineering of ontologies. In: Proceedings of the 16th30
European Conference on Artificial Intelligence. pp. 393–397 (2004)31
43. Poveda-Villal ´
on, M., G´
omez-P´
erez, A., Su´
arez-Figueroa, M.C.: Oops!(ontology pitfall scan-32
ner!): An on-line tool for ontology evaluation. International Journal on Semantic Web and33
Information Systems (IJSWIS) 10(2), 7–34 (2014)34
44. Ramos, C., Augusto, J.C., Shapiro, D.: Ambient intelligence—the next step for artificial intel-35
ligence. IEEE Intelligent Systems 23(2), 15–18 (2008)36
45. Rasmussen, M.H., Lefranc¸ ois, M., Schneider, G.F., Pauwels, P.: Bot: the building topology37
ontology of the w3c linked building data group. Semantic Web 12(1), 143–161 (2021)38
46. Ray, B.: How An Indoor Positioning System Works, AirFinder. https://www.39
airfinder.com/blog/indoor-positioning- system (2018), [Online; accessed40
September 13, 2022]41
47. Ren, Y., Parvizi, A., Mellish, C., Pan, J.Z., Van Deemter, K., Stevens, R.: Towards competency42
question-driven ontology authoring. In: Euro. Sem. Web Conf. pp. 752–767. Springer (2014)43
48. Sabou, M., Gracia, J., Angeletou, S., d’Aquin, M., Motta, E.: Evaluating the semantic web: A44
task-based approach. In: The Semantic Web. pp. 423–437. Springer Berlin Heidelberg, Berlin,45
Heidelberg (2007)46
49. Santos, L.S., Sicilia, M.A., Garcia-Barriocanal, E.: Ontology-based modeling of effect-based47
knowledge in disaster response. Int. J. on Semantic Web and Information Systems (IJSWIS)48
15(1), 102–118 (2019)49
50. Segev, A., et al.: Context ontology for humanitarian assistance in crisis response. In: ISCRAM50
2013 Conference Proceedings – 10th International Conference on Information Systems for51
Crisis Response and Management. pp. 526–535. ISCRAM (2013)52
SBEO: Smart Building Evacuation Ontology 27
51. Shearer, R., Motik, B., Horrocks, I.: Hermit: A highly-efficient owl reasoner. In: Owled. vol.1
432, p. 91 (2008)2
52. Sicilia, M. ´
A., Santos, L.: Main elements of a basic ontology of infrastructure interdependency3
for the assessment of incidents. In: Visioning and Engineering the Knowledge Society. A Web4
Science Perspective. pp. 533–542. Springer Berlin Heidelberg, Berlin, Heidelberg (2009)5
53. Sirin, E., Parsia, B.: Pellet: An owl dl reasoner. In: Proc. of the 2004 Description Logic Work-6
shop (DL 2004). pp. 212–213 (2004)7
54. Su´
arez-Figueroa, M.C., G´
omez-P´
erez, A., Fern´
andez-L´
opez, M.: The neon methodology for8
ontology engineering. In: Ontology engineering in a networked world, pp. 9–34. Springer9
(2012)10
55. Sumam, M.I., Vani, K.: Agent based evacuation simulation using leader-follower model. Inter-11
national Journal of Scientific & Engineering Research (IJSER) 4(8) (2013)12
56. Sure, Y., Staab, S., Studer, R.: On-to-knowledge methodology (otkm). In: Handbook on on-13
tologies, pp. 117–132. Springer (2004)14
57. Tsarkov, D., Horrocks, I.: Fact++ description logic reasoner: System description. In: Interna-15
tional joint conference on automated reasoning. pp. 292–297. Springer (2006)16
58. Tsetsos, V., Anagnostopoulos, C., Kikiras, P., Hadjiefthymiades, S.: Semantically enriched nav-17
igation for indoor environments. Int. J. of Web and Grid Services 2(4), 453–478 (2006)18
59. Turchet, L., Antoniazzi, F., Viola, F., Giunchiglia, F., Fazekas, G.: The internet of musical19
things ontology. Journal of Web Semantics 60, 100548 (2020)20
60. Uschold, M., Gruninger, M.: Ontologies: principles, methods and applications. The Knowledge21
Engineering Review 11(2), 93–136 (1996)22
61. van Heijst, G., Schreiber, A., Wielinga, B.: Using explicit ontologies in kbs development. In-23
ternational Journal of Human-Computer Studies 46(2), 183 – 292 (1997)24
62. Villal´
on, M.P., P´
erez, A.G.: Ontology Evaluation: a pitfall-based approach to ontology diagno-25
sis. PhD Thesis, Universidad Politecnica de Madrid, Escuela Tecnica Superior de Ingenieros26
Informaticos (2016)27
63. Wang, X., Dong, J., Chin, C., Hettiarachchi, S., Zhang, D.: Semantic space: an infrastructure28
for smart spaces. IEEE Pervasive Computing 3(3), 32–39 (2004)29
64. Yang, L., Worboys, M.: A navigation ontology for outdoor-indoor space: (work-in-progress).30
In: Proceedings of the 3rd ACM SIGSPATIAL international workshop on indoor spatial aware-31
ness. pp. 31–34 (2011)32
65. Yusupov, R., Ronzhin, A.: From smart devices to smart space. Herald of the Russian Academy33
of Sciences 80(1), 63–68 (2010)34
