=Paper=
{{Paper
|id=Vol-2389/07paper
|storemode=property
|title=Integrating building and IoT data in demand response solutions
|pdfUrl=https://ceur-ws.org/Vol-2389/07paper.pdf
|volume=Vol-2389
|authors=Iker Esnaola-Gonzalez,Francisco Javier Diez
|dblpUrl=https://dblp.org/rec/conf/ldac/Esnaola-Gonzalez19
}}
==Integrating building and IoT data in demand response solutions==
https://ceur-ws.org/Vol-2389/07paper.pdf
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
Integrating Building and IoT data in Demand
Response solutions
Iker Esnaola-Gonzalez1[0000−0001−6542−2878] and Francisco Javier Diez1
IK4-Tekniker, Iñaki Goenaga 5, Eibar 20600, Spain
{iker.esnaola,francisco.diez}@tekniker.es
Abstract. DR (Demand Response) programs have a big potential in
the residential sector to reduce peak energy demands. However, the poor
user-engagement is one of the main barriers of their adoption and success.
The RESPOND H2020 project aims to bring DR programs to neighbour-
hoods across Europe and in this article, focus is placed on the approach
implemented to solve the challenging integration of building topological
data and data produced by IoT systems within houses including sen-
sors, meters and actuators. In this regard, RESPOND leverages Seman-
tic Technologies to represent building data, while it uses Time Series
Databases (TSDB) to store IoT data. The combination of these tech-
nologies is expected to enhance the data querying, which is of utmost
importance for its display in the RESPOND mobile app.
Keywords: Demand Response · Buildings · IoT · Semantic Technologies
1 Introduction
Peak energy demand has a negative impact on many aspects including energy
grid capital, operational cost and environmental pollution. This is a direct con-
sequence of the carbon-intense generation plants that grid operators deploy in
order to satisfy energy demand during peak periods [4]. Demand side manage-
ment activities including load curtailment (i.e. a reduction of electricity usage)
or load reallocation (i.e. a shift of energy usage to other off-peak periods) have a
huge potential to match energy demand with energy supply side, thus avoiding
these undesirable peaks. As a matter of fact, Demand Response (DR) programs
are introduced into the smart grids so that reliable and economical operation
of power systems are ensured. DR can be understood as the set of technologies
or programs that concentrate on shifting energy use to help balancing energy
supply and demand [17].
DR programs traditionally had a bigger presence on the industrial sector
compared to residential or commercial sectors, considering that buildings such
as industrial plants are extensive energy consumers [11]. However, DR potential
is particularly promising for the still largely untapped residential sector. The resi-
dential sector is characterized by a large number of end consumers with relatively
low individual energy demand, but with very high demand when considered in
terms of home clusters, districts and residential communities. For example, in
92
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
2016 the residential sector represented the 25.4% of final energy consumption
and 17.4% of gross inland energy consumption in the EU1 . Furthermore, the
residential sector is characterized by a huge variety in user behaviour and habits,
thus representing a big challenge but at the same time, a great potential for DR
programs.
Renewable Energy Sources (RES) are increasingly penetrating the energy
production side, and in combination with DR programs and improvement in
energy storage options, could contribute to significantly reduce peak demands.
However, the integration of the different systems and technologies involved in the
distributed energy consumption and generation is a big challenge. Moreover, due
to the intermittent nature of RES, their availability commonly does not match
the distribution of energy demand in time, which may hinder their management
and exploitation.
Being able to accurately predict the amount of energy to be produced over
a period of time, and knowing in advance when demand peaks will occur, can
definitely contribute to a better management of their disparity, thus allowing
the suggestion of the most suitable DR programs to end-users. Likewise, this
helps improving end-users’ engagement, which is the key to the success of DR
programs. However, the successful implementation of DR programs in the resi-
dential sector is a problematic scenario with yet many unsolved challenges. The
RESPOND H2020 project aims to bring DR programs to neighbourhoods across
Europe and in special, delve into the adaptation of energy demand to the re-
newable energy produced locally. In this article, focus is placed on RESPOND’s
approach towards the integration of building topological data and data produced
by IoT systems including sensors, meters and actuators.
The rest of the article is structured as follows. Section 2 introduces the RE-
SPOND project. Section 3 presents RESPOND’s approach to integrate building
data with IoT data. Section 4 describes the semantic representation of the pilot
sites. Finally, the conclusions of this work are presented in Section 5.
2 The RESPOND project
The RESPOND (integrated demand REsponse Solution towards energy POsi-
tive NeighbourhooDs) project2 funded by EU’s H2020 program3 , aims to deploy
and demonstrate an interoperable, cost effective, user centred solution, entailing
energy automation, control and monitoring tools, for a seamless integration of
cooperative DR programs into the legacy energy management systems. In this
endeavour, RESPOND will be leveraged upon an integrated approach for real-
time optimal energy dispatching, taking into account both supply and demand
side, while exploiting all energy assets available at the site.
1
http://ec.europa.eu/eurostat/statistics-explained/index.php/Energy_
consumption_in_households
2
http://project-respond.eu
3
https://cordis.europa.eu/project/rcn/212867_en.html
93
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
The RESPOND solution being developed is foreseen to be flexible and scal-
able, thus being capable of delivering a cooperative DR both at building and
district levels. Furthermore, in order to enable the integration of the DR en-
abling elements and ensure a high replicability, RESPOND is based on open
standards. Likewise, the use of these open standards enables the interoperability
with smart home devices and automation systems, as well as the connectivity
and extendibility towards smart grid and third-party services such as weather
forecasting services and energy price providers.
Underpinned by the smart energy monitoring infrastructure, RESPOND will
leverage data coming from heterogeneous sources to perform various data analyt-
ics tasks. On the one hand, sensing, metering and actuating devices deployed in
pilot houses will be exploited to develop energy demand forecasting services and
ensure dwellers’ comfort levels. On the other, the monitoring and forecasting
of outdoor conditions will enable the estimation of renewable energy produc-
tion. Ultimately, the overall objective of all these data analytic tasks is to detect
potential energy conservation opportunities, and to adapt in real time to the
operational environment.
With the purpose of demonstrating the RESPOND solution, it is being imple-
mented in different types of residential buildings (i.e. apartments, single-family
and multi-family houses), situated in different climate zones (i.e. Mediterranean,
oceanic and humid continental climate), having different forms of ownership (i.e.
rental and home-ownership), population densities and underlying energy sys-
tems. Namely, the three RESPOND pilot sites are located in Aarhus (Denmark),
the Aran Islands (Ireland) and Madrid (Spain).
Having such a heterogeneous group of end-users hinders the diffusion and
impact of DR solutions, and it makes more difficult to ensure sustained user
engagement with DR programs. This is why, interaction with end-users is recog-
nized as a key point in the RESPOND project. Consequently, a set of tools and
services are planned to deliver measurement driven suggestions to end-users for
energy demand reduction and influence their behaviour making them an active
indispensable part of DR loop. One of these tools is a multilingual and cross-
platform mobile app which is expected to contribute in the user-engagement
matter. One of the app’s functionalities includes the display of house informa-
tion, the deployed IoT devices and their measurements (e.g. a dishwasher’s en-
ergy consumption or the kitchen temperature). The display of this information
requires from a previous integration of building topology and IoT data, which is
this article’s focal point. Furthermore, this data integration enables many data
analytic tasks such as energy demand and user comfort forecasting.
3 RESPOND’s approach for Integrating Building and
IoT data
Energy consumption is an outcome of performing everyday practices like shower-
ing, cooking and laundering. Usually people do not recognize energy consumption
as an activity in itself, and they often find it difficult to establish the link between
94
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
daily practices and the corresponding energy consumption [2]. This lack of aware-
ness is tackled by the RESPOND mobile app and the gamification techniques
it implements. This way, dwellers can check for example their energy consump-
tion, compare themselves with their neighbours and get rewards depending on
how efficient they behave from an energy expense viewpoint. Ultimately, these
strategies aim to improve-user engagement.
The mobile app relies on the available data to display relevant information
to the dwellers. This data includes, on the one hand, the topological information
of a house which gives insight of its distribution, the appliances installed, and
the different monitoring and actuating devices deployed in the house. And on
the other, the measurements registered by these IoT devices including an appli-
ance’s energy consumption, a room’s humidity or a window’s state (i.e. opened
or closed).
The advent of BIM (Building Information Model) supports the representation
of the former data source, that is, building information. BIM is a process used
by different stakeholders involved in the construction process of a building, and
deals with the digital representation of functional and physical characteristics of
a building [6]. Each of these stakeholders adds domain knowledge to a common
model which keeps information of the whole building life cycle. A BIM model
may contain static information of a building element. For example, in the case
of a window, data about its location, the material it is made of, and even when
it was installed is available and can be queried. Nevertheless, it is not possible
to know whether the window is opened or closed in a given moment.
Even with the development of BIM, the current practice of architectural de-
sign and construction still relies on conventional document-centric approaches [16].
This means that although file format and exchange standardization efforts are
made, parsing, interpretation, serialisation and deserialisation workflows that
are prone to errors and inefficiencies are still used. Recent research have showed
promising results in the use of Semantic Technologies to overcome document-
centric based approaches in the building domain [8].
With regards to the IoT devices, they generate time series data which com-
monly consists of at least 2 parts: time and value. Despite this simple structure,
IoT data is characterized by its abundance and it is estimated that in 2019 the
IoT will generate more than 500 zettabytes in data [3]. This data needs to be
stored in suitable storage systems which are able to manage such an amount of
data while ensuring a high performance. In this regard, time series databases
(TSDB) can be considered as the best option since they are optimized for han-
dling time series data. Based on the architecture of different TSDBs, each data
object can contain additional information apart from the required value and
timestamp attributes. The goal of this additional attributes is to better differ-
entiate the data and filter it easier. However, a balance needs to be found, as
adding too many variables may penalize the overall performance.
Summarizing, the RESPOND mobile app will leverage building information
data and IoT data. The former data will be stored in an RDF Store and the latter
in a TSDB towards an optimal data management and querying performance.
95
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
3.1 Pilot Site Characterization
In order to implement the presented approach, first of all each pilot site’s char-
acterization was performed. This task was undertaken by the RESPOND part-
ners in charge of these pilot sites, who had no previous knowledge of Seman-
tic Technologies. Therefore, an intermediate step was found necessary prior to
representing building information with appropriate ontological terms. Previous
experiences of RESPOND partners [14,15] were taken into account and it was
decided that the simplest way to fill this information were Excel sheets.
An Excel file was created for every pilot site, and in each of them, meters, sen-
sors and actuators deployed in pilot houses were represented with the following
information:
– Identifier of the device.
– Gateway to which the device is connected to send gathered data.
– Location of the device in terms of building, house and room.
– Location of the device within the room (e.g. floor or east wall).
– Type of device (e.g. humidity sensor or smart plug actuator).
– For actuators, the type of appliance controlled, its brand and model.
– The label and URI of the quality measured or controlled by the device (e.g.
temperature or energy consumption).
– Query to retrieve data gathered by the device stored in the TSDB.
Figure 1 shows an excerpt of the Excel file filled for the Danish pilot site.
Fig. 1. Excerpt of the Excel file with Danish pilot site information.
3.2 The RESPOND Ontology
Once pilot houses are characterized, this information needs to be semantically
annotated using appropriate ontology terms. For this purpose, the RESPOND
ontology was used, which is available online in https://w3id.org/respond.
Ontologies must be carefully designed and implemented, as these tasks have
a direct impact on their final quality. Therefore, the use of well-founded ontology
development methodologies is advised. For the development of the RESPOND
ontology, the NeOn Methodology [13] was followed mainly because unlike other
methodologies it does not prescribe a rigid workflow, but instead it suggests a
96
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
variety of paths. These paths are classified as scenarios which consist of different
tasks that ontology engineers must follow towards the development of a final
ontology that satisfies the tackled problem.
The reuse of ontological resources built by others that have already reached
some degree of consensus is a good practice in ontology development processes [12].
According to W3C’s Data on the Web Best practices [1], the reuse of an existing
vocabulary not only captures and facilitates consensus in communities, but also
increases interoperability and reduces redundancies. Furthermore, this practice
brings other important benefits:
– It increases the quality of the applications reusing ontologies, as these appli-
cations become interoperable and they are provided with a deeper, machine-
processable and commonly agreed-upon understanding of the underlying do-
main of interest.
– It reduces the costs related to ontology development because it avoids the
reimplementation of ontological components, which are already available on
the Web and can be directly (or after some additional customization tasks)
integrated into a target ontology.
– It potentially improves the quality of the reused ontologies, as these are
continuously revised and evaluated by various parties through reuse.
Following these best practices, the RESPOND ontology’s core is built by
reusing and extending three well-known ontologies: BOT to represent the dwelling
topology, and SAREF and SEAS Feature Of Interest ontologies to represent de-
vices, features of interest and qualities monitored and controlled by sensors and
smart appliances. The selection of these ontologies was based on a study of
related ontologies, which is out of the scope of this article.
BOT. The Building Topology Ontology4 [10] (BOT) is a minimal OWL DL
ontology for covering core concepts of a building and for defining relationships
between their subcomponents. A first design principle for the design of BOT has
been to keep a light schema that could promote its reuse as a central ontology
in the AEC (Architecture, Engineering and Construction) domain.
BOT describes sites comprising buildings, composed of storeys which have
spaces that can contain and be bounded by building elements. Sites, buildings,
storeys and spaces are all non-physical objects defining a spatial zone. These
basic concepts and properties make the schema no more complex than necessary
and this design makes the ontology a baseline extensible with concepts and
properties from more domain specific ontologies. Therefore, BOT serves as an
ontology to be shared. As a matter of fact, BOT is aligned with other related
domain ontologies including ifcOWL, which provides an OWL representation of
the EXPRESS schemas of the open standard IFC (Industry Foundation Classes)
developed by buildingSMART5 .
4
https://w3id.org/bot
5
https://www.buildingsmart.org/
97
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
SAREF. The Smart Appliances REFerence (SAREF) ontology6 [5] is a shared
model of consensus that facilitates the matching of existing assets in the smart
appliances domain. The ontology provides building blocks that allow the separa-
tion and recombination of different parts of the ontology depending on specific
needs. The central concept of the ontology is the saref:Device class, which is
modelled in terms of functions, associated commands, states and provided ser-
vices. The ontology describes types of devices such as sensors and actuators,
white goods, HVAC (Heating, Ventilation and Air Conditioning) systems, light-
ing and micro renewable home solutions. A device makes an observation (which
in SAREF is represented as saref:Measurement) which represents the value and
timestamp and it is associated with a quality (saref:Property) and a unit of mea-
surement (saref:UnitOfMeasure). The description of these concepts is focused on
the residential sector.
The modular conception of the ontology allows the definition of any new
device based on building blocks describing functions that devices perform. As
previously stated, for the building-related concepts SAREF provides the link to
the FIEMSER data model. Furthermore, SAREF can be specialized to refine the
general semantics captured in the ontology and create new concepts. The only
requirement is that any extension/specialization may comply with SAREF.
One of these specializations is the SAREF4ENER ontology7 , which focuses on
the energy domain. However, at the moment of writing this article, this ontology
was inconsistent.
SEAS Feature of Interest. The SEAS Ontology8 [7] is an ontology designed
as a set of simple core ODPs (Ontology Design Patterns) that can be instan-
tiated for multiple engineering related verticals. It is planned to be consoli-
dated with the SAREF ontology as part of ETSI’s Special Task Force 5569 . The
SEAS ontology modules are developed based on the following three core mod-
ules: the SEAS Feature of Interest ontology10 which defines features of interest
(seas:FeatureOfInterest) and their qualities (seas:Property), the SEAS Evalua-
tion ontology11 describing evaluation of these qualities, and the SEAS System
ontology12 representing virtually isolated systems connected with other systems.
On top of these core modules, several vertical SEAS ontology modules are
defined, which are dependent of a specific domain. Moreover, the SEAS ontology
offers a set of alignments to ontologies like SOSA/SSN and QUDT.
The RESPOND ontology reuses BOT, SAREF and SEAS Feature of Interest
ontologies. Furthermore, some terms from QUDT UNIT ontology13 are reused to
6
http://ontology.tno.nl/saref
7
https://w3id.org/saref4ener
8
https://w3id.org/seas/
9
https://portal.etsi.org/STF/STFs/STFHomePages/STF556
10
https://w3id.org/seas/FeatureOfInterestOntology
11
https://w3id.org/seas/EvaluationOntology
12
https://w3id.org/seas/SystemOntology
13
http://qudt.org/1.1/vocab/unit
98
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
represent units of measurements (e.g. unit:DegreeCelsius) and other terms from
M3-Lite taxonomy14 to represent qualities observed or controlled by installed
devices (e.g. m3-lite:Humidity). However, there are other RESPOND require-
ments that remain unsolved and a set of new axioms had to be defined to satisfy
them by extending these reused ontologies.
On the one hand, the list of appliances defined by SAREF was extended
to represent new ones including air conditioner (respond:AirConditioner ) and
tumble dryers (respond:TumbleDryer ). Furthermore, the list of qualities pro-
vided and the list of units of measurements provided by M3-lite and QUDT
Unit respectively were not sufficient to represent all the use cases within the
RESPOND pilots. Therefore, these ontologies were extended with the definition
of new qualities such as gas consumption (respond:GasConsumption) and new
units of measurements such as parts per million (ppm) (respond:ppm).
On the other, there are requirements that are intrinsic to the RESPOND
project and which existing ontologies do not satisfy. In the context of the project,
it is essential to know which is the gateway to which each device is connected
in order to send their measurements or control actions. This relationship is rep-
resented with the definition of the respond:connectsToInternetThrough object
property and a new class respond:Gateway as a subclass of saref:Device. Fur-
thermore, it is necessary to know how to query data gathered by a given device
which is stored in a TSDB. This information can be represented leveraging re-
spond:hasDBQuery data property, and its subproperty respond:hasInfluxDBQuery
for InfluxDB TSDB. As for assigning the icons to be shown in the mobile app,
the respond:hasIcon data property relates a resource with its corresponding icon.
Regarding the representation of space features such as the volume or area, a set
of data properties (e.g. respond:hasNetVolume) has been defined inspired by the
IFC4 specification. The representation of these data properties is expected to
be addressed by the W3C LBD (Linked Building Data) Community Group’s15
future PROPS ontology16 .
Figure 2 shows the RESPOND ontology’s main classes and properties.
4 Semantic Representation of Pilots
With regards to the semantic representation of pilot sites, an application based
on Apache Jena17 was developed. Apache Jena is a free and open source Java
framework for building Semantic Web and Linked Data applications. The de-
veloped Jena service extracts the information contained in the Excel sheets,
semantically annotates it with appropriate ontology terms, and stores it into
an RDF Store where it will remain accessible via SPARQL queries. Firstly, this
information was stored in a Stardog18 version 6.0.1 repository, but due to the
14
http://purl.org/iot/vocab/m3-lite
15
https://www.w3.org/community/lbd/
16
https://github.com/w3c-lbd-cg/props
17
https://jena.apache.org/
18
https://www.stardog.com/
99
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
Fig. 2. RESPOND ontology’s main classes and properties.
cease of its Community version after 31 March 2019, this information is now
stored in an Openlink Virtuoso Server19 version 07.20.3217. Figure 3 depicts the
representation of a Smart Plug developed by Develco Products20 and deployed
to measure the electric consumption and control the activation and deactivation
of a dishwasher installed in the kitchen of a pilot house in Denmark.
Fig. 3. Excerpt of a Smart Plug device deployed in a pilot house in Denmark.
19
https://virtuoso.openlinksw.com/
20
https://www.develcoproducts.com/
100
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
4.1 IoT data storage
Both practice and research suggests the use of a graph-based format to capture
building data, nevertheless keeping numeric data explicitly out of the semantic
graph for computational performance reasons [9]. This approach is followed in
RESPOND, thus storing the data gathered by deployed meters, sensors, actua-
tors and other IoT devices in a TSDB. More specifically, the open source TSDB
InfluxDB21 is used for this purpose. The selection of the InfluxDB was preferred
as it is part of the TICK Stack22 , which is employed in other developments of
the RESPOND project.
4.2 Data Discovery via mobile app
In order to hurdle the inherent diffusion and impact problems of DR solutions
in heterogeneous group of end-users, the RESPOND project plans to develop
a set of tools and services. These ones are expected to deliver measurement
driven suggestions to end-users for energy demand reduction and influence their
behaviour making them an indispensable active part of DR loop.
One of these tools is a mobile app developed both for iOS and Android
and available in three languages to ease interaction with end-users from the
pilot sites: in English, Danish and Spanish. The mobile app will offer different
functionalities that require from an integration of building topology and IoT
data, which has been tackled in previous sections of this article.
One of the app’s functionalities displays users the list of devices installed
within their houses, as shown in Figure 4. The display of this information is
based on a SPARQL query executed over the RDF Store that contains the
building topological information. Namely, the SPARQL query executed for this
purpose is shown in Listing 1.1, where the wild card $HOUSE ID is replaced by
the corresponding user’s house ID.
21
https://www.influxdata.com/time-series-platform/influxdb/
22
https://www.influxdata.com/time-series-platform/
101
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
Fig. 4. Devices deployed within an Irish pilot house shown in the RESPOND mobile
app.
PREFIX dc : < http :// purl . org / dc / terms / >
PREFIX bot : < https :// w3id . org / bot # >
SELECT DISTINCT ? deviceID
WHERE {
? space dc : identifier $HOUSE_ID ;
bot : hasSpace */ bot : hasElement ? deviceID .
}
Listing 1.1. SPARQL query to retrieve all the sensors and actuators deployed within
a house.
Users can also check data collected by deployed meters, sensors or actuators
deployed in their houses. For example, Figure 5 displays the electric consumption
of a Spanish pilot house in real-time shown by the RESPOND mobile app. The
electric consumption of a house, which is gathered by an electricity meter, is
stored in InfluxDB. However, in order to query this information, it is necessary to
know how to get the values of the electricity meter at hand. To do so, the SPARQL
query shown in Listing 1.2 is executed, where the wild card $HOUSE ID is
replaced by the corresponding user’s house ID.
102
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
Fig. 5. Real-time electric consumption of a Spanish pilot house shown in the RE-
SPOND mobile app.
PREFIX respond : < https :// w3id . org / def / respond # >
PREFIX seas : < https :// w3id . org / seas # >
PREFIX dc : < http :// purl . org / dc / terms / >
PREFIX saref : < https :// w3id . org / saref # >
SELECT ?dbQuery
WHERE {
? device saref : measuresProperty ? property ;
dc : identifier ? deviceID .
? property rdf : type respond : E lectricConsumption ;
seas : isPropertyOf ? foi ;
respond:hasDBQuery ?dbQuery.
? foi dc : identifier $HOUSE_ID .
}
Listing 1.2. SPARQL query to retrieve the TSDB query retrieving a
house’s electricity consumption.
5 Conclusions
DR programs in residential buildings have a big potential in terms of maximizing
the exploitation of locally produced renewable energy. Likewise, the exploitation
of this type of energy paves the way for reducing peak energy demands. How-
ever, DR programs’ success in this sector is scarce mainly due to user’s lack
103
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
of engagement. The RESPOND mobile app is developed as a way to increase
user-engagement with DR programs.
This mobile app leverages both building and IoT data, which are two dis-
parate data sources that need to be carefully managed. In order to avoid a prob-
lematic document-centric approach, RESPOND proposes the use of Semantic
Technologies to represent building data. More specifically, building topological
data is represented using appropriate ontological terms coming from well-known
ontologies, and it is stored in a Virtuoso RDF Store. With regards to the abun-
dant IoT data, RESPOND leverages the InfluxDB TSDB with the objective of
obtaining an enhanced performance. Finally, the proposed approach is aimed at
easing the scalability of the approach, as it enables the distribution of the data
according to specific needs.
5.1 Future work
So far, the RDF Store used in RESPOND hosts the topological information of
a limited number of test houses. Whether it could afford storing information for
thousands of houses while ensuring a high querying efficiency, still remains an
open issue. This aspect deserves further research in future stages of RESPOND.
Furthermore, at the moment of writing this article, all RESPOND mobile
app’s functionalities are not developed. The personalized DR suggestion to users
or the ability to activate or deactivate appliances are just some of the ser-
vices that are being developed and are expected to further increase the user-
engagement with DR programs.
Last but not least, the research of integrating IoT data with data sources
containing more complex building information (e.g. BIM models) is of interest.
Acknowledgements
This work has received support from H2020 project RESPOND (integrated de-
mand REsponse Solution towards energy POsitive NeighbourhooDs) with grant
agreement number 768619.
This work was conducted using the Protégé resource, which is supported by
grant GM10331601 from the National Institute of General Medical Sciences of
the United States National Institutes of Health.
References
1. Calegari, N., Burle, C., Loscio, B.F.: Data on the web best practices. W3C
recommendation, W3C (jan 2017), https://www.w3.org/TR/2017/REC-dwbp-
20170131/
2. Christensen, T.H., Larsen, S.P., Knudsen, H.N.: How to engage households in en-
ergy demand response solutions? In: Proceedings of ECEEE 2019 Summer Study
(2019)
104
Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019
3. CISCO: Cisco global cloud index: Forecast and methodology, 20162021 white pa-
per. Tech. Rep. 1513879861264127 (2018)
4. Collins, L.D., Middleton, R.H.: Distributed demand peak reduction with non-
cooperative players and minimal communication. IEEE Transactions on Smart
Grid (2018). https://doi.org/10.1109/TSG.2017.2734113
5. Daniele, L., den Hartog, F., Roes, J.: Created in close interaction with the
industry: the smart appliances reference (saref) ontology. In: International
Workshop Formal Ontologies Meet Industries. pp. 100–112. Springer (2015).
https://doi.org/10.1007/978-3-319-21545-7 9
6. Eastman, C.M., Eastman, C., Teicholz, P., Sacks, R., Liston, K.: BIM handbook: A
guide to building information modeling for owners, managers, designers, engineers
and contractors. John Wiley & Sons (2011). https://doi.org/10.6028/NIST.IR.7908
7. Lefrançois, M.: Planned ETSI SAREF extensions based on the W3C&OGC
SOSA/SSN-compatible SEAS ontology patterns. In: Proceedings of Workshop on
Semantic Interoperability and Standardization in the IoT, SIS-IoT, (July 2017)
8. Pauwels, P., Zhang, S., Lee, Y.C.: Semantic web technologies in aec
industry: A literature overview. Automation in Construction (2016).
https://doi.org/10.1016/j.autcon.2016.10.003
9. Petrova, E., Pauwels, P., Svidt, K., Jensen, R.L.: In search of sustainable design
patterns: Combining data mining and semantic data modelling on disparate build-
ing data. In: Advances in Informatics and Computing in Civil and Construction
Engineering, pp. 19–26. Springer (2019)
10. Rasmussen, M.H., Pauwels, P., Hviid, C.A., Karlshøj, J.: Proposing a central aec
ontology that allows for domain specific extensions. In: Joint Conference on Com-
puting in Construction. vol. 1, pp. 237–244 (2017). https://doi.org/10.24928/JC3-
2017/0153.
11. Shoreh, M.H., Siano, P., Shafie-khah, M., Loia, V., ao P.S. Catalão, J.: A survey of
industrial applications of demand response. Electric Power Systems Research 141,
31 – 49 (2016). https://doi.org/0.1016/j.epsr.2016.07.008
12. Simperl, E.: Reusing ontologies on the semantic web: A feasibility study. Data &
Knowledge Engineering 68(10), 905–925 (2009)
13. Suárez-Figueroa, M.C., Gómez-Pérez, A., Fernández-López, M.: The NeOn
Methodology for Ontology Engineering, pp. 9–34. Springer Berlin Heidelberg,
Berlin, Heidelberg (2012). https://doi.org/10.1007/978-3-642-24794-1 2
14. Tomašević, N., Batić, M., Mijović, V., Vraneš, S.: Data point mapping approach
to airport ontology modelling and population. In: Zdravković, M., Trajanović, M.,
Konjović, Z. (eds.) ICIST 2015 Proceedings Vol.1. pp. 261–266 (2015)
15. Tomašević, N.M., Batić, M.v., Blanes, L.M., Keane, M.M., Vraneš, S.: Ontology-
based facility data model for energy management. Adv. Eng. Inform. 29(4), 971–
984 (2015). https://doi.org/10.1016/j.aei.2015.09.003
16. Valdes, F., Gentry, R., Eastman, C., Forrest, S.: Applying systems
modeling approaches to building construction. In: 33th International
Symposium on Automation and Robotics in Construction (2016).
https://doi.org/10.22260/ISARC2016/0102
17. Warren, P.: A review of demand-side management policy in the uk.
Renewable and Sustainable Energy Reviews 29, 941 – 951 (2014).
https://doi.org/10.1016/j.rser.2013.09.009
105