DogOnt as a viable seed for semantic modeling of AEC/FM

Abstract

Energy consumption and performance assessment of Smart Cities must consider different levels and various sub-domains. A comprehensive energy profile of a city, in fact, should work at the city, district, and building levels. At the same time and for each level, it should take into account both electrical and thermal consumptions, and gather these information from a plethora of different sensors and from various stakeholders (i.e., citizens, utilities, policy makers, and energy providers). Current modeling approaches for this context address each level and domain separately, thus preventing a structured and comprehensive approach to a unified energy representation. Moreover, current approaches make it difficult to keep the consistency between the energetic data through levels, sub-domains, and across stakeholders. Starting from an analysis of ontologies at the state-of-the-art, this paper shows how DogOnt can be used as a foundation towards a shared and unified model for such a context. DogOnt was firstly developed in 2008 and withstands over 8 years of usage without major failures and shortcomings. We discuss successful design choices and adaptations, which kept the model up-to-date and increasingly adopted in such a mid-term time frame for energy representation in Smart Cities.

Keywords

Built environment ontology smart city AEC/FM energy modeling

1. Introduction

In such a context, intelligent, and in particular, semantic-based approaches can be seen as viable solutions to extract sense from the vast sea of information made available by the large number of sensors spread all over the city, at different levels, and involving the various stakeholders. Several research groups and companies are working on techniques deriving from the Semantic Web and Artificial Intelligence to address the modeling of so many different aspects, be it at the application, sensing, or device level. Three initiatives, in particular, tackle this issue from different perspectives: the Linked Open Data (LOD) initiative, the Semantic Sensor Web (SSW) initiative, and the Semantic Big Data research activities.

Linked Open Data (LOD) [3] acts at the application level and it provides machine understandable, shared and open semantics for representing a wide set of knowledge domains in the world. While monolithic approaches aim at modeling entire domains in a comprehensive manner, thus leading to single, rigid and practically not-scalable representation models, the LOD approach exploits the linking and mapping primitives defined in OWL and integrates more than 295 datasets1

¹
Such a figure refers to 2011, with the number of datasets steadily increasing in the last years.

with over 31 billions of triples representing real data, from personal e-mail contacts to world nations, from medical topics to plane parts.

The Semantic Sensor Web (SSW) [27], instead, specifically focuses on sensing networks, thus aims to address the diversity of sensors and sensory data. To do so, it provides means for modeling sensor devices (and their capabilities), systems, and processes. The most important results of the SSW initiative are the Semantic Sensor Network (SSN) ontology, defined by the W3C SSN XG group that was active from 2009 to 2011, and the related Sensor, Observation, Sample, and Actuator (SOSA) ontology [20].

Finally, the Semantic Big Data research field2

A definition and some papers are available at https://www.ifis.uni-luebeck.de/~groppe/sbd/, last visited on July 4, 2017.

aims at empowering big data solutions (e.g., Complex Event Processing [26] or distributed data processing [8,22]) with semantic technologies such as ontologies as well as definitions and behavior (inference) rules, to tackle the data cardinality and the heterogeneity issue. This supports the transformation of “raw” data events into meaningful information conforming to a formal semantics, which, in turn, supports better understanding of situations (states) by machines (agents), better understanding of relationships between events and declarative processing of events, and reaction to situations (i.e., event patterns).

Current modeling approaches and initiatives, however, are too general for the energy context (e.g., SSW [27]) or too domain-specific(e.g., [30]), since they aim at modeling each level and domain separately. In this way, a structured and comprehensive approach to a unified energy representation is not possible and, similarly, it is difficult to maintain the data consistency between the energetic information through levels and across sub-domains.

This paper builds upon the motivations sustaining semantics as a viable solution to effectively tackling the energy domain in Smart Cities with a unified model. Starting from an analysis of ontologies at the state-of-the-art, the paper discusses an ontology representation, DogOnt,3

The DogOnt ontology is available at http://elite.polito.it/ontologies/dogont.owl.

that was firstly published 8 years ago [4] and was initially designed, and developed, to tackle interoperability issues in home automation networks.

In the past eight years, DogOnt evolved to tackle representation issues emerging from residential, building, and factory automation solutions. Lately, it included primitives for dealing with distributed networks of sensors deployed as part of smart buildings. Nowadays, DogOnt empowers several research projects needing uniform, semantic access to environment sensors and actuators. Those projects encompass several domains and field of interest. To exemplify, in the smart grid domain DogOnt has been used in the Leaf Island project (i.e., imported in the Leaf Ontology) [7], while in the JEERP project [6] it was used for building an Energy-Aware Enterprise Resource Planning. Furthermore, it has been incorporated in the EEOnt ontology [13] for providing an unified representation of energy efficiency in buildings, it has been used as “as a starting point for the specification of [some] concepts in ThinkHome” [25], adopted by the UniDA framework [29] for the integration and interoperation of devices in Human Interaction Environments, and it was among the most important sources used in the creation of the SAREF ETSI standard [11,15].

Eventually, it successfully supports abstraction of several standards including both Internet of Things (e.g., ZigBee4

⁴

E.g., the ZigBee Home Automation (HA) extension is available at http://elite.polito.it/ontologies/zigbee.owl.

) and non-IoT (e.g., Modbus) technologies. We claim and demonstrate that DogOnt can be used as a foundation towards a shared and unified model for the energy modeling in Smart Cities.

The remainder of this paper is organized as follows: Section 2 provides an up-to-date overview of the current modeling panorama for energy consumptions and assessment in Smart City settings. Section 3 introduces the DogOnt model in its current form, by discussing the foundations and showing practical modeling examples, while Section 4 motivates and illustrates why DogOnt can be used as a unified model for this context, thus serving as an evaluation of the proposed approach. Finally, Section 5 provides final remarks and discusses the foreseen evolutions in the next 5 years.

2. Ontology-based AEC/FM modeling

Energy performance assessment and representation demands for models able to deal with an increasing variety of ground truth data, generated through heterogeneous monitoring networks and devices. The emergence of IoT approaches to Smart Cities is stressing the importance of a uniform and machine understandable representation of the energy qualities of devices, rooms, buildings and, by extension, of districts and entire cities. This need is currently acknowledged by several research efforts, both industrial and academic, which aim at building domain ontologies to model energy consumption and performance. In the energy domain, ontologies are employed to define shared and common inter-language for performance evaluation, energy rating, device consumption profiling, etc. Approaches present in the literature, typically, address the energy domain by splitting the analysis along different forms of energy, i.e., electrical and thermal. On the one hand, this division permits to tackle the specificity of the single energy form and the related engineering domains. On the other hand, it prevents a structured and comprehensive approach to energy representation, at higher levels of detail, like at the district level.

