Semantic Web 0 (0) 1–0 1IOS Press

DogOnt as a Viable Seed for SemanticModeling of AEC/FMEditor(s): Álvaro Sicilia, Universitat Ramon Llull, Spain; Pieter Pauwels, Universiteit Gent, Belgium; Leandro Madrazo, Universitat RamonLlull, Spain; María Poveda Villalón, Universidad Politécnica de Madrid, Spain; Jérôme Euzenat, INRIA & Université Grenoble Alpes, FranceSolicited review(s): Laura Daniele, TNO, Netherlands; German Nemirovski, Hochschule Albstadt-Sigmaringen, Germany; One anonymousreviewer

Dario Bonino a,∗, Luigi De Russis b

a Istituto Superiore Mario Boella, Torino, ItalyE-mail: bonino@ismb.itb Dipartimento di Automatica e Informatica, Politecnico di Torino, Corso Duca degli Abruzzi 24, Torino, ItalyE-mail: luigi.derussis@polito.it

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 timeand for each level, it should take into account both electrical and thermal consumptions, and gather these information from aplethora of different sensors and from various stakeholders (i.e., citizens, utilities, policy makers, and energy providers). Currentmodeling approaches for this context address each level and domain separately, thus preventing a structured and comprehensiveapproach to a unified energy representation. Moreover, current approaches make it difficult to keep the consistency between theenergetic 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 wasfirstly developed in 2008 and withstands over 8 years of usage without major failures and shortcomings. We discuss successfuldesign choices and adaptations, which kept the model up-to-date and increasingly adopted in such a mid-term time frame forenergy representation in Smart Cities.

Keywords: Built Environment, Ontology, Smart City, AEC/FM, Energy Modeling

1. Introduction

Energy consumption and performance assessmentof Smart Cities must consider different levels andvarious sub-domains. A comprehensive energy pro-file of a city, in fact, should work at the city, district,and building levels. At the same time and for eachlevel, it should take into account both electrical andthermal consumptions, and gather these informationfrom a plethora of different heterogeneous sensors andfrom various stakeholders (i.e., citizens, utilities, pol-icy makers, and energy providers).

*Corresponding author. E-mail: bonino@ismb.it

In such a context, intelligent, and in particular,semantic-based approaches can be seen as viable so-lutions to extract sense from the vast sea of informa-tion made available by the large number of sensorsspread all over the city, at different levels, and involv-ing the various stakeholders. Several research groupsand companies are working on techniques derivingfrom the Semantic Web and Artificial Intelligence toaddress the modeling of so many different aspects, beit at the application, sensing, or device level. Three ini-tiatives, in particular, tackle this issue from differentperspectives: the Linked Open Data (LOD) initiative,the Semantic Sensor Web (SSW) initiative, and the Se-mantic Big Data research activities.

1570-0844/0-1900/$35.00 c© 0 – IOS Press and the authors. All rights reserved

2 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

Linked Open Data (LOD) [3] acts at the appli-cation level and it provides machine understandable,shared and open semantics for representing a wideset of knowledge domains in the world. While mono-lithic approaches aim at modeling entire domains ina comprehensive manner, thus leading to single, rigidand practically not-scalable representation models, theLOD approach exploits the linking and mapping prim-itives defined in OWL and integrates more than 295datasets1 with over 31 billions of triples representingreal data, from personal e-mail contacts to world na-tions, from medical topics to plane parts.

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

Finally, the Semantic Big Data research field2 aimsat empowering big data solutions (e.g., Complex EventProcessing [26] or distributed data processing [8,22])with semantic technologies such as ontologies as wellas definitions and behavior (inference) rules, to tacklethe data cardinality and the heterogeneity issue. Thissupports the transformation of “raw” data events intomeaningful information conforming to a formal se-mantics, which, in turn, supports better understand-ing of situations (states) by machines (agents), bet-ter understanding of relationships between events anddeclarative processing of events, and reaction to situa-tions (i.e., event patterns).

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

1Such a figure refers to 2011, with the number of datasets steadilyincreasing in the last years.

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

This paper builds upon the motivations sustainingsemantics as a viable solution to effectively tacklingthe energy domain in Smart Cities with a unifiedmodel. Starting from an analysis of ontologies at thestate-of-the-art, the paper discusses an ontology repre-sentation, DogOnt3, that was firstly published 8 yearsago [4] and was initially designed, and developed, totackle interoperability issues in home automation net-works.

In the past eight years, DogOnt evolved to tacklerepresentation issues emerging from residential, build-ing, and factory automation solutions. Lately, it in-cluded primitives for dealing with distributed networksof sensors deployed as part of smart buildings. Nowa-days, DogOnt empowers several research projectsneeding uniform, semantic access to environment sen-sors and actuators. Those projects encompass severaldomains and field of interest. To exemplify, in thesmart grid domain DogOnt has been used in the LeafIsland project (i.e., imported in the Leaf Ontology) [5],while in the JEERP project [7] it was used for buildingan Energy-Aware Enterprise Resource Planning. Fur-thermore, it has been incorporated in the EEOnt on-tology [13] for providing an unified representation ofenergy efficiency in buildings, it has been used as “as astarting point for the specification of [some] conceptsin ThinkHome” [25], adopted by the UniDA frame-work [29] for the integration and interoperation of de-vices in Human Interaction Environments, and it wasamong the most important sources used in the creationof the SAREF ETSI standard [11,15].

Eventually, it successfully supports abstraction ofseveral standards including both Internet of Things(e.g., ZigBee4) and non-IoT (e.g., Modbus) technolo-gies. We claim and demonstrate that DogOnt can beused as a foundation towards a shared and unifiedmodel 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 cur-rent modeling panorama for energy consumptions andassessment in Smart City settings. Section 3 introducesthe DogOnt model in its current form, by discussingthe foundations and showing practical modeling exam-ples, while Section 4 motivates and illustrates why Do-gOnt can be used as a unified model for this context,thus serving as an evaluation of the proposed approach.

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

4e.g., the ZigBee Home Automation (HA) extension is available athttp://elite.polito.it/ontologies/zigbee.owl.

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 3

Finally, Section 5 provides final remarks and discussesthe foreseen evolutions in the next 5 years.

2. Ontology-based AEC/FM modeling

Energy performance assessment and representationdemands for models able to deal with an increasing va-riety of ground truth data, generated through hetero-geneous monitoring networks and devices. The emer-gence of IoT approaches to Smart Cities is stressingthe importance of a uniform and machine understand-able representation of the energy qualities of devices,rooms, buildings and, by extension, of districts andentire cities. This need is currently acknowledged byseveral research efforts, both industrial and academic,which aim at building domain ontologies to model en-ergy consumption and performance. In the energy do-main, ontologies are employed to define shared andcommon inter-language for performance evaluation,energy rating, device consumption profiling, etc. Ap-proaches present in the literature, typically, address theenergy domain by splitting the analysis along differentforms of energy, i.e., electrical and thermal. On the onehand, this division permits to tackle the specificity ofthe single energy form and the related engineering do-mains. On the other hand, it prevents a structured andcomprehensive approach to energy representation, athigher levels of detail, like at the district level.

2.1. Electrical sub-domain

Electric energy consumption is one of the most im-portant aspects modeled in the smart environments(e.g., home and building) domain. Such an impor-tance is related to the amount of “saving” that can beachieved by considering energy management as fun-damental part of home and building automation. Ap-proaches for modeling energy consumption in smartenvironments mainly address the problem under twocomplimentary point of views. The first aims at model-ing instantaneous consumption, i.e., consumption lev-els associated to specific, observable states of devicesand appliances. The last, instead, considers the over-all consumption “profile” of a given electric device,i.e., the sequence of consumption levels associated toa complete “working” cycle.

As an example, consider a washing machine. Thefirst approach finely models the machine consump-tion when spinning, heating water, drying clothes, etc.while inferring the current consumption according to

the machine state. The second, instead, considers com-plete washing cycles (e.g., delicate washing) and mod-els the energy consumption trend with respect to time,often in discrete steps.

