semantic web 0 (0) 1 ios press dogont as a viable seed for semantic modeling of · pdf...

Semantic Web 0 (0) 1 1IOS Press

DogOnt as a viable seed for semanticmodeling of AEC/FMDario Bonino a,∗, Luigi De Russis b

a Istituto Superiore Mario Boella, Torino, ItalyE-mail: [email protected] Dipartimento di Automatica e Informatica, Politecnico di Torino, Corso Duca degli Abruzzi 24, Torino, ItalyE-mail: [email protected]

Abstract. Energy consumption and performance assessment of Smart Cities must consider different levels, various sub-domains,and several stakeholders. 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 theseinformation from a plethora of different stakeholders (i.e., citizens, utilities, policy makers, and energy providers) and sensors.Current modeling approaches for this context address each level and domain separately, thus preventing a structured and com-prehensive approach to a unified energy representation. Moreover, current approaches make difficult to keep the consistencybetween the energetic data through levels, sub-domains and across stakeholders. Starting from an analysis of ontologies at thestate-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 withstand over 8 years of usage without major failures and shortcomings. We discusssuccessful design choices and adaptations, which kept the model up-to-date and increasingly adopted in domains ranging fromhome automation to energy 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, varioussub-domains, and several stakeholders. A comprehen-sive energy profile of a city, in fact, should work at thecity, district, and building levels. At the same time andfor each level, it should take into account both electri-cal and thermal consumptions, and gather these infor-mation from a plethora of different stakeholders (i.e.,citizens, utilities, policy makers, and energy providers)and heterogeneous sensors.

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-

*Corresponding author. E-mail: [email protected]

ing various stakeholders. Several research groups andcompanies are working on techniques deriving fromthe Semantic Web and the Artificial Intelligence to ad-dress the modeling of so many different aspects, be itat the application, sensing, or device level. Among theavailable initiatives, the most renowned encompass theLinked Open Data (LOD) initiative, acting at the appli-cation level, the Semantic Sensor Web initiative, whichaims at addressing, at least partially, the diversity ofsensors and sensors data, and the Semantic Big Dataresearch field aiming at tackling the data cardinalityand heterogeneity issue.

Linked Open Data (LOD) provides machine under-standable, shared and open semantics for representinga wide set of knowledge domains in the world. Ratherthan focusing on a single, rigid and practically not-scalable representation model, the LOD approach in-

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: latest evolutions and perspective adoption.

tegrates more than 295 datasets1 with over 31 billionsof triples representing real data, from personal e-mailcontacts to world nations, from medical topics to planeparts. The Semantic Sensor Web (SSW) specificallyfocuses on sensing networks, and provides means formodeling sensor devices (and their capabilities), sys-tems and processes. One of the most important resultsof the SSW initiative is the Semantic Sensor Network(SSN) ontology, defined by the W3C SSN XG groupwhich was active from 2009 to 2011 [1]. Finally, theSemantic Big Data initiative, aims at empowering bigdata solutions (e.g., Complex Event Processing) withsemantic technologies such as ontologies, definitionsand behavior (inference) rules. This allows to trans-form “raw” data events into meaningful informationconforming to a formal semantics, which, in turn, sup-ports better understanding of situations (states) by ma-chines (agents), better understanding of relationshipsbetween events and declarative processing of events,and reaction to situations (event patterns).

Current modeling approaches and initiatives, how-ever, are too general for the energy context (e.g., SSW)or too specific, since they aim at modeling each leveland domain separately. In this way, a structured andcomprehensive approach to a unified energy represen-tation is not possible and, similarly, it is difficult tomaintain the data consistency between the energetic in-formation through levels and across sub-domains.

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, DogOnt, that was firstly published 8 yearsago [2] and was initially designed, and developed, totackle interoperability issues in home automation net-works. In the past eight years, it evolved to tackle rep-resentation issues emerging from residential, building,and factory automation solutions. Lately, it includedprimitives for dealing with distributed networks of sen-sors deployed as part of smart buildings. Nowadays,DogOnt empowers several research projects needinguniform, semantic access to environment sensors andactuators and successfully supports abstraction of sev-eral standards including both Internet of Things (e.g.,ZigBee) and non-IoT (e.g., Modbus) technologies. Weclaim and demonstrate that DogOnt can be used as a

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

