Abstract
Occupant feedback enables building managers to improve occupants’ health, comfort, and satisfaction. However, acquiring continuous occupant feedback and integrating this feedback with other building information is challenging. This paper presents a scalable method to acquire continuous occupant feedback and directly integrate this with other building information. Semantic web technologies were applied to solve data interoperability issues. The Occupant Feedback Ontology was developed to describe feedback semantically. Next to this, a smartwatch app – Mintal – was developed to acquire continuous feedback on indoor environmental quality. The app gathers location, medical information, and answers on short micro surveys. Mintal applied the Occupant Feedback Ontology to directly integrate the feedback with linked building data. A case study was performed to evaluate this method. A semantic digital twin was created by integrating linked building data, sensor data, and occupant feedback. Results from SPARQL queries gave more insight into an occupant’s perceived comfort levels in the Open Flat. The case study shows how integrating feedback with building information allows for more occupant-centric decision support tools. The approach presented in this paper can be used in a wide range of use cases, both within and without the architecture, building, and construction domain.
Introduction
Whether at the office or at home, many people face indoor environmental discomfort. Opening the shading system to reach better brightness levels, resulting in too hot temperatures. Opening the door to let in some fresh air, causing noise distraction from your talking colleagues. Researchers admitted these challenges and found that the discomfort might lead to poor satisfaction rates [5,50,51], health issues [20,27,29], and reduced productivity [6,54]. This led to the development of models to assess the indoor environmental quality (IEQ), such as the predicted mean vote (PMV) method for thermal comfort [5] and the Spatial Daylight Autonomy for visual comfort [44]. Various standards [7,8,44] set objective values for these models, promising high-quality indoor environments.
However, practice shows different results. Even though advanced IEQ models were developed, occupants still face discomfort. Current IEQ models do not necessarily reflect the perceived environmental quality [16], and high scores on building codes and certificates do not undoubtedly lead to higher user satisfaction. Altomonte et al. [7,8] found that LEED-certified (Leadership in Energy and Environmental Design) buildings do not score significantly higher on user satisfaction, while non-BREEAM (Building Research Establishment Environmental Assessment Method) buildings even outperformed BREEAM-certified buildings on user satisfaction for certain parameters. Cheung et al. [16] found that the PMV model inaccurately predicts thermal sensation two out of three times. Building managers lack time, skills, and equipment to monitor IEQ parameters accurately [66], while monitoring devices face problems with accuracy and calibration [47]. Jayathissa et al. [47] argue that system control in buildings further simplifies those IEQ models, resulting in an even more significant gap between perceived and measured comfort.
Willems et al. [87] argued that IEQ models are too passive and deterministic and proposed the Healing Environment approach to improve the perceived comfort modeling practice. This approach combines physical measurements with actions, emotions, and the cognitive systems of occupants. Jayathissa et al. [47] listed various physiological, psychological, and environmental variables influencing the perceived IEQ. Scherer [76] recorded various affective phenomena, such as preferences, attitudes, mood, affect dispositions, and interpersonal stances, which influence emotions and thus one’s perception of space. However, standards to operate buildings according to occupancy and occupant behavior are still lacking [65].
Current facility management systems fail to perform such post-occupancy evaluations (POE) and use their results in decision-making processes in the operational phase of a building [24]. Li et al. [57] mentioned various issues in the current practice of POE. First, POE results are hardly integrated into the broader practice of building management. Secondly, most POE studies fail to perform continuous measurements, resulting in problems not being fully understood or even identified. Integrating continuous occupant feedback with building management data could improve building automation control systems [57] and occupant satisfaction [14].
A promising solution to integrate occupant feedback with building information is the development of semantic digital twins. Digital twins integrate data to represent a virtual counterpart of real-world situations and consist of three components: a real-world physical component, a virtual representation, and the data that connects them [12]. Various research initiatives applied semantic web technologies to create digital twins by linking different domain knowledge silos in an integrated way using ontologies. Nolich et al. [64] developed a semantic digital twin of a cruise ship cabin to optimize comfort levels and reduce energy consumption. Frešer et al. [30] created a decision support system by anticipating IEQ parameters using a semantic digital twin. Donkers et al. [22], Esnaola-Gonzalez et al. [25], Corry et al. [17], and Ploennigs et al. [69] used semantic digital twins to monitor thermal comfort in buildings.
However, state-of-the-art ontology development mainly focused on integrating the traditional IEQ parameters, while less attention has been paid to integrating softer, personal data related to occupants. Current semantic digital twins can integrate sensor data to monitor IEQ parameters but fail to evaluate the perceived comfort levels of an individual. Integrating individual comfort preferences and feedback with linked building data is expected to close the gap between measured and perceived comfort. Next to this, facility managers spend half of their on-site time matching problems with a location or an element [24], which could be significantly improved by semantically linking feedback to linked building data.
This paper introduces a novel method to continuously capture occupant feedback and integrate this feedback with other building information, creating so-called occupant-centric digital twins [65]. The first part of this paper reviews state-of-the-art occupant feedback systems and semantic web ontologies related to occupants and their feedback. Based on this review, this paper presents the Occupant Feedback Ontology (OFO) to describe passive and active occupant feedback. The second part of this paper introduces Mintal, a smartwatch application for longitudinal occupant feedback collection. Mintal uses the Occupant Feedback Ontology to link the obtained feedback with other building information using semantic web technologies. Finally, this paper presents a case study of an apartment building in the Netherlands, in which the functionality of our proposed system is validated.
Related work
Occupant feedback systems
There is a growing interest in occupant-centric buildings [65]. Occupants’ building performance assessments are considered vital input data for occupant-centric decision support systems. However, various researchers argue that there is a lack of scalable data collection tools [57,65]. This section reviews current methods to acquire occupant feedback and emphasizes the challenges to creating continuous occupant feedback systems.
Literature generally distinguishes two methods for post-occupancy evaluation: subjective methods and objective methods [36,38,57]. Most studies rely on subjective methods, often being occupant surveys, interviews, and walkthroughs [57]. While these methods hardly require equipment, the manual handling of verbally or textually transmitted feedback is a costly and time-consuming task causing a delay in decision-making processes. Next, current methods often capture people’s retrospective feedback [38], causing concerns about recall bias and ecological validity [45].
Ecological momentary assessments
The development of the Internet of Things is an opportunity to reconsider current methods to acquire occupant feedback [65]. The Ecological Momentary Assessment (EMA) method [79] is rooted in clinical psychologists’ need to acquire in-situ data on subjects’ states in the real world and samples a participant’s state in real-time. The real-time survey ensures ecological validity and reduces recall bias. Sampling a participant’s state over a longer period reveals behavioral variation over time, place, and situation. Since the EMA method originates from the psychology domain, it gathers information about moods, activities, satisfaction, behavior, stress, and health status [49,79]. EMA is, therefore, suitable to discover individual behavioral patterns, contextual associations, and temporal sequences in participants’ states [79,87].
The technologies to acquire data using the EMA method differ and range from traditional diaries to smartphones applications [79]. Sampling could either be event-based, time-based, or a combination. The chosen strategy affects the coverage of the sampling. An event-based complaint log can lead to a long list of complaints, even though occupants might feel comfortable between those assessments. Random time-based strategies reduce this bias. Some observations, e.g., performed by sensors, could result in continuous measurement of the subject.
Due to the high frequency of samplings, annoyance may occur if the assessment is not designed well enough [79]. Screens have limited display space [79]. While smartphones are cost-effective devices to perform EMA studies, both the length of the interruption (interface usage time) and the burden of unlocking the phone and opening an app (device access time) might feel like a burden for studies with a high temporal density [45]. Reactivity – the subject changing its behavior because it is assessed – may occur in longitudinal EMA studies [79], although some research states that the effect is small [45].
Following the EMA principles, Sheikh Khan et al. [78] defined occupant voting systems (OVS) as a “technology which occupants can use at any given time to provide continuous and real-time feedback on their perception of IEQ.” They distinguished OVS from various digital tools that were only available at specific times. Based on the drivers-needs-actions-systems framework [38], Sheikh Khan et al. [78] concluded that systems that only collect data on occupants’ actions (such as smart thermostats that measure manual changes from users [15]) are not considered as OVS since they do not measure perception (or drivers and needs [38]). Sheikh Khan et al. [78] defined feedback as any act of using OVS, while voting is limited to quantitative feedback. This section reviews occupant feedback systems (OFS), a term also mentioned by Lassen et al. [48], to cover both qualitative and quantitative feedback methods. Lassen [53] listed various data categories that should be collected for occupant-centric data collections: physical and spatial (building) information, physiological reactions of occupants, occupant control actions, and positive and negative evaluations.
Over the past years, a wide range of digital tools arose that partially collected the data categories mentioned by Lassen [53]. Both Lassen [53] and Sheikh Khan et al. [78] recently categorized those tools by interface type. They listed 23 [53] and 46 [78] applications, out of which most applications were smartphone apps, web apps, or dedicated devices (Fig. 1).