PowerOnt [6]5 follows the first approach and pro-vides a lightweight ontology that models consumptionassociated to specific states of devices. A rather coarse,yet modular, approach is used for defining three levelsof consumption for each state, with increasing level ofdetails. States are associated with a typical consump-tion (in Watt) which is derived from catalogs of de-vice categories, e.g., “A class” fridges. Such a typi-cal consumption can be better specified if the nominalconsumption rate is available for the specific state. Fi-nally, the model provides means to model the actualconsumption of the device, in a given state, extractedthrough direct metering. No notion of time is includedin the model, and no direct/explicit support to ther-mal energy is provided. However, the model is generalenough to represent both thermal and electric energy,with a little extension.

The challenge of representing electric device con-sumption has been tackled in several initiatives drivenby home automation standardization bodies. Amongthese, the Energy@Home consortium6, which was in-volved in the definition of the ZigBee Smart En-ergy [32] and Home Automation [31] specifications,tackled energy consumption modeling in terms of en-ergy profiles, i.e., of sequences of consumption levels,which evolve in time depending on the device type/-operating cycle. Unfortunately, such profiles have notbeen formalized in terms of ontologies and they haveonly been modeled in terms of data-types associated tospecific ZigBee clusters.

In the last years, the increasing need for standard-ization of energy consumption modeling and represen-tation promoted the European initiative on Energy Us-ing and Producing Products [12], which lead to thecreation of the Smart Appliances Reference ontology(SAREF [11]), now an ETSI standard [15]. SAREFformalizes in OWL the “energy profile” concept de-veloped in the ZigBee Alliance, thus providing a stan-dard, machine understandable representation of energyconsumption of devices, over time. Moreover, it mod-

5an extension of DogOnt designed and developed by the authorsand available at http://elite.polito.it/ontologies/poweront.owl

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

4 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

els explicitly the observable states of devices7 and istherefore directly linkable with PowerOnt. This offersa complete modeling of both instantaneous and tempo-ral energy consumption. It must be noted that, althoughSAREF implicitly assumes that devices are “electri-cal” and that the associated consumption is related tothe “electricity” form of energy, no formal constraintsprevent modeling primitives to be exploited for rep-resenting thermal quantities. As such, SAREF can beconsidered a nice merger for the two sub-domains.

With respect to DogOnt, whose first edition is an-tecedent the release of SAREF, the latter has consid-ered more than 23 base ontologies in its design, whileDogOnt was designed and built on the basis of theformer standard models for the home automation andappliances domains, e.g., the EHS taxonomy and theDomoML ontologies [18]. Nevertheless, in its evolu-tions, DogOnt incorporated many modeling primitivesand representation choices deriving from other relatedmodels, and its success in such a task is proven byits extensive adoption in SAREF. It is important tonotice that here the authors are not claiming that themodeling approach and solutions provided by DogOntare better than those supported by SAREF. Instead,they strongly sustain the adoption of SAREF as ref-erence model, in particular considering the latest ex-tensions for energy [17] and building [16]. The mainrationale of presenting DogOnt as a possible seed forAEC/FM modeling is providing a first “unified mod-eling” core, SAREF-compatible and able to easily in-clude/map existing energy-related models relying onDogOnt, e.g., [25] and [13] . In perspective, the authorsaim at bootstrapping mappings between such modelsand the ETSI standards, exploiting the common modeldescribed in this paper.

While SAREF tackles energy consumption model-ing at the device level, ThinkHome [25] (that also ex-ploits many of the DogOnt concepts for modeling de-vices) addresses energy representation with a morestructured approach. In fact, it considers building in-formation for supporting optimized control strategiesstriving for energy-efficient operation of smart en-vironments. It achieved this goal by explicitly inte-grating data stored in Building Information Models(BIM). Both Industry Foundation Classes (IFC) con-cepts and Green Building XML specifications [14] aresupported.

7as DogOnt was among the most important input sources used inthe creation of SAREF

The common modeling base shared by SAREF,PowerOnt and ThinkHome, i.e., DogOnt, provides astrong hint on the viability of a unified energy model-ing framework, based on ontologies, able to deal withdifferent levels of detail from single devices to fullhomes and buildings, regardless of the energy form.

The latter aspect, which is worth citing in the elec-trical domain, regards consumption flexibility, i.e., theability to perform temporal load switches dependingon both internal (self-production) or external (activedemand-response) constraints. In such a context, someattempts can be cited which tackle the flexibility chal-lenge by exploiting a formal, ontology-based mod-eling. Among them, the MIRABEL project definesthe FlexOffer ontology [30] and represents objects in-volved in energy flexibility systems and their relation-ships. It provides a conceptual framework where theflexibility concept is defined and set in relation withbuilding information and smart grid data. FlexOffer ismainly intended as a tool for supporting IT and En-ergy stakeholders to handle supply and demand of en-ergy, using a common inter-operation language. In ad-dition, FlexOffer is partly integrated in SAREF, thusbeing easily reconducted to the SAREF modeling baseontology.

2.2. Thermal sub-domain

Ontologies addressing energy profiling under thethermal standpoint typically represent the temporalevolution of consumption, since instantaneous data isless relevant in environments where time constants areof the order of minutes or hours. In the thermal do-main, most of the ontology-based models address en-ergy performance evaluation in terms of multiple en-ergy efficiency indexes, as prescribed by the EuropeanEnergy Performance of Buildings Directive (EPBD),which imposes the adoption of measures for improvingenergy efficiency in buildings.

The Energy Efficiency Ontology (EEOnt) [13], forexample, provides a semantics-rich, representation ofenergy data in terms of EPBD objectives, thus offeringmeans to model buildings and energy efficiency in aunified way. Moreover, it provides tools for buildingenergy assessment inventories, enabling the creation offormal, machine understandable and easily assessablecertification schemes.

Similarly to most of the ontologies described forthe electrical sub-domain, EEOnt builds upon the workdone in DogOnt [4] and its extensions. Through Do-gOnt, appliance properties are exposed according to

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 5

existing semantic models, while power consumptionis modeled by introducing a specific Energy Profileontology (i.e., PowerOnt [6]). EEOnt explicitly repre-sents links between building components and corre-sponding energy efficiency indexes, which is clearlycomplimentary to the ThinkHome approach.

The SmartCoDE ontology model [1], instead, repre-sents the thermal homologous of profile-based model-ing of electric consumption. It provides a classificationof Energy using Products (EuPs) into seven categoriesbased on their compound temporal and energy behav-ior. Included categories are:(a) variable services; (b)thermal services, (c) schedulable services, (d) event-timeout services, (e) charge control, (f) complete con-trol, and (g) custom control. Moreover, an energy man-agement and a cost profile characterize each product.SmartCoDe mappings with SAREF exists and can beeasily obtained [19].

2.3. City and district-level modeling

Systemic views of energy consumption are gain-ing momentum, thanks to an increasing demand forrepresenting building energy profiles in the context ofa wider district- or city-level vision. The Urban En-ergy Ontology (UEO)8, elaborated in the SEMANCOproject9, among many similar initiatives, describesthe domain of urban planning based on the SUMOupper-level ontology [24]. It includes concepts de-rived from diverse sources, and related to the domainof urban planning and energy management. UEO en-compasses terms and attributes for describing regions,cities, district and buildings, energy consumption pro-files and CO2 emission indicators, together with cli-mate and socio-economic factors that influence energyconsumption.

The CERISE CIM Profile for Smart Grids, i.e., theCommon Information Model developed by the Cerise-SG project10, addresses interoperability of informationexchanged between smart grids, public authorities, andgeographical information. The Cerise-SG project, inparticular, developed semantic model transformationservices bridging the gaps between modeling domains

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

9http://www.semanco-project.eu/, last visited onApril 05, 2017

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