2.1. Electrical sub-domain

Electric energy consumption is one of the most important aspects modeled in the smart environments (e.g., home and building) domain. Such an importance is related to the amount of “saving” that can be achieved by considering energy management as fundamental part of home and building automation. Approaches for modeling energy consumption in smart environments mainly address the problem under two complimentary point of views. The first aims at modeling instantaneous consumption, i.e., consumption levels associated to specific, observable states of devices and appliances. The last, instead, considers the overall consumption “profile” of a given electric device, i.e., the sequence of consumption levels associated to a complete “working” cycle.

As an example, consider a washing machine. The first approach finely models the machine consumption when spinning, heating water, drying clothes, etc. while inferring the current consumption according to the machine state. The second, instead, considers complete washing cycles (e.g., delicate washing) and models the energy consumption trend with respect to time, often in discrete steps.

PowerOnt [5]5

⁵
An extension of DogOnt designed and developed by the authors and available at http://elite.polito.it/ontologies/poweront.owl.

follows the first approach and provides a lightweight ontology that models consumption associated to specific states of devices. A rather coarse, yet modular, approach is used for defining three levels of consumption for each state, with increasing level of details. States are associated with a typical consumption (in Watt) which is derived from catalogs of device categories, e.g., “A class” fridges. Such a typical consumption can be better specified if the nominal consumption rate is available for the specific state. Finally, the model provides means to model the actual consumption of the device, in a given state, extracted through direct metering. No notion of time is included in the model, and no direct/explicit support to thermal energy is provided. However, the model is general enough to represent both thermal and electric energy, with a little extension.

The challenge of representing electric device consumption has been tackled in several initiatives driven by home automation standardization bodies. Among these, the Energy@Home consortium,6

⁶

http://www.energy-home.it, last visited on April 05, 2017.

which was involved in the definition of the ZigBee Smart Energy [32] and Home Automation [31] specifications, tackled energy consumption modeling in terms of energy profiles, i.e., of sequences of consumption levels, which evolve in time depending on the device type/operating cycle. Unfortunately, such profiles have not been formalized in terms of ontologies and they have only been modeled in terms of data-types associated to specific ZigBee clusters.

In the last years, the increasing need for standardization of energy consumption modeling and representation promoted the European initiative on Energy Using and Producing Products [12], which lead to the creation of the Smart Appliances Reference ontology (SAREF [11]), now an ETSI standard [15]. SAREF formalizes in OWL the “energy profile” concept developed in the ZigBee Alliance, thus providing a standard, machine understandable representation of energy consumption of devices, over time. Moreover, it models explicitly the observable states of devices7

⁷

As DogOnt was among the most important input sources used in the creation of SAREF.

and is therefore directly linkable with PowerOnt. This offers a complete modeling of both instantaneous and temporal energy consumption. It must be noted that, although SAREF implicitly assumes that devices are “electrical” and that the associated consumption is related to the “electricity” form of energy, no formal constraints prevent modeling primitives to be exploited for representing thermal quantities. As such, SAREF can be considered a nice merger for the two sub-domains.

With respect to DogOnt, whose first edition is antecedent the release of SAREF, the latter has considered more than 23 base ontologies in its design, while DogOnt was designed and built on the basis of the former standard models for the home automation and appliances domains, e.g., the EHS taxonomy and the DomoML ontologies [18]. Nevertheless, in its evolutions, DogOnt incorporated many modeling primitives and representation choices deriving from other related models, and its success in such a task is proven by its extensive adoption in SAREF. It is important to notice that here the authors are not claiming that the modeling approach and solutions provided by DogOnt are better than those supported by SAREF. Instead, they strongly sustain the adoption of SAREF as reference model, in particular considering the latest extensions for energy [17] and building [16]. The main rationale of presenting DogOnt as a possible seed for AEC/FM modeling is providing a first “unified modeling” core, SAREF-compatible and able to easily include/map existing energy-related models relying on DogOnt, e.g., [25] and [13] . In perspective, the authors aim at bootstrapping mappings between such models and the ETSI standards, exploiting the common model described in this paper.

While SAREF tackles energy consumption modeling at the device level, ThinkHome [25] (that also exploits many of the DogOnt concepts for modeling devices) addresses energy representation with a more structured approach. In fact, it considers building information for supporting optimized control strategies striving for energy-efficient operation of smart environments. It achieved this goal by explicitly integrating data stored in Building Information Models (BIM). Both Industry Foundation Classes (IFC) concepts and Green Building XML specifications [14] are supported.

The common modeling base shared by SAREF, PowerOnt and ThinkHome, i.e., DogOnt, provides a strong hint on the viability of a unified energy modeling framework, based on ontologies, able to deal with different levels of detail from single devices to full homes and buildings, regardless of the energy form.

The latter aspect, which is worth citing in the electrical domain, regards consumption flexibility, i.e., the ability to perform temporal load switches depending on both internal (self-production) or external (active demand-response) constraints. In such a context, some attempts can be cited which tackle the flexibility challenge by exploiting a formal, ontology-based modeling. Among them, the MIRABEL project defines the FlexOffer ontology [30] and represents objects involved in energy flexibility systems and their relationships. It provides a conceptual framework where the flexibility concept is defined and set in relation with building information and smart grid data. FlexOffer is mainly intended as a tool for supporting IT and Energy stakeholders to handle supply and demand of energy, using a common inter-operation language. In addition, FlexOffer is partly integrated in SAREF, thus being easily reconducted to the SAREF modeling base ontology.

2.2. Thermal sub-domain

Ontologies addressing energy profiling under the thermal standpoint typically represent the temporal evolution of consumption, since instantaneous data is less relevant in environments where time constants are of the order of minutes or hours. In the thermal domain, most of the ontology-based models address energy performance evaluation in terms of multiple energy efficiency indexes, as prescribed by the European Energy Performance of Buildings Directive (EPBD), which imposes the adoption of measures for improving energy efficiency in buildings.

The Energy Efficiency Ontology (EEOnt) [13], for example, provides a semantics-rich, representation of energy data in terms of EPBD objectives, thus offering means to model buildings and energy efficiency in a unified way. Moreover, it provides tools for building energy assessment inventories, enabling the creation of formal, machine understandable and easily assessable certification schemes.