foundation towards a shared and unified model for theenergy 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.Finally, Section 5 provides final remarks and discussesthe foreseen evolutions in the next 5 years.

2. Overview on AEC/FM modeling

Energy performance assessment and representationdemands for models able to deal with an increas-ing variety of ground truth data, generated throughheterogeneous monitoring networks and devices. Theemergence of IoT approaches to smart cities is stress-ing the importance of a uniform, 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-

Bonino et al. / DogOnt as a viable seed for semantic modeling AEC/FM: latest evolutions and perspective adoption. 3

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 tothe 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 [3] 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. Amongthe others, the Energy@Home consortium2, which wasinvolved in the definition of the ZigBee Smart En-ergy [4] and Home Automation [5] 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 repre-sentation, promoted the European initiative on Energy

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

Using and Producing Products [6], which lead to thecreation of the Smart Appliances Reference ontology(SAREF [7]), now an ETSI standard [8]. SAREF for-malizes in OWL the “energy profile” concept devel-oped in the ZigBee Alliance, thus providing a stan-dard, machine understandable representation of energyconsumption of devices, over time. Moreover, it mod-els explicitly the observable states of devices3 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.

While SAREF tackles energy consumption model-ing at the device level, ThinkHome [9] (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 [10] aresupported.

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 [11] 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 with

3as its device modeling approach partly stems from the DogOntontology [2]

http://www.energy-home.it


building 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) [12], 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 [2] and its extensions. Through Do-gOnt, appliance properties are exposed according toexisting semantic models, while power consumptionis modeled by introducing a specific Energy Profileontology (i.e., PowerOnt [3]). 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 [13], instead, rep-resents the thermal homologous of profile-based mod-eling of electric consumption. It provides a classifica-tion of Energy using Products (EuPs) into seven cat-egories based on their compound temporal and en-ergy behavior. Included categories are:(a) variable ser-vices; (b) thermal services, (c) schedulable services,(d) event-timeout services, (e) charge control, (f) com-plete control, and (g) custom control. Moreover, an en-ergy management and a cost profile characterize eachproduct. SmartCoDe mappings with SAREF exists andcan be easily obtained [14].

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)4, elaborated in the SEMANCOproject5, among many similar initiatives, describesthe domain of urban planning based on the SUMOupper-level ontology [15]. 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 project6, 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 domainsrelevant to smart grids (e.g., as in Gridpedia7), and pro-viding alignment and conflict resolution facilities. TheEnergy in Buildings Ontology8 is another attempt toprovide a systematic framework for city-level energymodeling. It provides a reference model for publishingenergy performance data of public buildings in Italy,with a Linked Open Data approach. With respect to theprevious models, and in addition to building-level rep-resentations, it addresses and represents energy flowsincoming and outgoing from a building district.

3. DogOnt

3.1. Overview

The DogOnt ontology aims at offering a uniform,extensible model for all devices being part of a smart

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

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

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

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

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

http://www.semanco-tools.eu/urban-enery-ontology

http://www.semanco-tools.eu/urban-enery-ontology

http://www.semanco-project.eu/

http://ns.cerise-project.nl/energy/def/cim-smartgrid

http://ns.cerise-project.nl/energy/def/cim-smartgrid

http://gridpedia.org

http://gridpedia.org

http://www.planergy.it/file/EiBO v1.owl


environment, 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 [2] and was originally meant to represent homeautomation devices for interoperability support. In thepast years, it underwent several reviews and amend-ments, and its scope was widened to include devicesand technologies typically part of an indoor IoT net-work. If the original focus was more on modeling oper-ational aspects enabling device control, the latest ver-sion, discussed in this paper, has moved to a more in-formed, modular and linked modeling approach whichenables adoption of DogOnt-based representations atdifferent abstraction layers. Device control and inter-operability is still one of the pillars of the represen-tation, but extensibility, modularity, and service-basedrepresentation of heterogeneous entities (IoT and non-IoT devices) empower the latest ontology, thus en-abling modular integration and reconciliation of differ-ent specifications, e.g., the cluster-based ZigBee HomeAutomation model and the registry-based Modbus datarepresentation. More attention is also devoted to theLinked Open Data initiative: the ontology is now listedin the Linked Open Vocabulary data set9 and its con-nections with well-known ontologies (see Figure 1) arebeing improved day by day.