relevant to smart grids (e.g., as in Gridpedia11), andproviding alignment and conflict resolution facilities.The Energy in Buildings Ontology12 is another attemptto provide a systematic framework for city-level en-ergy modeling. It provides a reference model for pub-lishing energy performance data of public buildings inItaly, with a Linked Open Data approach. With respectto the previous models, and in addition to building-level representations, it addresses and represents en-ergy flows incoming and outgoing from a building dis-trict.

Other relevant standards, at the city and districtlevel, such as the LandXML13 model for legal bound-aries are worth considering, although they still lack aformal representation as ontologies, thus making theintegration at this level even harder. Some approaches,however, are starting to appear, which aim at map-ping such models to corresponding ontology-basedrepresentations, e.g., the OWL translation of the OGCCityGML14 XML standard15, the LADM OWL ontol-ogy developed at the DELFT university [23] or the ap-proach to fusion of CityGML and LandXML proposedby 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 smartenvironment, no matter if at the home, building ordistrict level. Its major focus is on device modeling,for all the aspects needed to abstract device “capabil-ities” from low-level idiosyncrasies and communica-tion issues. This enables both abstract reasoning on de-vices, e.g., to find similar devices or to identify themost suitable output to which forward urgent notifi-cations, and actual integration of different technolo-gies, and paradigms. DogOnt was firstly introduced in2008 [4] and was originally meant to represent homeautomation devices for interoperability support. Cur-

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

12http://www.planergy.it/file/EiBOv1.owl, lastvisited on April 05, 2017

13http://landxml.org/, last visited on July 19, 2017.14http://cui.unige.ch/isi/onto/citygml2.0.

owl, last visited on September 06, 201715https://www.citygml.org/, last visited on July 19,

2017

6 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

rently at version 4.0, DogOnt underwent several re-views and amendments in the past years, and its scopewas widened to include devices and technologies typ-ically part of an indoor IoT network (e.g., through thecluster-based ZigBee HA extension16 or by incorpo-rating the Philips Hue devices in the ontology). If theoriginal focus was more on modeling operational as-pects enabling device control, the latest version, dis-cussed in this paper, has moved to a more informed,modular, and linked modeling approach which enablesadoption of DogOnt-based representations at differ-ent abstraction layers. Device control and interoper-ability is still one of the pillars of the representation,but extensibility, modularity, and service-based repre-sentation of heterogeneous entities (IoT and non-IoTdevices) empower the latest versions of the ontology,thus enabling modular integration and reconciliation ofdifferent specifications, e.g., the ZigBee HA model andthe registry-based Modbus data representation. Moreattention is also devoted to the Linked Open Data ini-tiative: the ontology is now listed in the Linked OpenVocabulary data set17 and its connections with well-known ontologies (see Figure 1) are being improvedday by day.

DogOnt

SSN

Good

RelationsUCUM

Fig. 1. DogOnt relations with well-known ontologies

If in the first release of DogOnt the main targetstakeholders were system integrators and developersdealing with issues related to interoperability of dif-ferent home and building automation systems, the lastversion of DogOnt, here summarized, targets a muchwider user base including: system integrators, develop-ers, IoT companies, IoT developers, data analysts andin general any stakeholder having the need to accessand represent IoT data according to a uniform, stan-dard and machine understandable model.

From a very high-level perspective, the ontologyis deployed along three main hierarchies of concepts,

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

17http://lov.okfn.org/dataset/lov/about/, lastvisited on July 05, 2017

supported by four additional trees that better specifythe knowledge encoded in the main topics. The threehierarchies are respectively rooted at BuildingThing,Functionality and State (Figure 2).

Building Thing

Functionality

State

Controllable UnControllable

hasFunctionality

hasState

Root Concepts

Child Concepts

subClassOf

Other Relations

Fig. 2. The main representation pillars.

The BuildingThing hierarchy is one of the pillarsof the DogOnt ontology and is completely devoted tothe description of objects contained inside architec-tural spaces. These object are divided in Controllableand UnControllable entities. The former represent anydevice that can be somewhat controlled into a closedenvironment, i.e., it represents the nodes of any smartenvironment network. The latter, instead, represents allphysical, inanimate objects contained in an indoor en-vironment, including furniture, inner walls and parti-tions, etc. This hierarchy is strictly interconnected withthe other two main pillars of the representation: theFunctionality and the State trees of classes.

Functionality is the top concept of a class hierarchythat was originally designed to represent devices underan operational perspective. Each device was given a setof functionality which completely specified the devicetype, allowing - for example - classification reasoning.In the latest ontology evolution, the functionality rep-resentation has moved to a more service oriented ap-proach18, where each device offers a well known set ofservices, and sufficient conditions are provided to cat-egorize devices as belonging to a specific class. How-ever, modelers are free to represent entities offering anarbitrary set of services (functionality), not necessarilycorresponding to actual device capabilities (e.g., vir-tual or high-level functionality such as energy manage-ment [19] or energy profiling).

Finally, concepts inheriting from the State classmodel the current condition of a device (Control-lable, in DogOnt), using the Harel’s state chart se-mantics [21] as reference model and allowing devices

18In such a sense also the “Functionality” name is undergoing aserious review process to better reflect the new nature of modeledconcepts.

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 7

to assume multiple states at the same time, with dif-ferent state values. For example, a smart microwaveoven which is heating a frozen meal can be modeledas being in the “on”, “defrosting”, and “emitting mi-crowaves” states at the same time. This enables higherflexibility in modeling, and permits to tackle differentabstraction levels and different granularity dependingon specific application cases.

On the formal standpoint, DogOnt is an OWL2DL compliant ontology with ALCHIQ(D)19 expres-sivity. It counts 896 classes and 6654 axioms. Thecurrent version (3.2.13) is released under the Apache2.0 License and is reachable at the correspondingnamespace20 through content negotiation, as suggestedby the W3C guidelines on RDF vocabulary publish-ing [2]. Table 1 summarizes the main ontology met-rics.

Table 1DogOnt metrics.

Metric ValueAxioms 6654Logical axioms count 5221Class count 896Object properties count 30Data properties count 46Individuals count 0DL Expressivity ALCHIQ(D)

SubClassOf axioms count 2595Equivalent classes axioms count 2Disjoint classes count 2425

As can easily be noticed, DogOnt adopts a modelingparadigm that maintains a clear separation between on-tology schema and instances (0 instances in the mainontology). In such a way, environment descriptionsare independent and slowly evolving knowledge (theschema) is well separated from quickly changing mod-els (environment representations).

Subsequent paragraphs better detail the DogOntmodel with respect to devices and surrounding envi-ronments.

19AL indicates the base language allowing atomic negation, con-cept intersection, universal restrictions and limited existential quali-fications; C means complex concept negation; H defines support forrole hierarchies (subproperties); I provides inverse relationships; Qdefines support for qualified cardinality restrictions and (D) indi-cates the capability to handle datatype properties and expressions.

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

3.2. Device modeling

Devices and sensors corresponding to physical ob-jects, or behaving as (virtual) physical devices, are rep-resented as subclasses of the main Controllable con-cept (equivalent to the Device class defined in theSSN ontology). Controllables are further specializedinto Appliances, HousePlants and NetworkComponent(Figure 3), which respectively identify smart objects(e.g., fridges, washing machines, etc.), sensors and ac-tuators21, and physical layer components, i.e., deviceswhose main function is to guarantee physical commu-nication of real devices (e.g., network controllers, gate-ways, etc.).

ControllableRoot Concepts

Child Concepts

subClassOf

MoreChildrenAppliances

HousePlants

NetworkComponent

White Goods

Brown Goods

ElectricalSystem

HVACSystem

SecuritySystem

ZigBeeComponent......

......

...

......

...

Fig. 3. Controllable subclasses.

While the initial modeling approach was mainly de-scriptive and modeled device operations through sin-gle, shared instances of subclasses of the Functionalityconcept, the current ontology adopts a strong service-oriented approach where devices and operations (func-tionality classes) are associated by means of objectproperties (dogont:hasFunctionality). Everymodeled device, in other words, is described as an en-tity having a (variable) set of functionality and states.While several device classes (over 400) are already de-scribed in the ontology, and their functionality prede-fined through owl:someValuesFrom restrictions(Figure 4 shows an example), modelers are free to cre-ate their own classes (and/or instances) by composingfunctionality and states through the dogont:has-Functionality and dogont:hasState rela-tions.