Similarly to most of the ontologies described for the electrical sub-domain, EEOnt builds upon the work done in DogOnt [4] and its extensions. Through DogOnt, appliance properties are exposed according to existing semantic models, while power consumption is modeled by introducing a specific Energy Profile ontology (i.e., PowerOnt [5]). EEOnt explicitly represents links between building components and corresponding energy efficiency indexes, which is clearly complimentary to the ThinkHome approach.

The SmartCoDE ontology model [1], instead, represents the thermal homologous of profile-based modeling of electric consumption. It provides a classification of Energy using Products (EuPs) into seven categories based on their compound temporal and energy behavior. Included categories are: (a) variable services; (b) thermal services, (c) schedulable services, (d) event-timeout services, (e) charge control, (f) complete control, and (g) custom control. Moreover, an energy management and a cost profile characterize each product. SmartCoDe mappings with SAREF exists and can be easily obtained [19].

2.3. City and district-level modeling

Systemic views of energy consumption are gaining momentum, thanks to an increasing demand for representing building energy profiles in the context of a wider district- or city-level vision. The Urban Energy Ontology (UEO),8

⁸
http://www.semanco-tools.eu/urban-enery-ontology, last visited on April 05, 2017.

elaborated in the SEMANCO project,9

⁹

http://www.semanco-project.eu/, last visited on April 05, 2017.

among many similar initiatives, describes the domain of urban planning based on the SUMO upper-level ontology [24]. It includes concepts derived from diverse sources, and related to the domain of urban planning and energy management. UEO encompasses terms and attributes for describing regions, cities, district and buildings, energy consumption profiles and CO2 emission indicators, together with climate and socio-economic factors that influence energy consumption.

The CERISE CIM Profile for Smart Grids, i.e., the Common Information Model developed by the Cerise-SG project,10

¹⁰

http://ns.cerise-project.nl/energy/def/cim-smartgrid, last visited on April 05, 2017.

addresses interoperability of information exchanged between smart grids, public authorities, and geographical information. The Cerise-SG project, in particular, developed semantic model transformation services bridging the gaps between modeling domains relevant to smart grids (e.g., as in Gridpedia11

¹¹

an RDF/XML model for the smart grid domain: http://gridpedia.org, last visited on April 05, 2017.

), and providing alignment and conflict resolution facilities. The Energy in Buildings Ontology12

¹²

http://www.planergy.it/file/EiBOv1.owl, last visited on April 05, 2017.

is another attempt to provide a systematic framework for city-level energy modeling. It provides a reference model for publishing energy performance data of public buildings in Italy, with a Linked Open Data approach. With respect to the previous models, and in addition to building-level representations, it addresses and represents energy flows incoming and outgoing from a building district.

Other relevant standards, at the city and district level, such as the LandXML13

¹³

http://landxml.org/, last visited on July 19, 2017.

model for legal boundaries are worth considering, although they still lack a formal representation as ontologies, thus making the integration at this level even harder. Some approaches, however, are starting to appear, which aim at mapping such models to corresponding ontology-based representations, e.g., the OWL translation of the OGC CityGML14

¹⁴

http://cui.unige.ch/isi/onto/citygml2.0.owl, last visited on September 06, 2017.

XML standard,15

¹⁵

https://www.citygml.org/, last visited on July 19, 2017.

the LADM OWL ontology developed at the DELFT university [23] or the approach to fusion of CityGML and LandXML proposed by Soon et al. [28].

3. DogOnt

3.1. Overview

The DogOnt ontology aims at offering a uniform, extensible model for all devices being part of a smart environment, no matter if at the home, building or district level. Its major focus is on device modeling, for all the aspects needed to abstract device “capabilities” from low-level idiosyncrasies and communication issues. This enables both abstract reasoning on devices, e.g., to find similar devices or to identify the most suitable output to which forward urgent notifications, and actual integration of different technologies, and paradigms. DogOnt was firstly introduced in 2008 [4] and was originally meant to represent home automation devices for interoperability support. Currently at version 4.0, DogOnt underwent several reviews and amendments in the past years, and its scope was widened to include devices and technologies typically part of an indoor IoT network (e.g., through the cluster-based ZigBee HA extension16

¹⁶
e.g., available at http://elite.polito.it/ontologies/zigbee.owl.

or by incorporating the Philips Hue devices in the ontology). If the original focus was more on modeling operational aspects enabling device control, the latest version, discussed in this paper, has moved to a more informed, modular, and linked modeling approach which enables adoption of DogOnt-based representations at different abstraction layers. Device control and interoperability is still one of the pillars of the representation, but extensibility, modularity, and service-based representation of heterogeneous entities (IoT and non-IoT devices) empower the latest versions of the ontology, thus enabling modular integration and reconciliation of different specifications, e.g., the ZigBee HA model and the registry-based Modbus data representation. More attention is also devoted to the Linked Open Data initiative: the ontology is now listed in the Linked Open Vocabulary data set17

¹⁷

http://lov.okfn.org/dataset/lov/about/, last visited on July 05, 2017.

and its connections with well-known ontologies (see Fig. 1) are being improved day by day.

Fig. 1.

DogOnt relations with well-known ontologies.

If in the first release of DogOnt the main target stakeholders were system integrators and developers dealing with issues related to interoperability of different home and building automation systems, the last version of DogOnt, here summarized, targets a much wider user base including: system integrators, developers, IoT companies, IoT developers, data analysts and in general any stakeholder having the need to access and represent IoT data according to a uniform, standard and machine understandable model.

From a very high-level perspective, the ontology is deployed along three main hierarchies of concepts, supported by four additional trees that better specify the knowledge encoded in the main topics. The three hierarchies are respectively rooted at BuildingThing, Functionality and State (Fig. 2).

Fig. 2.

The main representation pillars.

The BuildingThing hierarchy is one of the pillars of the DogOnt ontology and is completely devoted to the description of objects contained inside architectural spaces. These object are divided in Controllable and UnControllable entities. The former represent any device that can be somewhat controlled into a closed environment, i.e., it represents the nodes of any smart environment network. The latter, instead, represents all physical, inanimate objects contained in an indoor environment, including furniture, inner walls and partitions, etc. This hierarchy is strictly interconnected with the other two main pillars of the representation: the Functionality and the State trees of classes.

Functionality is the top concept of a class hierarchy that was originally designed to represent devices under an operational perspective. Each device was given a set of functionality which completely specified the device type, allowing - for example - classification reasoning. In the latest ontology evolution, the functionality representation has moved to a more service oriented approach,18

¹⁸

In such a sense also the “Functionality” name is undergoing a serious review process to better reflect the new nature of modeled concepts.