Interface types of OFS applications in Sheik et al. and Lassen.
O’Brien et al. [65] argue that the interface of occupant feedback systems needs more attention. Smartphone apps and digital surveys still do not fully solve problems regarding survey fatigue. The micro ecological momentary assessment (μEMA) method aims to reduce this limitation by using short interactions that hardly disrupt one’s ongoing activity. Smartwatch apps can mitigate both the device access time and the interface usage time and therefore fit the approach [45,47].
Literature [45,77] suggests that, compared to EMA, μEMA led to higher response rates, completion rates, and first prompt response rates while being perceived as less distracting. Occupants’ states could be assessed by prompting questions on the screen (time-based) [45] or by designing a home screen application where subjects could give feedback whenever they want (event-based) [47].
While EMA is hardware agnostic, μEMA is not. The use of high-tech wearables may burden the elderly or non-tech-savvy occupants. Kim et al. [49] found multiple studies that examined a higher dropout rate of older people due to technical issues or discomfort while using technological devices. They argue that standardized data protocols for mixed-method sampling studies will lead to better monitoring. While the smartwatch market is booming, the saturation rate is still relatively low, meaning that currently, extra costs are involved in μEMA studies.
Various research initiatives followed the μEMA method to monitor occupant feedback. Feldmeier and Paradiso [28] developed a wearable sensor with three buttons that allow users to input their thermal comfort. Intille et al. [45] created a smartwatch survey to monitor mood. Questions were scheduled and prompted using vibrations. Textual questions with three answers were shown on the screen, as Intille et al. [45] argued that more answers would introduce scrolling, small fonts, or small buttons. Jayathissa et al. [47,48] developed a more graphical interface for indoor environmental quality feedback. Their app – cozie – merely shows possible answers to a question. Removing the question leaves more space for the answer buttons. Unlike the app created by Intille et al. [45], cozie prompts a multi-question survey with questions related to a user’s location, clothing, activity level, and various comfort assessments. Those surveys were prompted using vibrations but could also be opened by the user at any time.
The development of embedded sensors in smartphones and smartwatches further increases methods to monitor occupants. Majumder and Jamal Deen [61] reviewed how those sensors are used to monitor mental health, cardiovascular health, activity, and sleep. Liu et al. [59] used wearable sensors to measure skin temperature, heart rate, and wrist accelerometry to create personal thermal comfort models. Sensors of commercial wearables were used to assess thermal comfort in multiple research initiatives [35,43,75]. Li et al. [56], Abdallah et al. [1] and Barrios and Kleiminger [11] combined sensors of wearables with thermal votes using a smartphone application.
Localization of occupant feedback is an essential step to enable the integration with other building information [62]. According to the review of Sheikh Khan et al. [78], most feedback systems use manual localization or do not have localization functionalities. In the latter case, manual localization was not always necessary, as some researchers used methods that were fixed to a specific location or object. The systems that did include manual localization functionalities used various techniques, such as RFID and QR tags, or manual location selection during the feedback process. Some automatic localization techniques were found, including trilateration using Received Signal Strength Indicators, Bluetooth beacons, and Wi-Fi signals. Jayathissa et al. [47,48] developed a smartwatch app that combined different localization techniques. The smartwatch’s GPS sensor is used for outdoor localization, while Bluetooth beacons are used for indoor localization. A tool created by Gray et al. [33] could be opened by scanning a QR code and automatically adds the location of the QR tag to the feedback metadata. Miller et al. [62] applied the clock face app of Jayathissa et al. [47,48] to integrate feedback with building information models using Bluetooth localization. Abdelrahman et al. [2] extended this research to create personal thermal comfort models.
Occupant feedback in the semantic web
The lack of integration of occupants and their feedback with other building information is a significant barrier for occupant-centric decision support tools [52,57]. This lack of integration is often caused by data interoperability issues [81]. Building information is typically produced by multiple stakeholders, using different software tools at different moments in the building lifecycle. During the operational phase, different users might produce different types of feedback, that in its turn could be used by multiple other stakeholders – all speaking their own domain language [74]. Semantic web technologies promise to accomplish higher interoperability levels in the architecture, engineering, and construction (AEC) domain [67]. Multiple researchers applied semantic web technologies to create rich digital representations of buildings [12], some of whom for research related to occupants’ comfort [17,22,25,30,64,69]. To better understand the existing promises and challenges of semantic web technologies to solve the interoperability issues, the following subsections give an overview of state-of-the-art semantic web developments related to occupants, their feedback, and their building performance assessments.
Semantic web technologies for occupants
Ontologies describing humans have been widely developed across multiple domains. FOAF [32] was created to describe people and their relations with other people and documents. FOAF, being a domain agnostic ontology, is widely used in a variety of use cases.
A disadvantage of domain agnostic ontologies is that they might lack classes and object properties for specific use cases. Various researchers, therefore, built upon FOAF to create occupant ontologies related to the built environment. Spoladore et al. [64,80,81] created various extensions of FOAF to represent occupants and their health and comfort information. They used this information to improve comfort in the hospitality sector. SEAS [55] reused FOAF in their comfort ontology module to describe the comfort levels of agents. Curry et al. [18] extended FOAF with information about the devices that people are using.
Hong et al. [38] identified four occupant-related components that influence occupants’ energy behavior in buildings: attributes, attitude, location, and state. Attributes (also referred to as properties in other works [86]) typically describe sociodemographic characteristics such as age, gender, and health information. Attitude describes how an occupant behaves towards and interacts with building systems. The occupants’ state relates to dynamic properties such as their metabolic rate or clothing level. Spoladore et al. [64,80,81] extended this by including the occupant’s activity.
Li et al. [58] further developed the work of Hong et al. [38] by creating an occupancy module as part of their EM-KPI ontology (prefixed eko). The ontology describes an eko:Occupant that has an eko:OccupantBehavior, influenced by eko:IndoorComfort, and therefore assumes that various indoor comfort parameters (such as temperature, humidity, and CO2 levels) directly affect one’s behavior. Comfort is not modeled as a property of the occupant but merely as a set of observable parameters of a zone. Degha et al. [19] created a similar occupant profile using a HumanProfile class. It describes, amongst others, humans’ states, activities, behavior, properties, and preferences.
Semantic web technologies for occupant feedback
Gray et al. [33] developed an ontology to describe occupant feedback in office buildings. The ontology is built upon ifcOWL and contains classes describing a building’s topology, geographical location, room types, building systems, and occupants and their feedback. Feedback is split into three classes, being:Feedback (to describe feedback of an occupant), :Comment (to describe comments on existing feedback), and :Vote (used to describe votes on existing feedback). The ontology includes a taxonomy of feedback type classes, hardcoding various possible feedback types in commercial buildings (such as:BlindsMoreCloseComplaint). Zhao and Yang [88] similarly hardcoded various evaluation tasks as classes. These were used to describe POE survey results in an RDF format.
While Gray et al. [33] follow the common monolithic approach that many non-RDF standards adhere to, semantic web technology best practices suggest creating modular ontologies that can be used following a plug-and-play principle [84]. Following those best practices, Spoladore et al. [81] developed ComfOnt to describe occupant comfort metrics. They introduced comf:ComfortMetrics as an owl:equivalentClass of saref:Property to describe comfort metrics, such as indoor temperature and indoor illuminance. Occupants can manually define preferred comfort metrics using comf:CustomizedComfortSetting, for example, by defining a minimum and maximum value. Qiu et al. [71] developed the Hex ontology to describe human experiences and sensations for the IEQ domain, and linked this ontology with their bim4Hex ontology that describes the spaces and building elements that these experiences are linked to.
Describing metadata in the context of building performance is essential but simultaneously one of the most time-consuming tasks [36]. Similar to FOAF, a few domain agnostic ontologies exist that might be used to describe metadata of feedback. Metadata of agents, documents, and other resources can be described using the DCMI Metadata Terms.1
Spoladore et al. [64,80,81] used SWRL rules [39] to assess the performance of a building and trigger systems to change their state accordingly. These rules typically compare a sensor reading with predefined criteria. These criteria can either be based on certification schemes or personal preferences. If a temperature sensor reading is, for example, greater than a maximum preferred value, the air conditioning system will be triggered. Degha et al. [19] used a similar strategy to trigger building systems to improve comfort and give feedback to the occupant. Zhao and Yang [88] used SWRL to evaluate whether POE survey results match predefined performance criteria.
Using SWRL or SHACL to assess building performance typically requires the sensor readings to be written in RDF format, using, for example, the SSN ontology [34]. However, various researchers suggest storing sensor readings in time-series databases [26,40,68]. The performance assessment is then often executed in a dedicated software layer that uses SPARQL results and time-series data [40]. Both Hu et al. [42] and Donkers et al. [22] used this principle to assess energy performance and indoor environmental quality, respectively.
Hu et al. [42] and Donkers et al. [22] stored performance metrics in an RDF format to evaluate building performance. Their work is based on ontologies previously developed by Hu et al. [40,41] and Corry et al. [17]. A similar ontology was created by Li et al. [58] and describes stakeholders and their key performance indicators in RDF. Performance indicators of different stakeholders can be linked to elements in cross-domain building information.
These ontologies show similarities with the work of Spoladore et al. [64,80,81] and Degha et al. [19]. However, Hu et al. [42], Donkers et al. [22], and Li et al. [58] query the performance indicators using SPARQL and compare them to sensor data in separate software applications, whereas Spoladore et al. [64,80,81] and Degha et al. [19] rely on SWRL to make this comparison.
Petrova et al. [68] argue that performance data should not be stored in a graph. They applied knowledge discovery techniques (suffix trees to find the longest repeated substrings) to interpret and evaluate sensor data in buildings. According to them, the results of such algorithms should be represented in semantic graphs and linked to the linked building data to be useful for later purposes. Adeleke et al. [4] used a multilayer perceptron model to predict indoor air quality based on sensor data and encoded the results as RDF triples. They extended SSN [34] to semantically describe the predicted performance and the assessment of the observations, while other ontologies already include specific classes to do so [3,55].
Research gaps
The introduction identified that there is a need for a scalable method to measure occupant feedback and integrate this feedback with building information. This related work section describes μEMA as a method to acquire continuous occupant feedback. Semantic web technologies show potential to integrate this feedback with building information and sensor data.
Currently available technologies are promising but lack a few components to fully reach the potentials of this research domain. Various wearable applications were designed to acquire occupant feedback [28,45,47,48] or monitor occupants [35,43,59,61,75]. However, none of these applications convert their results to RDF to integrate the data with other linked data. The HumBAS Feedback Tool of Ramsauer et al. [72] is based on the RDF model, but does not provide any wearable sensors.
Multiple ontologies exist that cover occupants, their feedback and building performance evaluations (as discussed in Section 2.2). Other ontologies are able to describe systems and their observations (such as SSN/SOSA [34,46] and Brick [10]), wearables (SAREF4WEAR [23]), and buildings and their properties (BOT [74] and OPM [73]). However, an ontology that covers the full semantics of continuous occupant feedback monitoring and integration has not been found. The existing ontologies either miss concepts to semantically describe feedback [10,18,22,23,34,40,42,46,58] or are not focused on wearables and the sensor data they generate [19,33,38,64,71,80,81,88]. Table 1 summarizes some features covered by these existing works.
An overview of the existing work
An overview of the existing work
Solving those challenges will lead to the creation of occupant-centric digital twins: digital twins that integrate heterogeneous data related to the preferences, actions, and behavior of occupants with building information, enabling occupant-centric building design and operation, as described in IEA EBC annex 79 [65].
This paper presents two novel developments to solve the issues of continuous occupant feedback monitoring and integration of this feedback with other building information. First, the Occupant Feedback Ontology is designed to enable semantic integration of passive and active occupant feedback with other data in the semantic web. The following steps were taken to develop the ontology: 1. Specification. 2. Knowledge acquisition. 3. Requirements specification. 4. Building. 5. Evaluation. 6. Integration. 7. Documentation and publication. After specifying various competency questions, state-of-the-art domain ontologies were reviewed related to those questions. Performing a state-of-the-art smartwatch technology review gave insights in the possible human-machine interactions and the available sensor technologies. A literature review into post-occupancy evaluations and conversations with housing corporations and IEQ professionals were held to understand the workflow and challenges of understanding occupant satisfaction. Based on this review, classes, object properties, datatype properties, and their restrictions are developed, after which the ontology is built using Stanford Protégé 5.5.0 [63]. The evaluation of the ontology is threefold. First, various SPARQL queries were designed to show how the ontology aims to answer the various competency questions. Later, these SPARQL queries come to life in a real-world case study. Next to this, OFO was validated using the OntOlogy Pitfall Scanner! (OOPS!) [70]. Step 3, 4, and 5 follow an iterative process, where insights from the evaluation phase were fed back into the requirements specification phase. Finally, the ontology is aligned with other ontologies and documented using WIDOCO [31]. The HTML documentation is openly published online.3
A smartwatch app – Mintal – was designed to measure occupant feedback continuously. The clock face app is designed for Fitbit OS 5 devices using Fitbit Studio and the Fitbit OS Simulator. Fitbit Studio allows developers to swiftly develop an app using JavaScript, CSS, and SVG. Many lessons were learned from Fitbit’s Application Architecture Guide4
A case study is performed to test the app’s functionality in a real-world scenario and to answer the competency questions. A BIM model of an apartment building – the OpenFlat – was created using Revit 2020 and converted to RDF Turtle using the IFC-to-LBD converter [13], after which the output was manually extended with the BOP [22] and BOT [74] ontologies. The full conversion procedure has been explained in earlier work [22]. Both the linked building data and the BIM model of the apartment are published online.5