The set of named devices defined in DogOnt encom-passes devices included in the early European HomeSystem (EHS) taxonomy, in the ZigBee device specifi-

21The common ancestor concept name (HousePlants) is under re-vision as it is no more intended to represent devices belonging tohouse plants, only.

8 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

LeakSensorRoot Concepts

Other Concepts

subClassOf

OtherRelations

LeakDetectionNoti�cationFunctionality

LeakDetectionState

hasFunctionality(owl:someValuesFrom)

hasState(owl:someValuesFrom)

LeakDetected LeakNotDetected

hasStateValue hasStateValue

LeakDetectedNoti�cation

LeakNotDetectedNoti�cation

hasNoti�cation

hasNoti�cation

Fig. 4. An example of device class predefined in the ontology.

cation for Smart Metering and Home Automation, plusseveral other entities typically occurring in actuationand metering infrastructures (e.g., in indoor IoT net-works). Nevertheless, this structure can easily be ex-tended to support generic device definition, by remov-ing the indoor constraint, and by adopting a more gen-eral naming schema less bounded to typical indoor sys-tems, e.g., by renaming the Controllable class to Con-nectedDevice, and so on.

Predefined device classes, in DogOnt, are organizedin the main three hierarchies reported in Figure 3,which are further subdivided in commonly used cat-egories. Appliances are split along the main whiteand brown goods categories, respectively referring tobig appliances such as fridges, ovens, stoves and tosmall devices such as TVs, Hi-Fi systems, etc. House-Plants are divided into sub-systems each pertaininga single, homogeneous field of application and in-clude the electric, the Heating, Ventilating and AirConditioning (HVAC), and the security (e.g., smokeor movement sensors) sub-systems. NetworkCompo-nents are eventually organized according to the phys-ical network they represent, e.g., ZigBeeComponentfor ZigBee networks, ModbusComponent for Mod-bus networks, HueComponent for the Philips Hueconnected lighting system, and so on. While Appli-ances and HousePlants are completely independentfrom network specific information and can be freelyadopted to abstract any physical device in terms of sup-ported functionality and possible states, the conceptsbelonging to the NetworkComponent tree are designedto “attach” network-specific data to abstract devices(through multiple typing), thus enabling low level ac-cess to the underlying physical sensor (e.g., through agateway software). Section 3.4 reports a complete, yetsimple, modeling walkthrough to better clarify the no-tions introduced here.

The concepts hierarchy stemming from the Func-tionality root defines the possible services (or opera-tions) that devices can provide. Such services are cate-gorized on the kind of interaction they support / imply.

In particular, 3 different types of interactions are con-sidered: query, notification and control. They are mod-eled by the sub-trees of classes rooted at QueryFunc-tionality, NotificationFunctionality and ControlFunc-tionality, respectively.

Query functionality model all possible interroga-tions that a device could answer to. They representthe typical request-based (or polling-based) interactionbetween devices and applications aimed at gatheringdata at application-driven instants. They represent, inother words, those device services that provide dataupon explicit request, e.g., to get the current powerconsumption from an electricity meter or to obtain theamount of cars counted by a vehicles counter sensor.Notification functionality, on the converse, representevent-driven interactions between devices and appli-cations, i.e., they represent the ability of a device toautonomously notify new data, e.g., measures, currentstate, etc. Eventually, control functionality representthe actuation (and configuration) capabilities of a de-vice. They permit to associate pre-defined set of com-mands (modeled by Command instances) to devices,thus allowing to completely model the device capabil-ities at an abstract, technology-independent level. Forthe sake of clarity, control functionality can be seen asabstract, shared interfaces that define how a device canbe controlled by applications (or end-users).

Control and notification functionality are comple-mented by two auxiliary set of classes respectivelyrooted at Command and Notification, which are ex-ploited to attach predefined set of commands (noti-fications) to functionality modeled in DogOnt. Forinstance, an OnOffControlFunctionality is definedas having at least one OnCommand and one Off-Command by means of suitable OWL restrictions(owl:someValuesFrom), as shown in Figure 5.

Root Concepts

Other Concepts

subClassOf

OtherRelations

OnO�Functionality

O�Command OnCommand

hasNoti�cation(owl:someValuesFrom)

hasNoti�cation(owl:someValuesFrom)

Fig. 5. Example of functionality modeling.

While concepts inheriting from the Functionalityclass model services offered by a given device, thecurrent device state is represented by means of thehierarchy of concepts stemming from the root Stateclass, and can assume several StateValues dependingon its definition. State modeling, in DogOnt, followsthe Harel’s statechart semantics (Hierarchical FSMs)

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 9

which provides support for complex state descriptionsincluding parallel states, history states, clustering, andrefinement. Such a semantics well adapts to complexbehavior of real-world sensors and permits to representcomplex devices as having multiple state values at thesame time. For instance, a smart plug might be at thesame time on, and measuring electric power, and so on.It should be noted, however, that statecharts semanticsdoes 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 whichare of little interest for actual interaction in EAC/FMscenarios. Therefore, modeled states are typically asubset of actual device states, and mostly refer to ob-servable conditions in which the device might be. Fig-ure 6 reports an example of state modeling for colordimmable lamps.

ColorDimmableLightRoot Concepts

Other Concepts

subClassOf

OtherRelations

LightIntensityStateOnO�State

hasState(owl:someValuesFrom)

hasStat

e

(owl:so

meValu

esFrom

)

OnStateValue O�StateValue

hasS

tate

Valu

e(o

wl:s

omeV

alue

sFro

m) hasStateValue

(owl:someValuesFrom

)

LevelStateValue

hasStateValue(owl:someValuesFrom) ColorStateHSB

hasState(owl:someValuesFrom)

HueStateValue

BrightnessStateValue

SaturationStateValue

hasStateValue

(owl:someValuesFr

om)

hasS

tate

Valu

e(o

wl:s

omeV

alue

sFro

m) hasStateValue

(owl:som

eValuesFrom)

Fig. 6. State modeling for color dimmable lamps.

Both functionality and states are partitioned in de-scriptions of properties assuming real and discrete val-ues, as defined in the former ontology versions. How-ever, in the presented ontology, the formal represen-tation of functionality and states assuming real valueshas been improved by accounting explicitly the asso-ciated unit of measures, thanks to a tighter integrationwith the well established UCUM / MUO ontologies22.

3.3. Environment modeling

Concepts stemming from BuildingEnvironment andfrom the UnControllable branch of the BuildingTh-ing hierarchy provide means to describe the environ-ment hosting the modeled devices, and in particular toroughly represent the architectural spaces (i.e., rooms,etc.) containing the modeled network. Such a hierarchyhas remained almost unchanged since 2008, therefore

22http://idi.fundacionctic.org/muo/, last visitedon April 04, 2017

we provide a general overview of the adopted model-ing paradigm, only, while interested readers may lookat the original publication [4].

Environment modeling in DogOnt is rather abstractand mainly aimed at locating indoor devices at roomgranularity. Reflecting this general design goal theavailable concepts permit to represent: (a) Buildings asinstances of the Building concepts. (b) Storeys, as partof multi-storey buildings. (c) Flats, either located onsingle or multiple storeys. (d) Rooms inside flats andother indoor locations (e.g. Garages) located outsideflats; (e) Walls, ceilings, floors, partitions, doors andwindows composing both rooms and building bound-aries.

Positioning is addressed by simple containment re-lations, i.e., dogont:IsIn whereas dedicated rela-tions are defined to represent environment compositionin flats, rooms, etc. Figure 7 depicts a typical room def-inition.

Fig. 7. Example room modeling, in RDF/XML syntax.