where each device offers a well known set of services, and sufficient conditions are provided to categorize devices as belonging to a specific class. However, modelers are free to represent entities offering an arbitrary set of services (functionality), not necessarily corresponding to actual device capabilities (e.g., virtual or high-level functionality such as energy management [19] or energy profiling).

Finally, concepts inheriting from the State class model the current condition of a device (Controllable, in DogOnt), using the Harel’s state chart semantics [21] as reference model and allowing devices to assume multiple states at the same time, with different state values. For example, a smart microwave oven which is heating a frozen meal can be modeled as being in the “on”, “defrosting”, and “emitting microwaves” states at the same time. This enables higher flexibility in modeling, and permits to tackle different abstraction levels and different granularity depending on specific application cases.

On the formal standpoint, DogOnt is an OWL2 DL compliant ontology with $ALCHIQ (D)$ 19

¹⁹

$A L$ indicates the base language allowing atomic negation, concept intersection, universal restrictions and limited existential qualifications; C means complex concept negation; H defines support for role hierarchies (subproperties); I provides inverse relationships; Q defines support for qualified cardinality restrictions and $(D)$ indicates the capability to handle datatype properties and expressions.

expressivity. It counts 896 classes and 6654 axioms. The current version (3.2.13) is released under the Apache 2.0 License and is reachable at the corresponding namespace20

²⁰

http://elite.polito.it/ontologies/dogont.owl

through content negotiation, as suggested by the W3C guidelines on RDF vocabulary publishing [2]. Table 1 summarizes the main ontology metrics.

Table 1

DogOnt metrics

Metric	Value
Axioms	6654
Logical axioms count	5221
Class count	896
Object properties count	30
Data properties count	46
Individuals count	0
DL Expressivity	$ALCHIQ (D)$
SubClassOf axioms count	2595
Equivalent classes axioms count	2
Disjoint classes count	2425

As can easily be noticed, DogOnt adopts a modeling paradigm that maintains a clear separation between ontology schema and instances (0 instances in the main ontology). In such a way, environment descriptions are independent and slowly evolving knowledge (the schema) is well separated from quickly changing models (environment representations).

Subsequent paragraphs better detail the DogOnt model with respect to devices and surrounding environments.

3.2. Device modeling

Devices and sensors corresponding to physical objects, or behaving as (virtual) physical devices, are represented as subclasses of the main Controllable concept (equivalent to the Device class defined in the SSN ontology). Controllables are further specialized into Appliances, HousePlants and NetworkComponent (Fig. 3), which respectively identify smart objects (e.g., fridges, washing machines, etc.), sensors and actuators,21

²¹
The common ancestor concept name (HousePlants) is under revision as it is no more intended to represent devices belonging to house plants, only.

and physical layer components, i.e., devices whose main function is to guarantee physical communication of real devices (e.g., network controllers, gateways, etc.).

Fig. 3.

Controllable subclasses.

While the initial modeling approach was mainly descriptive and modeled device operations through single, shared instances of subclasses of the Functionality concept, the current ontology adopts a strong service-oriented approach where devices and operations (functionality classes) are associated by means of object properties (dogont:hasFunctionality). Every modeled device, in other words, is described as an entity having a (variable) set of functionality and states. While several device classes (over 400) are already described in the ontology, and their functionality predefined through owl:someValuesFrom restrictions (Fig. 4 shows an example), modelers are free to create their own classes (and/or instances) by composing functionality and states through the dogont:hasFunctionality and dogont:hasState relations.

Fig. 4.

An example of device class predefined in the ontology.

The set of named devices defined in DogOnt encompasses devices included in the early European Home System (EHS) taxonomy, in the ZigBee device specification for Smart Metering and Home Automation, plus several other entities typically occurring in actuation and metering infrastructures (e.g., in indoor IoT networks). Nevertheless, this structure can easily be extended to support generic device definition, by removing the indoor constraint, and by adopting a more general naming schema less bounded to typical indoor systems, e.g., by renaming the Controllable class to ConnectedDevice, and so on.

Predefined device classes, in DogOnt, are organized in the main three hierarchies reported in Fig. 3, which are further subdivided in commonly used categories. Appliances are split along the main white and brown goods categories, respectively referring to big appliances such as fridges, ovens, stoves and to small devices such as TVs, Hi-Fi systems, etc. HousePlants are divided into sub-systems each pertaining a single, homogeneous field of application and include the electric, the Heating, Ventilating and Air Conditioning (HVAC), and the security (e.g., smoke or movement sensors) sub-systems. NetworkComponents are eventually organized according to the physical network they represent, e.g., ZigBeeComponent for ZigBee networks, ModbusComponent for Modbus networks, HueComponent for the Philips Hue connected lighting system, and so on. While Appliances and HousePlants are completely independent from network specific information and can be freely adopted to abstract any physical device in terms of supported functionality and possible states, the concepts belonging to the NetworkComponent tree are designed to “attach” network-specific data to abstract devices (through multiple typing), thus enabling low level access to the underlying physical sensor (e.g., through a gateway software). Section 3.4 reports a complete, yet simple, modeling walkthrough to better clarify the notions introduced here.

The concepts hierarchy stemming from the Functionality root defines the possible services (or operations) that devices can provide. Such services are categorized on the kind of interaction they support/imply. In particular, 3 different types of interactions are considered: query, notification and control. They are modeled by the sub-trees of classes rooted at QueryFunctionality, NotificationFunctionality and ControlFunctionality, respectively.

Query functionality model all possible interrogations that a device could answer to. They represent the typical request-based (or polling-based) interaction between devices and applications aimed at gathering data at application-driven instants. They represent, in other words, those device services that provide data upon explicit request, e.g., to get the current power consumption from an electricity meter or to obtain the amount of cars counted by a vehicles counter sensor. Notification functionality, on the converse, represent event-driven interactions between devices and applications, i.e., they represent the ability of a device to autonomously notify new data, e.g., measures, current state, etc. Eventually, control functionality represent the actuation (and configuration) capabilities of a device. They permit to associate pre-defined set of commands (modeled by Command instances) to devices, thus allowing to completely model the device capabilities at an abstract, technology-independent level. For the sake of clarity, control functionality can be seen as abstract, shared interfaces that define how a device can be controlled by applications (or end-users).

Control and notification functionality are complemented by two auxiliary set of classes respectively rooted at Command and Notification, which are exploited to attach predefined set of commands (notifications) to functionality modeled in DogOnt. For instance, an OnOffControlFunctionality is defined as having at least one OnCommand and one OffCommand by means of suitable OWL restrictions (owl:someValuesFrom), as shown in Fig. 5.

