The building sector consumes about 40% of global energy, which is largely caused by buildings' operations. Research showed that providing users with detailed consumption and appliance-usage data may engage them in energy e ciency activities. To do so, data analytic services must be deployed by third parties. These services require a huge amount of data from the users in order to o er high quality services. Nevertheless, users are usually reluctant to share their data especially if its private. This is the case of those measurements performed inside the buildings, as they may be an indicative of the occupants' behaviour. In these scenarios, data sovereignty plays a key role because it provides to data owners a way to de ne data usage requirements and verify their compliance in a trustworthy way. In consequence, the owners' predisposition to exchange their data is expected to increase. This article takes a step forward in the development of a trustworthy ecosystem for the built environment where data sovereignty is provided. Speci cally, an approach is proposed to formally specify data usage requirements for the built environment based on ontologies. Furthermore, this approach has been implemented in a real world home use case.
The European Commission agreed a set of binding legislation inside the EU 2020
package in order to meet the energy sustainability and minimize the climate
change. One of the spotlighted sectors regarding this package is the building
sector which, according to the UNEP (United Nations Environment Programme),
consumes about 40% of global energy and is responsible for 36% of CO2
emissions in the EU. This energy consumption, and specially energy demand peaks,
have a negative impact on operational cost and environmental aspects due to the
carbon-intense generation plants that are deployed to satisfy them [
Demand side management activities such as load curtailment or reallocation
have a huge potential to minimize these peaks, especially in the residential sector
which has traditionally been largely untapped. In this regard, the increasingly
penetration of Renewable Energy Sources (RES) in the energy production side,
and their combination with Demand Response (DR) programs and
improvement in energy storage options, could also contribute to signi cantly reduce
peak demands. DR can be understood as the set of technologies or programs
that concentrate on shifting energy use to help balancing energy supply and
demand [
Research showed that providing users with historical consumption
information and detailed appliance-speci c consumption information contributed to the
reduction of the energy consumption in the residential sector [
Traditional access control standard XACML2 (eXtensible Access Control Markup Language) has been established as the de-facto standard for data control. However, access control mechanisms only provide control at the time of the request on provider side when the consumer requests a resource in a speci c way (e.g. write or read). That is, once data access is granted, there is no control over its usage at consumer systems. In other words, access control is limited to past and present data restrictions and cannot cope with future control.
Distributed data usage control extends access control mechanisms by controlling how data is used by distributed consumers once access is granted as shown in Figure 1. Moreover, distributed data usage control is not limited to the fulllment of a set of conditions (e.g. time-based restrictions or usage purpose). As a matter of fact, it extends to the enforcement of obligations throughout data usage. These obligations consist in a set of actions that can range from data modi cations (e.g. anonymization) to system interactions (e.g. data deletion).
be1d-01aa75ed71a1/language-en
Therefore, the development of a trustworthy ecosystem where data sovereignty
is provided must face new challenges [
The International Data Spaces Association3 (IDSA) is working on the development of a trustworthy open data platform where business-to-business relationships can be searched and established to provide and consume data under easily customised data usage requirements guaranteeing data sovereignty. To reach this goal, distributed data usage control plays a key role. Therefore, IDSA is working on the research of the challenges de ned above.
This article takes an step towards the development of a trustworthy ecosystem for the built environment where data sovereignty is provided. Regarding the aforementioned challenges, focus is placed on the data usage requirements speci cation. Therefore, data usage requirements implementation, enforcement and reliability related challenges are out of scope.
Data usage requirements speci cation recognize three issues to be solved. Firstly, the formal speci cation of human-readable data usage requirements in a domain-agnostic way to be readable and interpretable by machines. In nowadays digitized world, data is provided, exchanged and consumed by machines instead of humans. Therefore, if human-readable data usage requirements are not implemented on such machines, there will be no reliable way to guarantee a provider that its data is actually being used as it was originally agreed. Secondly, the assets identi cation and speci cation for speci c domains, as data usage control is oriented to data sets rather than data points. Assets are economic goods generated by a participant, that can classi ed data points based on its value and usage requirements among others. These assets, must be formally speci ed for the corresponding domain. Thirdly, the formal speci cation of domain-agnostic data usage requirements in speci c domains. In this way, data usage requirements will be applicable for a speci c domain.
This article focuses on the formal speci cation of data usage requirements for the built environment based on IDSA's domain-agnostic approach.
The rest of the article is structured as follows. Section 2 introduces the challenges when specifying data usage requirements. Section 3 introduces a use case to illustrate the data usage control needs in a built environment scenario. Section 4 describes the proposed approach for satisfying the identi ed needs. Finally, conclusions of this work are described in Section 5. 2
Traditionally, textual contracts have been enough for setting data exchange agreements between business partners. Nevertheless, in nowadays digitized world where interactions are performed between machines instead of humans, data usage requirements must be autonomously translated to be machine-understandable. Otherwise, their compliance cannot be guaranteed. Therefore, higher degrees of formalization are needed to autonomously negotiate, specify, implement and enforce data usage requirements. Figure 2 represents di erent degrees of formalization for data usage requirements. The rst or lowest level of formalization belongs to traditional human-readable textual-contracts whose limitations have been previously identi ed. The second level comprises the descriptive policies which refer to machine-readable representations of these contracts (e.g. in JSON or XML format). However, the content of these policies must be manually translated to be at least interpretable by machines. In the third level, the formal policies extend these machine-readable policies by including speci cations such as a consistent semantic provided by, for example, RDFs (Resource Description Frameworks). Even though formal policies are interpretable by enforcement points, they must be translated into speci c data usage policy languages of existing technologies to be enforceable. In the fourth level, the enforceable policies are made based on translations from formal policies in a technology-dependent way in order to be autonomous enforceable. Finally, the autonomously negotiated policies allow the negotiation of data usage requirements without human interactions. This article focuses on reaching the level of formalization related to formal policies for the built environment. The IDSA de nes the IDS Information Model4, a domain-agnostic common language for the semantic description of the participants and components within the IDSA, which includes the speci cation of data usage requirements. This Data usage requirement speci cation is based on the ODRL (Open Digital Rights Language) Information model 2.25, a W3C recommended policy expression language that provides a vocabulary and data model for the description of machinereadable contracts. Moreover, the IDS Information Model extends it towards data usage control descriptions and enforcement.
IDSA de ne the concept of contract (ids:Contract ), a subclass of a Policy (odrl:Policy ), that is an abstract set of rules (ids:Rule) which are comprised of permissions (ids:Permission), prohibitions (ids:Prohibition ) and duties (ids:Duty ). Each of these rules describes an action (ids:Action) that stakeholder (ids:Participant ) might be permitted or prohibited to do on a digital content
(ids:DigitalContent ) under certain constraints (ids:Constraint ). This basic contract representation is shown in Figure 3.
As previously mentioned, the IDS Information Model is generic, with no commitment to any particular domain. That is, the domain knowledge has to be modelled or imported from other existing vocabularies. In this article, focus is placed on the speci cation of data usage requirements for the built environment to de ne formal policies based on this IDSA's approach. 3
The RESPOND H20206 project aims to deploy an interoperable energy automation, monitoring and control solution to deliver DR programs at a dwelling, building and district level to neighborhoods across Europe.
The use case presented in this article focuses on a home located in the Aran Islands (Ireland) participating in the RESPOND project (from now on referred to as Aran 01). In this use case, home occupants are provided with their householdrelated information via the RESPOND Mobile App7 and they can interact with the devices deployed in the home such as switching appliances on or o . Among other relevant information, occupants can visualize the electrical consumption and comfort measurements during a speci c time (both raw data or summarized as aggregated data), as well as the recommended optimal electrical consumption pro le. This optimal pro le is generated taking leverage of di erent data analytic services developed by technology providers, including the electricity demand forecasting, renewable energy production forecasting and optimization services. For the development of these analytic services, technology providers
released/ needs data that must be exchanged between the di erent stakeholders involved in this process. Therefore, some business relationships needs to be agreed.
Next, the stakeholders involved in the use case, the assets exchanged and the established agreements are described. 3.1
The stakeholders identi ed in the Aran 01 use case play di erent roles as follows: { Owner: The person or company that owns the home or the building. { Occupant: The person who lives in the home. He/She may be the owner of the home or not, if it is rented. He/She is the data owner of the monitored data on building behaviour and the data consumer of the results received from the analytic services. { Technology Provider: Third parties that provide hardware and/or software services. They can be classi ed into two di erent categories:
Data Acquisition Service Providers: The companies that provide the service needed to obtain and exchange data with other parties, but never use the data. They are the data providers.
Analytic Service Providers: The companies that provide data analytic services based on the data. They are the data consumers of the monitored data on building behaviour and the data owners/providers of the results obtained from the analytic services.
Regarding the stakeholders and their roles, the Aran 01 dwellers are the
owners and the occupants of the home. Energomonitor SRO8 from the Czech
Republic, TEKNIKER9 from Spain and Institut Mihajlo Pupin10 (PUPIN) from
Serbia are the technology providers. On the one hand, Energomonitor is a data
acquisition service provider. Even tough Energomonitor provides the devices and
the gateways that make and send measurements to data consumers, the Aran 01
user is the owner of this data. Therefore, the Aran 01 user has the right to de ne
textual contracts related to home data. On the other hand, TEKNIKER and
PUPIN are the analytic service providers. Their services include the generation of
optimized energy pro les for electricity consumption management [
The assets are the data sets exchanged between the stakeholders. These, can be classi ed as follows: { Temperature: Measurements related to the temperature in the home which includes:
Raw data: The temperature measured by a temperature sensor. Comfort data: The average temperature of all the temperature sensors of the home. { Electrical Demand: The measurements related to the electricity consumed by the home which includes:
Raw data: The electrical demand measured by an electricity meter. Aggregated data: The average value of raw electrical demand data aggregated for a given period of time (e.g. 1h).
Forecast data: The predicted electrical demand based on one-hourly aggregated electrical demand data. { Electrical Production: The measurements related to the electricity produced by the PV panels installed in the house, which includes:
Raw data: The electricity produced by the PV panels.
Forecast data: The predicted electrical production based on the raw electrical production data. { Electrical Optimized Pro le: The optimal electric demand curve with views to maximizing the renewable energy exploitation and minimizing electric demand peaks. 3.3
To reach the main goal of the use case, the stakeholders identi ed need to establish agreements between them for data exchange. Figure 4 shows the assets exchanged in every agreement between the di erent stakeholders.
Firstly, the Aran 01 user is the owner of the raw temperature measured every 30 seconds by the temperature sensors deployed in di erent rooms of the home, the raw electrical demand measured by the electricity meter every 5 seconds and the raw electrical production of the PV panels measured every hour. The Aran 01 user establishes a relationship with TEKNIKER and PUPIN for the exploitation of the data. On the one hand, TEKNIKER needs raw temperature data to provide the comfort service, and raw electrical demand for generating electrical demand aggregated data, which will be further used by TEKNIKER for the electrical demand forecasting service. For that purpose, the Aran 01 user grants TEKNIKER the raw temperature data usage for comfort purposes and electrical demand data usage for aggregation purposes, as long as this data is used before RESPOND project's ending date (i.e. 2021-01-01). Moreover, the Aran 01 user prohibits TEKNIKER from sharing the raw electrical demand data. On the other hand, PUPIN needs the electrical production raw data in order to provide the electrical production forecasting service. For that purpose, the Aran 01 user grants PUPIN the raw electrical production data usage for prediction purposes. Similar to the requirements set to TEKNIKER, PUPIN can only use the data prior to the RESPOND project's ending, and cannot share the data.
Secondly, TEKNIKER establishes a relationship with the Aran 01 user for comfort and forecasted data visualization, and with PUPIN for data exploitation purposes. On the one hand, the Aran 01 user is only allowed to use the electrical demand and the for mobile app visualization. Moreover, TEKNIKER forbids the Aran 01 user from sharing this data. On the other hand, PUPIN needs the electrical demand forecast data, in order to exploit it for providing the optimization service. Towards that goal, TEKNIKER allows PUPIN using the electrical demand forecast data only for optimization purposes, as long as it is used before the ending of the project. The sharing of this data is forbidden.
Finally, PUPIN establishes a relationship with the Aran 01 user for sending the results of the electrical production forecast service and the electrical optimized pro le, so that they can be visualized in the RESPOND Mobile App. For this purpose, PUPIN allows the Aran 01 user visualizing the forecasted electrical production data and the optimized pro le, but the sharing of this data is prohibited.
Therefore, as a result of the data exchanged between the di erent stakeholders, the Aran 01 user can visualize its own data, as well as aggregated, forecasted and optimized data provided by third parties. 4
In order to represent and formalize the use case's data usage requirements, the
IDS Information Model is used. However, as mentioned before, this ontology
domain-agnostic, so it is not enough to represent the assets to which data usage
requirements apply. Therefore, in order to represent all the necessary
information, the RESPOND ontology [
As part of other RESPOND project developments, every participant dwelling and neighbourhood is represented with appropriate ontological terms. This information remains accessible in an Openlink Virtuoso Server14 version 07.20.3217 for its further exploitation by other services via SPARQL queries.
In order to showcase the machine-interpretable de nition of formal policies, the contract between the Aran 01 user and TEKNIKER (described in the previous section) has been considered. This contract comprises two rules: a permission and a prohibition. This is represented with the following triples: : c o n t r a c t 0 0 2 A Z 6 3 rdf : type ids : Contract ; ids : p e r mi s s i o n : p e r m i s s i o n 2 5 ; ids : p r o h i b i t i o n : p r o h i b i t i o n 4 3 . : p e r m i s s i o n 2 5 rdf : type ids : Pe r m i s s i o n . : p r o h i b i t i o n 4 3 rdf : type ids : P r o h i b i t i o n . 11 https://w3id.org/bot 12 https://saref.etsi.org/core 13 https://w3id.org/seas/FeatureOfInterestOntology 14 https://virtuoso.openlinksw.com/
The permission de nes that TEKNIKER can use the Aran 01 user's demand data for aggregation purposes until the end of the project, that is, prior to the year 2021. This permission is represented with the following triples: : permission25 ids : action ids : READ ; ids : assignee : partner_TEKNIKER ; ids : assigner : aran_01 : ids : constraint : constraint_p25_01 ; ids : constraint : constraint_p25_02 ; ids : targetContent : aran_01_demand . : constraint_p25_01 rdf : type ids : Constraint ; ids : leftOperand ids : purpose ; ids : operator idsa :EQ; ids : rightOperand " Aggregation Purposes "^^ xsd : String . : constraint_p25_02 rdf : type ids : Constraint ; ids : leftOperand ids : now ; ids : operator idsa : BEFORE ; ids : rightOperand "2021 -01 -01 T00 :00:00 Z "^^ xsd : dateTimeStamp .
As it can be seen, the contract de ned using the IDS Information Model ontological terms is assigned to the aran 01 demand individual, which represents the electrical demand of Aran 01. As mentioned before, Aran 01 and the rest of the RESPOND participant dwellings are described and stored in the Virtuoso triplestore. Next, a simpli ed RDF representation of Aran 01 is shown: : irishSite rdf : type bot : Site ;
bot : hasBuilding : aran_01 . : aran_01 rdf : type bot : Building ;
bot : hasElement : aran_01_electricityMeter . : aran_01_electricityMeter rdf : type saref : Device ;
saref : measuresProperty : aran_01_demand . : aran_01_demand rdf : type saref : Property .
Regarding the second rule of the aforementioned usage restriction, it de nes that TEKNIKER cannot share the Aran 01 user's electrical demand data. This rule can be represented with these triples: : prohibition43 ids : action ids : DISTRIBUTE ; ids : assignee : partner_TEKNIKER ; ids : assigner : aran_01 : ids : targetContent : aran_01_demand .
Nowadays, the ine cient operation of buildings makes the building sector responsible for the consumption of about 40% of the global energy. According to recent research, this consumption could be reduced if building occupants are informed about their energy consumption and appliance-usage, as this information could improve the user engagement in energy e ciency activities. Furthermore, the data collected by the smart home solutions could then be exploited to provide users with added-value services to further engage them in this kind of activities. However, users are not eager to share their data unless data sovereignty is ensured.
With the proposed approach, which is based on IDSA's domain-agnostic data usage requirements speci cation approach, it has been demonstrated that machine-interpretable formal policies can be de ned in a built environment scenario for every relationship established between stakeholders. In this way, a step towards the development of a trustworthy ecosystem in the built environment has been taken. Therefore, not only B2B data exchange models are boosted, but also, high-quality analytic services and the energy consumption optimization as a consequence. 5.1
The presented work paves the way towards future research in two di erent aspects.
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 [
The IDSA approach is limited to the semantic representation of humanreadable usage control requirements into machine-interpretable policies. In the line of research related to the automatic speci cation and implementation of human-readable data usage requirements, two main challenges will be studied. On the one hand, the development of user-friendly templates which will autonomously specify the data usage requirements based on the formal speci cation proposed. On the other hand, before the implementation of data usage policies in a technology-dependent way, a translation must be done in order to make speci ed data usage requirements enforceable by speci c technologies. The LUCON open source usage control technology15 is not able to translate machine-intepretable policies into enforceable policies. LUCON will be studied in order to develop a translator which will allow the implementation of technologydependent policies from the speci ed data usage requirements. 15 https://industrial-data-space.github.io/trusted-connectordocumentation/docs/usage control/