Extensions are currently under development to linkDogOnt concepts to positioning ontologies capableof handling indoor positioning systems. In particu-lar, while exploiting the W3C WGS84 for localizingthe “origin point” of a building, storey or room, weare planning to integrate relative xyz (in meters) po-sitioning as typically provided by indoor localizationsystems, e.g., based on the Ultra Wide Band (UWB)technology. Accurate modeling, e.g., exploiting Re-gion Connection Calculus [9] and other well known,and widely recognized modeling paradigms is still un-der refinement and out of the scope of this paper.

10 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

3.4. Modeling Walk-through

To better clarify how DogOnt can be exploited tomodel devices and networks, and the services they of-fer, a sample modeling walk-through is reported in thissection. Lets assume a Smart Energy context in whicha given indoor environment is hosting a sensing net-work to monitor energy consumption of appliances,smart home devices, sensors and actuators, e.g., for im-plementing Smart Grid or Demand-side ManagementPolicies (e.g., as in the GreenCom EU project23). Insuch a context several smart plugs (using whichevercommunication technology, e.g., Z-Wave or ZigBee)are wirelessly interconnected to a network coordina-tor and provide information about current energy andpower consumption. Despite the simplistic nature ofthe scenario, lets consider the case in which severalbuildings are participating to the initiative each ex-ploiting a different smart plug technology. In such acase, DogOnt easily supports abstraction of servicesand capabilities offered by involved devices and of-fers a common representation layer exploitable, forinstance, to implement technology-independent SmartEnergy Management Systems.

For the sake of simplicity, let us shrink down theproblem to the representation of a single metering plugmeasuring the consumption of a traditional oven lo-cated in the kitchen of a given house participating inthe project. As the smart-plug object is already mod-eled in DogOnt by means of the MeteringPowerOutletconcept definition, the modeling process simply con-sists in creating the individuals needed to represent thegiven plug, the oven, the room, and the house in whichthe plug is placed.

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

1. identify the object to represent and the corre-sponding DogOnt concept (if exists);

2. model the object according to the DogOnt classdefinition including functionality and states, asimposed by DogOnt-defined constraints;

3. define individuals for additional functionality andstates (not available in the pre-defined class spec-ification);

4. model any object that is functional to the cor-rect representation of the initial object (e.g., con-nected devices for the smart plug scenario);

23http://www.greencom-project.eu, last visited onApril 05, 2017

5. model the environment(s) in which the objects areplaced;

6. model any explicit relation between objects, e.g.,the control relation between a switch and its cor-responding actuator;

7. model the network-specific information allowingto interface real-devices, e.g., by adopting a gate-way software.

The final result of these steps applied to the samplemetering plug is reported in Figure 11, while the pro-cess applied in steps 1-3, 4 and 5 is better detailed inFigure 8.

3.4.1. Steps 1-3The first three steps of the modeling methodology

tackle the representation of the device in focus, i.e., ofthe sample smart plug, Figure 8 shows the correspond-ing activity diagram. Identify the DogOnt concept corresponding to the given object/deviceis Concept existing?Create individuals for the object and for the functionalities and states "mandated" by DogOntyesidentify functionalities and states "missing" in the set "mandated" by the DogOnt concept speci�cationidentify DogOnt functionalities and states corresponding to "missing" functionalities and states Missing functionality and/or states? yesis Concept existing?Create individuals for the missing functionalities and states using DogOnt concepts

nono yesExtend DogOnt no

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

The earliest step in this phase involves a quickbrowsing of devices currently supported in DogOnt.As a general hint, in this phase, the more quick ap-proach to browsing is “thinking” at system-level: the

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 11

plug is part of a general electric system/plant, and itis something that can be controlled. The correspond-ing DogOnt concept, if available, should therefore beunder the Controllable concept, possibly located in theElectricSystem subtree, which in turn stems from theHousePlants class. By browsing the concepts imme-diately inheriting from the ElectricSystem, it is easyto notice 2 candidate subtrees, respectively rooted atPowerDelivery and Meter. Few hierarchy levels be-low, the two subtrees converge on the PowerMetering-PowerOutlet class, which perfectly matches the sam-ple smart plug; for the sake of simplicity we assumehere that the plug is only able to measure the instanta-neous power absorbed by connected electrical loads.

At this point, the modeler shall concentrate on theclass definition, where mandatory relations and prop-erties are defined through suitable OWL2 restrictions(constraints). In the PowerMeteringPowerOutlet case,these restrictions (either locally defined or inheritedthrough all the concept ancestors) define the plug (seeFigure 9) as having:

– an OnOffFunctionality, i.e., the ability to beturned on and off;

– an OnOffNotificationFunctionality, i.e., the abil-ity to autonomously generate events about thecurrent activation state of the plug, e.g., to detectexternal control events;

– a SinglePhaseActivePowerMeteringFunctional-ity, i.e, the ability to measure currently consumedpower and to be queried about current consump-tion;

– a SinglePhaseActivePowerMeteringNotification-Functionality i.e., the ability to autonomouslygenerate events about the current consumption ofconnected electrical loads;

– an OnOffState, modeling the state assumed by theplug, reflecting its ability to be providing powerto connected devices, or not;

– a SinglePhaseActivePowerMeasurementState, rep-resenting the current state in terms of the cur-rently measured consumption value, and the rela-tive unit of measure.

A suitable instance shall be created for each conceptinvolved into such existential constraints, and the pro-cess must be recursively repeated on each of the newlycreated models. It must be noticed the complete ab-sence of any technology-specific detail in the represen-tation generated so far.

3.4.2. Step 4The fourth modeling step involves the analysis of

the existing relations between the device in focus (thesmart plug) and the other devices present in the samesmart environment context. Relations modeling in Do-gOnt is quite lightweight, and mainly 3 relation fami-lies 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 thatcontrols a lamp. The second is specifically related toinstances of classes stemming from the PowerDeliveryconcept and represents the fact that a device is con-nected to a power delivery object to draw the electricenergy needed to provide its own functions. The lat-ter, allows modeling the process of measuring physicalquantities of interest, over a set of devices: for exam-ple, it permits to specify which set of electrical loadsare monitored by a given power meter.

In this modeling step (4th) these relations are an-alyzed to find devices and, more in general, objectsforming the context surrounding a given object, fo-cus of the modeling process. In the sample smart plugcase, a single electric load is connected to the plug: a“standing” lamp, with no intelligence on board. As theplug only powers one device, also the metering rela-tion will involve only one instance, i.e., the same lamp.If we assume that our plug is controlled by a remoteswitch, e.g., located inside the same room of the plug,we finally obtain the result in Figure 10 where the plugmodel has been omitted to concentrate on objects mod-eled in this step.

3.4.3. Step 5In this step the “built” environment in which objects

are placed is represented, including all architecturalfeatures as well as all “relevant” UnControllable ele-ments. In the considered example, the main involvedentity is the room containing the plug, the switch andthe standing lamp. The instantiation process is almostequal to the one followed in steps 1 to 3 for control-lable objects and is omitted here for the sake of clarity.

3.4.4. Step 6The sixth step is the last technology-independent

modeling step and provides the complete representa-tion of concepts involved in the described modelingexercise. In such a step, previously isolated models areconnected through object properties and correspond-ing instances are related, thus allowing to perform in-ferences on the represented information; e.g., to derivethat since the lamp is connected to the plug, turning the

12 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

SmartPlug1

dogont:MeteringPowerOutlet

OnO�Functionality1

dogont:OnOffFunctionality

OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommand

dogont:realCommandValue =

"on" dogont:realCommandValue =

"off"

dogont:hasFunctionality

dogont:hasCommand

dogont:hasCommand

SinglePhaseActivePower

MeasurementFunctionality1

dogont:SinglePhaseActivePower

MeasurementFunctionality

Get1PhaseActive

PowerCommand

dogont:Get1PhaseAcive

PowerCommand

dogont:hasCommand

dogont:realCommandValue =

"getActivePower"

dogont:

hasFunc

tionality

OnO�Noti�cation

Functionality1

dogont:OnOffNotificationù