Fig. 5.

Example of functionality modeling.

While concepts inheriting from the Functionality class model services offered by a given device, the current device state is represented by means of the hierarchy of concepts stemming from the root State class, and can assume several StateValues depending on its definition. State modeling, in DogOnt, follows the Harel’s statechart semantics (Hierarchical FSMs) which provides support for complex state descriptions including parallel states, history states, clustering, and refinement. Such a semantics well adapts to complex behavior of real-world sensors and permits to represent complex devices as having multiple state values at the same time. For instance, a smart plug might be at the same time on, and measuring electric power, and so on. It should be noted, however, that statecharts semantics does not imply exact modeling of any real device state, as this is often unfeasible. Real devices might, in fact, evolve through several, unknown, internal states which are of little interest for actual interaction in EAC/FM scenarios. Therefore, modeled states are typically a subset of actual device states, and mostly refer to observable conditions in which the device might be. Figure 6 reports an example of state modeling for color dimmable lamps.

Fig. 6.

State modeling for color dimmable lamps.

Both functionality and states are partitioned in descriptions of properties assuming real and discrete values, as defined in the former ontology versions. However, in the presented ontology, the formal representation of functionality and states assuming real values has been improved by accounting explicitly the associated unit of measures, thanks to a tighter integration with the well established UCUM/MUO ontologies.22

²²

http://idi.fundacionctic.org/muo/, last visited on April 04, 2017.

3.3. Environment modeling

Concepts stemming from BuildingEnvironment and from the UnControllable branch of the BuildingThing hierarchy provide means to describe the environment hosting the modeled devices, and in particular to roughly represent the architectural spaces (i.e., rooms, etc.) containing the modeled network. Such a hierarchy has remained almost unchanged since 2008, therefore we provide a general overview of the adopted modeling paradigm, only, while interested readers may look at the original publication [4].

Environment modeling in 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 as instances of the Building concepts. (b) Storeys, as part of multi-storey buildings. (c) Flats, either located on single or multiple storeys. (d) Rooms inside flats and other indoor locations (e.g. Garages) located outside flats; (e) Walls, ceilings, floors, partitions, doors and windows composing both rooms and building boundaries.

Positioning is addressed by simple containment relations, i.e., dogont:IsIn whereas dedicated relations are defined to represent environment composition in flats, rooms, etc. Figure 7 depicts a typical room definition.

Fig. 7.

Example room modeling, in RDF/XML syntax.

Extensions are currently under development to link DogOnt concepts to positioning ontologies capable of handling indoor positioning systems. In particular, while exploiting the W3C WGS84 for localizing the “origin point” of a building, storey or room, we are planning to integrate relative $x y z$ (in meters) positioning as typically provided by indoor localization systems, e.g., based on the Ultra Wide Band (UWB) technology. Accurate modeling, e.g., exploiting Region Connection Calculus [9] and other well known, and widely recognized modeling paradigms is still under refinement and out of the scope of this paper.

3.4. Modeling walk-through

To better clarify how DogOnt can be exploited to model devices and networks, and the services they offer, a sample modeling walk-through is reported in this section. Lets assume a Smart Energy context in which a given indoor environment is hosting a sensing network to monitor energy consumption of appliances, smart home devices, sensors and actuators, e.g., for implementing Smart Grid or Demand-side Management Policies (e.g., as in the GreenCom EU project23

²³
http://www.greencom-project.eu, last visited on April 05, 2017.

). In such a context several smart plugs (using whichever communication technology, e.g., Z-Wave or ZigBee) are wirelessly interconnected to a network coordinator and provide information about current energy and power consumption. Despite the simplistic nature of the scenario, lets consider the case in which several buildings are participating to the initiative each exploiting a different smart plug technology. In such a case, DogOnt easily supports abstraction of services and capabilities offered by involved devices and offers a common representation layer exploitable, for instance, to implement technology-independent Smart Energy Management Systems.

For the sake of simplicity, let us shrink down the problem to the representation of a single metering plug measuring the consumption of a traditional oven located in the kitchen of a given house participating in the project. As the smart-plug object is already modeled in DogOnt by means of the MeteringPowerOutlet concept definition, the modeling process simply consists in creating the individuals needed to represent the given plug, the oven, the room, and the house in which the plug is placed.

The aforementioned modeling approach follows a simple, yet general, set of representation steps:

identify the object to represent and the corresponding DogOnt concept (if exists);

model the object according to the DogOnt class definition including functionality and states, as imposed by DogOnt-defined constraints;

define individuals for additional functionality and states (not available in the pre-defined class specification);

model any object that is functional to the correct representation of the initial object (e.g., connected devices for the smart plug scenario);

model the environment(s) in which the objects are placed;

model any explicit relation between objects, e.g., the control relation between a switch and its corresponding actuator;

model the network-specific information allowing to interface real-devices, e.g., by adopting a gateway software.

The final result of these steps applied to the sample metering plug is reported in Fig. 11, while the process applied in steps 1-3, 4 and 5 is better detailed in Fig. 8.

3.4.1. Steps 1–3

The first three steps of the modeling methodology tackle the representation of the device in focus, i.e., of the sample smart plug, Fig. 8 shows the corresponding activity diagram.

Fig. 8.

Activity diagram describing steps from 1 to 3. Step 4 and 5 follow a similar process.

Fig. 9.

Modeling approach applied to a smart plug, steps from 1–3.

The earliest step in this phase involves a quick browsing of devices currently supported in DogOnt. As a general hint, in this phase, the more quick approach to browsing is “thinking” at system-level: the plug is part of a general electric system/plant, and it is something that can be controlled. The corresponding DogOnt concept, if available, should therefore be under the Controllable concept, possibly located in the ElectricSystem subtree, which in turn stems from the HousePlants class. By browsing the concepts immediately inheriting from the ElectricSystem, it is easy to notice 2 candidate subtrees, respectively rooted at PowerDelivery and Meter. Few hierarchy levels below, the two subtrees converge on the PowerMeteringPowerOutlet class, which perfectly matches the sample smart plug; for the sake of simplicity we assume here that the plug is only able to measure the instantaneous power absorbed by connected electrical loads.

At this point, the modeler shall concentrate on the class definition, where mandatory relations and properties are defined through suitable OWL2 restrictions (constraints). In the PowerMeteringPowerOutlet case, these restrictions (either locally defined or inherited through all the concept ancestors) define the plug (see Fig. 9) as having:

