Abstract
Spaces and elements in the built environment have emerged as platforms where materializations of observations and actuations promise to be very profitable. The advent of the Internet of Things (IoT) paves the way to address this challenge but the heterogeneity of the represented knowledge about these artifact systems poses a real problem. Ontologies can be considered as part of the solution to overcome the IoT’s inherent hurdles. A wise option promoted by recent approaches is to design networks of complementary ontologies. However, different points of view are possible and such diversity could lead to interoperability problems. This article advocates for a networked ontology infrastructure conceived on a principled basis guided by documented judicious conceptualizations. In this regard, this survey points towards ontologies involved in conceptualizations of observations and actuations, where the utility of that conceptualization arises when some features of interest need to be observed or acted upon. For each of the reviewed ontologies, their fundamentals are described, their potential advantages and shortcomings are highlighted, and the use cases where these ontologies have been used are indicated. Additionally, use case examples are annotated with different ontologies in order to illustrate their capabilities and showcase the differences between reviewed ontologies. Finally, this article tries to answer two research questions: Is there a firm basis, broadly admitted by the community, for the development of such a networked ontology infrastructure for the observations and actuations in buildings? What ontologies may be considered helpful towards that goal?
Introduction
The Internet of Things (IoT) [36] facilitates the monitoring of qualities of real-world entities and events thanks to physical things equipped with electronic components and ubiquitous intelligence that allow them to connect, interact and exchange data. Furthermore, the expansion of the IoT has led to the massive amount of data available nowadays, which has the potential to enable new discoveries and improve decision making processes. It is estimated that in 2019, the IoT will generate more than 500 zettabytes in data [16]. This huge quantity of data not only represents observations or actuations generated by potentially billions of devices, but also describes related aspects including devices themselves, the location of these devices, and the context under which the qualities of a feature of interest are observed or acted upon. Without connecting all these data with its underlying semantics, the users of the IoT may end up in information silos that would require different applications to access and use them. These circumstances definitely pose a challenge for transforming the raw data into business insight, thus hindering the exploitation of the data for better and smarter decisions.
The advent of the IoT paves the way to address situations that remain challenging in various domains. One of those domains is the AEC (Architecture, Engineering and Construction) sector, where the installation of the IoT systems in buildings enables understanding occupants’ behaviour as well as discovering the discrepancies between buildings’ expected and actual performance [55]. This may in turn allow facing problems that are still unsolved in most buildings such as fulfilling occupants’ thermal comfort whilst reducing energy consumption. These two aspects are equally important. On the one hand conducted research proved that thermal comfort has a direct impact on human working efficiency [39,40], occupants morale [57], and potential health impairments [63] and on the other, the energy efficiency is one of the major concerns in buildings since they consume more than 35% of global energy in the EU [1]. These references reveal the relevance of paying attention to the building domain in particular.
Nevertheless, one of the most highlighted drawbacks of the IoT lies in the data level heterogeneity. 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. Yet devices manufactured by the same vendor may use different data models, which further aggravates the data heterogeneity situation. Such diversity derives in semantic interoperability problems, where each system can represent the same thing in different ways, hindering the integration and understanding between these systems.
Semantic Technologies can be leveraged to remedy aforementioned issues as they enable integrating data across several data sources as well as the adequate management of data semantics, data interrelationships, and knowledge representation. More specifically, ontologies, ontology-driven rules and ontology-driven data access are foreseen as the main drivers to address the aforementioned challenges. An ontology can be defined as a formal, explicit specification of a shared conceptualization [35,83]. The conceptualization specified by each ontology is usually devoted to representing a certain phenomenon, topic, or subject area, and designed with a certain purpose.
It has been shown that ontology-based approaches could contribute in achieving semantic interoperability [58], for example by annotating each data element with ontology terms thus providing them with semantics [49–51]. Annotating the raw data with terms coming from ontologies allows a better representation of the data, structuring it and setting formal types, relations, properties and constraints that hold among them. In addition, it allows representing data coming from multiple sources in a uniform way, thereby supporting data integration [60]. Another benefit of the semantic annotation lies in the additional background knowledge about a domain that can be added to the set of available data. This leads to the enrichment of the dataset at hand, as well as enabling the application of indexing techniques, which are based on resource URIs and ensure the retrieval and navigation through related resources [5]. 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 the raw data’s underlying structure.
Ontologies can be considered as part of the solution to overcome the IoT’s inherent hurdles, although defining a single comprehensive shared ontology for the whole IoT domain may be challenging due to the existence of more than 200 ontologies [37]. This fact may be motivated because the IoT scenarios tackle a wide range of aspects such as the things used to observe or act, their configuration and capabilities, the location where they are deployed, the modalities of the context upon which they operate, the data accessibility permission, or the service orchestration, among others. Moreover, it is highly probable that these ontologies do not share the conceptualization of the core elements, and therefore, a proper integration of the ontologies is very difficult, if ever possible.
A wise option promoted by recent approaches is to design networks of complementary ontologies. However, different points of view are possible and such diversity could lead to interoperability problems. This article advocates for a networked ontology infrastructure conceived on a principled basis guided by documented judicious conceptualizations. Two research questions can be stated: Is there a firm basis, broadly admitted by the community, for the development of such a networked ontology infrastructure for the observations and actuations in buildings? What ontologies may be considered helpful towards that goal?
In order to answer these research questions, the survey presented in this article has been carried out following the method described next:
Establishment of the conceptualization of observation and actuation.
Extraction of the Competency Questions (CQs) from a sample scenario that serve as a benchmark.
Establishment of the scope of the survey and the criteria to review ontologies.
Review of the selected ontologies.
Discussion of the obtained results and the reached conclusions.
The notions of observation and actuation may be considered an adequate starting core for a proper ontology network development. According to this vision, an explicit conceptualization of these notions should be presented and explained. These notions can be considered variations of the more general notion of transduction. The transduction can be understood as the action or process of converting something such as the energy or a signal into another form. An observation outputs a readable result from a stimulus. Likewise, an actuation transforms a signal into a change of state of a device.
The observation term is already used in different ways in different communities. The O&M (Observations and Measurements) model described in ISO 19156:20111
Concepts from the DUL ontology involved in the notion of an observation/actuation.
For the sake of simplicity, these questions will be expressed in terms of the observation notion but notice that they are analogous for the actuation notion. To begin with, considering an observation as described by ISO 19156:2011 (see above) which is admittedly shared by a wide range of the community, it may be adequate to say that an observation is a particular kind of dul:Event, an upper class of the DUL ontology. And the following questions can be considered:
What is observed? A quality of a feature of interest. That notion of quality is captured by the class dul:Quality, which is defined as: “Any aspect of an Entity (but not a part of it), which cannot exist without that Entity. For example, the way the surface of a specific PhysicalObject looks like, or the specific light of a place at a certain time, are examples of Quality”. The feature of interest would be, more specifically, an individual of the class dul:Object, which is defined as: “Any physical, social, or mental object, or a substance. Following DOLCE Full, objects are always participating in some event (at least their own life), and are spatially located”. In the context of this survey, features of interest are elements in the domain of buildings.
Who is the observer? A sensor, which is a particular kind of dul:Object.
How is the observation made? Following a procedure, which can be considered an individual of dul:Plan which is a particular kind of the class dul:Description.3
The textual definition in DUL documentation is quite cryptic due to its desired versatility. A dul:Description is defined as “a SocialObject that represents a conceptualization”. Likewise, a dul:SocialObject is “any Object that exists only within some communication Event, and needs to be expressed by some information object (information objects are self-expressing)”. Finally, a dul:InformationObject is defined as “a piece of information, such as a musical composition, a text, a word, a picture, independently from how it is concretely realized”.
Where is the observation made? In a location, that would be represented by an individual of the class dul:Region, which is defined as: “Any region in a dimensional space (a dimensional space is a maximal Region), which can be used as a value for a quality of an Entity. For example, TimeInterval, SpaceRegion, PhysicalAttribute, Amount, SocialAttribute are all subclasses of Region. Regions are not data values in the ordinary knowledge representation sense; in order to get patterns for modelling data, see the properties: representsDataValue and hasDataValue”. Notice that the location of the observation is decoupled from the location of the feature of interest observed.
When is the observation made? In a time region, represented by an individual of dul:Region.
Which is the result of the observation? An encoding of a value represented by an individual of dul:Region. This encoding can be achieved by asserting an xsd:_ value to that individual region by using the property dul:hasRegionDataValue (such a xsd:_ value is a simple XML style codification of a structured data including numbers and strings as required).
The Fig. 1 shows a diagram representing the aforementioned analysis of the notion of observation (and its counterpart actuation) involving classes of the DUL ontology. The 5W1H questions suggest properties of an observation (and analogously, of an actuation) and the adequacy of the proposed conceptualization arises when the features of interest that need to be observed or acted upon and their circumstances come into play. Attention to different domains or different contexts can be achieved, in a loosely coupled way, by changing specific ranges of these properties.
Relevance of the building domain has been previously highlighted in order to support the decision of focusing on that domain in this article. Additionally, the context of the data has been identified as a critical aspect for any data-centric effort, including Machine Learning [41,87]. The lack of a context may impede the knowledge extraction from raw data to achieve the goals and objectives set by the different individuals and organizations [81]. Likewise, even within a given domain, the same observations may mean entirely opposite things in different contexts [52]. A prime example of contextual variables that can be exploited for data-centric or even human-centric approaches are space and time [14]. Units of measurements are also a relevant source of contextual data of observations and actuations, which ease determining their value meaning. For example, a temperature observation with a value of 42 is very different when the observation is measured in kelvins, in degrees Celsius or in degrees Fahrenheit. Therefore, the analysis of the ontologies representing observations and actuations context is of interest.
Next, a simple working scenario is presented and some basic requirements are extracted in the form of CQs. These CQs can serve as a benchmark for the domain ontologies to be reviewed.
Consider two rooms (roomA and roomB) located in the first floor (floor01) of a building (building01) with coordinates 40.74° latitude and −73.98° longitude. A sensor (sensor01) observing the temperature in roomA measured an observation (obs01) with a temperature of 29°C on 15th December 2018 at 19:00 by implementing a monitoring procedure (monitoringProc). Another sensor (sensor02) observing the temperature in roomB and the humidity in roomA, measured two observations (obs02 and obs03) corresponding to the respective qualities. That is, an observation (obs02) of the temperature in roomB and another observation (obs03) of the humidity in roomA. These observations were measured employing the same monitoring procedure used by the sensor sensor01. Taking this sample scenario into consideration, the Table 1 displays a set of basic CQs for the ontologies that should address this scenario.
Requirements of the proposed sample scenario
The rest of the paper is structured as follows. Section 2 presents the scope of the survey. In Section 3 ontologies are reviewed. The outcomes of this review are discussed and concluded in Section 4.
The IoT is a broad domain and many ontologies, with different purposes and character, have been designed to address it. In this regard, a recent survey by Bajaj et al. can be found at [6]. However, the present article is not aimed at covering the whole IoT domain. Instead, the scope of this survey is restricted to, on the one hand, the ontologies that consider as core concepts the notions exposed in the 5W1H analysis of the previous section and, on the other, the ontologies that consider spaces and buildings elements as features of interest whose qualities are commonly required to be observed and actuated upon. The intended goal of this survey is to provide grounded answers to the research questions posed in the introduction.
Given the abundance of existing ontologies covering the aforementioned areas of knowledge, it is advisable to make explicit the ontology selection criteria and the features to be reviewed in every ontology.
Four reputed sources have been consulted to retrieve an initial collection of relevant ontologies: the LOV4
The keyword ‘ontology’ was not necessary for LOV.
Then, the selected ontology set was filtered by the following criteria:
Having an explicit license. As any other intellectual creation, ontologies are protected by copyright, so they cannot be used unless a license permits so. Therefore, in order to make the ontologies reusable, specifying this piece of information is necessary.
Having enough documentation of its purpose, design fundamentals, CQs, etc. as typically asked in an ORSD [84] (Ontology Requirements Specification Document). When discovering an ontology, one of the first activities consists in reading its documentation to understand the ontology domain and determine whether it describes this domain appropriately or not. This is why nowadays, the ontologies should have comprehensive web pages describing their theoretical backgrounds and features.
Having minimum metadata. The W3C’s Data on the Web Best Practices [15] 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. Since the guidelines described by Garijo and Poveda-Villalón [34] are the most complete ones, having at least a label (e.g. by means of rdfs:label) and a definition (e.g. by means of rdfs:comment) towards describing each class and property of the ontology is set as a criterion.
Having explicit alignments with other ontologies. Setting mappings to other ontologies alleviates integration problems [60], helps to ensure clarity in modelling and avoids errors that have unintended reasoning implications [18].
Having evidence of ontology use. According to the W3C’s Data on the Web Best practices [15], the reuse of existing ontological resources is advised. The evidence of its usage can symbolize the acceptance of an ontology by the community.
Having a principled design. Following ontology design principles may contribute to high quality ontologies, therefore, pointing out design basis including ODP-based (ontologies based on Ontology Design Patterns, which are modelling solutions to solve recurrent design problems that arise in ontology development processes [33]), model-based (ontologies based on existing models such as ISOs or conceptual schemas) or ontologies based on the reengineering of existing assets is of interest. It is worth mentioning that these principles are not mutually exclusive, so the ontologies may follow more than one of them.
Since very few ontologies satisfied all these criteria, the weaker requisite of satisfying most of them (at least four) was adopted in order to include an ontology into the surveyed collection. These requisites were lowered for the case of the Building domain ontologies, as only a few of these ontologies satisfied them. Moreover, some ontologies were included to illustrate some particular points.
The resulting collection of ontologies was separated into two sets: the ontologies related to observations and actuations (reviewed in Section 3.1), and those more related to the building domain (reviewed in Section 3.3). Both sets of ontologies received the same analysis but in a separate manner in order to ease the reader’s understanding. For each of the reviewed ontology, their fundamentals are described, their potential advantages and shortcomings are highlighted, and the use cases where these ontologies have been used are indicated. In addition, since there are ontologies built upon other ontologies, each ontology’s parent ontology from which they inherit concepts as well as its design principles are described. Furthermore, for each ontology the latest available version’s date is shown (which may hint at the maintenance of the ontology), the license is specified, and checks are assigned to the following aspects: documentation, metadata, alignments9
In order to avoid overwhelming the reader, links to ontology alignments are not provided. These should be accessed by means of the ontology’s documentation page.
Furthermore, Section 3.2 is dedicated to present some ontologies that cover complementary but necessary contextual aspects such as time and units of measure. These domains are out of scope of this survey but a sample of them is presented in order to show a more complete picture of the scenario, although they are not submitted to the aforementioned reviewing criteria.
This section presents the review of the ontologies selected according to the scope delimited in Section 2. Section 3.1 reviews the ontologies representing observations and actuations, Section 3.2 reviews the ontologies representing contextual information such as spatio-temporal information, and Section 3.3 reviews the ontologies representing building information.
Observations and actuations ontologies
As mentioned before, the IoT devices generate a vast amount of data, especially observations of the real world and actuations triggered to change the state of the real world. However, the raw observation and actuation results do not provide the context required to adequately interpret and understand them. Without the proper description of the situations under which these observations and actuations are performed, their exploitation capabilities may be rather limited. In this regard, the semantic annotation of this data with the adequate ontology terms is expected to ease the exploitation of their underlying semantics. Therefore, the review of the ontologies available for this purpose is of interest.
In order to illustrate the capabilities and differences between the reviewed ontologies, the following snippet from the modelling problem proposed in Section 1 will be considered:
“A sensor (sensor01) observing the temperature in roomA measured an observation (obs01) by implementing a monitoring procedure (monitoringProc). Another sensor (sensor02) observing the temperature in roomB and humidity in roomA, measured two observations (obs02 and obs03) corresponding to the respective qualities. That is, an observation (obs02) of the temperature in roomB and another observation (obs03) of the humidity in roomA. These observations were measured employing the same monitoring procedure used by the sensor sensor01.”
This snippet addresses the What, Who and How questions of the 5W1H method and the following subset of proposed CQs:
CQ01: What are the observations performed by the sensor sensor01?
CQ02: How is the observation obs01 measured?
CQ03: Who observed the temperature in roomA?
CQ04: Which room does a given observed temperature belong to?
The Table 2 checks whether the ontologies reviewed in this section correctly address the aforementioned CQs or not.
Observation and actuation ontologies addressing the presented CQs. *=CQ satisfied if the observation-centric style is used
Observation and actuation ontologies addressing the presented CQs. *=CQ satisfied if the observation-centric style is used
The initial Semantic Sensor Network Ontology10
In this paper SSNO will denote the 2011 version of the SSN ontology.
The core of the SSNO put the sensor stimulus (ssno:Stimulus12
ssno is the namespace of the SSNO.
The SSNO has been reused to a greater or lesser extent by other domain ontologies including the IoT-O ontology (reviewed in Section 3.1.6), the IoT-Lite ontology (reviewed in Section 3.1.7) or the FIESTA-IoT ontology (reviewed in Section 3.1.8). This usage has been eased by the W3C Software license that enables its reuse, the ontology documentation page and the necessary metadata to facilitate the understanding of ontological terms. Furthermore, as mentioned before, the SSNO is aligned with DUL.
The following triples would represent the previously proposed use case example:
As mentioned before, the SSNO’s SSO ODP adds the notion of a stimulus to a sensor-observation relationship, therefore, incrementing the number of triples necessary to represent the proposed modelling problem’s scenario. An alternative way of codifying this scenario is possible ignoring the Stimulus concept, as follows:
These triples directly link a sensor to its corresponding observed properties and implemented procedures, thus avoiding the necessity of representing a stimulus. However, this codification ignores the SSO pattern in which the ontology is based. It is obvious that the CQ01 can be satisfied with these modelling triples. But the CQ02 cannot be satisfied if the sensor that made the observation implements more than one procedure, what is perfectly possible depending on the qualities observed by the sensor. Then, the proper answer to the CQ02 cannot be elucidated. Moreover, the CQ04 can be satisfied by the following SPARQL query, assuming that :temp is the given temperature:
evaluated over the given set of triples, retrieves :sensor01 and :sensor02 as answers, which is not enough to elucidate the sensor who observed temperature in the :roomA. This inconvenience would have been avoided if the modelling had been more precisely adjusted to the definition of ssno:Property in the SSNO documentation (i.e., “(...) an aspect of an entity that is intrinsic to and cannot exist without the entity and is observable by a sensor.”, which corresponds to the definition of dul:Quality in Section 1). It is clear that :temp is not intrinsic to the :roomA and that it exists as a quality of the :roomB even if the :roomA disappears. An alternative modelling, using triples such as the following, solves this issue.
Moreover, this modelling style offers the possibility to create subclasses of ssno:Property such as Temperature or Humidity that could play a similar generic role to :temp and :hum. However, the modelling style that uses :temp and :hum as generic qualities is very frequent in applications and should be taken into account to be able to create sets of triples that solve the CQ03 issue. A possible solution for the CQ02 and the CQ03 will be presented in the following section, dedicated to the SOSA/SSN ontology.
The W3C Spatial Data on the Web Working Group (SDWWG13
Contrary to the SSNO, the SOSA/SSN ontology focuses on the complete observation as an event. In consequence, sosa:Observation is defined as a subclass of dul:Event in its alignment with the DUL ontology. Therefore, following the conceptualization of Observation explained in Section 1.
A list of 23 ontologies that already reuse the SOSA and the 23 datasets that use the SOSA classes and properties to define data in their applications can be found in the SSN Usage document.16
Nevertheless, neither the SSNO nor the new SOSA/SSN ontology describes the different qualities which can be measured by sensors or acted upon by actuators. Related concepts such as the units of measurements of these qualities, the hierarchies of sensor/actuator/sampler types, or the spatio-temporal terms are not covered either. All this knowledge has to be modelled by the user, or preferably imported from other existing ontologies.
A literal translation of the set of triples presented in the previous SSNO subsection to the SOSA/SSN ontology is possible by replacing the SSNO properties with their equivalents in the SOSA/SSN ontology. That is, replacing ssno:observedBy, ssno:observes, ssno:featureOfInterest, ssno:isPropertyOf and ssno:implements, with sosa:madeBySensor, sosa:observedProperty, sosa:hasFeatureOfInterest, ssn:isPropertyOf and sosa:usedProcedure, respectively. However, the resulting model would suffer from the same problems noted in the section dedicated to the SSNO. A better alternative to represent the use case example could be the following:
Notice the observation-centric modelling instead of a sensor-centric modelling. It is crucial to gather the set of properties sosa:usedProcedure, sosa:madeBySensor, sosa:observedProperty, and sosa:hasFeatureOfInterest of an observation as reflecting an n-ary relationship.
This way, the following queries could satisfy the following Competency Questions:
CQ01:
CQ02:
CQ03:
CQ04:
It is worth mentioning that these two modelling alternatives are not completely equivalent. While the first one can be inferred from the second with rules like [obs sosa:observedProperty qual and obs sosa:madeBySensor sensor then sensor sosa:observes qual], the second cannot be inferred from the first, since a sensor can observe several qualities and therefore, it cannot be elucidated which of the qualities is the one observed by an observation made by that sensor.
Nevertheless, that inferencing is not possible by using only the current definitions and constraint axioms in the SOSA/SSN ontology, since their designers preferred a lightweight ontology and avoided to include some constraint axioms that could specify assumed relationships.
The om-lite ontology18
The om-lite ontology allows combining data unambiguously and referring to the observations made in-situ, remotely, or ex-situ with respect to the location. These observation details are also important for the data discovery and for the data quality estimation. Furthermore, the om-lite ontology removes dependencies with pre-existing ontologies and frameworks, and can therefore be used with minimal ontologies commitment beyond the O&M conceptual model. Additionally, it provides stub classes for time, geometry and measure (scaled number), which are expected to be substituted at run-time by a suitable concrete representation of the concept.
The ontology is accessible under a CC BY 3.0 license, it has a documentation page, the ontological terms have adequate metadata and it is aligned with domain ontologies including the SSNO and the PROV-O. Nevertheless, to the extent of knowledge of authors, there is no evidence of the om-lite ontology’s usage.
The following triples would represent the previously proposed use case example:
The om-lite ontology does not define any class for the observed qualities or the features of interest. Therefore, the individuals :roomA, :roomB, :temp and :hum cannot be adequately represented. Furthermore, the oml:procedure object property would lead the way to answer the CQ01 with the following query:
However, on the one hand, the range of this object property are individuals of the class oml:Process which include both sensors and procedures, and on the other hand, the om-lite ontology does not offer classes to distinguish sensors and procedures. Therefore, the CQ03 and the CQ04 remain unsatisfied. Furthermore, the CQ2 cannot be satisfied with the following query: 
The Smart Appliances REFerence (SAREF) ontology19
The modular conception of the ontology allows the definition of any new device based on building blocks describing functions that the devices perform. Furthermore, the SAREF ontology can be specialized to refine the general semantics captured in the ontology and create new concepts. The only requirement is that any extension or specialization may comply with the SAREF ontology. There are six extensions of the ontology available in the official ETSI portal for SAREF:20
The SAREF ontology terms have been used in applications that range from energy efficiency semantic models [56] to comfort management in hotels [82]. Furthermore, standards organizations and alliances, such as CENELEC26
The following triples would represent the previously proposed use case example:
These triples showcase the SAREF ontology’s device-centric modelling in contrast to the more event-centric modelling style of other ontologies such as the SOSA/SSN and the om-lite ontologies. Furthermore, the SAREF ontology cannot represent the relationship between an observed quality (e.g. a room’s temperature) and the feature of interest to which it belongs (e.g. the room at hand), thus the CQ04 remains unsatisfied. As a matter of fact, the SAREF ontology does not represent the notion of a feature of interest, so that in the triples above, individuals :roomA and :roomB to which the observed qualities belong cannot be adequately represented. Therefore, the CQ3 cannot be addressed. Last but not least, the CQ2 cannot be satisfied for situations when the sensor in charge of making an observation has more than one value for the object property saref:hasFunction. This is caused by the lack of constraint axioms for saref:Sensor over saref:hasFunction, and the fact that saref:hasFunction is not a functional object property.
The SEAS ontology28
On top of these core modules, several vertical SEAS ontology modules are defined, which are dependent of a specific domain. Some of these modules include the SEAS Electric Power System ontology34
The SEAS ontology and its modules are licensed under Apache License, version 2.0 and have a thorough documentation and a complete metadata, which eases its understanding and their potential reuse. One of the few examples of its usage is EROSO [27], a framework that is aimed at ensuring thermal comfort in workplaces and extends the SEAS Forecasting ontology.35
The following triples would represent the previously proposed use case example. Namespace pep belongs to the PEP ontology.
The aforementioned three observations on two rooms are appropriately codified in the SEAS ontology for adequately answering the proposed four competency questions CQ01, CQ02, CQ03, and CQ04. It should be noted that the object property seas:isPropertyOf is declared functional and, therefore, the SEAS ontology supports the notion that a quality is intrinsic to the feature of interest to which it belongs.
The IoT-O ontology36
A sensing module, based on the SSNO and particularly on the SSO pattern.
An acting module, based on the SAN (Semantic Actuator Network) ontology,37
A service module, based on the MSM38
A lifecycle module,40
An energy module, based on the PowerOnt.41
Furthermore, to maximize its reusability and extensibility, the IoT-O imports the DUL and aligns all its concepts and imported modules with it.
The ontology as a whole has been used by an application aimed at distributing semantic data processing in the Fog [80] as well as an ontology to represent interactions between an entity and an IoT system [90]. Likewise, the SAN ontology module (which is part of the IoT-O ontology) has been reused by the BCI (Brain-Computer Interaction) ontology42
Being based on the SSNO, the previously proposed use case example would be represented with the same triples proposed in Section 3.1.1.
The IoT-Lite ontology43
The IoT-Lite ontology is built around the main three concepts which, according to the IoT-Lite authors, are necessary in any ontology describing the IoT: objects/entities, resources/devices, and services. However, the coverage of the ontology is limited to upper-level concepts, rather than representing the types of devices as subclasses of ssno:SensingDevice (e.g. thermometer) or the units of measurements as subclasses of qu:Unit (e.g. degrees Celsius). Although the terms used in the IoT-Lite ontology are aligned with their generalized counterparts, the representation of the key concepts in sensor-related environments (e.g. sensor, action and observation) is limited.
As mentioned before, the IoT-Lite ontology is developed to being used by platforms in the open calls of the Fiesta-IoT project. To the extent of knowledge of authors, the ontology has been reused only by the Fiesta-IoT ontology reviewed next. Being licensed under CC BY 3.0 and having a documentation page with the ontology’s instantiation examples, fosters its potential reuse. However, the lack of the adequate metadata of ontological terms may prevent users from reusing it.
Being based on the SSNO, the previously proposed use case example would be represented with the same triples proposed in Section 3.1.1.
The FIESTA-IoT ontology46
The SSNO has a strong influence in the FIESTA-IoT ontology when describing sensors and observations. The central class is ssno:Observation, which is related with the ssno:Sensor which generates it, the quality it observes (qu:QuantityKind) and the temporal and location context.
The M3-lite taxonomy47
The FIESTA-IoT ontology has been used to federate eleven IoT deployment testbeds from heterogeneous application domains including smart cities, maritime and smart grids [77]. Furthermore, the M3-lite taxonomy, which is part of the FIESTA-IoT, has been used in an outlier detection framework in Wireless Sensor Networks [28]. Furthermore, the ontology has a complete documentation and metadata, a set of alignments with other ontologies including the SSNO, and an explicit license towards fostering its potential reuse.
Being based on the SSNO, the previously proposed use case example would be represented with the same triples proposed in Section 3.1.1.
The SmartEnv ontology48
Although the SmartEnv ontology and its modules were developed under the E-care@home project,49
Being based on the SOSA/SSN ontology, the previously proposed use case example would be represented with the same triples proposed in Section 3.1.2.
The representation of the notion of an observation is the central element in most reviewed ontologies, although its counterpart actuation is also addressed by certain ontologies. The main ontology in this regard is the SOSA/SSN ontology, which is based on the reengineering of the SSNO. There are also other ontologies based on the SSNO (e.g. the FIESTA-IoT and the IoT-O ontologies) and likewise, there are ontologies based on the new SOSA/SSN ontology (e.g. the SmartEnv ontology). However, thanks to the alignment between the initial SSNO and the new SOSA/SSN ontology versions, interoperability issues among these ontologies may be alleviated.
Furthermore, there are ontologies that differ from the SSNO’s stimuli-centric modelling or the SOSA’s event-centric modelling. For example, the SAREF ontology takes a more device-centric modelling, while the om-lite ontology tries to make a more faithful representation of an ISO schema model.
Most of the reviewed ontologies offer explicit classes for representing the notions of Observation, Actuation, Sensor, Actuator, Feature of Interest, and Quality, but some of them miss Feature of Interest (i.e., the om-lite and the SAREF ontologies) or Quality (i.e., the om-lite ontology), and the SAREF ontology does not relate a quality to its feature of interest.
The SOSA/SSN ontology allows different ways of modelling observable properties, although this flexibility means that different stakeholders may adopt different modelling options that can derive in interoperability problems. In this regard, there are ontologies such as the SEAS ontology that renounce to this flexibility and propose the notion that a quality is functionally related to its feature of interest, being therefore more aligned with the DUL ontology’s conceptualization.
It is worth mentioning that all of the reviewed ontologies provide an explicit license and documentation page, except for the SmartEnv ontology. Likewise, the metadata of terms, the alignments to other ontologies and the evidence of the usage are present in most of the reviewed ontologies.
The Table 3 summarizes the features of the ontologies reviewed in this section.
Summary of the reviewed observations and actuations domain ontologies
Summary of the reviewed observations and actuations domain ontologies
Observations and actuations are the central elements of the problem tackled in this survey. However, the spatial, temporal, and units of measurements aspects of their values are a contextual information of utmost importance in buildings. This context information may differ in nature and granularity levels, and responds to the When, Where, Which questions of the 5W1H analysis of Section 1. Next, the ontologies representing such a context of observations and actuations are reviewed.
Time
Since nearly everything is liable to undergo change, the notion of time features in the discourse about any subject. Many ontologies defining the temporal context exist [32,42,62,91,92], including the DAML-Time50
The OWL-Time is a W3C recommendation representing temporal concepts for describing the temporal properties of resources. The ontology expresses facts about the topological relations among instants and intervals, together with information about durations and temporal positions including date-time information. The time positions and durations may be expressed using either the conventional (Gregorian) calendar and clock or using another temporal reference system such as the Unix-time, the geologic time, or different calendars.
The following triples would represent an observation (obs01) generated on 15th December 2018 at 19:00. Namespace xsd belongs to the XML Schema Datatypes.
This example addresses the When questions of the 5W1H method and the following proposed CQ:
CQ05:When was the observation obs01 generated?
Together with time, the spatial location is the other primary aspect that may help specifying a context. The WGS84 Geo Position53
The following triples would represent the location of a building (building01) with coordinates 40.74° latitude and −73.98° longitude with the WGS84 Geo Position terms:
This example addresses the Where questions of the 5W1H method and the following proposed CQ:
CQ06: Where is the building building01 located?
Another approach proposes a more detailed ontology to describe the location of device-based services that occur in ubiquitous computing environments [31]. GeoSPARQL [68] is the OGC (Open Geospatial Consortium) standard that not only defines an extension to the SPARQL query language, but also defines an ontology for representing geospatial data in RDF.
Units of measurement play a key role in many engineering and scientific applications, and the correct handling of the scale is of utmost importance in most fields. Therefore, nowadays there are numerous ontologies describing the units of measurement and their relations. Keil et al. [45] evaluate and compare different ontologies for modelling units of measurements and one of the main findings is that the reviewed ontologies use different terms to refer to the same concepts. For example, the concept “kind of quantity”, is denoted as “physical quality” by the MUO54
The use of any of the aforementioned ontologies for representing the observation results, means that the quantity values are usually represented as OWL individuals linked to the numeric values and a unit of measure. Next, QUDT and another approach (which is not covered in the aforementioned survey) are reviewed.
QUDT The QUDT is an initiative sponsored by the NASA to formalize Quantities, Units of Measure, Dimensions and Types using ontologies. The QUDT is organized as a catalogue of quantity kinds and units of different disciplines (e.g. acoustics or climatology). A quantity (qudt:Quantity) is the central element which represents a measurement of an observable quality of a particular object, event or physical system. The quantity is related with the context of the measurement, and the underlying quantity kind remains independent of any particular measurement. A quantity kind is distinguished from a quantity in that the former is a type specifier, while the latter carries a value.
The dimensional approach of the QUDT relates each unit to a system of base units using numeric factors and a vector of exponents defined over a set of fundamental dimensions. By this means, each base unit’s role is precisely defined in the derived unit. Furthermore, this allows reasoning over the quantities as well as the units.
Although at the moment of writing this survey there are efforts towards the development of a second version of the QUDT, these ontologies have only been partly published.
The following triples would represent a 29°C quantity value in the QUDT:
This example addresses the Which questions of the 5W1H method and the following proposed CQ:
CQ07: Which is the value of the observation obs01?
UCUM datatypes The work presented by Lefrançois et al. [48] leverages the UCUM (Unified Code of Units of Measure), a code system which aims at including the units of measures currently used in international sciences, engineering, and business.
This proposal is different to the rest of the aforementioned ontologies representing units of measurements and related concepts. The proposed lexical space is the concatenation of an xsd:decimal value, at least one space, and a unit chosen from the case sensitive version of the UCUM code system. The value space corresponds to the set of measures, or the quantity values as defined by the International Systems of Quantities. Using the UCUM datatypes requires only one triple to link a quantity to a fully qualified value, which is a reduction from the at least three triples needed in the aforementioned proposals.
The following triples would represent a 29°C quantity value in the UCUM Datatypes:
Furthermore, custom mechanisms to canonicalize literals based on external descriptions of units of measurements are not required. Therefore, one of the main advantages of the use of the UCUM Datatypes lies in the lighter datasets and simpler queries achieved. However, although the specification is stable, at the time of writing this survey authors acknowledged that this work has not yet been implemented in the main RDF stores.
BIM (Building Information Modelling) is a process used by different stakeholders involved in the construction process of a building and deals with the digital representation of the functional and physical characteristics of a building [26]. Each of these stakeholders adds domain knowledge to a common model which keeps the information of the whole building life cycle. As a consequence, the model serves as a valuable source of information.
A BIM model may contain the static information of a building element. For example, in the case of a window, the data about its location, the material it is made of, and even when it was installed is available in the BIM model and it can be queried. Nevertheless, BIM models are not aimed at containing more dynamic information such as the data stemming from IoT sources. On the contrary, IoT data, which is characterized by its abundance, is recommended to be stored in suitable storage systems such as Time Series Databases.59
Therefore, the integration of the static building information and the IoT data becomes a prime challenge [23]. Furthermore, it can be stated that more often than not, easy and intuitive ways to rapidly browse, query and use the BIM information combined with the IoT data are not available [64].
Semantic Technologies can be leveraged to remedy these issues, as they allow a more dynamic manipulation of the building information in RDF graphs via query and rule languages [64]. Furthermore, the ontology modelling paradigm for providing and implementing a BIM model of a target building increases its value [66] and supports a variety of advantages such as the reusability and the automated reasoning upon the modelled entities. There are a variety of technologies that offer conceptual modelling capabilities to describe a domain of interest, but only ontologies combine this feature with Web compliance, formality and reasoning capabilities [61].
There are many building domain ontologies, each designed to fulfil the specific information requirements of a certain use case within the AEC domain. However, the lack of a common building model for representing data prevents the interoperability and limits the scalability of applications. Next, a set of the most relevant ontologies for modelling buildings are reviewed.
Ontologies that do not cover building topology representation but instead they cover areas that are indirectly related to buildings are out of scope of this survey. For example, the HBC (Human Comfort in Building) ontology60
In order to illustrate the capabilities and differences between the reviewed ontologies, the following snippet from the modelling problem proposed in Section 1 is considered:
“The location of a room (roomA) in the first floor (floor01) of a building (building01)”.
This snippet addresses the following subset of proposed CQs:
CQ08: Which building does the floor floor01 belong to?
CQ09: What kind of space is a floor?
CQ10: Which floor does the room roomA belong to?
The Table 4 checks whether the ontologies reviewed in this section correctly address the aforementioned CQs or not.
Building domain ontologies addressing the presented CQs
The ifcOWL ontology61
The ifcOWL ontology aims at supporting the conversion of IFC instance files into equivalent RDF files. This means that it is of secondary importance that an instance RDF file can be modelled from scratch using the ifcOWL ontology and an RDF editor. Furthermore, the ifcOWL ontology defines a faithful mapping of the IFC EXPRESS schema, replicating its conceptualization which has been found inconvenient for some practical engineering use cases [64]. For example, the ifcOWL ontology’s conceptualization of some relationships and properties as instances of classes (i.e., ifc:IfcRelationship and ifc:IfcProperty) is counterintuitive to the Semantic Web modelling principles that would expect OWL properties to represent them. In this regard, a systematic transformation of this modelling issue has been proposed in the IfcWoD (IFC Web of Data) ontology65
At the moment of writing this survey, the ontology is not publicly available.
The ifcOWL ontology is a necessary tool to incorporate IFC models to the Semantic Web infrastructure but resulting graphs will be at least as large and complex as the original IFC models, which may be too complicated and even inconvenient for some scenarios. In this regard, efforts were made to split the ontology into modules representing different domains [85], but it is still closer to the concepts introduced within EXPRESS and IFC than to those of the Semantic Web modelling style [53]. The lack of such a modular approach may be one of the reasons behind the lack of evidence of usage of the ontology. Additionally, the scarce metadata related to ifcOWL terms definitely do not contribute to the reuse of the ontology. However, it is worth mentioning that, it has an explicit CC BY 3.0 license, a publicly available documentation page and since it follows the EXPRESS schema of the IFC in order to allow bidirectional conversion, many ontologies from the building domain offer a set of mappings to the ifcOWL ontology.
The following triples would represent the previously proposed use case example:
In the IFC standard, the relationship between the buildings, the storeys and the spaces are represented using intermediate IfcRelAggregates instances. However, these instances are unnecessary in most of the applications and services that may use or query this information. Therefore, their presence in the RDF graph raises its complexity unnecessarily.
The Building Topology Ontology66
The BOT describes sites comprising buildings, composed of storeys, which have spaces that can contain and be bounded by building elements. Sites, buildings, storeys and spaces are all non-physical objects defining a spatial zone [75]. These basic concepts and properties make the schema no more complex than necessary and this design makes the ontology a baseline extensible with concepts and properties from more domain specific ontologies. Therefore, the BOT serves as an ontology to be shared.
Moreover, the W3C LBD is aimed at producing more ontologies addressing geometry, products and other requirements across the life cycle of buildings that will extend from the BOT concepts. The Building Product Ontology (PRODUCT68
The BOT has been reused by other ontologies leveraged for different use cases that range from Building Automation and Control Systems (BACS) [86] to applications that support the design decisions related to thermal comfort and indoor climate [69], as well as the management of Demand Response actions in the H2020 RESPOND project72
The following triples would represent the previously proposed use case example: 
The DogOnt ontology73
Environment modelling in the DogOnt is rather abstract and mainly aimed at locating indoor devices at room granularity. Reflecting this general design goal the available concepts permit to represent: (a) buildings, (b) storeys, as part of multi-storey buildings, (c) flats, either located on single or multiple storeys, (d) the rooms inside flats and other indoor locations located outside flats (e.g. garages), (e) the walls, ceilings, floors, partitions, doors and windows composing both rooms and building boundaries, and (f) the objects contained in an indoor environment including furniture (e.g. chairs and desks) [11].
The DogOnt influenced the design principles of other ontologies such as the EEOnt and it has been used in research projects that encompass different domains such as the smart grid domain in the case of the JEERP (Java Energy-Aware ERP) project [12]. The DogOnt authors claim that, since these ontologies and projects have the DogOnt as a common origin, it could be reused as a foundation towards a shared and unified schema for the AEC ontologies interoperability. Additionally, the DogOnt terms are aligned with the DUL ontology and the SSNO terms. However, even though it is licensed under Apache License version 2.0 and it has a documentation page, the latest DogOnt version available at the moment of writing this survey (version 4.0.2) counts with over 1,000 classes and over 70 properties, which may be rather large to reuse in some cases. Moreover, the scarce ontology metadata may hinder the DogOnt terms’ understanding and consequently, its usage as a unified schema.
The following triples would represent the previously proposed use case example: 
The SAREF4BLDG ontology74
According to its representation, a building may have different spaces, which may also have other sub spaces within themselves. These classes alongside with the class representing physical objects, are declared as subclasses of geo:SpatialThing in order to reuse the conceptualization for locations already proposed by the Basic Geo vocabulary (also known as the WGS84 Geo Position vocabulary). Moreover, the SAREF4BLDG ontology’s current list of building devices should not be considered exhaustive, and it might be needed to extend this hierarchy if needed by a particular use case. At the moment of writing this survey, there is no evidence of the usage of this ontology. However, it has a rich documentation and ontology metadata, and it is licensed under CC BY 4.0 terms. The SAREF4BLDG ontology sets mappings to the ifcOWL ontology (IFC4 Addendum 1) using the property rdfs:seeAlso, but this property does not adequately represent the relationship of mapped terms. On the contrary, the mappings with the SAREF ontology classes are explicit and the relationship between these terms is clear, as some of the SAREF4BLDG ontology classes are defined as subclasses of the SAREF ontology classes (e.g. s4bldg:BuildingDevice rdfs:subClassOf saref:Device).
The following triples would represent the previously proposed use case example:
The SAREF4BLDG ontology does not define a class for storeys, so they may be represented with class s4bldg:BuildingSpace. That is, the CQ09 cannot be satisfied, and consequently, the CQ10 neither.
The ThinkHome ontology76
The building information module (BuildingOntology79
There are enough concepts to model whole buildings including wall layers, window sizes and types, door sizes and positions, room areas and volumes as well as room purposes and orientation of buildings. Although the M3 framework [22] reused terms designed by the ThinkHome ontology for the weather domain, there is no evidence of usage of the reviewed building information module. This fact may be influenced by the lack of an ontology documentation page, the ontology metadata, the alignments to other ontologies and especially, the lack of an ontology license.
The following triples would represent the previously proposed use case example:
The BuildingOntology does not define a relationship between a storey and a room within that storey, therefore, this connection cannot be represented. That is, the CQ10 cannot be satisfied.
The FIEMSER ontology81
The FIEMSER data model represents one of the main trends identified in the context of the Smart Appliances study of the SAREF ontology. The SAREF ontology authors claim that the saref:BuildingSpace class provides the link to the FIEMSER data model, however, at the moment of writing this survey, there is no alignment between the two ontologies. Furthermore, although having a publicly available ontology documentation page, the metadata related to the FIEMSER terms are rather infrequent, and even worse, no license is specified. This may explain the lack of the FIEMSER ontology’s usage evidence.
The following triples would represent the previously proposed use case example:
Although the FIEMSER ontology does not contain the notion of a storey, this may be represented with the class fi:BuildingPartition. However, the CQ09 cannot be adequately satisfied, and consequently, the CQ10 neither.
The Brick ontology82
The design of the Brick ontology follows a methodology that combines tagging (like in the Project Haystack83
The following triples would represent the previously proposed use case example. Namespace bf belongs to BrickFrame, an ontology module imported by the Brick ontology. 
The SEAS Building ontology84
Likewise the rest of the SEAS ontology modules, it is licensed under Apache 2.0, and it has a rich documentation page and metadata which eases its understanding. However, at the moment of writing this survey, the SEAS Building ontology is not used in any project or known use case. Furthermore, the SEAS Building ontology has no alignments with other domain ontologies.
The following triples would represent the previously proposed use case example:
The seas:subZoneOf object property links a zone to another it is contained in, which may be the inverse to the relationship defined in other reviewed ontologies (e.g. bot:containsZone).
The Semantic BMS (SBMS) ontology86
The SBIM ontology contains concepts describing the locations and the parts of the facilities adapted from the IFC 4 specification. The representation of the BIM individuals is modelled as subclasses of classes defined in the BOT (reviewed in Section 3.3.2) using rdfs:subClassOf axioms. Authors of this ontology state that the BOT serves for the SBIM ontology’s identical purposes but lacks the representation of sites, the universal transitive isPartOf property and the representation of device types. The first two issues are covered in the BOT version 0.2 by means of the class bot:Site and the transitive object property bot:containsZone respectively. Therefore, the SBIM ontology could be updated to be defined as an extension of devices that are out of scope of the BOT.
Regarding the ontology’s usage, the SBIM ontology (as part of the SBMS ontology) is used to evaluate the environment of a room and an energy efficiency use case at the University Campus of Masaryk University (Czech Republic). Furthermore, the ontology is aligned with the DUL ontology, defining the SBIM ontology’s concepts as subclasses of dul:DesignedArtefact and dul:PhysicalPlace, and object properties as subproperties of some DUL properties. Nevertheless, the SBIM ontology’s reuse for future use cases is definitely hindered by the absence of a documentation page, the scarcity of metadata related to ontological terms, and especially by the lack of an explicit license.
The following triples would represent the previously proposed use case example: 
The REC (RealEstateCore) Building Module88
The REC ontology and its modules are published as open source under the MIT License to ensure its free access for commercial use to property owners, suppliers, integrators, etc. It provides a documentation page which includes simple examples on how to make use of the ontology. However, at the moment of writing this survey, there is no evidence of its usage. Although the REC ontology contains a Metadata module, the metadata associated with ontology terms is incomplete as most of them lack a description, which may hinder its understanding in many cases (e.g. the difference between building:DishingRoom and building:DiningRoom). Regarding the alignments to other ontologies or standards, the REC ontology’s documentation page claims to have them in separate alignment files. However, the URIs of the target ontologies of these alignments are not the correct ones for referencing the corresponding ontology terms (e.g. https://w3id.org/rec/alignments/IFC/IfcBuilding89
This page does not exist.
The following triples would represent the previously proposed use case example. Namespace core belongs to the REC Core module.90
Ontologies like the ifcOWL ontology are necessary to convey the data registered in standard formats (e.g. IFC files) to the semantic realm (e.g. RDF files). These ontologies enable the automatic conversion of big quantities of data to leverage capabilities offered by the Semantic Technologies. However, such ontologies may be inadequate for a direct use in some scenarios due to their inconvenient, complex and often counterintuitive conceptualization of data for the task at hand. This aspect has been demonstrated by the triples annotated with the ifcOWL ontology to represent the use case example.
It is remarkable that many of the reviewed ontologies have the IFC specification as a reference, although the influence on some of them is bigger (e.g. the ifcOWL ontology) than on others (e.g. the SAREF4BLDG or the SBIM ontologies). However, there are also ontologies that follow other standards that are more suitable for their use cases, such as the ThinkHome’s BuildingOntology which is based on the gbXML or the Brick ontology which follows the Haystack project’s foundation.
Some ontologies such as the DogOnt, the ThinkHome ontology and the FIEMSER ontology are more focused on the residential sector, while others are more independent from the type of building. Furthermore, there are ontologies that do not represent the notion of a storey (e.g. the FIEMSER ontology and the SAREF4BLDG ontology) or the relationship between storeys and rooms (e.g. the BuildingOntology), which may be rather recurrent concepts when describing the topology of a building.
The number of ontologies that show evidence of their usage in a variety of real-world use cases is rather limited (e.g. the BOT and the DogOnt), although the rich documentation and metadata puts some of these ontologies in a good position to be reused (e.g. the SAREF4BLDG ontology and the SEAS Building ontology). Obviously, ontologies without a license (e.g. the ThinkHome ontology, the FIEMSER ontology and the SBIM ontology) have high possibilities to be discarded for a potential reuse, because the terms of its reusability are not specified.
In this section, focus is placed on a rather limited scope of the building domain, namely in the building topology. However, this did not prevent us from finding ontologies re-defining overlapping concepts over and over again. Even worse, the relationships of the terms defined by the different ontologies are not known, due to a generalized lack of metadata and alignments of terms. Therefore, a user cannot determine whether a Space defined in the SAREF4BLDG ontology and in the BOT represents the same concept or not.
The Table 5 summarizes the features of the ontologies reviewed in this section.
Summary of the reviewed building domain ontologies
Summary of the reviewed building domain ontologies
According to Fernández-López et al. [30], the deficiencies in existing ontologies are important obstacles for reusing ontologies. As a matter of fact, the potential ontology users may be tempted to design their own ontologies rather than reusing/reengineering/extending an existing one when they are faced with the following problems: technical difficulties for locating and downloading a desired ontology; insecurity about the rights to use a located ontology; unclear or non-existent explanations of the goal or the scope of a downloaded ontology; and doubts about the meaning of the terms appearing in a candidate ontology. In view of the proliferation of ontologies in the observations and actuations domain as well as the building domain, such problems appear to be very frequent.
Providing the means for a correct download of an ontology is only a technical matter and it is surprising that downloading fails happen so often if the authors of the ontology have real desires to share it. Nowadays, there are enough tools and services to successfully accomplish this task, and by no means can it be considered an inconvenience for sharing ontologies.
The fact that an ontology is actually available online does not imply that it can be legally reused. The lack of an explicit license that specifies the terms under which they can be used is another issue that limits the reusability of ontologies. But, similar to the previous issue, this can be easily solved by assigning a license selected from one of the standardized proposals [70], including Creative Commons (CC) or Apache licenses. Most of the ontologies reviewed in this survey exhibit this kind of licenses, although there are ontologies which do not show any (e.g. the SmartEnv, the ThinkHome, the FIEMSER and the SBIM ontologies). Creating new usage agreement terms as an alternative to standard proposals, as in the case of the Brick ontology, may discourage potential ontology reuse, as users may face unfamiliar terms.
Certainly, a good documentation increases the understandability and potential usability of ontologies, both by experts in semantics and by people who are not necessarily experts in semantics and languages like OWL, RDF or RDFS [67]. However, generating a good documentation requires dedicated work to publicly explain the goal, the requirements, the covered scope, the design foundation, and the collection of terms of the ontology. The good news is that there is a proliferation of available tools for the automatic generation of an HTML documentation from ontologies. These tools minimize the efforts of writing a proper documentation and enable the interactive exploration of the ontology with the use of hyperlinks and/or Javascript mechanisms. The bad news is that the quality and completeness of such explanations for current ontologies are so different among each other that it is difficult to accept the mere existence of a documentation page as a criterion for awarding a fundamental reference role to an ontology. We should be more demanding with the documentation quality of the ontologies that are supposed to play a basic role in a networked ontology infrastructure to be shared by the community. A clear example of the ontologies offering a nice documentation are the SOSA/SSN ontology, the SEAS ontology and the BOT, which accompany the basic documentation produced by the aforementioned tools with examples of its usage or the rationale behind some ontology design choices.
However, the documentation alone is not enough to support a general basis of agreement. Apart from offering an ontology documentation page, it is of utmost importance to provide proper descriptions of the ontology itself (e.g. the ontology namespace URI or version dates) as well as of the classes and properties (e.g. labels and textual definitions) defined in the ontology if its reuse is aimed. These descriptions should be sufficiently clear to convey the conceptualization considered for these terms to the reader. This is especially advisable for ontologies with a high number of classes and/or properties, since a lack of careful metadata with explanatory descriptions of the intended meanings of their terms becomes a hurdle to their usage. This situation arises in ontologies such as the DogOnt, the ThinkHome, the ifcOWL, the Brick and the IoT-Lite ontologies.
Names are not enough to convey a conceptualization, so careful explanations with adequate examples are necessary. Sometimes, similar names hide differences in their conceptualization. And a mismatch in the conceptualization is one of the most critical points that prevents the consolidation of a firm basis for an agreed networked ontology infrastructure. For example, the conceptualization of a process defined by the om-lite ontology (oml:Process) includes sensors, protocols or workflows, while the SOSA/SSN ontology’s procedure (sosa:Procedure) does not consider sensors, as part of its conceptualization. Another example of the mentioned issue is showcased in the definition of a space made by different ontologies. According to the SAREF4BLDG ontology, a space (s4bldg:Space) refers to an entity used to define physical spaces of a building, and the BOT (bot:Space) defines these spaces physically or notionally.
A trend towards a pattern-based design tends to produce modular ontologies that are more understandable and more easily extended or reengineered when necessary. The SSNO may be an example of this pattern-based design, and the IoT-O and the FIESTA-IoT ontologies may be considered extensions of the SSNO. Moreover, when some undesirable design decisions on the SSNO were spotted, its reengineering to the new SOSA/SSN ontology was clearly reasonable. The ODP design promotes the conceptualization of concise and simple ideas and, moreover, encourages to provide good metadata descriptions that may ease the usage, reuse and extension of the ontologies. For example, the SmartEnv modules were developed as the SOSA/SSN ontology extensions. The SEAS ontology and the BOT are other representative ontologies of this pattern-based design. As a matter of fact, this trend towards lightweight ontologies is preferred by the Linked Data and Schema.org communities [44]. Conversely, ontologies such as the ifcOWL ontology or the DogOnt which contain hundreds of terms are more likely to incur in conceptual disagreements with other community partners.
Finally, the explicit alignment of terms from different ontologies as well as the mapping to upper-level ontologies promotes interoperability. More comprehensive alignments are favoured between the clearly conceptualized and well documented ontologies. The BOT offers a set of mappings to other domain ontologies such as the ifcOWL ontology, the Brick ontology, and the DogOnt. Both the SOSA/SSN and the SEAS ontologies publish collections of precise mapping files to other related ontologies. Unfortunately, few ontologies follow this practice, which may further impede the achievement of an interoperable ontology space. At times, it is claimed that ontologies include alignments with other ontologies, although in fact they are only imprecise relationships between concepts (e.g. the SAREF, the SAREF4BLDG and the REC Building ontologies).
In conclusion, when new ontology proposals appear and they overlap with existing ones but differ in fundamental aspects, it is difficult to say that an agreement has been reached on the ontologies that should form the basis on which to develop a infrastructure of interoperable ontologies in the domain of observations and actuations carried out in buildings. Nevertheless, it can be said that there exist some good ontologies which could be selected for being discussed in depth with the community, towards their polishing or completing their design, promoting updated versions of them that would achieve a wider consensus. After the review followed in this survey, authors would like to suggest ontologies like the SOSA/SSN and the SEAS ontologies in the observations and actuations domain, and the BOT in the building domain, to continue developing a firm basis towards the development of a networked ontology infrastructure for observations and actuations in buildings. Special attention should be paid to their appropriate networking with ontologies representing contextual information for observations and actuations in buildings, including spatio-temporal ontologies and ontologies about measurements and units topics.
Footnotes
Acknowledgements
This work is partly supported by the projects Internet of Food & Farms 2020 and RESPOND (integrated demand REsponse Solution towards energy POsitive NeighbourhooDs) which have received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 731884 and no. 768619 respectively. This work is also supported by PRE-2016-1-0303, IT1041-16-GBV and FEDER/TIN2016-78011-C4-2-R.