Functionality

OnNoti�cation1

dogont:OnNotification

O�Noti�cation1

dogont:OffNotification

dogont:notificationName =

"on" dogont:notificationName =

"off"

dogont:hasNoti�cationdogont:hasNoti�cation

dogont:hasFunctionality

SinglePhaseActivePower

MeasurementNoticationFunctionality1

dogont:SinglePhaseActivePower

MeasurementNotificationFunctionality

SinglePhaseActive

PowerNotication1

dogont:SinglePhaseAcive

PowerNotification

dogont:hasCommand

dogont:notificationName =

"newActivePowerValue"

dogont:notificationParamName =

"powerValue"

Watt

uomvocab:UnitOfMeasurement

uomvocab:

measuredIn

dogont:hasFunctionality

OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue

dogont:OffStateValue

dogont:realStateValue =

"on"

dogont:realStateValue =

"off"

dogont:hasStateValue

dogont:hasStateValue

dogont:hasState SinglePhaseAcrivePower

MeasurementState1

dogont:SinglePhaseActivePower

MeasurementState

dogont:hasState

ActivePower

StateValue1

dogont:ActivePower

StateValue

dogont:hasStateValue

Watt

uomvocab:UnitOfMeasurement

uomvocab:

measuredIn

Fig. 9. Modeling approach applied to a smart plug, steps from 1-3.

Lamp1

dogont:SimpleLamp

OnO�Functionality1

dogont:OnOffFunctionality

OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommand

dogont:realCommandValue =

"on" dogont:realCommandValue =

"off"

dogont:hasFunctionality

dogont:hasCommand

dogont:hasCommand

OnO�Noti�cation

Functionality1

dogont:OnOffNotification

Functionality

OnNoti�cation1

dogont:OnNotification

O�Noti�cation1

dogont:OffNotification

dogont:notificationName =

"on" dogont:notificationName =

"off"

dogont:hasNoti�cationdogont:hasNoti�cation

dogont:hasFunctionality

OnOState1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

OStateValue

dogont:OffStateValue

dogont:realStateValue =

"on"

dogont:realStateValue =

"off"

dogont:hasStateValue

dogont:hasStateValue

dogont:hasState

Switch1

dogont:OnOffSwitch

OnO�Noti�cation

Functionality1

dogont:OnOffNotification

Functionality

OnNoti cation1

dogont:OnNotification

O�Noti�cation1

dogont:OffNotification

dogont:hasNoti�cationdogont:hasNoti�cation

dogont:hasFunctionality

OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue

dogont:OffStateValue

dogont:hasStateValue

dogont:hasStateValue

dogont:hasState

Fig. 10. Modeling approach applied to a smart plug, step 4.

plug also causes the lamp to be switched off. Figure 11reports the full model.

4. Is end-to-end modeling possible?

Given the survey of current energy modeling effortsreported in Section 2, it clearly emerges that energyconsumption modeling at district and city level is fea-sible, and can be achieved on the basis of a solid, stan-

dard and shared modeling framework based on ontolo-gies. Among the analyzed efforts, DogOnt proved tobe a solid baseline model for high granularity infor-mation on device states, which can be easily related toboth instantaneous (PowerOnt) and temporal (e.g., asin SAREF) behaviors in terms of energy. Due to ex-isting connections between DogOnt and the SAREFETSI standard [15], any effort for exploiting DogOntas a seed for end-to-end modeling of the AEC/FM do-main can also be seen as a concrete possibility of defin-

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 13

Lamp1

dogont:SimpleLamp

OnO�Functionality1

dogont:OnOffFunctionality

OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommand

dogont:realCommandValue =

"on"

dogont:realCommandValue =

"off"

dogont:hasCommand

dogont:hasCommand

OnO�Noti�cation

Functionality1

dogont:OnOffNotification

Functionality

OnNoti�cation1

dogont:OnNotification O�Noti�cation1

dogont:OffNotification

dogont:notificationName =

"on"

dogont:notificationName =

"off"

dogont:hasNoti�cation

dogont:hasNoti�cation

dogont:hasFunctionality

OnOState1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

OStateValue

dogont:OffStateValue

dogont:realStateValue =

"on"

dogont:realStateValue =

"off"

dogont:hasStateValue

dogont:hasStateValue

dogont:hasState

Switch1

dogont:OnOffSwitch

OnO�Noti�cation

Functionality1

dogont:OnOffNotification

Functionality

OnNoti cation1

dogont:OnNotification

O�Noti�cation1

dogont:OffNotification

dogont:hasNoti�cation

dogont:hasNoti�cation

dogont:hasFunctionality

OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue

dogont:OffStateValue

dogont:hasStateValue

dogont:hasStateValue

dogont:hasState

dogont:meterOf

dogont:controlledObject

dogont:pluggedIn

SmartPlug1

dogont:MeteringPowerOutlet

OnO�Functionality1

dogont:OnOffFunctionality

OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommanddogont:realCommandValue =

"on"

dogont:realCommandValue =

"off"

dogont:hasFunctionality

dogont:hasCommand

dogont:hasCommand

SinglePhaseActivePower

MeasurementFunctionality1

dogont:SinglePhaseActivePower

MeasurementFunctionality

Get1PhaseActive

PowerCommand

dogont:Get1PhaseAcive

PowerCommand

dogont:hasCommand

dogont:realCommandValue =

"getActivePower"

dogont:

hasFunc

tionality

OnO�Noti�cation

Functionality1

dogont:OnOffNotificationù

Functionality

OnNoti�cation1

dogont:OnNotification

O�Noti�cation1

dogont:OffNotification

dogont:notificationName =

"on"

dogont:notificationName =

"off"

dogont:hasNoti�cation

dogont:hasNoti�cation

dogont:hasFunctionality

SinglePhaseActivePower

MeasurementNoti�cationFunctionality1

dogont:SinglePhaseActivePower

MeasurementNotificationFunctionality

SinglePhaseActive

PowerNoti�cation1

dogont:SinglePhaseAcive

PowerNotification

dogont:notificationName =

"newActivePowerValue"

dogont:notificationParamName =

"powerValue"Watt

uomvocab:UnitOfMeasurement

uomvocab:

measuredIn dogont:hasFunctionality

OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O StateValue

dogont:OffStateValue

dogont:realStateValue =

"on"

dogont:realStateValue =

"off"

dogont:hasS

tateValue

dogont:hasStateValue dogont:hasState

SinglePhaseAcrivePower

MeasurementState1

dogont:SinglePhaseActivePower

MeasurementState

dogont:hasState

ActivePower

StateValue1

dogont:ActivePower

StateValue

dogont:hasStateValue

Watt

uomvocab:UnitOfMeasurement

uomvocab:

measuredIn

dogont:generatesCommand

dogont:generatesCommand

dogont:hasFunctionality

Fig. 11. Modeling approach applied to a smart plug, step 6.

ing a “unified modeling framework” for the AEC/FMdomain based on standard representations (ETSI) andLinked 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 needto be addressed. In the following subsections, initialmappings between layers are, therefore, discussed andtheir relations with the DogOnt ontology are high-lighted. Clearly no fully applicable, generally viablesolution can be identified. Nevertheless, end-to-endmodeling of the AEC/FM domain seems feasible andmost of the gaps appear to be bridgeable through suit-able ontology-mappings, many of those basing on Do-gOnt. This confirms the potential validity of the au-thors’ initial claim.

4.1. Device to Building mappings

Bridging the device-level representation addressedby DogOnt and the relative energy indicators ab-

stracted at the building level is feasible and couldbe based on, for example, ThinkHome and EEOnt.Unfortunately, direct mappings between DogOnt andthese building level ontologies, in the AEC/FM do-main, are not always available. While for EEOntlinks already exist, which for example relate theeeont:BuildingEnvironment concept to thecorresponding dogont:BuildingEnvironment,or the eeont:Controllable and eeont:Un-controllable classes with the homonym classesin Dogont, ThinkHome directly embeds concepts de-fined in DogOnt, breaking some of the original hier-archies and redefining some of the core classes. Thisre-use of single classes and/or model subsets, breaksthe linking ontology principles and requires explicitmapping to be defined, possibly solving inconsisten-cies that might arise due to different approaches inmodeling.