an OnOffFunctionality, i.e., the ability to be turned on and off;

an OnOffNotificationFunctionality, i.e., the ability to autonomously generate events about the current activation state of the plug, e.g., to detect external control events;

a SinglePhaseActivePowerMeteringFunctionality, i.e, the ability to measure currently consumed power and to be queried about current consumption;

a SinglePhaseActivePowerMeteringNotificationFunctionality i.e., the ability to autonomously generate events about the current consumption of connected electrical loads;

an OnOffState, modeling the state assumed by the plug, reflecting its ability to be providing power to connected devices, or not;

a SinglePhaseActivePowerMeasurementState, representing the current state in terms of the currently measured consumption value, and the relative unit of measure.

A suitable instance shall be created for each concept involved into such existential constraints, and the process must be recursively repeated on each of the newly created models. It must be noticed the complete absence of any technology-specific detail in the representation generated so far.

Fig. 10.

Modeling approach applied to a smart plug, step 4.

3.4.2. Step 4

The fourth modeling step involves the analysis of the existing relations between the device in focus (the smart plug) and the other devices present in the same smart environment context. Relations modeling in DogOnt is quite lightweight, and mainly 3 relation families are represented: control,connection and metering. The former represents the fact that a device can control/be controlled by another device, e.g., a switch that controls a lamp. The second is specifically related to instances of classes stemming from the PowerDelivery concept and represents the fact that a device is connected to a power delivery object to draw the electric energy needed to provide its own functions. The latter, allows modeling the process of measuring physical quantities of interest, over a set of devices: for example, it permits to specify which set of electrical loads are monitored by a given power meter.

In this modeling step (4th) these relations are analyzed to find devices and, more in general, objects forming the context surrounding a given object, focus of the modeling process. In the sample smart plug case, a single electric load is connected to the plug: a “standing” lamp, with no intelligence on board. As the plug only powers one device, also the metering relation will involve only one instance, i.e., the same lamp. If we assume that our plug is controlled by a remote switch, e.g., located inside the same room of the plug, we finally obtain the result in Fig. 10 where the plug model has been omitted to concentrate on objects modeled in this step.

3.4.3. Step 5

In this step the “built” environment in which objects are placed is represented, including all architectural features as well as all “relevant” UnControllable elements. In the considered example, the main involved entity is the room containing the plug, the switch and the standing lamp. The instantiation process is almost equal to the one followed in steps 1 to 3 for controllable objects and is omitted here for the sake of clarity.

3.4.4. Step 6

The sixth step is the last technology-independent modeling step and provides the complete representation of concepts involved in the described modeling exercise. In such a step, previously isolated models are connected through object properties and corresponding instances are related, thus allowing to perform inferences on the represented information; e.g., to derive that since the lamp is connected to the plug, turning the plug also causes the lamp to be switched off. Figure 11 reports the full model.

Fig. 11.

Modeling approach applied to a smart plug, step 6.

4. Is end-to-end modeling possible?

Given the survey of current energy modeling efforts reported in Section 2, it clearly emerges that energy consumption modeling at district and city level is feasible, and can be achieved on the basis of a solid, standard and shared modeling framework based on ontologies. Among the analyzed efforts, DogOnt proved to be a solid baseline model for high granularity information on device states, which can be easily related to both instantaneous (PowerOnt) and temporal (e.g., as in SAREF) behaviors in terms of energy. Due to existing connections between DogOnt and the SAREF ETSI standard [15], any effort for exploiting DogOnt as a seed for end-to-end modeling of the AEC/FM domain can also be seen as a concrete possibility of defining a “unified modeling framework” for the AEC/FM domain based on standard representations (ETSI) and Linked Open Data approaches.

Clearly, some needed glue layers are still missing. In particular when crossing the modeling domains, from bottom layers (devices) to higher layers (district) modeling gaps and inconsistencies emerge and need to be addressed. In the following subsections, initial mappings between layers are, therefore, discussed and their relations with the DogOnt ontology are highlighted. Clearly no fully applicable, generally viable solution can be identified. Nevertheless, end-to-end modeling of the AEC/FM domain seems feasible and most of the gaps appear to be bridgeable through suitable ontology-mappings, many of those basing on DogOnt. This confirms the potential validity of the authors’ initial claim.

Fig. 12.

Oversimplified mappings between DogOnt and ThinkHome.

4.1. Device to building mappings

Bridging the device-level representation addressed by DogOnt and the relative energy indicators abstracted at the building level is feasible and could be based on, for example, ThinkHome and EEOnt. Unfortunately, direct mappings between DogOnt and these building level ontologies, in the AEC/FM domain, are not always available. While for EEOnt links already exist, which for example relate the eeont:BuildingEnvironment concept to the corresponding dogont:BuildingEnvironment, or the eeont:Controllable and eeont:Uncontrollable classes with the homonym classes in Dogont, ThinkHome directly embeds concepts defined in DogOnt, breaking some of the original hierarchies and redefining some of the core classes. This re-use of single classes and/or model subsets, breaks the linking ontology principles and requires explicit mapping to be defined, possibly solving inconsistencies that might arise due to different approaches in modeling.

Fig. 13.

Relations between DogOnt, W3C BOT, and ThinkHome, oversimplified for the sake of clarity.

Still in this case some mappings can be defined which allow exploiting DogOnt as seed model. For example, single sensor and actuator classes in DogOnt can be directly mapped (through owl:equivalentClass relations) to corresponding concepts in ThinkHome (see, e.g., Fig. 12), while the building modeling branch rooted at thinkhome:BuildingEnvironment is completely equivalent to the one rooted at dogont:BuildingEnvironment. Moreover, some cross-fertilization might also be considered, e.g., evolving the DogOnt design to better account the different nature of network-specific components and more general devices and/or appliances, as done in ThinkHome.

Far more challenging would be setting up suitable mappings between same-level ontologies, e.g., between ThinkHome and EEOnt as they potentially follow completely different approaches to model the building-level information. Nevertheless, being both linkable to DogOnt, bridging over a common subset of “shared” classes is certainly feasible.

One of the initially unforeseen commonalities between DogOnt-based modeling and building-level ontologies, emerging from shared adoption of the former, is the rather abstract approach to representation of the built environment, in terms of rooms, walls, etc. While existing efforts in BIM modeling have extensively addressed the building modeling issues, in many applications of the energy domain BIM models are too detailed and include details which are often superfluous. As an example, modeling walls and openings is important for defining the energy indicators of a certain building, however, fine grained details on building materials may often be replaced by much lighter coefficients, thus reducing the computational footprint of the resulting model (e.g., as done in EEOnt). To acknowledge these common needs a dedicated W3C working group24