DogOnt

SSN

Good

RelationsUCUM

Fig. 1. DogOnt relations with well-known ontologies

From a very high-level perspective, the ontologyis deployed along three main hierarchies of concepts,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).

9http://lov.okfn.org/dataset/lov/about/, lastvisited on April 05, 2017

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-proach10, 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 [14] 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 [16] as reference model and allowing devicesto 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 higher

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

http://lov.okfn.org/dataset/lov/about/


flexibility 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)11 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 correspondingnamespace12 through content negotiation, as suggestedby the W3C guidelines on RDF vocabulary publish-ing [17]. 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.

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 specialized

11AL 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.

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

into Appliances, HousePlants and NetworkComponent(Figure 3), which respectively identify smart objects(e.g., fridges, washing machines, etc.), sensors and ac-tuators13, 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

More

ChildrenAppliances

HousePlants

NetworkComponent

White Goods

Brown Goods

ElectricalSystem

HVACSystem

SecuritySystem

ZigBeeComponent...

...

...

......

......

...

Fig. 3. Controllable subclasses.

Differently from the initial modeling approach,which was mainly descriptive and modeled deviceoperations through single, shared instances of sub-classes of the Functionality concept, the current ontol-ogy adopts a strong service-oriented approach wheredevices and operations (functionality classes) are as-sociated by means of object properties (dogont:-hasFunctionality). Every modeled device, inother words, is described as an entity having a (vari-able) set of functionality and states. While several de-vice classes (over 400) are already described in theontology, and their functionality predefined throughowl:someValuesFrom restrictions (Figure 4 showsan example), modelers are free to create their ownclasses (and/or instances) by composing functionalityand states through the dogont:hasFunctional-ity and dogont:hasState relations.

LeakSensorRoot Concepts

Other Concepts

subClassOf

Other

Relations

LeakDetection

Noti�cationFunctionality

LeakDetection

State

hasFunctionality

(owl:someValuesFrom)

hasState


LeakDetected LeakNotDetected

hasStateValue hasStateValue

LeakDetected

Noti�cation

LeakNotDetected

Noti�cation

hasNoti�cation

hasNoti�cation

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

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

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

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


The set of named devices defined in DogOnt encom-passes devices included in the early European HomeSystem (EHS) taxonomy, in the ZigBee device specifi-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 represent

the 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

Other

Relations

OnO�Functionality

O�Command OnCommand

hasNoti�cation


hasNoti�cation


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)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

Other

Relations

LightIntensityStateOnO�State

hasState(owl:som

eValuesFrom)

hasSta

te

(owl:s

omeV

alues

From

)

OnStateValueO�StateValue

hasSta

teValu

e(o

wl:som

eValu

esFro

m)

hasS

tate

Valu

e

(ow

l:som

eValu

esFro

m)

LevelState

Value

hasStateValue

(owl:someValuesFrom) ColorStateHSB

hasState


HueStateValue

Brightness

StateValue

Saturation

StateValue

hasSta

teValu

e

(owl:s

omeValu

esFro

m)

hasS

tate

Valu

e

(ow

l:so

meValu

esF

rom

)

hasS

tate

Valu

e

(ow

l:som

eValu

esFro

m)

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 ontologies14.

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, thereforewe provide a general overview of the adopted model-ing paradigm, only, while interested readers may lookat the original publication [2].

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

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

as instances of the Building concepts. (b) Storeys,as part of multi-storey buildings. (c) Flats, either lo-cated on single or multiple storeys. (d) Rooms in-side flats and other indoor locations (e.g. Garages) lo-cated outside flats; (e) Walls, ceilings, floors, parti-tions, doors and windows composing both rooms andbuilding boundaries.

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.

As can easily be noticed, the modeling approach isvery lightweight, however in future evolutions it mighteasily evolve to fully fledged environment representa-tions exploiting Region Connection Calculus [18] andother well known, and widely recognized modelingparadigms.

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. Let 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 project15). In

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

http://idi.fundacionctic.org/muo/

http://www.greencom-project.eu


such 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, let 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 modeling approach to follow, which finallyleads to the result reported in Figure, follows a simple,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);

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