Experimental setup to integrate occupant feedback with linked building data.
There’s a growing interest in building performance; however, facility managers lack methods to use POE results in their decision-making. We, therefore, identified the demand for an ontology that can integrate occupant feedback with other building information. Based on this demand and the practical use cases found in the literature, we set up the following seven competency questions for this ontology:
The Occupant Feedback Ontology aims to semantically describe passive and active occupant feedback and to enable integration of this feedback with linked building data. The ambition to create a scalable concept for mass implementation introduces multiple requirements. The feedback process should be quick and painless to prevent survey fatigue.
Therefore, the Occupant Feedback Ontology should introduce various patterns for inferencing so that the digital twin can describe a rich occupant profile and context with limited input data. As there is no standard method to acquire occupant feedback, OFO should not impose a particular method of semantically describing the feedback results on the data modeler. Simultaneously, OFO should be able to semantically describe multiple types of feedback, including simple votes stored in the graph [78], longitudinal feedback in external time-series databases [47], or documents.
OFO is documented at
To enable seamless data integration with building information, OFO follows the high-level structure of the Building Performance Ontology (BOP) [21,22]. Therefore, the color convention in Fig. 3 and Table 2 follows the color convention of BOP. OFO’s classes and object properties are aligned with BOP in an alignment module available at OFO’s HTML documentation. This alignment allows simultaneous querying of sensor measurements and occupant feedback on the same property.

An overview of the Occupant Feedback Ontology.
The ontology’s core is a block of four classes (Fig. 3). It semantically describes how an ofo:Wearable could be used to give ofo:Feedback on an ofo:Property of an ofo:FeatureOfInterest. This construct is inspired by the sensor pattern of BOP (bop:Sensor makes a bop:Observation on a bop:Property of a bop:FeatureOfInterest).
Class definitions of the Occupant Feedback Ontology
The result of an ofo:Feedback can be described in the graph itself using an ofo:Result or a literal, or as an ofo:DataPoint. The ofo:DataPoint points towards a value in an external ofo:Database, in which the feedback is stored. Depending on the use case, one of the two options might be more efficient. Similarly, (medical) data measured by the built-in smartwatch sensors can be described using an ofo:Property and can be stored in the graph or in external databases, while the graph stores the relevant metadata.
OFO follows the ideas of earlier research initiatives [22,73,85] to include multiple levels of detail describing properties. Results of type ofo:Result could therefore be linked to either ofo:Feedback, an ofo:Property, or an ofo:FeatureOfInterest. As all object properties pointing towards ofo:Result are subproperties of ofo:hasResult, one could query different types of results using only one query. Similarly, ofo:hasSimpleResult groups all datatype properties pointing towards a simple result in the form of a literal.

Snippet of the Occupant Property Taxonomy as a subclass of ofo:Property.
An ofo:Wearable could be worn by an ofo:Person, which is also the one that gives the ofo:Feedback. Both the ofo:Person and the ofo:Wearable can have an ofo:Location. In practice, the location of a wearable and the person wearing it will be similar. Ofo:Wearable has one subclass; the ofo:Smartwatch. While ofo:Smartwatch will be used most in practice, adding the more abstract notion of ofo:Wearable enables extending the ontology with other wearable IoT devices if necessary.
An ofo:Property can be part of an ofo:PropertySet. This construct allows the data modeler to group properties based on similarities or practical reasons. One could, for example, group properties related to stress and query them simultaneously.
A modular taxonomy of properties is introduced to make OFO applicable in practice. In previous work [22], we reused the qudt quantitykind ontology [37] to cover various properties. However, state-of-the-art wearables typically measure various properties related to a person, for instance, skin temperature, heart rate, and stress levels, and quantitykind does not cover the full range of properties necessary for the various use cases mentioned in Section 2. This is why the Occupant Property Taxonomy (OPT) introduces these specific properties as subclasses of ofo:Property (Fig. 4). Where possible, these specific properties are aligned to quantitykind (e.g. opt:SkinTemperature ⊑ quantitykind:Temperature). The taxonomy of properties is based on earlier work by Tekce et al. [83]. The properties can be part of property sets to enhance querying possibilities. OPT is being maintained at

Property chains in the Occupant Feedback Ontology.

Subproperties of ofo:hasSimpleProperty in OPT
OPT also includes various rdfs:subPropertyOf properties of ofo:hasSimpleProperty adding some fundamental datatype properties to describe persons, shown in Listing 1. Using these datatype properties, a data modeler could describe basic personal information as literals.
The fact that a person wears a smartwatch leads to multiple logical reasoning constructs. For example, if the smartwatch is in RoomX, the person wearing that smartwatch is also in RoomX. If the smartwatch monitors feedback, this feedback belongs to the person wearing that smartwatch. Property chains were used to model this kind of logic (Fig. 5). These property chains increase the reasoning capabilities of OFO and reduce the amount of data that needs to be captured during surveys, reducing the risk of survey fatigue. Listing 2 shows the Turtle syntax of the applied property chains. The last property chain in Listing 2 is demonstrated in Listing 18.

Property chains in OFO (Turtle syntax)
OFO is designed based on multiple existing modeling patterns, described in Section 2.2. The ontology is strongly aligned with existing ontologies, such as SOSA/SSN [34,46] and OPM [73], and has relations with SAREF4WEAR [23] and FOAF [32] as well. To overcome a heterogeneous landscape of domain ontologies and enable reuse of applications, explicit alignment modules were created for OFO to SOSA/SSN, OPM, SAREF4WEAR and FOAF. Next to this, an alignment to BOP [21] was created. All modules are available at the html documentation of OFO.
Mintal
While OFO can structure occupant feedback (and its metadata) as a graph and integrate it with linked building data, the literature identifies the need for scalable data collection methods [24,57,65]. Based on findings in the literature [45,47,48], we identified the need for a smartwatch app that can easily acquire occupant feedback and integrate it with linked building data. Based on this demand, we set various design requirements:

Mintal app architecture.
This paper presents Mintal to solve the mentioned challenges. Mintal is an easy-to-use, scalable method for longitudinal feedback collection. The smartwatch clock face is designed for Fitbit Sense and Versa 3. The next subsections will cover Mintal’s functionality and explain how the clock face app aims to satisfy the design requirements.
Mintal is a clock face app that can be opened by simply activating the Fitbit screen (Fig. 6). Simple red and green buttons allow the user to select negative or positive feedback. After clicking one of the buttons, the user will be guided to a second screen to select the property that the feedback is given to. In the current version of Mintal, these are thermal comfort, visual comfort, acoustic comfort, and air quality. After selecting the property, a final screen asks the location of the feedback. The survey can be finalized in only a few seconds by minimizing the number of screens, reducing the risk of survey fatigue (
A companion app, running on the user’s smartphone, accompanies the clock face app. After installing Mintal, an additional settings menu will appear in the Fitbit application (Fig. 7). The menu enables the user to fill in some personal data, edit the locations menu, and edit the name of the building. The companion uses this information to create a Turtle file later (
Internal processes
Once a user clicks on one of the two feedback buttons on the home screen, a feedback data variable is initiated. If available, a geolocation is added to the feedback data, which would mainly be useful for outdoor application. Every click initiates switching to a new screen using a buttonX.onclick function. New screens could be easily added, which is useful for potential future extensions of Mintal (
Each click on a feedback button stores the value of this button in the feedback data variable. Data is stored as 0 (“not comfortable”) or 1 (“comfortable”). These values can be extended or changed for future applications (
The feedback data is sent to the companion. The companion connects to an InfluxDB cloud database based on the given settings in the settings menu of the companion’s Fitbit app. This includes the name of the database URL, bucket, and organization. Secure interaction between users and data is ensured using authentication tokens. Mintal uses separate read- and write-tokens; Mintal-users only have write access and could never see the data in a database, while applications using this data – such as smart homes – would only be granted read access. The companion transforms all feedback data to InfluxDB Line Protocol so that it can be stored in the InfluxDB database. This feedback data includes location, time, various health metrics, and the given feedback (
Creating RDF metadata

Snippet of the settings menu in the companion’s Fitbit app.

Instantiation of the Occupant Feedback Ontology.
Mintal applies the OFO ontology so that the sensor data can be automatically linked to other linked data. Metadata is created, containing the person, the smartwatch, the feedback, properties, units, data points, and the database (Fig. 8). After filling in the user information in the companion’s settings menu, the companion creates an RDF Turtle representation using JavaScript string concatenation. The basic string contains the prefixes of ontologies used in this RDF file (Listing 3). Triples are created by querying the data from the settings menu and inserting this data in the string (Listing 4). String concatenation is turned off for sensors that are turned off in the settings menu.

Basic personRDF string containing prefixes

Adding a triple to the personRDF string
The promise of Mintal and OFO to enable continuous feedback monitoring and integration is validated by answering seven competency questions. To make the answers tangible, we applied the Turtle file of the OpenFlat and the Turtle file created by Mintal. These files were used to perform various queries in GraphDB that answer each competency question. The functionality of Mintal and OFO in practice has been tested by performing real tests in the OpenFlat. The following subsections show the answers to those competency questions and the case study results.
Figure 9 shows the Turtle representation of the OpenFlat. When using the same prefix, the :Kitchen node in the graph created by Mintal (Fig. 8) and the :Kitchen node in the OpenFlat graph (Fig. 9) will overlap each other so that one can traverse both graphs simultaneously. The following subsections demonstrate how the various competency questions are answered by OFO and Mintal and show how a rich knowledge graph containing building information, sensor data, and occupant feedback could be applied in practical use cases.

Turtle representation of the OpenFlat using the BOP and BOT ontologies.
Best practices suggest that sensor data could be best stored in time-series databases [26,68]. As Mintal is designed to generate large amounts of feedback, the application stores this feedback in InfluxDB. Mintal creates RDF metadata of this feedback (as explained in 5.3). Similar to querying sensor data from external databases [22], the datapoint of the feedback in InfluxDB is stored in the graph and could be queried using SPARQL. Listing 5 shows a simple SPARQL query that finds all the feedback on an ofo:Property by :JohnDoe. Listing 6 shows how the results of this query could be used to query specific feedback from InfluxDB. Those basic InfluxDB queries could be extended by using more SPARQL results, for example, by only querying feedback on thermal comfort or only querying feedback in a specific room.

Querying feedback on comfort properties and the related database

Querying time-series data based on the SPARQL results
State-of-the-art wearables are increasingly able to monitor health and well-being metrics using advanced health sensors. As there is a likely relationship between those metrics and the feeling of comfort in buildings, OFO and Mintal are designed to monitor those health metrics and capture them in the graph. The amount of sensor data that can be obtained from a wearable is highly vendor-dependent but is likely to grow in the future. That is why OPT introduced the opt:PersonalProperty class (as a subclass of ofo:Property) that describes those properties of a person, measured by an ofo:Wearable. Listing 7 shows the SPARQL query that queries the metadata of those personal properties. The construct is highly extendable; adding a new personal property to a graph would not cause problems with the SPARQL query in Listing 7 and the corresponding InfluxDB query in Listing 8.

Querying feedback on comfort properties and the related database

Querying time-series data based on the SPARQL results
This research aims to tackle the lack of feedback integration with other building information [57] by directly linking occupant feedback to linked building data. OFO introduces two methods. First, feedback can be linked with the feature of interest of this feedback. Listing 9 shows how one could query the feature of interest of given feedback. This structure could also be used to query feedback that has been specifically given on one feature of interest, such as an object or a room.

Querying the feature of interest of feedback given by John Doe
Secondly, OFO introduces the ofo:Location class that describes the location of a person or wearable giving feedback. Since the location of an occupant is highly volatile, Mintal stores the location of feedback in an InfluxDB cloud database. The ofo:Location class could be used to query the location of given feedback or all feedback given at a particular location. Listing 10 shows how the relevant metadata could be queried using SPARQL, after which one could use the results of this query as an input for a Flux query (Listing 11). The property chains in OFO enable inferring the location of an ofo:Wearable if worn by an ofo:Person. Since the queries in CQ3 are similar to those in CQ1 and CQ2, these could be easily combined to simultaneously query active feedback, passive feedback, and related building information.

Querying the location of John Doe

Querying John Doe’s location from InfluxDB based on the SPARQL results
The ofo:Person class is introduced to describe occupants that gave feedback. Section 6.3 showed how ofo:hasFeatureOfInterest links feedback to a specific feature of interest. Combining OFO with other domain ontologies, such as BOT [74], could link feedback directly to building elements. The query in Listing 12 returns all feedback given on building elements in the :Kitchen, including the person that gave this feedback. The Turtle files generated by Mintal include an ofo:Person, their ofo:Feedback, and a corresponding ofo:FeatureOfInterest.

Querying feedback on an FOI and the person who gave that feedback
Various use cases require the ability to query feedback given in a specific period. Time could be stored in multiple ways, such as in the graph (as a literal) or in external databases (such as a timestamp in a time-series database). OFO offers multiple options to query feedback with a specific timestamp.
Mintal stores feedback in a time-series database. Querying feedback between two timeslots should therefore be done in InfluxDB itself (Listing 13). InfluxDB enables querying data with a specific timestamp, data within a certain time range, and various other mathematical functions to specify the time of the feedback.

Querying all feedback given between
OFO, however, also enables storing feedback directly in the graph, either as RDF-based or non-RDF-based descriptions. Inspired by the OPM ontology [73], time could be linked to a property state (in this case ofo:Result) using prov:generatedAtTime. This datatype property links an ofo:Result to a literal representing time. SPARQL has several built-in functions that can be used to filter query results based on that time value. As an example, Listing 14 results all feedback given in the last three years.

Querying all feedback given between
OFO introduces an ofo:PropertySet class to group properties. Using property sets, one can query all the properties related to a specific IEQ parameter. Listing 15 shows a simple SPARQL query that queries all feedback given properties of a :ThermalComfortPropertySet. Feedback is filtered for persons located in :Room1.

Querying all feedback related to thermal comfort given by persons in :Room1
Such a SPARQL query would return the feedback on properties in the :ThermalComfortPropertySet (using Listing 17). Listing 15 does require the description of a person’s location in the graph. As Mintal stores this information in an external database, a data modeler could filter the location in the InfluxDB query. The input for this location could be a manual input (such as in Listing 17) or a result of a previous SPARQL query.
The query in Listing 15 could be further specified to only query feedback by a specific person (Listing 16). With the availability of richer graph datasets (such as HR data or agendas), data modelers could even further specify queries and, for example, query the feedback on air quality by maintenance workers that work after 5 PM. The ofo:PropertySet could be used to include sensor data or building information, to simultaneously query a building’s properties and the feedback related to those properties.

Querying all feedback related to thermal comfort given by :JohnDoe

Querying all feedback of :JohnDoe on thermal comfort in :Room1
Research suggests that health-related properties, such as skin temperature and heart rate [2,59], affect the perceived IEQ. Mintal allows the user to measure various health-related properties and automatically creates RDF metadata of those properties. Listing 7 and 8 describe how those personal properties could be queried individually. The SPARQL query in Listing 18 simultaneously queries the datapoints of this passive feedback and the active feedback given by a person. A simple query in InfluxDB (Listing 17) would return all properties, while Listing 13 would add a time filter. The last property chain axiom in Listing 2 enables querying the datapoint of the feedback results by using ofo:hasResult, without explicitly linking this to the instance of ofo:Feedback.

Querying properties of :JohnDoe and feedback on properties by :JohnDoe
A case study was conducted to validate the answers to the seven competency questions. Two solutions are presented that can lead to improved insight into an occupant’s evaluation of a building. The first solution compares objective measurements to the active occupant feedback. The queries answering CQ1, CQ3, CQ4, and CQ5 were used to find both sensor data and active feedback given by :JohnDoe on thermal comfort and air quality in the :Kitchen between 9:00 AM and 12:00 AM. Figure 10 shows how these queries enable a visual analysis of occupant feedback and possibly related sensor data.

Sensor data in the :Kitchen and feedback given by :JohnDoe.
In the second solution, objective sensor measurements are used to calculate the thermal comfort of the :Kitchen using the PMV/PPD method [5,9] and compare the results with both active and passive occupant feedback. Tartarini and Schiavon [82] built a python library that calculates the PMV/PPD using the dry-bulb temperature, mean radiant temperature (
= mean radiant temperature [°C]
= indoor surface temperature [°C]
= surface area [m2].
The indoor surface temperature of each wall was calculated using dry-bulb temperature and relative humidity (returned from the sensors), area, tilt, and the solar azimuth of walls, windows, doors, floors, and ceilings (queried from the linked building data), meteorological data (acquired via CustomWeather6
The results show the calculated PPD (Percentage of People Dissatisfied) and the feedback on thermal comfort to assess the relationship between the active feedback and the measured state of the building (CQ6). Figure 11 also shows the heart rate measured during the interaction with Mintal. This enables us to assess so-called passive feedback, such as health status, stress levels, and sleep score with active feedback (CQ7).
Based on indoor thermal comfort criteria by Loomans et al. [60], the observed thermal comfort is poor. This is likely caused by the relatively low operative temperature and low clothing levels. A rising relative humidity causes improved thermal comfort, indicated by a decline of the PPD. While the dataset is too small to find statistical significance, we can observe positive thermal feedback when the PPD drops, followed by negative thermal feedback after a rising PPD.

PPD in the :Kitchen and :JohnDoe’s thermal feedback and heart rate.
To assess the contribution of this study, this discussions section reflects on the impact that Mintal and OFO might have on current trends and challenges in the AEC sector. A few findings could be drawn based on the results of our study.
First, we conclude that the growing attention for occupant-centric buildings has not yet been extensively concretized in the domain of linked data in the AEC sector. More effort is necessary to digitize occupants’ needs and integrate occupant-related ontologies with common domain ontologies in the AEC sector. Integrating occupants and their drivers, needs, and actions with linked building data is necessary to kick-start the development of decision support tools that can help various stakeholders in occupant-centric buildings.
Secondly, the literature stated that we lack systems to acquire longitudinal occupant feedback. Based on the results of our study, we conclude that smartwatches can serve as a tool to acquire this feedback using the μEMA-method and fill this research gap. The method fulfills the requirements of multiple stakeholders. It serves the end-user, as the tool – compared to existing solutions – is faster, easier to operate, and less intrusive. It serves the data user, as the method showed to give more response than other methods [45]. Considering the projected growth of the smartwatch as a consumer gadget, implementation of the μEMA-method is expected to become cheaper and easier in the future. Finally, the tool solves various existing challenges in collecting feedback. Research demonstrated lower survey fatigue, reduced recall bias, high ecological validity [45], and little device access time and interface usage time.
Thirdly, semantic web technologies are deemed to be valuable in integrating data from heterogeneous sources. Implementing the Occupant Feedback Ontology in a smartwatch app – Mintal – resulted in direct integration of feedback with other linked building data. The case study in the Open Flat demonstrated this integration successfully. Simple SPARQL queries can return rich information, including passive and active occupant feedback, building information, and sensor data. Combining a tool for longitudinal data collection and a method for semantic data integration demonstrably fills the identified research gaps. This method can be applied to a multitude of use cases in the AEC sector, including facility management, HVAC automation, maintenance, and other post-occupancy evaluations. However, possible use cases extend beyond buildings and include complaint management in cities, measuring emotions at festivals, and issue management at manufacturing halls.
Finally, we obtain labeled time-series data by directly integrating occupant feedback with linked building data and sensor data. Every time an occupant provides feedback, the occupant produces a series of sensor data, building information, personal data, and a label: comfortable or uncomfortable. This labeled data would perfectly fit various machine learning algorithms and could lead to developments in building automation processes. More than ever, decisions could be made based on occupants’ needs, enabling truly occupant-centric decision support systems. These systems could be used in the operational phase of a building (for example operating an HVAC system based on the occupants’ feedback on IEQ parameters) or the design phase (by using the feedback on an existing building as design input for a new building).
Creating linked building data is still a manual process, which is a limitation in terms of scalability of the approach. Good IFC-to-RDF converters exist [13], but do not incorporate the custom stack of ontologies that was developed for this paper. Extending the converter to include those ontologies would highly improve scalability of the approach. Another limitation is the fact that Mintal can only be used for μEMA, while some occupant feedback might require different forms. Creating tools that convert different types of feedback to RDF would further enhance occupant-centric decision making.
Conclusion
Optimizing the indoor climate is a crucial factor in enhancing occupants’ health. The growing interest in occupant-centric building operation [65] teaches us that decisions on indoor climate should not be entirely based on models but rather on the occupants’ needs. We identified two challenges. First, it is challenging to collect occupant feedback on a large scale [57,65]. Secondly, subsequently integrating that feedback with other building information to play a role in multiple decision-making processes is a challenge [52,57]. Wearable devices are promising to acquire occupant feedback [28,45,47,48] or monitor occupants [35,43,59,61,75], however, none of the available applications convert their results to RDF. Simultaneously, semantic web technologies in the AEC domain proved to enable the integration of heterogeneous data by semantically describing systems and their observations, wearables and buildings and their properties. However, the existing ontologies miss concepts to semantically describe feedback [10,18,22,23,34,40,42,46,58] or are not focused on wearables and the sensor data they generate [19,33,38,64,71,80,81,88].
This is why we presented two developments in this paper. First, we presented the Occupant Feedback Ontology. OFO semantically describes passive and active occupant feedback and enables integration of this feedback with linked building data. By answering seven competency questions, a robust ontology was established that can be used in practice and adds academic value. OFO follows the structure of the Building Performance Ontology, enabling integration with linked building data and sensor data.
The second development of this paper is Mintal. Mintal is a clock face app that runs on Fitbit Sense and Versa 3 and allows occupants to provide quick feedback about the indoor environmental quality. Six requirements were set based on the challenges identified in the literature review. Mintal is designed to provide feedback in less than 5 seconds while collecting information about the occupant’s heart rate and other passive feedback. During this process, Mintal encodes metadata about the provided feedback in RDF Turtle format to integrate the feedback with linked building data.
OFO and Mintal were demonstrated in a case study. It shows how OFO and Mintal succeed in collecting occupant feedback and integrating this feedback with linked building data. We, therefore, believe that this method answers state-of-the-art challenges found in the literature study.
Future research should focus on applying Mintal and OFO to create occupant-centric buildings. This could be done by creating occupant-driven decision support systems, such as personal preference profiles based on occupant feedback or the automation of building systems based on the output of Mintal. Given that Mintal produces labeled time-series data, including feedback, personal data, building information, and sensor data, future research will investigate the role of Machine Learning in creating more occupant-centric buildings. Collecting data over a longer period might also lead to a better understanding of the occupants’ needs by integrating active and passive feedback, sensor data, and linked building data.
Footnotes
Acknowledgements
The authors would like to gratefully acknowledge the support from Eindhoven University Technology, KPN (TKI-HTSM 19.0162), and the Netherlands Enterprise Agency, as part of the ‘SmartTWO: Maverick Telecom Technologies as Building Blocks for Value Driven Future Societies’ project (TK|L912P06).