²⁴

https://w3c-lbd-cg.github.io/lbdw/, last visited on April 11, 2017.

is working on the definition of the so-called Building Topology (BOT) ontology, which largely shares the DogOnt modeling approach. In such a sense, defining links between BOT and DogOnt (and this is granted by direct participation of some of the authors to the working group) again enables the adoption of DogOnt a seed model for the AEC/FM domain (see Fig. 13).

4.2. Building to city and district mappings

At the district-level, ontologies providing district and city-level views of energy performance indicators and models for energy flows are available. However, a general lack of mappings between systematic representations at district-level and existing building-level characterizations, can be observed. Similarly to the device-to-building case, a possible modeling framework to bridge such a gap can exploit DogOnt as seed, optionally building atop of mappings defined at the building level. Considering the SEMANCO-HEAD ontology [10] as a viable example of district-level model developed in the context of the SEMANCO EU project25

²⁵
http://www.semanco-project.eu, last visited on April 11, 2017.

possible mappings with Dogont can indeed be established. In particular, connections can be defined between the semanco:Electrical_Appliances concept and the dogont:Appliances class, as well as between the semanco:Technical_Building_System and the dogont:HousePlants, see Fig. 14.

Fig. 14.

A very preliminary mapping between SEMANCO-HEAD and DogOnt.

These mappings are not yet published, nor completely checked: for example a possible inconsistency might arise from disjoint axioms in DogOnt that are potentially in conflict with the hierarchy relationship between semanco:Electrical_Appliances and semanco:Technical_Building_System. Nevertheless it appears clear that, with careful design of ontology interlinks DogOnt can also be exploited to bridge the gap between district and building level modeling. At least on some, almost shared subset of concepts including both the building modeling and the device modeling hierarchies.

5. Conclusions

In this paper we presented the latest edition of DogOnt (version 4.0) and we discussed its possible role as “emerging” seed for linked, shared modeling of the AEM/FC domain. While monolithic approaches to modeling are clearly not feasible, a linked-open data approach emerging bottom-up from currently adopted models can provide a suitable, shared modeling basis for this challenging domain. According to literature, the DogOnt ontology is starting to emerge as a possible seed to such a bottom-up process and many of the currently available ontologies in the AEC/FM domain can somewhat be referred to such an ontology. While introducing the latest modification to the DogOnt model, the authors highlighted how the emerging role of DogOnt can be sustained by the availability of official mappings between ontologies at the device, building and district levels.

The proposed mappings have various degrees of maturity and are neither exhaustive nor complete. The work presented in the paper, in fact, is more focused on fostering the definition of links between different modeling efforts in the AEC/FM domain rather than in completely specifying ontology mappings and alignments. Several open challenges remain to reach a sufficiently linked set of ontologies for Architecture/Engineering/Construction (AEC) and Facilities Management (FM), thus calling for further research from both the semantic modeling and the AEC/FM research communities.

References

Bell and

Bjørkhaug, A buildingSMART ontology, in: EWork and EBusiness in Architecture, Engineering and Construction. ECPPM 2006: Proceedings of the 6th European Conference on Product and Process Modelling, 13–15 September 2006, Valencia, Spain,

Martínez and

Scherer, eds, Taylor & Francis, 2006, pp. 185–190.

Berrueta and

Phipps (eds), Best practice recipes for publishing RDF vocabularies, W3C Working Group note, 28 August 2008, https://www.w3.org/TR/swbp-vocab-pub/.

Bizer,

Heath and

Berners-Lee, Linked data – The story so far, International Journal on Semantic Web and Information Systems (IJSWIS)5(3) (2009), 1–22. doi:10.4018/jswis.2009081901.

Bonino and

Corno, DogOnt – Ontology modeling for intelligent domotic environments, in: The Semantic Web – ISWC 2008, 7th International Semantic Web Conference, ISWC 2008, Karlsruhe, Germany, October 26–30, 2008. Proceedings,

A.P.

Sheth,

Staab,

Dean,

Paolucci,

Maynard,

T.W.

Finin and

Thirunarayan, eds, Lecture Notes in Computer Science, Vol. 5318, Springer, 2008, pp. 790–803. doi:10.1007/978-3-540-88564-1_51.

Bonino,

Corno and

De Russis, PowerOnt: An ontology-based approach for power consumption estimation in smart homes, in: Internet of Things. User-Centric IoT – First International Summit, IoT360 2014, Rome, Italy, October 27–28, 2014, Revised Selected Papers, Part I,

Giaffreda,

Vieriu,

Pásher,

Bendersky,

A.J.

Jara,

J.J.P.C.

Rodrigues,

Dekel and

Mandler, eds, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, Vol. 150, Springer, 2014, pp. 3–8. doi:10.1007/978-3-319-19656-5_1.

Bonino,

De Russis,

Corno and

Ferrero, JEERP: Energy-aware enterprise resource planning, IT Professional16(4) (2014), 50–56. doi:10.1109/MITP.2013.22.

Bonino and

Procaccianti, Exploiting semantic technologies in smart environments and grids: Emerging roles and case studies, Science of Computer Programming95 (2014), 112–134. doi:10.1016/j.scico.2014.02.018.

Boury-Brisset, Managing semantic big data for intelligence, in: Proceedings of the Eighth Conference on Semantic Technologies for Intelligence, Defense, and Security, Fairfax VA, USA, November 12–15, 2013,

K.B.

Laskey,

Emmons and

P.C.G.

da Costa, eds, CEUR Workshop Proceedings, Vol. 1097, CEUR-WS.org, 2013, pp. 41–47, http://ceur-ws.org/Vol-1097/STIDS2013_T06_Boury-Brisset.pdf .

A.G.

Cohn,

Bennett,

Gooday and

N.M.

Gotts, Qualitative spatial representation and reasoning with the region connection calculus, GeoInformatica1(3) (1997), 275–316. doi:10.1023/A:1009712514511.

10.

Corrado,

Ballarini,

Madrazo and

Nemirovski, Data structuring for the ontological modelling of urban energy systems: The experience of the SEMANCO project, Sustainable Cities and Society14 (2015), 223–235. doi:10.1016/j.scs.2014.09.006.

11.

Daniele,

F.T.H.

den Hartog and

Roes, Created in close interaction with the industry: The smart appliances REFerence (SAREF) ontology, in: Formal Ontologies Meet Industry – 7th International Workshop, FOMI 2015, Berlin, Germany, August 5, 2015, Proceedings,

