Abstract
Achieving a comfortable thermal situation within buildings with an efficient use of energy remains still an open challenge for most buildings. In this regard, IoT (Internet of Things) and KDD (Knowledge Discovery in Databases) processes may be combined to address these problems, even though data analysts may feel overwhelmed by heterogeneity and volume of the data to be considered. Data analysts could benefit from an application assistant that supports them throughout the KDD process and aids them to discover which are the relevant variables for the matter at hand, or informing about relationships among relevant data. In this article, the EEPSA (Energy Efficiency Prediction Semantic Assistant) ontology which supports such an assistant is presented. The ontology is developed on the basis that a proper axiomatization shapes the set of admitted models better, and therefore, establishes the ground for a better interoperability. On the contrary, underspecification facilitates the admission of non-isomorphic models to represent the same state which hampers interoperability. This ontology is developed on top of three ODPs (Ontology Design Patterns) which include proper axioms in order to improve precedent proposals to represent features of interest and their respective qualities, as well as observations and actuations, the sensors and actuators that generate them, and the procedures used. Moreover, the ontology introduces six domain ontology modules integrated with the ODPs in such a manner that a methodical customization is facilitated.
Introduction
In the early 2000s, Klepeis et al. (2001) estimated that people used to spend around 90% of their time indoors, and this is a situation that may still hold nowadays. Thence, feeling comfortable while staying indoors is a must. Building users’ comfort can be influenced by the visual, acoustic or thermal conditions to which they may be exposed, the latter being an aspect that may end up having a significant effect. According to the ANSI/ASHRAE Standard 55-2017,1
thermal comfort can be defined as: “that condition of mind that expresses satisfaction with the thermal environment and is assessed by subjective evaluation”. Being a subjective perception, under the same thermal conditions people can experience different levels of comfort. Therefore, ensuring a thermally comfortable environment for all the users of a building is not a straightforward task.Although many times being an overlooked factor, extensive research has been conducted proving the impact of thermal comfort on humans. Haynes (2008) and Hedge and Gaygen (2010) showed the relation between indoor environment conditions and working efficiency or productivity, which have a direct effect on company revenues. Mulville et al. (2016) demonstrated that indoor environment conditions can have a significant impact on occupants comfort, morale, health and wellbeing in commercial office buildings. It is also proved by Parsons (2014) that having an uncomfortable thermal situation involves many risks including clinical diseases, health impairments, and reduced human performance and work capacity. Therefore, all this evidence reinforces the need of ensuring comfortable thermal conditions in buildings.
However, occupants’ thermal comfort is not the only concern related to buildings. According to Abergel et al. (2019), the building sector consumes more than 35% of global energy and it is responsible for nearly 40% of energy-related CO2 emissions in the EU. This is why, with a view to meeting the energy sustainability and minimize the climate change, this sector is addressed by the set of binding legislations agreed by the European Commission in the EU 2020 climate and energy package.2
Fulfilling occupants’ comfort whilst reducing energy consumption is still an unsolved problem in most buildings. Furthermore, it is important to note that certain type of buildings have specific features which may further hinder this problem. For example, tertiary buildings normally contain spaces with big dimensions which are prone to have bigger thermal inertia (Verbeke and Audenaert, 2018). This results in longer periods of time to heat up or cool down spaces and consequently, they cannot be effectively climatised with rather simple solutions like thermostat-based reactive systems. Instead, heating or cooling systems need to be activated in a specific mode in advance, in order to ensure having a comfortable thermal condition in a given time. The expansion of the Internet of Things (IoT) and Knowledge Discovery in Databases (KDD; Fayyad et al., 1996) techniques may allow to improve matters in this regard. According to Gubbi et al. (2013), the IoT facilitates the monitoring of real-world qualities and events thanks to physical things equipped with electronic components and ubiquitous intelligence that allow them to connect, interact and exchange data. This led to the massive amount of data available nowadays, which has the potential to enable new discoveries and improve decision making processes. However, this data tends to be diverse and heterogeneous. Devices from different vendors may represent data in different formats, and even when a common format is used, the internal data model schema typically varies. Moreover, data may come from disparate external sources (often referred to as exogenous data), which further aggravates the data heterogeneity situation. Furthermore, the great variety of technical data hinders the human comprehension with regards to assessing which data is relevant for the matter at hand. These circumstances definitely pose a challenge for data analysts in charge of a KDD process, which is a process that enables the extraction of useful knowledge from raw data by means of five steps: data selection, preprocessing, transformation, data mining and interpretation.
In this context, data analysts have to deal with data related to the building where energy efficiency and user thermal comfort is aimed at. Not only building structural elements need to be described, but also information about sensors and actuators deployed in the building, their location, features and certainly their measurements and actuations, among others. Under such circumstances where a deep energy efficiency, thermal comfort and building domain knowledge is required to efficiently handle all this information, having insufficient domain expertise could make data analysts feel overwhelmed. Consequently, they typically resort to a trial-and-error approach searching for variables and tasks that could be confidently used to make accurate predictions. Moreover, due to the plethora of possible combination of algorithms in each KDD phase, according to Bernstein et al. (2005), even expert data analysts may turn to this trial-and-error approach.
This is definitely an undesirable approach and it would be much more profitable to count with a KDD process assistant supported by technologies that enable the management of data semantics, data interrelationships, and knowledge representation. This means it is necessary to represent features of interest and their respective qualities, as well as observations and actuations, the sensors and actuators that generate them, and the procedures used. Furthermore, observations and actuations have to be described with respect to their values, in addition to their spatial and temporal context. Additionally, the specialization of these concepts for the domain in which the assistant is framed needs to be conveyed. In this paper, the development of a core ontology that supports such a KDD assistant is described.
The rest of this article is structured as follows. Section 2 reviews ontologies related to the domain of discourse. Section 3 presents the development of the proposed core ontology. Section 4 shows the usefulness of the ontology by applying it in a real-world use case. Finally, the conclusions of this work are shown in Section 5.
Linking or mapping raw data to existing ontologies or vocabularies, allows a better representation of the data, structuring it and setting formal types, relations, properties, and restrictions that hold among them. In addition, as stated by Noy (2004), it allows representing data coming from multiple sources in a unified way, thereby supporting data integration. Another benefit of the semantic annotation lies in the additional background knowledge about a domain that can be added to the dataset (Paulheim and Fümkranz, 2012; Liao et al., 2015). This leads to the enrichment of the dataset, as well as enabling the application of indexing techniques, which are based on resource URIs and ensure the retrieval and navigation through related resources (Andrews et al., 2012). Last but not least, after a semantic annotation process, data is more domain-oriented than the original source and allows more application-independent solutions. Consequently, there is no need for the user to be aware of raw data’s underlying structure.
Due to the aforementioned benefits, Yoon et al. (1999), Kopanas et al. (2002) and Pinto and Santos (2009) state that annotating data semantically can contribute to improving the KDD process. However, the semantic annotation process relies on adequate ontologies to unlock the aforementioned benefits. A comprehensive comparative review of ontologies involved in conceptualizations of observations and actuations with a special focus of the building domain is described in Esnaola-Gonzalez et al. (2020). Next, a brief overview of the most relevant ontologies is presented.
The initial Semantic Sensor Network (SSNO) ontology3
The W3C Spatial Data on the Web Working Group (SDWWG9
The SEAS Ontology14
The Observation ODP19
The IoT Application Profile (IoT-AP) ontology20
The ifcOWL ontology22
The Building Topology Ontology25
The DogOnt ontology27
Each of the aforementioned ontologies focuses on a limited domain interest, either observations, actuations or buildings. However, these domains cover only a portion of the scope of a KDD process assistant. To the extent of the authors’ knowledge, at the moment of writing this article there is no ontology covering all the subjects of knowledge required to sustain such an assistant.
Towards the incorporation of the semantic technologies in the assistant that supports data analysts through the KDD process, it is of utmost importance to rely on proper ontologies and vocabularies that codify the required knowledge and enables a proper annotation of the data. As a matter of fact, such an ontology or network of ontologies may be the cornerstone of this assistant (Esnaola-Gonzalez et al., 2018a).
This section describes the EEPSA (Energy Efficiency Prediction Semantic Assistant) ontology28
Data analysts dealing with energy efficiency and thermal comfort problems in buildings need to handle data from various domains and with different granularity levels. This data may describe building structural element properties including materials, heat transfer coefficients, and orientation of their boundaries. For example, a room located in the second floor of a building having a skylight with 2 m2 of surface, and a door with a U-factor of 2.61 that is opened by swinging to the left, and connects the hall with the southern outside part of the building. Furthermore, data analysts need to consider information about sensors and actuators deployed in the building, their location, features and certainly their measurements and actuations. For example, a temperature sensor located in the meeting room 042 that measured 22°C on 13th February 2020 at 09:40, and a blind actuator that lowered blinds of window 23 on 21st June 2019 at 15:30. Likewise, data about weather conditions and weather forecasts for the building location are relevant, such as a forecast for Madrid made by the Spanish meteorology agency on 12th May 2020 at 13:00 forecasting a relative humidity of 62% on 10th May 2020 at 15:00, or a weather report that described cloudy skies during the morning of 7th November 2019 in Amsterdam. Additionally, energy consumption and generation data needs to be addressed, such as the domestic hot water consumption of the apartment 7A on 15th October 2019, or the energy generated by the PV panels installed in the roof of an office during the 25th June 2020. Even more, thermal knowledge may be of utmost importance, for example, that the temperature of a given room which is poorly insulated will be heavily affected by the outdoor temperature, indoor humidity and the solar radiation received. Other sources of information may also be pertinent including the space occupancy, work schedule or human related organization. For example, the 30th January 2020 is a reduced working hours day or the occupancy value of the meeting room 07 at 12:00 is of 6 people.
Data analysts may also benefit from resources that help them identifying the most relevant variables of the KDD problems they are trying to solve. For example, knowing the variables that influence a given waiting room of a hospital such as its volume, the number of seats available and its comfort. Furthermore, it would definitely be helpful to know that the comfort level of a hospital’s waiting room is affected by, on the one hand, it’s sound level which is affected by the walls soundproofing and by the external noise levels, which in turn will be affected by the nearby traffic density, and on the other, its temperature affected by the indoor humidity levels, the solar radiation and the occupancy level. In addition, data analysts could take advantage of resources that facilitate the exploration of information related to the devices deployed in the waiting room and the past events as well as the scheduled events.
All this evidence reinforces the need of a core ontology that covers all the aspects involved in energy efficiency and thermal comfort problems in buildings. To the extent of the authors’ knowledge, at the moment of writing this article there is no ontology covering all the aforementioned subjects of knowledge, therefore, the development of the EEPSA ontology is a prime task, not only for semantic representation purposes, but more importantly, for supporting data analysts in KDD processes.
Ontology development methodology
Ontologies must be carefully designed and implemented, as these tasks have a direct impact on their final quality. Therefore, the use of well-founded ontology development methodologies (e.g. On-To-Knowledge presented by Sure et al. (2004) and DILIGENT presented by Pinto et al. (2004)) is advised. For the development of the EEPSA ontology, the NeOn Methodology proposed by Suárez-Figueroa et al. (2012) was followed mainly because it does not prescribe a rigid workflow but instead it suggests a variety of paths. The NeOn Methodology comprises 9 scenarios supporting different aspects of the ontology development process, and the following scenarios inspired the development of the EEPSA ontology:
Scenario 1: From specification to implementation. In this scenario, the ORSD (Ontology Requirement Specification Document (Suárez-Figueroa and Gómez-Pérez, 2012)) was created, which collected the ontology purpose, its intended users, and the set of ontology requirements in the form of Competency Questions (CQ). For building and maintaining the ontology, the Protégé29
Scenario 7: Reusing ontology design patterns. In this scenario, existing ODPs were reviewed (e.g. from the ODP repository OntologyDesignPatterns.org30
Scenario 3: Reusing ontological resources. According to Simperl (2009) the reuse of ontological resources built by others that have already reached some degree of consensus is a good practice in ontology development processes. In this scenario, a set of ontologies were reviewed, assessed and compared to decide whether they were suitable for reuse.
Scenario 4: Reusing and re-engineering ontological resources. Following with the review of ontological resources made for the Scenario 3, in this scenario, the ones that were unsuitable to be reused as-they-were, were re-engineered prior to their reuse to satisfy the requirements identified.
One of the main components of the ORSD is the identification of functional requirements. These are content specific requirements that the ontology should fulfil, or in other words, the particular knowledge to be represented by the ontology. Towards such a goal, a group of data analysts (who are the primary final users of the ontology) were interviewed in order to identify the initial set of ontology requirements. Furthermore, thermal and energy domain experts were interviewed to elicit and formalize their knowledge and satisfy the requirements identified. The acquisition of these CQs was approached with a top-down strategy, identifying complex questions first that were later on decomposed in simpler ones. This approach derived in the identification of the following set of recurrent CQs that summarize basic requirements for assisting data analysts through a KDD process:
CQ01: Which are the qualities that influence a feature of interest?
CQ02: Which are the qualities that affect a given quality of a feature of interest?
CQ03: Which feature of interest does a given quality belong to?
CQ04: Which are the observations/actuations performed by a given procedure?
CQ05: Which are the observations/actuations performed by a given sensor/actuator?
CQ06: Which are the procedures implemented by a given sensor/actuator?
CQ07: Which are the features of interest on a given observation/actuation?
CQ08: Which are the qualities sensed/actuated by a given observations/actuations?
CQ09: Which are the features of interest of a given sensor/actuator?
CQ10: Which are the qualities sensed/actuated by a given sensor/actuator?
CQ11: Which is the value of an observation?
CQ12: When was an actuation generated?
CQ13: For what time interval or instant is valid an observation?
CQ14: For what spatial location is valid an observation?
For each competency question CQn, a twin competency question CQni can be considered, which consists in rephrasing the question in the opposite direction. For example, CQ01i would be defined as “Which are the features of interest influenced by a given quality?”. In terms of a SPARQL query, it means that the query variable is moved from the subject position to the object position, or the other way round, in the triple pattern.
Apart from these 14 basic CQs, 53 additional CQs were identified. The final 67 CQs were validated by a review performed by final users (data analysts) and domain experts, as suggested by Wieringa (1996). Although it was confirmed that this group of users was not aware of additional requirements, the EEPSA ontology is designed to be extended with additional knowledge from different experts to satisfy new use cases that may appear.
Developing the EEPSA ontology on top of ODPs
In ontology development processes, recurrent design problems may arise. Indeed, these problems may happen during the ontology conceptualization activity, the ontology formalization activity, or during the ontology implementation activity. Gangemi and Presutti (2009) defines an ODP as a modelling solution to solve this kind of problems. Furthermore, according to Hitzler et al. (2016), ODPs should ideally be extensible but self-contained, minimize ontological commitments to foster reuse, address one or more explicit requirements (such as use cases or competency questions), be associatable to an ontology unit test (Vrandečić and Gangemi, 2006), be the representation of a core notion in a domain of expertise (Gangemi and Presutti, 2010), be alignable to other patterns, span more than one application area or domain, address a single invariant instead of targeting multiple reoccurring issues at the same time, follow established modelling best practices, and so forth.
Developing the EEPSA ontology on top of ODPs was found convenient due to the great flexibility provided by this modelling solution, which allows a proper segmentation of the intended conceptualization. In this case, the considered recurrent CQs that summarize the basic requirements were divided in three subsets according to the subject of knowledge they covered: {CQ01, CQ02, CQ03}, {CQ04, CQ05, CQ06, CQ07, CQ08, CQ09, CQ10} and {CQ11, CQ12, CQ13, CQ14}.31
The rest of the CQs considered were satisfied by developing ontology modules as explained in Section 3.5.
Even though these ODPs are motivated by energy efficiency and thermal comfort problems in buildings, they are designed to be applicable to similar problems in different use cases. Therefore, for each ODP a set of alignments or mappings are developed. These alignments target domain ontologies as well as upper-level ontologies, as setting mappings to a common upper ontology alleviates integration problems (Noy, 2004), helps to ensure clarity in modelling and avoids errors that have unintended reasoning implications (Cox, 2016). These alignments are kept in separate files and are available online in each ODP’s documentation page. Furthermore, an instantiation example of each ODP is shown in the Appendix, along with SPARQL queries that solve some CQs.
Next, the three proposed ODPs are presented: the AffectedBy ODP,32
Data analysts dealing with energy efficiency problems in buildings would benefit from a resource that supports the discovery of relevant variables that affect the environment of a given space or another feature of interest. Any of these variables will be represented as qualities of a feature of interest. Specifically, the competency questions CQ01, CQ02 and CQ03 must be considered. Therefore, the conceptualization must include classes representing features of interest (aff:FeatureOfInterest) and their qualities (aff:Quality).
In the context of this article, the notion of a feature of interest can be understood as anything of a domain of discourse which is relevant to be modelled for analysing it. It may be a physical or an abstract thing, real or imaginary, a social convention or an invented concept. Typically, the analysis of a feature of interest is based on the qualities that describe aspects of its form or state, its content or context, its flow or dynamics. The appropriate representation and modelling of these qualities is relevant for supporting the analysis of features of interest. Furthermore, it is interesting to represent not only the association of qualities with features of interest, but also the relationships among qualities, possibly from different features of interest, or with pertinent contextual information.
As for the qualities, they can be considered basic entities which are qualifiable, quantifiable, observable, or operable. According to Masolo et al. (2003) where the DOLCE documentation was presented: “Qualities inhere to entities: every entity (including qualities themselves) comes with certain qualities, which exist as long as the entity exists. Within a certain ontology, we assume that these qualities belong to a finite set of quality types (like color, size, smell, etc., […]), and are characteristic for (inhere in) specific individuals: no two particulars can have the same quality, and each quality is specifically constantly dependent on the entity it inheres in: at any time, a quality can’t be present unless the entity it inheres in is also present”.
The SOSA/SSN ontology contains a building block that may be useful for this matter. As a matter of fact, the ssn:Property class is textually defined as “a quality of an entity. An aspect of an entity that is intrinsic to and cannot exist without the entity”, which comes directly from its predecessor the SSNO ontology that inherited it from DOLCE. Furthermore, the ssn:Property class is linked to the sosa:FeatureOfInterest class with the ssn:isPropertyOf object property. However, an inconvenience was spotted. This object property is not declared functional, so the following triples (graphically shown in Fig. 1) can be found in a triple set annotated with SOSA/SSN terms:
A SOSA/SSN annotated set of triples where the sensor observing temperature of room03 cannot be precisely found.
According to the aforementioned ssn:Property’s class textual definition, individual :temperature is intrinsic to and cannot exist without the existence of individual :room03. However, the triples shown contradict such definition because the individual :temperature represents a generic quality, that is, it is a quality of different entities. It is not possible to answer the query “Which sensor observes temperature of :room03?” precisely. It can be argued that more triples should be added concerning the observations that relate sensors and rooms. However, that could not be enough, as will be shown later in Section 3.4.2. As a matter of fact, García-Castro et al. (2020) verified that many datasets adopted the use of generic qualities. Moreover, it should be noted that such a representation may conceal conceptual disagreements if proper attention to conceptualization is neglected. For example, a cooling system may have three qualities of different nature: inlet air temperature, outlet air temperature and coolant temperature. The faithfulness to the DOLCE conceptualization requires that there should exist three different individuals representing the three different specific qualities, respectively. A recent publication about the SOSA/SSN ontology (Haller et al., 2019) is aware of this duality (generic, specific) and explicitly expresses that “multiple observations across different features of interest or by different sensors or both can measure the same generic property”. The publication also recognizes the choice to represent observable properties as inherent characteristics specific to a feature of interest. Therefore, the SOSA/SSN ontology allows different ways of modelling observable properties and it is expected that “communities and applications to develop their own approaches to building catalogues of observable properties and choosing appropriate levels of specificity”. However, the fact that different stakeholders adopt different modelling options may derive in interoperability problems. Frequently, the option of using generic qualities is promoted due to its simplicity that encourages reusability, but underspecification worsens the interoperability. According to Guarino et al. (2009), widening the set of admitted models goes against precisely approximate the set of intended models. In this case, the SOSA/SSN ontology admits different models to represent the same state of affairs but these models are not isomorphic, since one of them can be transformed into the other but the inverse transformation is not always possible. As a consequence, some questions can be correctly answered with one model but not with the other (as will be shown later in Section 3.4.2).
The AffectedBy ODP defines the aff:belongsTo object property as functional to support the notion that a quality is intrinsic to the feature of interest to which it belongs (inheres in). It is defined with aff:Quality as domain and aff:FeatureOfInterest as range, and it solves CQ03. Furthermore, the following axiom formalizes that every quality belongs to a feature of interest:
aff:Quality ⊑ ∃aff:belongsTo.aff:FeatureOfInterest .
In order to tackle this specific issue and to solve CQ02, the aff:affectedBy object property is introduced. This property has class aff:Quality both as its domain and its range, and it is declared to be transitive. Notice that no similar object property exists in the SOSA/SSN ontology.
Then, in order to solve CQ01, the aff:influencedBy35
In the previous version of the AffectedBy ODP published in Esnaola-Gonzalez et al. (2018b), this object property was named aff:hasQuality. However, it was renamed after aff:influencedBy to avoid misleading interpretations.
aff:belongsTo−1 ⊑ aff:influencedBy, and
aff:influencedBy ∘ aff:affectedBy ⊑ aff:influencedBy .
It is worth noticing that, with the presented axiomatization of the AffectedBy ODP, only basic assertions using aff:belongsTo and aff:affectedBy are initially needed since the rest of true facts are inferred by OWL2 DL reasoners.
The AffectedBy ODP. (F) represents functional and (T) transitive properties.
A diagram of the AffectedBy ODP is shown in Fig. 2.
The SEAS Feature of Interest ontology presents a similar design to AffectedBy ODP. The seas:isPropertyOf object property links a seas:Property to a seas:FeatureOfInterest and it is declared functional. However, the property seas:hasProperty (inverse of seas:isPropertyOf) does not play the role of aff:influencedBy. Moreover, it also defines a symmetric object property seas:derivesFrom which links a seas:Property to another seas:Property it derives from, whose conceptualization is different from the aff:affectedBy object property. As a matter fact, the AffectedBy ODP and the SEAS Feature of Interest ontology could be defined as extensions of each other.
AffectedBy ODP alignments. The AffectedBy ODP is aligned with the SOSA/SSN ontology and the SEAS Feature of Interest ontology. Furthermore, it is mapped with the upper-level DUL ontology. These alignments are kept in separate files and are available online in the AffectedBy ODP’s documentation page
Another interesting information for data analysts working on energy efficiency and thermal comfort problems in buildings is addressed by CQ04, CQ05, CQ06, CQ07, CQ08, CQ09 and CQ10. These CQs are the requirements considered for the EEP ODP.
A SOSA/SSN annotated set of triples.
It may be questionable why competency questions related to results of observations or actuations are disregarded in this ODP, specially because it is common to include this information as parameters of observations or actuations. However, there are some modelling alternatives such as the SEAS Evaluation ontology, where the qualification of the value of a seas:Property is preferred. Moreover, different conceptualizations of the result and their spatio-temporal context may be conceived depending on the application. This is the rationale behind designing a separate ODP (presented in the next subsection) to represent result-related matters. Such a design intends to improve the reusability of the proposal, allowing users to easily replace such ODP if they are not satisfied with its modelling decision.
The aforementioned CQs (CQ04 to CQ10) have been tackled by the SOSA/SSN ontology. However, the following (typical) set of triples annotated with SOSA/SSN (graphically shown in Fig. 3) cannot properly solve a question like CQ10i: which is the sensor that observes the temperature of :room07?
The following query could try to answer the previous question, but the received answer is imprecise.
The rationale behind this issue is that the property path linking sensors to features of interest (through the sosa:Observation class) is not sufficiently constrained and therefore, there are admitted models which are not useful to answer some queries. Underspecification impedes enough discrimination of situations.
The proposed Execution-Executor-Procedure (EEP) ODP is an adaptation of the PEP ontology to fully satisfy the required competency questions, overcoming the indicated weaknesses about SOSA/SSN. Again, a careful axiomatization has been provided that permits to infer desirable property values from a minimum set of triple assertions, in contrast to other proposals where the lack of inferencing possibilities oblige to assert the complete set of needed triples.
The EEP ODP imports the AffectedBy ODP alongside with its notion that a quality is intrinsic to the feature of interest it belongs to. Apart from the two classes imported from the AffectedBy ODP (i.e. aff:FeatureOfInterest and aff:Quality), the EEP ODP consists of three more classes: eep:Execution, eep:Executor, and eep:Procedure (see Fig. 4). An individual of eep:Execution is an event upon a quality of a feature of interest, produced by an agent by performing a procedure. As for an individual of eep:Executor, it is an agent capable of performing tasks by following procedures. Lastly, an individual of eep:Procedure is a description of some actions to be executed by agents.
The Execution-Executor-Procedure (EEP) ODP. (F) represents functional and (T) transitive properties.
Note that individuals of class eep:Execution can be abstractly represented by a ternary relationship of its executor, the procedure used to produce the execution, and the quality of the feature of interest being considered. Accordingly, the class eep:Execution is the domain of the three functional object properties: eep:madeBy, eep:usedProcedure, and eep:onQuality. Moreover the following axioms are introduced:
eep:Execution ⊑ ∃eep:madeBy.epp:Executor,
eep:Execution ⊑ ∃eep:onQuality.eep:Quality, and
eep:Execution ⊑ ∃eep:usedProcedure.eep:Procedure
The object property eep:madeBy links an execution to the agent that performs the action; the object property eep:usedProcedure links an execution to the procedure that describes the task to be performed; and the object property eep:onQuality links an execution to the quality concerned by the execution. These three functional object properties jointly with the functional aff:belongsTo form the backbone of the EEP ODP.
The remaining object properties are: eep:implements, linking executors to procedures; eep:hasFeatureOfInterest, linking executions to features of interest; eep:forQuality, linking executors to qualities; and eep:forFeatureOfInterest, linking executors to features of interest. The values of all of them are inferred by the values of the four functional properties that form the backbone, due to the corresponding property chain axioms included in the EEP ODP:
eep:madeBy−1 ∘ eep:usedProcedure ⊑ eep:implements,
eep:onQuality ∘ eep:belongsTo ⊑ eep:hasFeatureOfInterest,
eep:madeBy−1 ∘ eep:onQuality ⊑ eep:forQuality, and
eep:forQuality ∘ eep:belongsTo ⊑ eep:forFeatureOfInterest .
EEP ODP alignments. The EEP ODP is aligned with the SOSA/SSN ontology, the PEP ontology and PROV-O. Furthermore, it is mapped to the upper-level DUL ontology. These alignments are kept in separate files and are available online in the EEP ODP’s documentation page
Although the AffectedBy and EEP ODPs alleviate much of the data analysts’ information needs, they may still require from data representing the results of the executions and their contexts. For example: which is the value of an observation? Or when was an actuation performed? This information may be collected answering the competency questions CQ11, CQ12, CQ13 and CQ14.
Every ontology or ontology network covering observations or actuations need to take into account the representation of these actions’ results. For example, the SOSA/SSN ontology uses the sosa:hasResult object property, the IoT Application Profile (IoT-AP) ontology36
With respect to the proposed Result-Context (RC) ODP (shown in Fig. 5), the representation of both complex and simple results is modelled with the object property rc:hasResult and the datatype property rc:hasSimpleResult respectively. This way, CQ11 is solved.
The Result-Context (RC) ODP.
There are occasions in which parameters referring to temporal and spatial aspects may be necessary to qualify a result. Regarding the representation of temporal aspects, the SOSA/SSN ontology distinguishes two notions: the time when the result of an observation, actuation, or sampling applies to the feature of interest (with the object property sosa:phenomenonTime) and the instant of time when such an observation, actuation or sampling was completed (with the datatype property sosa:resultTime). The phenomenon time is specified with an individual of OWL-Time ontology’s time:TemporalEntity class as it may be either an instant, an interval of time, or even a temporal complex. Meanwhile, the result time describes an instant represented with xsd:dateTime. As for the SEAS Evaluation ontology, the temporal context is modelled with the seas:hasTemporalContext object property that links an evaluation with its temporal entity modelled as an individual of time:TemporalEntity. Furthermore, PROV-O also enables the representation of temporal context. Specifically, the prov:generatedAtTime datatype property allows representing the completion of production of a new entity, which would be similar to the sosa:resultTime datatype property.
With respect to the RC ODP, it defines two properties inspired by the design of the SOSA/SSN ontology: rc:hasGenerationTime which is equivalent to sosa:resultTime, and rc:hasTemporalContext which is equivalent to sosa:phenomenonTime. These definitions solve CQ12 and CQ13 respectively.
When using the SOSA/SSN ontology, spatial aspects of an observation/actuation/sampling are expected to be associated with the feature of interest, the sensor/actuator/sampler or the platform on which they are mounted. However, the representation of this association is not covered by the ontology itself and has to be made by deferring to external ontologies. By contrast, the SEAS Evaluation ontology leans towards a modelling option which is similar to the temporal aspect. Namely, it defines the seas:hasSpatialContext that links an evaluation to its spatial validity context represented as an individual of geo:SpatialThing class.
In the RC ODP, the rc:hasSpatialContext object property has been defined. It plays seas:hasSpatialContext property’s same role, but it has eep:Execution class as domain, and geo:SpatialThing as range. This object property solves CQ14.
The RC ODP opted to define its own URIs for these properties, in order to be self-sufficient and completely integrated with the EEP ODP, but following the good practices of the ontology engineering, the equivalences with the corresponding SOSA/SSN ontology terms are explicitly represented in the alignment files.
RC ODP alignments. The RC ODP is aligned with the SOSA/SSN and PROV-O ontologies. These alignments are kept in separate files and are available online in the RC ODP’s documentation page
The RC ODP is designed as a horizontal extension of the EEP ODP. But there are cases where data analysts may require from both ODPs so they need to be used jointly. For example:
Which is the temperature value of room 03 on 2018-11-20 at 16:00?
These three ODPs are the cornerstone of the EEPSA ontology. As a matter of fact, the classes defined by the AffectedBy and EEP ODPs act as stub classes, and for each of them an ontology module is developed. The EEPSA ontology is the integration of the following ontological resources: the three ODPs presented (AffectedBy, EEP and RC), five ontology modules specializing the stub classes defined by these ODPs (FoI4EEPSA, Q4EEPSA, P4EEPSA, EXR4EEPSA and EXN4EEPSA), and an ontology module containing expert knowledge (EK4EEPSA). Figure 6 shows an overview of the EEPSA ontology.
Overview of the EEPSA ontology.
The ontology modularization consists in partitioning them into independent self-contained knowledge components. Such a modular approach brings benefits, including the flexibility for component reuse (Grau et al., 2008), the support for more efficient query answering (Stuckenschmidt and Klein, 2007), and the enhancement of component changes and evolution (Ensan and Du, 2013).
When an already existing ontology is large and monolithic, it needs to be split up in order to benefit from the mentioned advantages. There are different techniques that perform ontology partitioning by dividing an ontology into a set of significant modules that together form the original ontology. However, according to d’Aquin et al. (2009) there is no universal way to modularize an ontology, and the choice of a particular technique or approach should be guided by the requirements of the application or use case.
The implementation of ontology modularization techniques is advised in early ontology development stages because, otherwise, it could end up being a complex task. Following this advice, the EEPSA ontology is modularized by design in order to address the remaining CQs that were not addressed by the three ODPs. The EEPSA ontology modules are presented below.
FoI4EEPSA (Feature of Interest for EEPSA) ontology module
This ontology module covers the knowledge specializing the aff:FeatureOfInterest class for the EEPSA Ontology. In the context of this article, a feature of interest is understood as an abstraction of a phenomenon (object, event, etc). A feature of interest is then described in terms of its qualities, which are qualifiable, quantifiable, observable or operable.
In particular, the FoI4EEPSA ontology module37
Which building does a given space belong to?
How many spaces does a building have?
Which storey is a given space located on?
Different ontologies that cover the representation of the building domain were reviewed (a survey can be found in Esnaola-Gonzalez et al. (2020)), and finally BOT38
As for representing building elements, which are also an important part of the domain at hand, the FoI4EEPSA ontology module needs to solve the following CQs:
Which space does a given door belong to?
How many walls does a given space have?
Is a given window adjacent-to-outdoors?
To this end, the Building Product Ontology (PRODUCT39
Last but not least, information related to the building context is also an important aspect. Namely, FoI4EEPSA has to solve the following CQs:
Which is the intended use of the building?
When was the building built?
Which is the gross floor area of the building?
IFC presents a comprehensive collection of property sets (known as PSETs) for describing different aspects of building and building-related context. However, the conceptualization of these properties in the ifcOWL ontology42
It is worth noting that, although the FoI4EEPSA ontology module is mainly focused on building-related elements, it may be extended with other features of interest such as events that may be of interest to represent. Examples of such events include meetings that may be scheduled for a given room of a building, or even the Demand Response events where customers are asked to increase or decrease their energy consumption to help electric utilities. These events should ideally be modelled by the EEPSA ontology user or, preferably, imported from other existing ontologies such as the OpenADR ontology43
This ontology module covers the knowledge specializing the aff:Quality class, which refers to qualities or aspects of a feature of interest that are intrinsic to and cannot exist without the feature of interest.
In particular, the Q4EEPSA ontology module44
Which are the actuatable qualities?
Which are the predictable qualities?
Which are the thermal comfort qualities?
In Q4EEPSA, two categories of qualities are differentiated. On the one hand, observable qualities of a feature of interest defined by the class q4eepsa:ObservableQuality. Bearing in mind the conceptualization of observation proposed by the O&M (Observations and Measurements) model described in ISO 19156:201145
Meteorological qualities such as solar radiation (q4eepsa:SolarRadiation) or cloud coverage (q4eepsa:CloudCover) are defined as subclasses of q4eepsa:MeteorologicalQuality, which are observable but not actuatable, as defined with the following axiom:
q4eepsa:MeteorologicalQuality ⊑
q4eepsa:ObservableQuality ⊓ ¬q4eepsa:ActuatableQuality .
Qualities that may have an influence on the comfort of building users such as indoor temperature (q4eepsa:IndoorTemperature) and indoor humidity (q4eepsa:IndoorHumidity) are represented as subclasses of q4eepsa:ComfortQuality. Since comfort is assessed by subjective evaluation, the same objective measurement of a given quality may be perceived in different ways by different people. For example, although a given room may have an illuminance level of 100 lux, a person may consider it too bright and another one too dark. These qualities can be observed and acted on. Furthermore, qualities related to the resource consumption derived from the building operation such as water consumption (q4eepsa:WaterConsumption) or electric generation (q4eepsa:ElectricGeneration) are also defined. These concepts are described as subclasses of q4eepsa:ResourceConsumptionQuality, which is observable. However, even though it can be indirectly acted on (for example with consumption restriction strategies), a consumption is not directly actuatable, so that it is not categorised as a subclass of q4eepsa:ActuatableQuality.
Some of the mentioned classes are reengineered and reused from the M3-lite taxonomy46
Overview of the classes defined in Q4EEPSA (visualized in Protégé).
The Q4EEPSA ontology module is aligned with related ontologies such as SAREF, the SEAS Generic Property ontology48
Figure 7 shows an overview of the main Q4EEPSA classes.
This ontology module covers the knowledge specializing the eep:Procedure class, which represents workflows, protocols, plans, algorithms, or computational methods specifying how to produce an event.
In particular, the P4EEPSA ontology module49
Which are the actuating procedures?
Which are the predictive procedures?
Which are the imputation procedures?
P4EEPSA represents four types of procedures: actuating procedures (p4eepsa:ActuatingProcedure), specifying how to act on an event; sensing procedures (p4eepsa:SensingProcedure), specifying how to sense an event; imputation procedures (p4eepsa:ImputationProcedure), specifying how to impute an event; and predictive procedures (p4eepsa:PredictiveProcedure), specifying how to predict an event. Such a procedure classification is a requirement of the data analyst assistant.
The fine-grained description of the procedures themselves are not a requisite of the EEPSA ontology, so this knowledge has to be modelled by the user, or preferably imported from other existing ontologies. With a view to easing the extension of the P4EEPSA ontology in that direction, it is aligned with the ML Schema Core Specification.50
This ontology module covers the knowledge specializing the eep:Executor class, which represents agents that produce an event by implementing a procedure.
The EXR4EEPSA ontology module 53
Which type of sensor is a given sensor?
Is a given executor a window actuator?
Is a given executor a predictive model?
EXR4EEPSA concepts are categorised in four different classes: sensors, actuators, predictive models and imputation methods. The class exr4eepsa:Sensor represents agents that implement a procedure to sense a value change in a real-world quality. Following the SOSA/SSN ontology’s conceptualization, a sensor is not necessarily a physical device; it can also be virtual, even a human being. Sensors are classified in two main classes: meters and environment sensors. On the one hand, the class exr4eepsa:UtilityMeter defines a set of meters measuring water, heat, gas or electricity consumption, as well as meters to observe the energy generated by a photovoltaic panel. On the other hand, sensors observing environment conditions (exr4eepsa:EnvironmentSensor) include anenometers (exr4eepsa:Anenometer), for sensing wind speed and humidity sensors (exr4eepsa:HumiditySensor). Furthermore, these environment sensors include the exr4eepsa:AirQualitySensor subclass comprising agents sensing air pollution and gases in the surrounding area (e.g. exr4eepsa:CO2Sensor).
The class exr4eepsa:Actuator represents agents that implement a procedure to act on a real-world quality. This concept is more general than the seas:Actuator, iot-lite:ActuatingDevice or sosa:Actuator classes since, similarly to sensors, the agent does not necessarily need to be a device or a physical element. It can be, for example, a software that switches a light bulb on or off. This class includes a set of common actuators for an energy efficiency problem in tertiary buildings, such as door actuators (exr4eepsa:DoorActuator) and window actuators (exr4eepsa:WindowActuator).
The EXR4EEPSA ontology module is not aimed at making an exhaustive representation of different types of sensors and actuators. Instead, it focuses on describing sensors and actuators that are recurrent to energy efficiency and thermal comfort problems in buildings. Furthermore, two additional high-level class of executors are defined in the EXR4EEPSA ontology module. The first one is the class exr:PredictiveModel, representing agents that implement a predictive modelling procedure to forecast unknown or future outcomes. The second one, the class exr:ImputationMethod, describes agents that implement a procedure to compute an estimation of missing values.
Some of the classes created to satisfy the identified CQs are inspired by the M3-lite taxonomy. However, they are not reused because they do not represent the same concept of sensors/actuators (e.g. M3-lite represents only physical sensors, while in the context of EXR4EEPSA sensors are not necessarily physical objects). Some other classes are reengineered and reused from the SEAS Smart Meter ontology.54
This ontology module covers the knowledge specializing the eep:Execution class. This class represents events or actions made by an agent executing a task implemented by a procedure with respect to a quality of a feature of interest.
In particular, the EXN4EEPSA ontology module55
Is a given execution an actuation?
Is a given execution an observation?
Which are the imputed observations?
To that end, this ontology module defines three main concepts: an observation (exn4eepsa:Observation), which is an execution made by an executor to estimate or calculate a value of a quality of a feature of interest; an actuation (exn4eepsa:Actuation), which is an execution made by an executor to act upon a quality of a feature of interest; and a missing value (exn4eepsa:MissingValue), which happens when executions are empty or null in attributes where a value should have been recorded. Likewise, an observation can be predicted or forecast (exn4eepsa:Forecast), obtained after using an imputation method (exn4eepsa:Imputation), or it can even be an outlier (exn4eepsa:Outlier) when it does not conform to the expected behaviour.
In addition, multiple executions can be grouped in collections, such as a sequence of missing values, or the collection of observations forecast by a predictive model. Therefore, the following CQs need to be answered:
Which are the executions of a given collection?
Which collection’s member is a given execution?
The EXN4EEPSA ontology module defines the class exn4eepsa:CollectionOfExecutions for representing a set of executions. Furthermore, object properties exn4eepsa:hasMember and its inverse exn4eepsa:isMemberOf are defined to associate individuals of class eep:Execution that belong to a collection of executions, and vice versa.
Such a detailed hierarchy of concepts is motivated by the relevance these concepts may have in data analysis problems. Furthermore, the EXN4EEPSA ontology module is aligned with a set of domain ontologies such as the SOSA/SSN ontology, the SEAS Device ontology,56
This ontology module covers the necessary expert knowledge to provide inferencing capabilities that can be exploited by the data analyst assistant. This module is defined under the supervision of experts in the domain at hand in order to capture task-based knowledge.
In particular, the EK4EEPSA57
What is a naturally enlightened space?
Which types of spaces are in a building?
Which are the qualities affecting the temperature of a badly insulated space?
On the one hand, the EK4EEPSA ontology module defines a classification of types of spaces in buildings. These space definitions are based on their structural features, such as spaces in contact with outdoor environment (ek4eepsa:AdjacentToOutdoorSpace) or spaces located below the ground floor (ek4eepsa:BelowGroundLevelSpace). However, other space definitions may be incorporated, such as the ones proposed by the HBC (Human Comfort in Building) ontology58
ek4eepsa:AdjacentToOutdoorSpace ≡
bot:Space ⊓
∃bot:hasElement.foi4eepsa:ExternalBuildingElement
On the other hand, for each space type, qualities that affect their indoor temperature are captured. Such modelling relies on qualities represented in the Q4EEPSA ontology module and the axioms defined in the AffectedBy ODP. It is worth noting that this is the only EEPSA ontology module that has dependencies with other EEPSA ontology modules. However, the data analyst assistant has a requisite that needs the ability to ask for interrelationships of entities coming from any other modules. For example, the temperature of an adjacent-to-outdoor space may be affected by qualities such as the indoor humidity, and the occupancy of the room, as represented in the following axiom:
ek4eepsa:AdjacentToOutdoorSpaceIndoorTemperature ⊑
∃aff:affectedBy.q4eepsa:IndoorHumidity ⊓ ∃ aff:affectedBy.q4eepsa:Occupancy
⊓ ∃aff:affectedBy.q4eepsa:SolarRadiation ⊓ ∃aff:affectedBy.q4eepsa:WindSpeed .
This knowledge modelling can be exploited by application programs and to support data analysts in a proper manner. After knowing which is the type of space at hand, data analysts get to know which are the qualities that are relevant to solve the energy efficiency or thermal comfort problem.
At the moment of writing this article, the EK4EEPSA ontology module solves the presented CQs. However, being an ontology module containing expert knowledge, it is extendible as more requisites are demanded.
The adequate integration of the six EEPSA modules with the three ODPs enables satisfying a set of more complex CQs such as the following:
Which are the noise qualities influencing the rooms in the first floor? Which are the qualities affecting the indoor temperature of the tribology laboratory? Which sensor measured 22°C in the meeting room 042 on 13th February 2020 at 09:40?
According to Peroni et al. (2013), a good ontology documentation increases its understandability and potential usability, both by experts in semantics and by people who are not necessarily experts. The documentation of the EEPSA ontology and its ontology modules is generated with WIDOCO (a WIzard for DOCumenting Ontologies) developed by Garijo (2017) which creates a set of linked enriched HTML pages. These HTML pages are extended with hand-made sections such as the alignments to other ontologies or with ontology usage examples.
W3C’s Data on the Web Best Practices (Calegari et al., 2017) states that providing metadata is a fundamental requirement that helps human users and computer applications to understand the data as well as other important aspects that describe a dataset. All the ontological resources presented in this article are annotated following guidelines described by Garijo and Poveda-Villalón59
Next, the canonical URIs for the different ontology modules documentation are shown. All URIs are provided by the
EEPSA ontology:
AffectedBy ODP:
EEP ODP:
RC ODP:
FoI4EEPSA ontology module:
Q4EEPSA ontology module:
P4EEPSA ontology module:
EXR4EEPSA ontology module:
EXN4EEPSA ontology module:
EK4EEPSA ontology module:
The EEPSA ontology is published in the LOV60
There are many evaluation metrics for assessing ontologies in existing literature such as Brank et al. (2005) and Obrst et al. (2007). Most of them focus on structural notions without taking into account the semantics, leading to incomparable measurement results (Vrandečić and Sure, 2007). And even though these are valid metrics, they may not be enough to determine the quality of an ontology. In order to avoid a biased evaluation, next, the EEPSA ontology and the modules that comprise it are assessed from three perspectives: design correctness, structural metrics, and modularity quality. Additionally, a testing process has been designed to verify that the EEPSA ontology and its modules satisfy their functional requirements, which were collected in the form of CQs.
Design correctness metrics
The design correctness is evaluated using OOPS! (OntOlogy Pitfall Scanner) developed in Poveda-Villalón et al. (2014), which detects some of the most common pitfalls appearing within ontology developments. OOPS! is available online63
Summary of ontology design correctness evaluation by OOPS!
Overall, most ontology modules share the same minor pitfalls “P04: Creating unconnected elements” and “P08: Missing annotations”. These pitfalls appear mainly in the stub classes that ontology modules extend (e.g. the class aff:FeatureOfInterest for the case of the FoI4EEPSA ontology module) as well for the voaf:Vocabulary class used to describe the ontology itself. These concepts are adequately annotated and connected in their source ontology module, so annotating them again would derive in having duplicated metadata when all ontology modules are imported by the EEPSA ontology. Therefore, these pitfalls are ignored.
Regarding the important pitfalls, the “P10: Missing disjointness” is repeated in all the ontology modules and ODPs. This pitfall arises when an ontology lacks from disjointness axioms between classes or between properties that should be defined as disjoint. However, in the EEPSA ontology modules case, those suggested disjointness axioms are an inconvenient conceptualization constraint, so it was decided not to add those constraints.
Structural metrics by themselves may not be enough to assess the quality of an ontology or an ontology module, but they may still be relevant to describe an ontology. Protégé has an Ontology Metrics tab64
Results show that ODPs are richer from a DL expressivity point of view. They define more constraints, while the rest of the ontology modules are more light weighted. As for the size, most of the EEPSA ontology modules are rather small (less than 17 classes). The only exceptions are the Q4EEPSA, EXR4EEPSA and EK4EEPSA ontology modules, which represent over 25 classes. The first two are in charge of representing qualities, sensors and actuators that are typical in problems addressed in the article, so it is understandable to contain a bigger number of classes. The latter, in turn, actually defines only 8 new classes. The rest of the classes are defined in other modules but are reused to describe the expert knowledge contained in the module.
Summary of ontology structural metrics by Protégé’s Ontology Metrics tab (OP = Object Properties, DP = Datatype Properties, * = Imported axioms are not considered)
The EEPSA ontology’s module quality is also assessed based on the guidelines proposed by Khan and Keet (2016). This work creates a comprehensive list of module evaluation metrics as well as a definition of 14 ontology modules types. For each ontology module type, it is described which metrics need to be measured and the expected values for a high quality ontology module. In the case of the EEPSA ontology, modules of type T1 (ODP modules: AffectedBy, EEP and RC) and T2 (Subject domain modules: FoI4EEPSA, Q4EEPSA, P4EEPSA, EXR4EEPSA, EXN4EEPSA and EK4EEPSA) are identified. The evaluation is performed with TOMM65
Regarding the ODPs, the guidelines suggest that a good quality module should have a small size compared to the original ontology size (i.e. relative size), a small cohesion (i.e. the extent to which entities in a module are related to each other), and be complete. The proposed three EEPSA ODPs satisfy the small relative size and cohesion requirements. However, EEP and RC are not logically complete, as they do not describe terms defined in other ontologies (e.g. the aff:affectedBy object property in the EEP ODP and the class eep:Execution in the RC ODP) to avoid duplicated metadata in the final EEPSA ontology.
With regards to the rest of the ontology modules, which can be classified as of type “T2-subject domain modules”, they are required to fulfil these criteria to be considered good quality modules: small cohesion, large encapsulation (i.e. “swappability” or ease to exchange a module for another without side effects), small coupling (i.e. the degree of interdependence of a module) and small redundancy (i.e. the duplication of axioms within a set of ontology modules). All the EEPSA ontology modules satisfy these criteria.
In order to verify that the EEPSA ontology satisfies the ontology requirements identified in the ORSD, a validation process has been implemented. This validation has been performed with Themis,67
For each of the EEPSA ontology modules and the ODPs, a set of tests have been designed, implemented and run to verify that the targeted CQs are adequately addressed and the desired knowledge is modelled. These tests have been represented with the Verification Test Case (VTC) ontology68
Although the EEPSA ontology is aimed at supporting data analysts in energy efficiency and thermal comfort problems in buildings, it is designed to enable its customization to support data analysts in similar problems in different types of buildings. Being modularized by design, the EEPSA ontology is expected to be easily modified. Furthermore, as it has been demonstrated that the EEPSA ontology modules are loosely coupled and have few dependencies between them, this ontology customization can be methodically approached.
The customization of the EEPSA ontology is recommended to be performed via ontology module replacement. That is, existing ontology modules should be replaced with other ontology modules, which can be new modules or extensions of existing ones. This way, the development of customized EEPSA ontologies is expected to be of bounded complexity. This ontology customization process is illustrated with a real-world poultry farm use case in Esnaola et al. (2019).
EEPSA ontology in use
The incorporation of the semantic technologies in the assistant that supports data analysts through the KDD process for energy efficiency and thermal comfort problems is presented in Esnaola-Gonzalez et al. (2018a). This assistant is based on the presented EEPSA ontology, and this section aims to show the role that the EEPSA ontology plays in this assistance. Namely, it proves that the proposed ontology is not a mere collection of classes and properties to semantically annotate data, but it is aimed at providing assistance to data analysts through the KDD process.
The capabilities of the EEPSA ontology are demonstrated in Tekniker’s headquarters, a building located in Eibar (Spain) which hosts the activities of the technological centre. Within this building, the electronics laboratory (from now on referred to as ELE lab) has been targeted, where different electronic components, systems and equipment are designed, developed, and tested. Due to the intermittent usage of the laboratory, ensuring occupants’ thermal comfort while achieving an efficient use of energy is currently an unsolved problem. Towards finding a solution to this problem, a system that proposes the optimal HVAC (Heat, Ventilation and Air Conditioning) activation strategies is sought. Such a system could rely on the assistant that supports data analysts through the KDD processes.
The first step to exploit the EEPSA ontology capabilities consists in annotating the target space, its structural elements, deployed equipment, and the rest of the relevant elements with adequate ontological terms. This semantic annotation process was manually performed by the facility manager of Tekniker, who received the guidance and assistance of an ontologist. As pointed out by Esnaola-Gonzalez et al. (2018a), in the future, this data annotation task should be facilitated with a GUI (graphical user interface) where the user could add building elements and features to the space in an intuitive and easy manner.
The building topology was represented using the FoI4EEPSA ontology module. The Tekniker building (:tekniker) was represented as an instance of the bot:Building class, its minus 2 storey (:minus2Storey) as an instance of the bot:Storey class and the ELE lab (:eleLab) located in such storey as an instance of the bot:Space class. Likewise, the structural elements including the room’s door (:door01), were modelled using the same FoI4EEPSA ontology module. As for the representation of the equipment deployed within the laboratory such as temperature sensors (:tempSen01) or submetering systems (:plug01), the EXR4EEPSA ontology module was used. Regarding the measurements registered by the different devices, the EXN4EEPSA ontology module was used, and more specifically, the exn4eepsa:Observation class. It is worth noting that observations registered by devices are stored in a PostgreSQL database, and that only a few of them were modelled for the purpose of showing the capabilities of the EEPSA ontology. As a matter of fact, as suggested by Petrova et al. (2019), sensor data should be kept out of semantic graphs for computational performance reasons.
The resulting simplified representation of the ELE lab has an ABox size of 57 triples and an excerpt is available below:
Once this semantic annotation process has been finished, a reasoner can be used to infer relevant implicit knowledge. In this case particular case, a HermiT69
ek4eepsa:BelowGroundLevelSpace ≡
bot:Space ⊓ ∃bot:hasSpace−1.foi4eepsa:UndergroundStorey .
Furthermore, since ELE lab is inferred to be an instance of class ek4eepsa:BelowGroundLevelSpace, it is also inferred to be influenced by some below ground level space indoor temperature, due to the axioms:
ek4eepsa:BelowGroundLevelSpace ⊑
∃aff:influencedBy.ek4eepsa:BelowGroundLevelSpaceTemperature .
Consequently, due to the definition of ek4eepsa:BelowGroundLevelSpaceTemperature, it is inferred that the indoor temperature of ELE lab is affected by the atmospheric pressure (q4eepsa:AtmosphericPressure), indoor humidity (q4eepsa:IndoorHumidity) and the occupancy of the room (q4eepsa:Occupancy).
ek4eepsa:BelowGroundLevelSpaceTemperature ⊑
∃aff:affectedBy.q4eepsa:AtmosphericPressure ⊓
∃aff:affectedBy.q4eepsa:IndoorHumidity ⊓
∃aff:affectedBy.q4eepsa:Occupancy .
Therefore, once the semantic representation of the ELE laboratory is performed, thanks to the expert knowledge captured in the EEPSA ontology and the execution of a reasoner, it is inferred that the ELE laboratory is a space located below ground level, and consequently, its temperature is affected by atmospheric pressure, indoor humidity, and laboratory occupancy.
The information inferred thanks to the knowledge formalized within the EEPSA ontology, makes up for the data analyst’s probable lack of knowledge for energy efficiency and thermal comfort problems in buildings. Consequently, they will no longer need to resort to the typical trial-and-error approach searching for variables and tasks that could be confidently used in a KDD process.
In this work, first of all, and following a well-known ontology development methodology, the requirements of the EEPSA ontology have been collected. Then, the backbone of the EEPSA ontology has been discussed and defined as a combination of three ODPs which try to, on the one hand, be minimal in the number of classes and properties offered but complete with respect to the considered CQs and, on the other, include appropriate ontology axioms that allow proper inferences. Moreover, the careful design of property axioms overcome some weaknesses found in existing ontologies. On top of these ODPs, a set of ontology modules were developed, each of them specializing knowledge in the scope of the stub classes defined in the ODPs and reusing existing resources as much as possible. Furthermore, in order to contribute to the interoperability of the solution, the EEPSA ODPs and ontology modules are aligned with other related ontologies as well as upper-level ontologies. All these developments are properly documented, made available online, validated and evaluated from three different viewpoints. Moreover, thanks to the modular design of the EEPSA ontology and the high encapsulation of its modules, the customization of the ontology to address similar problems in different use cases can be methodically approached.
The resulting EEPSA ontology is a core ontology developed on the basis that a proper axiomatization shapes the set of admitted models better and, therefore, establishes the ground for a better interoperability. On the contrary, underspecification facilitates the admission of non-isomorphic models to represent the same state, hampering interoperability. Furthermore, the EEPSA ontology’s objective goes beyond having a mere collection of classes and properties to semantically annotate data, as it aims at supporting a data analyst assistant in energy efficiency and thermal comfort problems in buildings. To do so, the necessary domain and expert knowledge related to data analysis procedures and tasks is adequately captured and formalized in the ontology. With a view to demonstrating this support to data analysts, the ontology has been instantiated in a real-world laboratory.
Footnotes
Acknowledgements
This work is supported by the REACT project which has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 824395. This work is also supported by PRE-2016-1-0303, IT1041-16-GBV and FEDER/TIN2016-78011-C4-2-R.
This work was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.
Application examples of the ODPs
This appendix shows an example of the presented three ODPs.