6. model any explicit relation between instances,e.g., the control relation between a switch and itscorresponding actuator;

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

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. The earliest step in this phaseinvolves a quick browsing of devices currently sup-

ported in DogOnt. As a general hint, in this phase, themore quick approach to browsing is “reasoning” bysystems: the plug is part of a general electric system /plant, and it is something that can be controlled. Thecorresponding DogOnt concept, if available, shouldtherefore be under the Controllable concept, possiblylocated in the ElectricSystem subtree, which in turnstems from the HousePlants class. By browsing theconcepts immediately inheriting from the ElectricSys-tem, it is easy to notice 2 candidate subtrees, respec-tively rooted at PowerDelivery and Meter. Few hi-erarchy levels below, the two subtrees converge onthe PowerMeteringPowerOutlet class, which perfectlymatches the sample smart plug; for the sake of simplic-ity we assume here that the plug is only able to mea-sure the instantaneous power absorbed by connectedelectrical 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 8) 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 ability to be provid-ing power to connected devices, or not;

– a SinglePhaseActivePowerMeasurementState, rep-resenting the currently measured consumptionvalue, and the relative 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.


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


"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



MeasurementNoti�cationFunctionality1


MeasurementNotificationFunctionality

SinglePhaseActive

PowerNoti�cation1

dogont:SinglePhaseAcive

PowerNotification

dogont:hasCommand


"newActivePowerValue"

dogont:notificationParamName =

"powerValue"

Watt

uomvocab:UnitOfMeasurement

uomvocab:

measuredIn


OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue

dogont:OffStateValue

dogont:realStateValue =

"on"


"off"

dogont:hasStateValue


dogont:hasState SinglePhaseAcrivePower

MeasurementState1


MeasurementState

dogont:hasState

ActivePower

StateValue1

dogont:ActivePower

StateValue


Watt


uomvocab:

measuredIn

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

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, focusof the modeling process. In the sample smart plug case,a single electric load is connected to the plug: a “stand-ing” lamp, with no intelligence on board. As the plugonly powers one device, also the metering relation willinvolve only one instance, i.e., the same lamp. If weassume that our plug is controlled by a remote switch,e.g., located inside the same room of the plug, we fi-nally obatin the result in Figure 9 where the plug model

has been omitted to concentrate on objects modeled inthis 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 istantiation process is almostequal to the one followed in steps 1 to 3 for control-lable objects and is omitted here for the sake of clar-ity. The same simplification is applied to graphical rep-resentation where the containing room is representedby omitting related concepts, such as walls, floor andceiling, etc.

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 theplug also causes the lamp to be switched off. Figure 10reports the full model.


Lamp1

dogont:SimpleLamp



OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommand


"on" dogont:realCommandValue =

"off"


dogont:hasCommand

dogont:hasCommand

OnO�Noti�cation

Functionality1

dogont:OnOffNotification

Functionality

OnNoti�cation1


O�Noti�cation1



"on" dogont:notificationName =

"off"



OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue



"on"


"off"



dogont:hasState

Switch1

dogont:OnOffSwitch

OnO�Noti�cation

Functionality1


Functionality

OnNoti�cation1


O�Noti�cation1




OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue




dogont:hasState

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

Lamp1

dogont:SimpleLamp



OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommand


"on"


"off"

dogont:hasCommand

dogont:hasCommand

OnO�Noti�cation

Functionality1


Functionality

OnNoti�cation1

dogont:OnNotification O�Noti�cation1



"on"


"off"

dogont:hasNoti�cation



OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue



"on"


"off"



dogont:hasState

Switch1

dogont:OnOffSwitch

OnO�Noti�cation

Functionality1


Functionality

OnNoti�cation1


O�Noti�cation1





OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue




dogont:hasState

dogont:meterOf

dogont:controlledObject

dogont:pluggedIn

SmartPlug1

dogont:MeteringPowerOutlet



OnCommand1

dogont:OnCommand

O�Command1

dogont:OffCommanddogont:realCommandValue =

"on"


"off"


dogont:hasCommand

dogont:hasCommand


MeasurementFunctionality1


MeasurementFunctionality

Get1PhaseActive

PowerCommand

dogont:Get1PhaseAcive

PowerCommand

dogont:hasCommand


"getActivePower"

dogont:

hasFunc

tionality

OnO�Noti�cation

Functionality1

dogont:OnOffNotificationù

Functionality

OnNoti�cation1


O�Noti�cation1



"on"


"off"





MeasurementNoti�cationFunctionality1


MeasurementNotificationFunctionality

SinglePhaseActive

PowerNoti�cation1

dogont:SinglePhaseAcive

PowerNotification


"newActivePowerValue"

dogont:notificationParamName =

"powerValue"Watt


uomvocab:

measuredIn dogont:hasFunctionality

OnO�State1

dogont:OnOffState

OnStateValue

dogont:OnStateValue

O�StateValue



"on"


"off"

dogont:hasS

tateValue

dogont:hasStateValue dogont:hasState

SinglePhaseAcrivePower

MeasurementState1


MeasurementState

dogont:hasState

ActivePower

StateValue1

dogont:ActivePower

StateValue


Watt


uomvocab:

measuredIn

dogont:generatesCommand

dogont:generatesCommand


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


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 [8], any effort for exploiting DogOnt asa seed for end-to-end modeling of the AEC/FM do-main can also be seen as a concrete possibility of defin-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 AEM/FC 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 AEM/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. This

re-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-valentClass relations) to corresponding conceptsin ThinkHome (see, e.g., Figure 11), 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. 11. 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 manyapplications 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 group16 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 AEM/FC domain(see Figure 12).

4.2. Building to city and district mappings

At the district-level, ontologies providing districtand city-level views of energy performance indi-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 [19] as a vi-able example of district-level model developed inthe context of the SEMANCO EU project17 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 13.

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

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

DogOnt

W3C BOT

Think Home

owl:equivalentClass

owl:equivalentClass

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

DogOnt

SEMANDO-HEAD ontology

Fig. 13. 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 design

https://w3c-lbd-cg.github.io/lbdw/

http://www.semanco-project.eu


of ontology interlinks DogOnt can also be exploitedto bridge the gap between district and building levelmodeling. At least on some, almost shared subset ofconcepts including both the building modeling and thedevice modeling hierarchies.

5. Conclusions

In this paper we presented the last edition of DogOntand we discussed its possible role as “emerging” seedfor linked, shared modeling of the AEM/FC domain.While monolithic approaches to modeling are clearlynot feasible, a linked-open data approach emergingbottom-up from currently adopted models can providea suitable, shared modeling basis for this challeng-ing domain. According to literature, the DogOnt on-tology is starting to emerge as a possible seed to sucha bottom-up process and many of the currently avail-able ontologies in the AEM/FC domain can somewhatbe referred to such an ontology. While introducing thelatest modification to the DogOnt model, the authorshighlighted how the emerging role of DogOnt can besustained by the availability of official mappings be-tween ontologies at the device, building and districtlevels.

Proposed mappings have various degrees of matu-rity and are neither exhaustive nor complete. The workpresented in the paper, in fact, is more focused on fos-tering the definition of links between different model-ing efforts in the AEC/FM domain rather than in com-pletely specifying ontology mappings and alignments.Several open challenges remain to reach a sufficientlylinked set of ontologies for Architecture/Engineering/-Construction (AEC) and Facilities Management (FM).

Additional efforts are needed to explicitly addresspolicy regulations for the energy market, as this aspectis crucial for the successful exploitation of ontology-based energy profiling. In this sense, cities are al-ready moving towards policy-making based on data:an example is represented by the “Global City Indica-tors” [20], a term created in 2010 to establish a globalstandard of over 100 city indicators with a standard-ized definition and methodology. Unfortunately, a for-mal representation of policies and regulations in theenergy domain has yet to appear, and it can be consid-ered as an open challenge that calls for suitable solu-tions to be designed and developed.

Moreover, applying the full stack of models fromdistrict to device can lead to computational issues withinference processes being completed in not acceptable

times or even not converging in case of “too” expres-sive models. Particular attention shall therefore be puton understanding what are the most effective ways ofexploiting such emerging, shared models within a fea-sible computational framework.

References

[1] Michael Compton, Payam Barnaghi, Luis Bermudez, RaúlGarcía-Castro, Oscar Corcho, Simon Cox, John Graybeal,Manfred Hauswirth, Cory Henson, Arthur Herzog, VincentHuang, Krzysztof Janowicz, W. David Kelsey, Danh Le Phuoc,Laurent Lefort, Myriam Leggieri, Holger Neuhaus, AndriyNikolov, Kevin Page, Alexandre Passant, Amit Sheth, andKerry Taylor. The SSN ontology of the W3C semantic sensornetwork incubator group. Web Semantics: Science, Servicesand Agents on the World Wide Web, 17(0):25 – 32, 2012.

[2] Dario Bonino and Fulvio Corno. DogOnt: Ontology Mod-eling for Intelligent Domotic Environments, pages 790–803.Springer Berlin Heidelberg, Berlin, Heidelberg, 2008.

[3] Dario Bonino, Fulvio Corno, and Luigi De Russis. PowerOnt:An Ontology-Based Approach for Power Consumption Estima-tion in Smart Homes, pages 3–8. Springer International Pub-lishing, Cham, 2015.

[4] ZigBee Alliance Inc. ZigBee Smart Energy Public Profile.Technical report, 2014.

[5] ZigBee Alliance Inc. Zigbee home automation public profile.Technical report, 2010.

[6] European Commission and TNO. Study on Semantic Assetsfor Smart Appliance Interoperability. Technical report, April2015.

[7] Laura Daniele, Frank den Hartog, and Jasper Roes. Createdin Close Interaction with the Industry: The Smart AppliancesREFerence (SAREF) Ontology, pages 100–112. Springer In-ternational Publishing, Cham, 2015.

[8] TS 103 264, SmartM2M, Smart Appliances, Reference Ontol-ogy and oneM2M Mapping. Technical report, ETSI, Novem-ber 2015.

[9] Christian Reinisch, MarioJ Kofler, Félix Iglesias, and Wolf-gang Kastner. ThinkHome Energy Efficiency in FutureSmart Homes. EURASIP Journal on Embedded Systems,2011(1):104617, 2010.

[10] 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 Tenth International IBPSA Conference, 2007.

[11] J. Verhoosel, D. Rothengatter, F. J. Rumph, and M. Konsman.An ontology for modeling flexibility in smart grid energy man-agement, chapter 122, pages 931–938. eWork and eBusiness inArchitecture, Engineering and Construction. CRC Press, 2012.

[12] Juan Jose Vinagre, Mark Wilby, Ana Belen Rodriguez Gon-zalez Munoz, A.oz, and Jose Garcia. EEOnt: an ontologicalmodel for a unified representation of energy efficiency in build-ings. Energy and Buildings, page In press, 2013.

[13] H. Bell and L. Bjorkhaug. A buildingSMART ontology, pages185–190. eWork and eBusiness in Architecture, Engineeringand Construction. Taylor & Francis, 2006.

[14] Christhoph Grimm and Dario Bonino. Towards standardiza-tion of M2M communication in Smart Appliances. In Ro-


gelio Segovia and Régis Decorme, editors, ICT for Sustain-able Places, 4th Workshop organised by the EEB Data ModelsCommunity, pages 61– 71. European Commission DG CON-NECT H5 Smart Cities & Sustainability, September 2014.

[15] Ian Niles and Adam Pease. Origins of the IEEE standard upperontology. In Working notes of the IJCAI-2001 workshop on theIEEE standard upper ontology, pages 37–42, 2001.

[16] David Harel. Statecharts: A visual formalism for complex sys-tems. Science of Computer Programming, 8(3):231–274, 1987.

[17] Diego Berrueta and John Phipps. Best Practice Recipes forPublishing RDF Vocabularies. W3c working group note, W3C,August 2008.

[18] Anthony G. Cohn, Brandon Bennett, John Gooday, andNicholasMark Gotts. Qualitative Spatial Representation andReasoning with the Region Connection Calculus. GeoInfor-matica, 1(3):275–316, 1997.

[19] Vincenzo Corrado, Ilaria Ballarini, Leandro Madrazo, and Ger-man Nemirovskij. 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.

[20] Mark S. Fox. A foundation ontology for global city indicators.University of Toronto, Toronto, Global Cities Institute, 2013.

semantic web 0 (0) 1 ios press dogont as a viable seed for semantic modeling of · pdf...

Documents