Cuel and

Young, eds, Lecture Notes in Business Information Processing, Vol. 225, Springer, 2015, pp. 100–112. doi:10.1007/978-3-319-21545-7_9.

12.

L.M.

Daniele,

F.T.H.

den Hartog and

J.B.M.

Roes, Study on semantic assets for smart appliances interoperability – D-S4: Final report, Technical report, European Union, 2015, https://repository.tudelft.nl/view/tno/uuid:73c44272-1ac0-4acb-a359-423d053475a6/.

13.

J.J.V.

Díaz,

M.R.

Wilby,

A.B.R.

González and

J.G.

Munoz, EEOnt: An ontological model for a unified representation of energy efficiency in buildings, Energy and Buildings60 (2013), 20–27. doi:10.1016/j.enbuild.2013.01.012.

14.

Dong,

Lam,

Huang and

Dobbs, A comparative study of the IFC and gbXML informational infrastructures for data exchange in computational design support environments, in: Proceedings of the International Building Performance Simulation Conference (IBPSA) 2007, September 03–06, 2007, Beijing, China, Vol. 10, 2007, pp. 1530–1537, http://www.ibpsa.org/proceedings/BS2007/p363_final.pdf .

15.

ETSI Technical Committee Smart Machine-to-Machine Communications (SmartM2M), SmartM2M; smart appliances; reference ontology and oneM2M mapping, Technical Specification TS, 103 264 V2.1.1, ETSI, 2017, http://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf.

16.

ETSI Technical Committee Smart Machine-to-Machine Communications (SmartM2M), SmartM2M; smart appliances extension to SAREF; part 3: Building domain, Technical Specification TS, 103 410–3 V1.1.1, ETSI, 2017, http://www.etsi.org/deliver/etsi_ts/103400_103499/10341003/01.01.01_60/ts_10341003v010101p.pdf.

17.

ETSI Technical Committee Smart Machine-to-Machine Communications (SmartM2M), SmartM2M; smart appliances extension to SAREF; part 1: Energy domain, Technical Specification TS, 103 401–1 V1.1.1, ETSI, 2017, http://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.01.01_60/ts_10341001v010101p.pdf.

18.

Furfari,

Sommaruga,

Soria and

Fresco, DomoML: The definition of a standard markup for interoperability of human home interactions, in: EUSAI 2004: Proceedings of the 2nd European Union Symposium on Ambient Intelligence, ACM, New York, NY, USA, 2004, pp. 41–44. ISBN 1-58113-992-6.

19.

Grimm and

Bonino, Towards standardization of M2M communication in smart appliances, in: ICT for a Low Carbon Economy – EEBuilding Data Models – Energy Efficiency Vocabularies and Ontologies: Proceedings of the 4th Workshop Organised by the EEB Data Models Community ICT for Sustainable Places Nice, France, 9th–11th September, 2013, European Commission DG CONNECT H5 Smart Cities & Sustainability, 2014, pp. 61–71. doi:10.2759/40897.

20.

Haller,

Janowicz,

Cox,

Le Phuoc,

Taylor and

Lefrançois (eds), Semantic sensor network ontology, W3C Recommendation, 19 October 2017, https://www.w3.org/TR/vocab-ssn/.

21.

Harel, Statecharts: A visual formalism for complex systems, Science of Computer Programming8(3) (1987), 231–274. doi:10.1016/0167-6423(87)90035-9.

22.

Lee,

Chinthavali,

Duan and

Shankar, Utilizing semantic big data for realizing a national-scale infrastructure vulnerability analysis system, in: Proceedings of the International Workshop on Semantic Big Data, San Francisco, CA, USA, July 1, 2016,

Groppe and Le Gruenwald , eds, ACM, 2016, p. 3. doi:10.1145/2928294.2928295.

23.

Lemmen,

van Oosterom and

Bennett, The land administration domain model, Land Use Policy49 (2015), 535–545. doi:10.1016/j.landusepol.2015.01.014.

24.

Niles and

Pease, Origins of the IEEE standard upper ontology, in: Working Notes of the IJCAI-2001 Workshop on the IEEE Standard Upper Ontology, 2001, pp. 37–42.

25.

Reinisch,

M.J.

Kofler,

Iglesias and

Kastner, ThinkHome energy efficiency in future smart homes, EURASIP Journal on Embedded Systems2011 (2011). doi:10.1155/2011/104617.

26.

Schaaf,

S.G.

Grivas,

Ackermann,

Diekmann,

Koschel and

Astrova, Semantic complex event processing, in: Recent Researches in Applied Information Science: Proceedings of the 5th WSEAS Congress on Applied Computing Conference, and Proceedings of the 1st International Conference on Biologically Inspired Computation, BICA’12, World Scientific and Engineering Academy and Society (WSEAS), Stevens Point, Wisconsin, USA, 2012, pp. 38–43. ISBN 978-1-61804-089-3.

27.

Sheth,

Henson and

S.S.

Sahoo, Semantic sensor web, IEEE Internet Computing12(4) (2008), 78–83. doi:10.1109/MIC.2008.87.

28.

K.H.

Soon,

Thompson and

Khoo, Semantics-based fusion for CityGML and 3D LandXML, in: 4th International FIG 3D Cadastres Workshop, 9–11 November 2014, Dubai, United Arab Emirates, 2014, pp. 323–338, https://www.oicrf.org/-/semantics-based-fusion-for-citygml-and-3d-landxml .

29.

Varela,

Paz-Lopez,

J.A.

Becerra,

Vazquez-Rodriguez and

R.J.

Duro, UniDA: Uniform device access framework for human interaction environments, Sensors11(10) (2011), 9361–9392. doi:10.3390/s111009361.

30.

Verhoosel,

Rothengatter,

F.J.

Rumph and

Konsman, An ontology for modeling flexibility in smart grid energy management, in: EWork and EBusiness in Architecture, Engineering and Construction. ECPPM 2012: Proceedings of the 6th European Conference on Product and Process Modelling, 25–27 July 2012, Reykjavik, Iceland,

Gudnason and

Scherer, eds, CRC Press, 2012, pp. 931–938, https://repository.tudelft.nl/view/tno/uuid:bfe13c5f-a5db-4056-bc31-bde4f5ddd643/ . doi:10.1201/b12516-146.

31.

ZigBee Alliance Inc., ZigBee home automation, 2010, http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeehomeautomation.

32.

ZigBee Alliance Inc., ZigBee smart energy, 2014, http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeesmartenergy.