Achieving an energy e cient operation of a building is not a straightforward task. In this article, two Ontology Design Patterns (ODP) are proposed, motivated by speci c challenges that arise in this domain, and with the intention to support data analysts towards this goal. The two proposed ODPs are the A ectedBy ODP and the EEP (Execution-Executor-Procedure) ODP, which is an extension of the rst. Both of them are intended to ll the gap that existing ontologies and ODPs fail to address adequately. Furthermore, both ODPs are aligned to an upper level ontology and some other related ontologies, which makes them applicable to other domains and scenarios.
Buildings and construction account for more than 35% of global energy use and
nearly 40% of energy-related CO2 emissions [
The EEPSA (Energy E ciency Prediction Semantic Assistant) process addresses this problem taking leverage of Semantic Technologies like ontologies, ontology-driven rules and ontology-driven data access to guide data analysts through the di erent KDD phases in a semi-automatic manner, towards the enhancement of the KDD process [4]. In this process, the EEPSA ontology3 plays a vital role capturing the necessary knowledge, mainly related to buildings, sensing and actuating devices, and their corresponding observations and actuations. This knowledge, along with other relevant domain and expert knowledge for the matter at hand, is captured in well-decoupled modules and represented in a form that can support data analysts.
In this paper, two Ontology Design Patterns (ODP) are proposed: the AffectedBy ODP and the Execution-Executor-Procedure (EEP) ODP, which is an extension of the A ectedBy ODP. Both ODPs are motivated by speci c challenges that arise in problems related to energy e ciency in buildings, and they are de ned with the intention to support data analysts throughout the KDD process. These two ODPs form the core of the renewed version of the EEPSA ontology. Furthermore, both ODPs are aligned to an upper level ontology and some other related ontologies, which makes them applicable to other domains and scenarios.
The rest of this paper is structured as follows. Section 2 introduces the related work. Section 3 describes the two ODPs. Finally, the conclusions of this work are presented in section 4. 2
The energy e ciency in buildings domain spans concepts that overlap with the IoT eld such as spaces, devices, observations, procedures, properties, and units of measurements to name a few. Some ontologies have considered these issues in their universe of discourse. However, the intended broad scope of these ontologies, usually cause large and complex bodies of terminology, and sometimes introduce too speci c commitments that provoke a hard learning curve and hinder their reuse. An encouraging ontology design methodology to unlock these problems is the pattern-based ontology design. An ODP is a modelling solution to solve a recurrent ontology design problem [5]. Ideally, ODPs should be extendable 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, be the representation of a core notion in a domain of expertise, be alignable to other patterns, span more than one application area or domain, address a single invariant instead of targeting multiple reocurring issues at the same time, follow established modelling best practices, and so forth [6]. Following, a quick review of ODP-based ontologies related to sensing and actuating devices, and their context, is presented.
The DOLCE+DnS Ultralite (DUL4) ontology is a simpli cation of some parts of the DOLCE Lite-Plus library and Descriptions and Situations ontology. It is an upper-level ontology, and it de nes general terms that are common across di erent domains. Therefore, it supports a broad semantic interoperability 3 https://w3id.org/eepsa 4 http://www.ontologydesignpatterns.org/ont/dul/DUL.owl among domain-speci c ontologies by providing a common starting point for the formulation of de nitions.
The Semantic Sensor Network (SSN) ontology [7] was developed by the W3C Semantic Sensor Networks Incubator Group (SSN-XG5) and described sensors, observations and methods used for sensing among other concepts. It was aligned with the DUL ontology and built around a central ODP called Stimulus-SensorObservation [8] (SSO) describing the relationship between sensors, stimulus and observations. The W3C Spatial Data on the Web Working Group (SDWWG6) proposed an update of the SSN ontology7 that became a W3C recommendation. The new version of the SSN ontology8 follows a horizontal and vertical modularization architecture by including a lightweight but self-contained core ontology called SOSA9 (Sensor, Observation, Sample, and Actuator) for its elementary classes and properties. Furthermore, similar to the original SSO patterns, SOSA acts as a central building block for the new SSN ontology. In line with the changes implemented for the new SSN ontology, SOSA also avoids the direct DUL import that previous version had, although an optional alignment can be achieved via the SSN-DUL alignment module10.
The Actuation-Actuator-E ect11 (AAE) ODP intends to model the relationship between an Actuator and the E ect it has on its environment through Actuations. This pattern adapts the SSN ontology's SSO ODP for actuators. The new version of the SSN ontology covers the function of the AAE ODP for actuators by expanding the SSO pattern in the SOSA ontology.
The SSN ontology does not provide enough constraints to the de nitions of classes and properties to guarantee a proper answer to a question like: what is the feature of interest corresponding to a given property that has been observed by a sensor? And neither to this other question: which sensors observe a given property of a feature of interest? The patterns proposed in this paper solve these problems.
The SmartEnv ontology, proposed as a representational model to assist the development process of smart environments, is a network of 8 di erent ODPs [9]. These ODPs are used to modularize the proposed solution, while at the same time avoiding strong dependencies between the modules to manage the representational complexity of the ontology. The SmartEnv relies on the SSN ontology without introducing enough constraints to solve the aforementioned weaknesses of the SSN ontology.
The SEAS Ontology[10] is an ontology designed as a set of simple core ODPs that can be instantiated for multiple engineering related verticals. It is planned 5 https://www.w3.org/2005/Incubator/ssn/ 6 http://www.opengeospatial.org/projects/groups/sdwwg 7 https://www.w3.org/TR/vocab-ssn/ 8 http://www.w3.org/ns/ssn/ 9 http://www.w3.org/ns/sosa/ 10 http://www.w3.org/ns/ssn/dul 11 http://ontologydesignpatterns.org/wiki/Submissions:
Actuation-Actuator-Effect to be added to the SAREF (Smart Appliances REFerence) ontology12, which is expected to ease its adoption and extension by industrial stakeholders, while ensuring easy maintenance of its quality, coherence, and modularity [11]. The SEAS Feature of Interest ontology13, is one of the modules that forms the SEAS ontology, and de nes features of interest (seas:FeatureOfInterest ) and properties (seas:Property). The Procedure Execution ontology14 (PEP) de nes procedure executors that implement procedure methods, and generate procedure execution activities. Furthermore, PEP de nes an ODP as a generalization of SOSA's sensor-procedure-observation and actuator-procedure-actuation models. The patterns proposed in this paper are a reengineering of the PEP and the FeatureOfInterest ontologies and, additionally, an integration of them into a single ODP.
The Observation15 ODP aims at representing observations of things, under a set of parameters. This set of parameters may include the place where the observation was made, the time when it was made, and any other feature concerning the speci c thing being observed.
The IoT Application Pro le (IoT-AP) ontology, is an ontology for representing and modelling the knowledge within the domain of the IoT [12]. The ontology is designed re-using ODPs such as the aforementioned Observation ODP. It focuses in observations, but it also covers sensors that make those observations, values of those observations and observation collections. However, this ontology su ers from similar weaknesses to those previously commented about the SSN ontology. This is basically due to the lack of proper constraints on property de nitions.
The ODP repository16 collects and makes ODPs available on the web, allowing users to download, propose, and discuss them. Some of the mentioned ODPs are hosted in this repository. 3
The EEPSA ontology supports data analysts that are not experts in the energy e ciency in tertiary buildings domain, towards the creation of enhanced predictive models. For that purpose, the ontology not only needs to contain both domain knowledge and expert knowledge, but also needs to represent it in a way that can be leveraged to guide data analysts throughout the KDD process.
In energy e ciency problems related to tertiary buildings domain, two recurrent modelling challenges arise. The rst one is related to modelling variables that may a ect an indoor condition such as indoor temperature or occupancy. The second one is related to modelling the variables measured within a building and the systems to measure them. The de nition of ODPs for these problems 12 https://w3id.org/saref 13 https://ci.mines-stetienne.fr/seas/FeatureOfInterestOntology 14 https://ci.mines-stetienne.fr/pep/ 15 http://ontologydesignpatterns.org/wiki/Submissions:Observation 16 http://www.ontologydesignpatterns.org would be bene cial and could ideally act as building blocks to be reused in case someone else faces these same modelling challenges. 3.1
In the rst phase of a typical KDD process, known as the Data Selection phase, the EEPSA process supports data analysts selecting datasets and subset of variables or data samples that are relevant for the matter at hand. Taking into account that data analysts may not be experts in the energy e ciency in tertiary buildings domain, they may feel overwhelmed during this task, due to their lack of expertise in choosing the adequate variables. Therefore, they would bene t from a resource that supports the discovery of relevant variables that a ect the environment of a given space or another feature of interest. Any of these variables will be represented as properties or qualities of a feature of interest.
For example, let us consider the LR03 lecture room as a feature of interest: a lecture room located on the ground oor of a building, and with a large window that overlooks the road that passes near the building. Some properties of LR03 are: the area of the lecture room, the number of seats available or the quality of comfort at any given time. The quality of comfort in this lecture room is a ected by the room temperature and the nearby outdoor noise. In turn, the temperature of LR03 is a ected by the number of people present in the lecture room, the humidity of the lecture room, and the intensity of solar radiation received through the room window. Regarding the impact of outdoor noise, it is a ected by the sound insulation factor of the room. Lastly, the received solar radiation is a ected by the azimuth (i.e. orientation) of the lecture room window.
The following competency questions must be considered: { CQ1: What are the properties/qualities of a feature of interest? { CQ2: What are the properties/qualities that a ect a given property of a feature of interest? { CQ3: Which feature of interest does a given property/quality belongs to?
The SSN Ontology contains a building block that may be useful for this matter. However, an inadequacy was spotted. The ssn:Property class is textually de ned as \a quality of an entity. An aspect of an entity that is intrinsic to and cannot exist without the entity". This de nition is made basically, according to the de nition of the dul:Quality class. In fact, it is declared17 that ssn:Property rdfs:subClassOf dul:Quality. Furthermore, the ssn:Property class is linked to the ssn:FeatureOfInterest class with the ssn:isPropertyOf object property. Nevertheless, this object property is not functional, meaning that the ssn:isPropertyOf property can have more than one value for the same individual, so the following triples can be found in a ssn-annotated triple set: :temperature rdf:type ssn:Property.
:temperature ssn:isPropertyOf :lr03. 17 https://www.w3.org/TR/vocab-ssn :lr03 rdf:type ssn:FeatureOfInterest. :temperature ssn:isPropertyOf :lr07. :lr07 rdf:type ssn:FeatureOfInterest. :lr03 owl:differentFrom :lr07.
According to the aforementioned ssn:Property 's class textual de nition, individual :temperature is intrinsic to and cannot exist without the existence of individual :lr03. However, the triples shown contradict such de nition (i.e., :temperature is a quality of di erent entities). Probably, designers of the SSN ontology would advise against this practice and, in fact, example \B.3 apartment 134"18 uses the URI <apartment/134/electricConsumption> for referring to an individual that represents the electrical consumption of the apartment #134. However, the identi cation of the feature of interest (i.e., apartment #134) of this property is embedded in the URI and this is not enough for machine interpretation. Of course, two di erent rooms may have the same temperature value (e.g. 15 C) but such circumstance would be represented as a property value of each di erent temperature instances. Moreover, a suitable hierarchy of Property subclasses may be desirable. A class Temperature would be a subclass of class Property. Therefore, it could be possible to ask for all the features of interest that have a temperature quality.
The issue mentioned above is tackled in the SEAS Feature of Interest ontology, where an ODP to describe features of interest and their properties is de ned. In this pattern, the seas:isPropertyOf object property links a seas:Property to a seas:FeatureOfInterest, and it is declared as subproperty of ssn:isPropertyOf. However, seas:isPropertyOf is functional. Therefore, it represents more faithfully the textual de nition of ssn:Property.
Furthermore, the SEAS Feature of Interest ontology also de nes the seas:derivesFrom object property which links a seas:Property to another seas:Property it derives from. This object property is de ned as a symmetric property, which means that the property has itself as inverse. However, this constraint is unnecessary and sometimes even inappropriate. For instance, the temperature of individual :lr03 may derive from the occupancy of the room, but the occupancy does not necessarily derive from the temperature of the room.
In addition, the SEAS Feature of Interest ontology contains a textual comment that, although relevant, it is not materialized as an axiom: seas:hasProperty <seas:hasProperty
seas:derivesFrom
The A ectedBy ODP is inspired by the identi ed SSN ontology and SEAS Feature of Interest ontology weaknesses. It de nes the building block shown in Figure 1, that consists of two classes: a :FeatureOfInterest and a :Quality, and three properties: a :hasQuality, a :belongsTo, and a :a ectedBy. 18 https://www.w3.org/TR/vocab-ssn/#apartment-134
Fig. 1. The A ectedBy ODP.
The property a :a ectedBy (released from the symmetric constraint) is dened in the A ectedBy ODP to replace the role of the property seas:derivesFrom. It can be asserted that seas:derivesFrom is a subproperty of a :a ectedBy. The class a :FeatureOfInterest is equivalent to seas:FeatureOfInterest, and the class seas:Property is equivalent to a :Quality. Moreover, seas:hasProperty is subproperty of a :hasQuality, and seas:isPropertyOf is subproperty of a :belongsTo. Furthermore, a :belongsTo is de ned to be functional and it is the inverse of a :hasQuality, to support the notion that a quality is intrinsic to the feature of interest (i.e., an entity) to which it belongs (according to the conceptualization in DUL); and it is also asserted that every quality belongs to a feature of interest, i.e., a :Quality rdfs:subClassOf a :belongsTo some a :FeatureOfInterest). Finally, the following property chain axiom is asserted: a :hasQuality
a :a ectedBy rdfs:subPropertyOf a :hasQuality
Even though the ODP is motivated by the energy e ciency in buildings problem, it is applicable to similar problems from di erent domains. Therefore, the A ectedBy ODP is aligned with the DUL ontology. Moreover, the A ectedBy ODP is also aligned to the SSN Ontology and the SEAS Feature of Interest ontology. The alignments with these three ontologies are kept in separate les19. 19 https://github.com/iesnaola/AffectedBy/tree/master/alignments Likewise, the HTML documentation of the ODP is available20 via LODE (Live OWL Documentation Environment [13]) and in the ODP repository21. Application. The instantiation of the A ectedBy ODP for the aforementioned LR03 lecture room is shown in Figure 2. For the sake of simplicity, the rdf:type relationships are not shown.
With respect to this example, the following competency questions can be applied and answered: { (CQ2): What are the properties that a ect the property :lr03Comfort ? SPARQL query: SELECT ?x WHERE f:lr03Comfort a :a ectedBy ?x.g Answer: :lr03Temperature, :lr03OutdoorNoise. { (CQ2): What are the properties that a ect the property :lr03Temperature? SPARQL query: SELECT ?x WHERE f:lr03Temperature a :a ectedBy ?x.g Answer: :lr03Occupancy, :lr03Humidity, :lr03SolarRadiation. { (CQ1): What are the properties of the feature of interest :lr03 ? SPARQL query: SELECT ?x WHERE f:lr03 a :hasQuality ?x.g Answer: :lr03Area, :lr03NumSeats :lr03Comfort, :lr03Temperature, :lr03OutdoorNoise, :lr03Occupancy, :lr03Humidity, :lr03SolarRadiation, :lr03SoundInsulation, :lr03WindowAzimuth. (After inferences provided by the axiom a :hasQuality a :a ectedBy rdfs:subPropertyOf a :hasQuality ). { (CQ3): Which feature of interest does the property :lr03SolarRadiation belongs to?
SPARQL query: SELECT ?x WHERE f:lr03SolarRadiation a :belongsTo 20 https://w3id.org/affectedBy 21 http://ontologydesignpatterns.org/wiki/Submissions:AffectedBy ?x.g Answer: :lr03. (After inferences provided by the axioms a :hasQuality a :a ectedBy rdfs:subPropertyOf a :hasQuality and a :belongsTo inverseOf a :hasQuality). 3.2
An interesting information for data analysts could be: which are the sensors/actuators deployed in the space where the energy e ciency is aimed? And even more: which are the capabilities of those sensors/actuators? Moreover, knowing this information would let data analysts make further queries to discover sensors or actuators that observe or act on a given property of a space. More speci cally, the CQs considered are the following: { CQ1: What are the observations/actuations performed by a given procedure? { CQ2: What are the observations/actuations performed by a given sensor/actuator? { CQ3: What are the procedures implemented by a given sensor/actuator? { CQ4: What are the features of interest on a given observation/actuation? { CQ5: What are the properties/qualities sensed/actuated by a given observations/actuations? { CQ6: What are the features of interest of a given sensor/actuator? { CQ7: What are the properties/qualities sensed/actuated by a given executor?
For each competency question CQn, we can consider a twin competency question CQni which consists on rephrasing the question in the opposite direction. For instance, CQ1i is de ned as \What is the procedure used in a given observation/actuation?". 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, of the triple pattern.
These questions have been tackled by the SSN ontology with SOSA's Observation-Sensor-Procedure pattern, and by the SAN ontology with the AAE pattern. However, in their current state, they cannot properly ful l the discovery of sensors and actuators because no property has been de ned that directly links sensors or actuators to features of interest, and moreover, compositions of properties that link them through the Observation or Actuation class, are not su ciently constrained to satisfy the aforementioned competency questions. For instance, the following set of ssn-annotated triples is not enough to answer the question: which is the sensor that observes the temperature of :lr07? :sensor1 sosa:madeObservation :obs1;
sosa:observes :temperature. :temperature ssn:isPropertyOf :lr03. :obs1 sosa:hasFeatureOfInterest :lr03. :sensor2 sosa:madeObservation :obs2;
sosa:observes :temperature. :temperature ssn:isPropertyOf :lr07. :obs2 sosa:hasFeatureOfInterest :lr07. :sensor1 sosa:madeObservation :obs3;
sosa:observes :humidity. :humidity ssn:isPropertyOf :lr07. :obs3 sosa:hasFeatureOfInterest :lr07.
In order to ll this gap, the Execution-Executor-Procedure (EEP) ODP presented in this paper represents executions (e.g., events such as observations or actuations) made by executors (e.g., systems such as sensors or actuators) that implement procedures to carry out their goals. Executions and executors are taken over features of interest and their intrinsic properties or qualities.
The EEP ODP is an adaptation of the PEP ontology from the SEAS ontology which, in turn, is a generalization of the Observation-Sensor-Procedure and Actuation-Actuator-Procedure patterns used in the SOSA and SSN ontologies. The EEP ODP imports the A ectedBy ODP that involves classes for features of interest and their intrinsic properties/qualities. Furthermore, from the A ectedBy ODP, the EEP ODP imports the notion that a property/quality is intrinsic to the feature of interest that it belongs to (i.e., according to the de nition of the class Quality in the DUL ontology).
Apart from the two classes (i.e., a :FeatureOfInterest and a :Quality) imported from the A ectedBy ODP, the EEP ODP consists of three more classes: eep:Execution, eep:Executor, and eep:Procedure (see Figure 3). An individual of eep:Execution is an action related to a property of a feature of interest, produced by an agent by performing a procedure. An individual of eep:Executor is an agent capable of performing tasks by following procedures. An individual of eep:Procedure is a description of some actions to be executed by agents. The class eep:Execution and their three functional object properties eep:madeBy, eep:usedProcedure, and eep:onQuality, form the backbone of the ODP. The property eep:madeBy links an execution to the agent that performs the action; the property eep:usedProcedure links an execution to the procedure that describes the task to be performed; and the property eep:onQuality links an execution to the quality/property concerned by the execution. Therefore, an execution jointly with their three object values of the three aforementioned properties can be considered as a n-ary relationship. Note that every quality belongs to a unique feature of interest, so a feature of interest is also involved in the n-ary relationship.
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. Note that an executor can implement different procedures corresponding to di erent executions performed by the same executor. Analogously, an executor may be committed to di erent properties and features of interest. These four properties are de ned in terms of the functional
Fig. 3. The Execution-Executor-Procedure (EEP) ODP. object properties using the following property chain axioms: inverse(eep:madeBy) eep:usedProcedure rdfs:subPropertyOf eep:implements. eep:onQuality eep:belongsTo rdfs:subPropertyOf eep:hasFeatureOfInterest. inverse(eep:madeBy) eep:onQuality rdfs:subPropertyOf eep:forQuality. eep:forQuality eep:belongsTo rdfs:subPropertyOf eep:forFeatureOfInterest.
Axioms included in the EEP ODP provide inferences that allow to answer the formulated CQs properly, solving the previously referred weaknesses of the sosa/ssn ontologies. Note that only triples about the four functional object properties eep:madeBy, eep:usedProcedure, eep:onQuality, and a :belongsTo, need to be asserted, and the remaining triples are inferred by the property axioms.
Likewise the A ectedBy ODP, the EEP ODP is motivated by the energy e ciency in buildings problem but it is applicable to di erent domains. It is aligned with the DUL ontology, the SSN Ontology, and the PEP ontology. The alignments with these three ontologies are kept in separate les22. Furthermore, the HTML documentation of the ODP is available23 via LODE and in the ODP repository24. 22 https://github.com/iesnaola/EEP/tree/master/alignments 23 https://w3id.org/eep 24 http://ontologydesignpatterns.org/wiki/Submissions:EEP Application. The EEP ODP is instantiated in a farm scenario where poultry are reared. In this case, a sensor :sensor36 deployed in the farm individual :farm is in charge of measuring both farm's temperature and humidity (i.e., :farmTemperature and :farmHumidity ). Furthermore, this sensor implements a monitoring procedure (:monitoringProc) to make two observations :obs13 and :obs14. Figure 4 shows this instantiation.
With respect to this example, the following competency questions can be applied and answered: { (CQ1): What are the executions performed by procedure :monitoringProc? SPARQL query: SELECT ?x WHERE f?x eep:usedProcedure :monitoringProc.g
Answer: :obs13, :obs14. { (CQ2): What are the observations performed by sensor :sensor36 ? SPARQL query: SELECT ?x WHERE f?x eep:madeBy :sensor36.g Answer: :obs13, :obs14. { (CQ3): Which are the procedures implemented by the sensor :sensor36 ? SPARQL query: SELECT ?x WHERE f:sensor36 eep:implements ?x.g Answer: ::monitoringProc (After inferences provided by the axiom inverse(eep:madeBy) Procedure rdfs:subPropertyOf eep:implements ). eep:used{ (CQ4i): What are the executions on the feature of interest :farm? SPARQL query: SELECT ?x WHERE f?x eep:hasFeatureOfInterest :farm.g Answer: :obs13, :obs14. (After inferences provided by the axioms eep:onQuality eep:belongsTo rdfs:subPropertyOf eep:hasFeatureOfInterest and a :belongsTo inverseOf a :hasQuality ). { (CQ5): What are the qualities observed by the observation :obs13 ? SPARQL query: SELECT ?x WHERE f:obs13 eep:onQuality ?x.g Answer: :farmTemperature. { (CQ6i): What are the executors that observe/act on the feature of interest :farm? SPARQL query: SELECT ?x WHERE f?x eep:forFeatureOfInterest :farm.g Answer: :sensor36. (After inferences provided by the axioms eep:forQuality eep:belongsTo rdfs:subPropertyOf eep:forFeatureOfInterest and inverse(eep:madeBy) eep:onQuality rdfs:subPropertyOf eep:forQuality ). { (CQ7): What are the qualities observed by sensor :sensor36 ? SPARQL query: SELECT ?x WHERE f:sensor36 eep:forQuality ?x.g Answer: :farmTemperature, :farmHumidity. (After inferences provided by the axiom inverse(eep:madeBy) eep:onQuality rdfs:subPropertyOf eep:forQuality ).
The EEP ODP presented in this paper left out the temporal context, which undoubtedly is a relevant issue. In fact, EEP can be easily extended by importing di erent conceptualizations of such temporal aspect. For instance, a simple solution is to de ne a property like :atTime linking eep:Execution to :TimeInterval (like in IoT-AP ontology, or similarly in Fiesta-IoT ontology [14]), and additionally to include some other property like sosa:resultTime linking eep:Execution to xsd:dateTime in order to di erentiate the temporal entity that applies to the execution from the instant the execution was completed (as it is made in SOSA ontology). Moreover, a more complex conceptualization may be necessary in a scenario where executions are also features of interest and time is a quality of these executions, then :Time may be a subclass of a :Quality (similarly to what is done in SAREF ontology). Otherwise, features of interest and their properties may need to be quali ed by time-related properties; for instance, state duration of a feature of interest or change frequency of a property during a temporal context (as it is proposed in the SEAS Time Ontology25). In summary, EEP is ready to incorporate the preferred solution adopted by the EEP user. 25 https://ci.mines-stetienne.fr/seas/TimeOntology
In this paper we presented two ODPs: the A ectedBy ODP and the EEP (Execution-Executor-Procedure) ODP, which is an extension of the rst. Both of them are expected to solve recurrent design problems that arise in energy e ciency problems for buildings and that are not adequately addressed by existing ontologies and ODPs. Both ODPs are aligned with related ontologies which make them applicable to similar problems in di erent domains, and are stored in the ODP repository.
In future work, both ODPs are expected to be the base for building ontology modules. Namely, they are planned to be the foundation for the reengineering of the measurements4EEPSA ontology module (an adapted extraction of the m3-lite26 and QUDT27 ontologies) responsible for containing measurements and device related knowledge, and a new ontology module containing expert knowledge in the energetic eld.
Furthermore, these ODPs will be used in KDD processes with other goals that di er from attempting an energy e cient management of a building. Namely, they are expected to support the energy production forecasting of a Photovoltaic (PV) system as well as the management of Demand-Response strategies.
Part of the presented work received funding from FEDER/TIN2016-78011-C42-R. This work was conducted using the Protege resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health. 26 http://ontology. esta-iot.eu/ontologyDocs/m3-lite.owl 27 http://www.qudt.org