Still in this case some mappings can be definedwhich allow exploiting DogOnt as seed model. Forexample, single sensor and actuator classes in Do-gOnt can be directly mapped (through owl:equi-

14 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

valentClass relations) to corresponding conceptsin ThinkHome (see, e.g., Figure 12), while the build-ing modeling branch rooted at thinkhome:Build-ingEnvironment is completely equivalent to theone rooted at dogont:BuildingEnvironment.Moreover, some cross-fertilization might also be con-sidered, e.g., evolving the DogOnt design to better ac-count the different nature of network-specific compo-nents and more general devices and/or appliances, asdone in ThinkHome.

Far more challenging would be setting up suit-able mappings between same-level ontologies, e.g.,between ThinkHome and EEOnt as they potentiallyfollow completely different approaches to model thebuilding-level information. Nevertheless, being bothlinkable to DogOnt, bridging over a common subset of“shared” classes is certainly feasible.

DogOnt

ThinkHome

owl:equivalentClass

owl:equivalentClass

Fig. 12. Oversimplified mappings between DogOnt and ThinkHome.

One of the initially unforeseen commonalities be-tween DogOnt-based modeling and building-level on-tologies, emerging from shared adoption of the for-mer, is the rather abstract approach to representationof the built environment, in terms of rooms, walls, etc.While existing efforts in BIM modeling have exten-sively addressed the building modeling issues, in many

applications of the energy domain BIM models are toodetailed and include details which are often superflu-ous. As an example, modeling walls and openings isimportant for defining the energy indicators of a cer-tain building, however, fine grained details on build-ing materials may often be replaced by much lightercoefficients, thus reducing the computational footprintof the resulting model (e.g., as done in EEOnt). Toacknowledge these common needs a dedicated W3Cworking group24 is working on the definition of theso-called Building Topology (BOT) ontology, whichlargely shares the DogOnt modeling approach. In sucha sense, defining links between BOT and DogOnt (andthis is granted by direct participation of some of theauthors to the working group) again enables the adop-tion of DogOnt a seed model for the AEC/FM domain(see Figure 13). DogOntW3C BOT Think Homeowl:equivalentClass owl:equivalentClassFig. 13. Relations between DogOnt, W3C BOT, and ThinkHome,oversimplified for the sake of clarity.

4.2. Building to city and district mappings

At the district-level, ontologies providing districtand city-level views of energy performance indi-

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

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 15

cators and models for energy flows are available.However, a general lack of mappings between sys-tematic representations at district-level and exist-ing building-level characterizations, can be observed.Similarly to the device-to-building case, a possiblemodeling framework to bridge such a gap can ex-ploit DogOnt as seed, optionally building atop ofmappings defined at the building level. Consider-ing the SEMANCO-HEAD ontology [10] as a vi-able example of district-level model developed inthe context of the SEMANCO EU project25 possi-ble mappings with Dogont can indeed be established.In particular, connections can be defined betweenthe semanco:Electrical_Appliances con-cept and the dogont:Appliances class, as wellas between the semanco:Technical_Build-ing_System and the dogont:HousePlants,see Figure 14.

DogOnt

SEMANCO-HEAD ontology

Fig. 14. A very preliminary mapping between SEMANCO-HEADand DogOnt.

These mappings are not yet published, nor com-pletely checked: for example a possible inconsistencymight arise from disjoint axioms in DogOnt that arepotentially in conflict with the hierarchy relationshipbetween semanco:Electrical_Appliancesand semanco:Technical_Building_System.Nevertheless it appears clear that, with careful designof ontology interlinks DogOnt can also be exploitedto bridge the gap between district and building levelmodeling. At least on some, almost shared subset of

25http://www.semanco-project.eu, last visited onApril 11, 2017.

concepts including both the building modeling and thedevice modeling hierarchies.

5. Conclusions

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

The proposed mappings have various degrees of ma-turity and are neither exhaustive nor complete. Thework presented in the paper, in fact, is more focusedon fostering the definition of links between differentmodeling efforts in the AEC/FM domain rather than incompletely specifying ontology mappings and align-ments. Several open challenges remain to reach a suffi-ciently linked set of ontologies for Architecture/Engi-neering/Construction (AEC) and Facilities Manage-ment (FM), thus calling for further research from boththe semantic modeling and the AEC/FM research com-munities.

References

[1] Håvard Bell and Lars Bjørkhaug. A buildingSMART ontol-ogy. In Manuel Martínez and Raimar Scherer, editors, eWorkand eBusiness in Architecture, Engineering and Construction.ECPPM 2006: Proceedings of the 6th European Conferenceon Product and Process Modelling, 13-15 September 2006, Va-lencia, Spain, pages 185–190. Taylor & Francis, 2006.

[2] Diego Berrueta and Jon Phipps, editors. Best PracticeRecipes for Publishing RDF Vocabularies. W3C WorkingGroup Note, 28 August 2008. URL https://www.w3.org/TR/swbp-vocab-pub/.

[3] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked data- the story so far. International Journal on Semantic Web andInformation Systems (IJSWIS), 5(3):1–22, 2009. DOI https://doi.org/10.4018/jswis.2009081901.

16 Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM

[4] Dario Bonino and Fulvio Corno. DogOnt - Ontology model-ing for intelligent domotic environments. In Amit P. Sheth,Steffen Staab, Mike Dean, Massimo Paolucci, Diana Maynard,Timothy W. Finin, and Krishnaprasad Thirunarayan, editors,The Semantic Web - ISWC 2008, 7th International Seman-tic Web Conference, ISWC 2008, Karlsruhe, Germany, Octo-ber 26-30, 2008. Proceedings, volume 5318 of Lecture Notesin Computer Science, pages 790–803. Springer, 2008. DOIhttps://doi.org/10.1007/978-3-540-88564-1_51.

[5] Dario Bonino and Giuseppe Procaccianti. Exploiting semantictechnologies in smart environments and grids: Emerging rolesand case studies. Science of Computer Programming, 95:112–134, 2014. DOI https://doi.org/10.1016/j.scico.2014.02.018.

[6] Dario Bonino, Fulvio Corno, and Luigi De Russis. PowerOnt:An ontology-based approach for power consumption estima-tion in smart homes. In Raffaele Giaffreda, Radu-LaurentiuVieriu, Edna Pásher, Gabriel Bendersky, Antonio J. Jara, JoelJ. P. C. Rodrigues, Eliezer Dekel, and Benny Mandler, edi-tors, Internet of Things. User-Centric IoT - First InternationalSummit, IoT360 2014, Rome, Italy, October 27-28, 2014, Re-vised Selected Papers, Part I, volume 150 of Lecture Notesof the Institute for Computer Sciences, Social Informatics andTelecommunications Engineering, pages 3–8. Springer, 2014.DOI https://doi.org/10.1007/978-3-319-19656-5_1.

[7] Dario Bonino, Luigi De Russis, Fulvio Corno, and Gianni Fer-rero. JEERP: Energy-aware enterprise resource planning. ITProfessional, 16(4):50–56, July 2014. DOI https://doi.org/10.1109/MITP.2013.22.

[8] Anne-Claire Boury-Brisset. Managing semantic big data forintelligence. In Kathryn Blackmond Laskey, Ian Emmons, andPaulo Cesar G. da Costa, editors, Proceedings of the EighthConference on Semantic Technologies for Intelligence, De-fense, and Security, Fairfax VA, USA, November 12-15, 2013.,volume 1097 of CEUR Workshop Proceedings, pages 41–47. CEUR-WS.org, 2013. URL http://ceur-ws.org/Vol-1097/STIDS2013_T06_Boury-Brisset.pdf.

[9] Anthony G. Cohn, Brandon Bennett, John Gooday, andNicholas Mark Gotts. Qualitative spatial representation andreasoning with the region connection calculus. GeoInfor-matica, 1(3):275–316, 1997. DOI https://doi.org/10.1023/A:1009712514511.

[10] Vincenzo Corrado, Ilaria Ballarini, Leandro Madrazo, and Ger-man Nemirovski. Data structuring for the ontological mod-elling of urban energy systems: The experience of the SE-MANCO project. Sustainable Cities and Society, 14:223 –235, 2015. DOI https://doi.org/10.1016/j.scs.2014.09.006.

[11] Laura Daniele, Frank T. H. den Hartog, and Jasper Roes. Cre-ated in close interaction with the industry: The smart appli-ances reference (SAREF) ontology. In Roberta Cuel andRobert Young, editors, Formal Ontologies Meet Industry - 7thInternational Workshop, FOMI 2015, Berlin, Germany, August5, 2015, Proceedings, volume 225 of Lecture Notes in BusinessInformation Processing, pages 100–112. Springer, 2015. DOIhttps://doi.org/10.1007/978-3-319-21545-7_9.

[12] Laura M. Daniele, Frank T. H. den Hartog, and Jasper B.M.Roes. Study on semantic assets for smart appliances interoper-ability – D-S4: FINAL REPORT. Technical report, EuropeanUnion, April 2015. URL https://repository.tudelft.nl/view/tno/uuid:73c44272-1ac0-4acb-a359-423d053475a6/.

[13] Juan José Vinagre Díaz, Mark Richard Wilby, Ana Belén Ro-dríguez González, and José García Munoz. EEOnt: An onto-

logical model for a unified representation of energy efficiencyin buildings. Energy and Buildings, 60:20 – 27, 2013. DOIhttps://doi.org/10.1016/j.enbuild.2013.01.012.

[14] B. Dong, K. Lam, Y. Huang, and G. Dobbs. A comparativestudy of the IFC and gbXML informational infrastructures fordata exchange in computational design support environments.In Proceedings of the International Building Performance Sim-ulation Conference (IBPSA) 2007, September 03-06, 2007,Beijing, China, volume 10, pages 1530–1537, 2007. URLhttp://www.ibpsa.org/proceedings/BS2007/p363_final.pdf.

[15] ETSI Technical Committee Smart Machine-to-Machine Com-munications (SmartM2M). SmartM2M; Smart Appliances;Reference Ontology and oneM2M Mapping. TechnicalSpecification TS 103 264 V2.1.1, ETSI, March 2017. URLhttp://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v020101p.pdf.

[16] ETSI Technical Committee Smart Machine-to-Machine Com-munications (SmartM2M). SmartM2M; Smart AppliancesExtension to SAREF; Part 3: Building Domain. Tech-nical Specification TS 103 410-3 V1.1.1, ETSI, Jan-uary 2017. URL 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 Com-munications (SmartM2M). SmartM2M; Smart AppliancesExtension to SAREF; Part 1: Energy Domain. Tech-nical Specification TS 103 401-1 V1.1.1, ETSI, Jan-uary 2017. URL http://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.01.01_60/ts_10341001v010101p.pdf.

[18] Francesco Furfari, Lorenzo Sommaruga, Claudia Soria, andRoberto Fresco. DomoML: the definition of a standard markupfor interoperability of human home interactions. In EUSAI2004: Proceedings of the 2nd European Union symposium onAmbient intelligence, pages 41–44, New York, NY, USA, 2004.ACM. ISBN 1-58113-992-6.

[19] Christhoph Grimm and Dario Bonino. Towards standardiza-tion of M2M communication in smart appliances. In ICT fora Low Carbon Economy – EEBuilding Data Models – EnergyEfficiency Vocabularies and Ontologies: Proceedings of the4th Workshop organised by the EEB Data Models CommunityICT for Sustainable Places Nice, France, 9th–11th Septem-ber, 2013, pages 61– 71. European Commission DG CON-NECT H5 Smart Cities & Sustainability, January 2014. DOIhttps://doi.org/10.2759/40897.

[20] Armin Haller, Krzysztof Janowicz, Simon Cox, Danh LePhuoc, Kerry Taylor, and Maxime Lefrançois, editors. Seman-tic Sensor Network Ontology. W3C Recommendation, 19 Oc-tober 2017. URL https://www.w3.org/TR/vocab-ssn/.

[21] David Harel. Statecharts: a visual formalism for complex sys-tems. Science of Computer Programming, 8(3):231–274, 1987.DOI https://doi.org/10.1016/0167-6423(87)90035-9.

[22] Sangkeun Lee, Supriya Chinthavali, Sisi Duan, and Mallikar-jun Shankar. Utilizing semantic big data for realizing anational-scale infrastructure vulnerability analysis system. InSven Groppe and Le Gruenwald, editors, Proceedings of theInternational Workshop on Semantic Big Data, San Francisco,CA, USA, July 1, 2016, page 3. ACM, 2016. DOI https://doi.org/10.1145/2928294.2928295.

[23] Christiaan Lemmen, Peter van Oosterom, and Rohan Bennett.The Land Administration Domain Model. Land Use Policy,49:535–545, 2015. DOI https://doi.org/10.1016/j.landusepol.2015.01.014.

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM 17

[24] Ian Niles and Adam Pease. Origins of the IEEE Standard Up-per Ontology. In Working notes of the IJCAI-2001 workshopon the IEEE standard upper ontology, pages 37–42, 2001.

[25] Christian Reinisch, Mario Jerome Kofler, Félix Iglesias, andWolfgang Kastner. ThinkHome energy efficiency in futuresmart homes. EURASIP Journal on Embedded Systems, 2011,2011. DOI https://doi.org/10.1155/2011/104617.

[26] Marc Schaaf, Stella Gatziu Grivas, Dennie Ackermann, ArneDiekmann, Arne Koschel, and Irina Astrova. Semantic com-plex event processing. In Recent Researches in Applied In-formation Science: Proceedings of the 5th WSEAS Congresson Applied Computing Conference, and Proceedings of the 1stInternational Conference on Biologically Inspired Computa-tion, BICA’12, pages 38–43, Stevens Point, Wisconsin, USA,2012. World Scientific and Engineering Academy and Society(WSEAS). ISBN 978-1-61804-089-3.

[27] Amit Sheth, Cory Henson, and Satya S. Sahoo. Semantic sen-sor web. IEEE Internet Computing, 12(4):78–83, July 2008.DOI https://doi.org/10.1109/MIC.2008.87.

[28] Kean Huat Soon, Rod Thompson, and Victor Khoo.Semantics-based fusion for CityGML and 3D LandXML.In 4th International FIG 3D Cadastres Workshop, 9-11November 2014 , Dubai, United Arab Emirates, pages

323–338, November 2014. URL https://www.oicrf.org/-/semantics-based-fusion-for-citygml-and-3d-landxml.

[29] Gervasio Varela, Alejandro Paz-Lopez, José Antonio Becerra,Santiago Vazquez-Rodriguez, and Richard José Duro. UniDA:uniform device access framework for human interaction en-vironments. Sensors, 11(10):9361–9392, 2011. DOI https://doi.org/10.3390/s111009361.

[30] J. Verhoosel, D. Rothengatter, F. J. Rumph, and M. Kons-man. An ontology for modeling flexibility in smart grid en-ergy management. In Gudni Gudnason and Raimar Scherer,editors, eWork and eBusiness in Architecture, Engineeringand Construction. ECPPM 2012: Proceedings of the 6thEuropean Conference on Product and Process Modelling,25-27 July 2012, Reykjavik, Iceland, pages 931–938. CRCPress, 2012. URL https://repository.tudelft.nl/view/tno/uuid:bfe13c5f-a5db-4056-bc31-bde4f5ddd643/.

[31] ZigBee Alliance Inc. ZigBee Home Automation,2010. URL http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeehomeautomation.

[32] ZigBee Alliance Inc. ZigBee Smart Energy, 2014.URL http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeesmartenergy.