key: cord-0057760-7vfdgj3a authors: van der Weerdt, Roderick; de Boer, Victor; Daniele, Laura; Nouwt, Barry title: Validating SAREF in a Smart Home Environment date: 2021-02-22 journal: Metadata and Semantic Research DOI: 10.1007/978-3-030-71903-6_4 sha: 2add809b9e7642a606384b99c85db54da99b7a94 doc_id: 57760 cord_uid: 7vfdgj3a SAREF is an ontology created to enable interoperability between smart devices. While the IoT community has shown interest and understanding of SAREF as a means for interoperability, there is a lack in the literature of practical examples to implement SAREF in real applications. In order to validate the practical implementation of SAREF we perform two experiments. First we map IoT data available in a smart home into RDF using SAREF. In the second part of the paper an IoT environment is created by using the Knowledge Engine, a framework created to allow communication between smart devices, operating on Raspberry Pi’s emulating IoT devices, where the communication of the IoT devices is performed by sharing knowledge represented with SAREF. These experiments demonstrate that SAREF is an ontology that is successfully applicable in different situations, with data-mapping showing that SAREF is able to represent the information of different smart devices and by using the Knowledge Engine showing that SAREF can enable interoperability between smart devices. Over the last years more and more companies have started making smart devices that can be connected to the Internet of Things (IoT). Connecting multiple devices brings the promise that all those devices are now able to interact with each other in meaningful ways. Unfortunately the reality is that devices are not nearly as interconnected as one would want [1] , often devices can only be accessed from specific (vendor-based) apps, other times the devices are not able to communicate because they do not speak the same language. In order to make the interoperability between smart devices within IoT possible the Smart Applications REFerence ontology (SAREF) has been created [2] , an ontology specifically designed to encompass the information that smart devices need to exchange in order to have meaningful interactions. SAREF has been validated before [3, 4] to determine the quality of the ontology. But until now there has not been a practical implementation of the SAREF ontology, to validate if it satisfies requirements needed to map real data from real devices. The goal of this paper is to create an example of said implementation, validating the ontology in two ways, its ability to express all the information available from multiple smart devices in a home and its ability to enable interoperability by representing messages in a meaningful manner allowing for communication between smart devices. To achieve the first goal we map data collected in a smart home (Sect. 3) into RDF using SAREF. For the second goal the Knowledge Engine is proposed to validate the effectiveness of using SAREF for communication (Sect. 4). The paper will start with describing the SAREF ontology and related research. To provide a background to our experiments we will first present an in depth examination of the SAREF ontology, followed by three related ontologies and lastly other validation studies using competency questions to validate ontologies. The Smart Applications REFerence ontology (SAREF) is a reference ontology for IoT applications (https://saref.etsi.org/) [5] . Its development started in 2013, when the European Commission, in collaboration with the European Telecommunication Standardization Institute (ETSI), launched an initiative to build a common ontology in close collaboration with the smart appliances industry 1 [2] . In a fragmented landscape of IoT standards, platforms and technologies across different vertical domains [6, 7] , SAREF was created as a shared model of consensus that could enable the communication among various IoT devices from different manufacturers that use different protocols and standards [8] . The first proof-of-concept solution based on SAREF was demonstrated and implemented in 2017 on existing commercial products in the energy domain 2 [4] . SAREF is published as a series of ETSI technical specifications, consisting of a modular framework that comprises a generic core ontology for loT [5] and 10 domainspecific extensions (ETSI TS 103 410, parts 1-10), such as SAREF for Energy, Buildings and Cities, amongst others. The SAREF framework is maintained and evolved by ETSI and experts from several European organizations that successfully collaborate with each other 3 . One of the latest supported initiatives is the development of an open portal for the SAREF community and industry stakeholders, so that they can contribute directly to the SAREF evolution (https:// forge.etsi.org/rep/SAREF). Figure 1 shows an overview of the main classes and relationships in SAREF. In total SAREF contains 81 classes, 35 object properties and 5 data properties. The starting point is the concept of Device, which is defined as a tangible object designed to accomplish a particular Task. In order to accomplish this task, the device performs a Function. For example, a temperature sensor is a device of type saref:Sensor, is designed for tasks such as saref:Comfort, saref:WellBeing or saref:EnergyEfficiency, and performs a saref:SensingFunction. Functions have commands. A Command is a directive that a device needs to support to perform a certain function. Depending on the function(s) it performs, a device can be found in a corresponding State. A device that wants (a certain set of) its function(s) to be discoverable, registerable, and remotely controllable by other devices in the network can expose these functions as a Service. A device can also have a Profile, which is a specification to collect information about a certain Property or Commodity (e.g. Energy or Water) for optimizing their usage in the home/building in which the device is located. A Property is defined as anything that can be sensed, measured or controlled by a device, and is associated to measurements. For example, a temperature sensor measures a property of type saref:Temperature. A Measurement is the measured value made over a property and must be associated to an unit of measure and a timestamp. The Feature of Interest concept further allows to represent the context of a measurement, i.e., any real world entity from which a property is measured. For example, whether the measured temperature is that of a room or of a person. A more detailed description of the SAREF classes and properties can be found in [5] . The Semantic Sensor Network (SSN) ontology, was specifically created for the modeling of sensors and their observations [9] . This strict focus on sensors allows for a modular use of the ontology with other ontologies. A sensor is defined as "anything that observes", which means it does not include all the different kinds of smart devices that a smart home offers. The Sensor, Observation, Sample, and Actuator (SOSA) ontology is an extension and partial replacement of SSN created to model "the interaction between the entities involved in the acts of observation, actuation, and sampling" [10] . Because SSN was considered to rigid SOSA was created to be more flexible, having 13 concepts and 21 properties compared to the 41 concepts and 39 object properties of SSN. The Web of Things Thing Description (TD) is a newer ontology that was also created by W3C [11] . This ontology models the metadata of the devices instead of the measurements. The creators envision that every smart device will its own TD to serve as identification and as a starting point for interaction with the device, similar to a index page of a website. But it lacks the representation of the measurements made by the devices that is needed for our experiments. Validation of an ontology can be done by creating a scenario and formulating a set of competency questions. Competency questions are proposed as a way to informally define requirements for an ontology, the resulting ontology should be able to answer all of the competency questions to prove it is the correct ontology to use in this scenario [12] . Competency questions have been used to validate SAREF before, as demonstrated in the research by Moreira et al. [4] . In their work they created a model that maps a knowledge graph using the SSN ontology into a knowledge graph using the SAREF ontology. Using an example situation of a wind sensor represented using the SSN ontology they were able to map the data to a knowledge graph, but were not able to keep all of the information that was available in the original representation. Competency questions were used to define the requirements that the ontologies required and showed that the new knowledge graph did not retain enough information from the original. The experiment they performed used an example specifically created for SSN, in this paper we will use data that comes from smart devices in a home setting, which is what SAREF was developed for and should therefore allow a better evaluation of SAREF. Another example of competency questions being used as a tool to select different ontologies can be found in [3] . Bajaj et al. use the competency questions they define to determine which classes an ontology requires to fit to their requirements. For example SAREF was rejected by the authors as a suitable ontology because it lacked a class to define the concept of location. Since then a new addition to the SAREF ontology has been the Feature of Interest class, which allows for exactly such a definition. Sagar et al. [13] extend the SOSA/SSN ontology in order to allow for smart sensors, sensors that are able to select and run different algorithms resulting in different data, to be modelled accurately. They create 13 competency questions and based on those reject existing ontologies, including SAREF. The S3N ontology that they propose was able to resolve all the competency questions. Instead of trying to model the algorithms behind "smarter" observations the decision was made to only look at the output of the devices for our experiment since this is the relevant information that we have available. Similarly we only look at the output of a thermometer and not at the intricate ways the device measures the temperature of the room. The main purpose of SAREF is to enable interoperability between different devices and services [5] . In order to validate SAREF this experiment will focus on whether SAREF is capable of expressing all of the information from a smart home by mapping the smart devices to a knowledge graph using SAREF. This experiment will take data from 33 smart devices in a smart home and transforms it into a knowledge graph using the SAREF ontology. The smart home is part of a pilot from a large construction company experimenting with adding smart devices to the houses they build. We started with removing duplicate smart devices that were used multiple times in the house such as the thermometer in the living room and in the bedroom. This resulted in nine data sources that will be used for this experiment: -current temperature, measurement of the room temperature in degrees Celsius. -CO2 levels, measurement of the ppm CO2 in a room. -last time movement detected, marks the most recent moment (timestamp) that movement was detected in a room. Used to determine when residents are at home. -first time movement detected, marks the beginning (timestamp) of new movement detected in a room. Used to determine when residents are at home. -motion detected, returns a yes or no state based on whether the sensor detected motion. -presence detected, returns a yes or no state based on whether the sensor detected presence, based on the CO2 levels in a room. -humidity, measurement of the percentage of humidity in a room. -smart switch actuator, an actuator that can be turned on or off by sending it an on/off command. -target temperature, the desired temperature of a room in degrees Celsius, controlled by the thermostat. All the sensors send updated information every five seconds, which is recorded with a timestamp. The complexity of the data from the sensors differs from the "simpler" thermometer to the more elaborate last time movement detected. As was discussed in Sect. 2.3 we only focus on the output of the device and not the internal calculations. The combination of these data sources can be used in multiple scenarios, a possible scenario would be to adjust the room temperature when there are no people present. Using a combination of the first time movement detected data and the last time movement detected data, which in turn is based on the motion detected and presence detected data, we can determine whether a home is occupied. When there are no people present the target temperature could be set to a lower setting, meaning lower as opposed to the target temperature when there are people present. When the current temperature is below the target temperature a command can be send to the heating system of the home (in the case that one of the smart switch actuators is connected to a heating system) shutting it down, this would allow a home to only be heated when it is needed. Not all classes shown in Fig. 1 are used in the mapping for a data source. For example a command that is sent to a smart actuator will not be using the saref:Measurement class. The Technical Specification [5] describing the SAREF ontology is used to make a selection of relevant classes for each smart device. The relevant classes for each device can be seen in Table 1 . Most mappings are easily performed by selecting the straightforward SAREF class, for example for the saref:Property class in the mapping of the thermometer we can use its subclass saref:Temperature to mean that the measurement in this graph pattern relates to temperature. For the sake of clarity this paper only contains mappings for two data sources and a summary of the special cases where the decisions made need an explanation. The complete mapping of all the data sources can be found online 4 where all the mappings are represented as triples. The two examples that are chosen to be clarified are the data from the thermometer and the data from the CO2 sensor. The thermometer mapping is an example of a mapping where all the relevant classes are already available. For the CO2 sensor two new subclasses have to be added. The OM1.8: Units of Measure ontology [14] was chosen to use to represent the units of measure, as suggested in [5] . Thermometer. The thermometer makes a measurement of the temperature in a room. The mapping requires the: saref:Measurement class for the value of the temperature and timestamp. Aside from the two cases described above there was one other case where extra work was required. Just like with the CO2 levels measurements the humidity measurements requires a new subclass for saref:UnitOfMeasure to express that it is a humidity measure. It uses the OM1.8 instance for percentage: om:percent rdf:type ex:HumidityUnit This part of the paper is designed to test the capability of SAREF to enable interoperability between different devices. First the scenario will be detailed and the competency questions will be formulated accordingly. To achieve interoperability, multiple separate devices should be setup that 1) do not have direct or hard links between them and 2) communicate exclusively using SAREF. To the best of our knowledge no other ontology-based interoperability framework in smart homes allows for the data to remain at the source where it is produced. Our findings should generalize to other interoperability frameworks. The Knowledge Engine will be shortly described in Sect. 4.2, followed by the implementation and its results. For the sake of simplicity, the paper uses an simple scenario of a temperature controlled room, meaning we will need: information about what room the information is about, information about the temperature of the room, information about the desired temperature and the possibility to control the temperature of the room. Although more competency questions can be defined based on this scenario, we define here the following three competency questions as an example: 1. What is the temperature of a specific room? 2. Is this higher or lower than the threshold temperature? 3. Should the heater be turned on or off? The Knowledge Engine is a framework that allows multiple IoT devices to exchange knowledge in an interoperable way within a network. It is used by adding a smart connector to each device and registering this smart connector in the service directory, a visualization can be found in Fig. 2 . The smart connector provides two functions to achieve interoperability: translation and discovery. It translates between a common ontology and the specific language of the device it is connected to, allowing devices from different vendors to understand each other. It also dynamically discovers other smart connectors that can supply relevant data, which prevents hard links between devices. These two functions of the smart connector allow connections between devices in a network to be solely based on concepts and relations from a common ontology. This means that any device in the network can potentially be replaced by a similar one from a different vendor without loss of function i.e. they are interoperable with each other. Both the translation and the discovery functions of the smart connector require configuration. Regarding the translation, this configuration consists of custom code provided by a developer that maps the specific device language to the common ontology. For discovery, the smart connector needs to be configured with the capabilities of the device (i.e. the knowledge demand and knowledge supply). The demand describes (in terms of the common ontology) the data that the device requires to function, while the supply describes the data that the device can provide to other devices. These capability descriptions use a SPARQL-like syntax to describe graph patterns, see Fig. 3 . Apart from this configuration, the discovery function also requires a component called "Service Directory" to which all smart connectors in the network register themselves and from which they can retrieve the other smart connectors currently available. A single smart connector is an extended version of the Apache Jena Fuseki triple store that is not used for actually storing the triples, but for its reasoner to orchestrate the knowledge exchange process. This reasoner uses rules that are based on the configuration (i.e. capabilities) of all available smart connectors in the network about which every smart connector regularly retrieves updates from the service directory. Whenever a device publishes or requests data, the smart connectors make sure that it is received by or from the correct device. Mutually, the smart connectors use a combination of SPARQL and a publish/subscribe mechanism to communicate. For example, a thermometer device would have a supply capability description, like the one shown in Fig. 3b . The thermostat requesting this information uses a demand capability description that looks identical, because both supply and demand capability descriptions follow the same SPARQL-like structure, multiple triples with variables for the data that it either demands or supplies. The Knowledge Engine can use any ontology to structure the knowledge that it shares (both capability descriptions and RDF data). For this experiment SAREF was used, but it could also work with different ontologies like SOSA/SSN [10] . By using the Knowledge Engine we can validate SAREF by implementing it for the knowledge that is exchanged within its communications. The smart connectors run on Raspberry Pi 4B's, allowing easy configuration relevant to the device it is connected to with a config file 5 . The configuration requires a name and short description of the device and allows for inclusion of their capability descriptions. For this experiment, the smart device and smart connector are on one device with the devices being controlled with a python script that "makes" the devices smart allowing for communication with the Apache Fuseki server. A separate laptop runs the service directory and lastly, a WiFi router allows the smart connectors to connect to each other and to the service directory, as represented by the dashed lines in Fig. 2 . The first Raspberry Pi functions as a thermometer. It has one knowledge supply containing the temperature measurements made by the connected thermometer and the room it is located in. This knowledge supply can be found in Fig. 3b , ?room is the name of the room and ?temp is the latest measurement of the temperature. The second Raspberry Pi functions as a thermostat, it has an internal desired state for the temperature of this room which can be adjusted with the connected buttons. It demands the temperature of this room (knowledge demand in Fig. 3b) and supplies a command based on that current temperature (knowledge supply in Fig. 3a) , if the current temperature is below the desired state the smart connector will send saref:OnCommand for ?command, if it is higher it will send saref:OffCommand. The last Raspberry Pi represents a heating device, demanding a command for this room (knowledge demand in Fig. 3a) . When the smart connector receives a saref:OnCommand it will turn on the heater (in this case the led light will turn on) and when it receives a saref:OffCommand it will turn it off. When all three of these smart connectors communicate correctly they will be able to control the temperature in a room. Smart connector b will receive the temperature of the room from smart connector a, compare it with the desired temperature (which can be adjusted with its buttons) and based on that send either an on or off command towards smart connector c. In order to make all of the knowledge exchanges between the smart connectors possible two different capability descriptions are required, shown in Fig. 3 . Using the information from these devices we are able to answer all three of the competency questions. The graph patterns that are sent by the smart connector connected to the thermometer (Fig. 4b) answers the first question, the temperature of the room. The second competency question is answered internally in the smart connector connected to the thermostat and the third competency question is solved by the thermostat smart connector sending its graph pattern that is received by the third smart connector that interprets and either turns the heater off or, in the case of Fig. 4a , on. In the first part of the paper we validated how data sources of a smart home scenario could be mapped to SAREF. We demonstrated that this can be done in a straightforward way. In the two cases were there were exceptions, as shown in Sect. 3.2 they were simple to add given the flexibility by design of SAREF. On the other hand, this could potentially lead to incompatibility issues if different people create their own extensions for similar situations. To that end, ETSI has recently created a open community portal (saref.etsi.org) where SAREF users can submit their contributions that will then be considered in the official standardization process to become part of new SAREF releases. The second part of the paper showed a simple, practical implementation of SAREF using the Knowledge Engine, which is a promising framework that allows multiple IoT devices to exchange knowledge in an interoperable way within a network. The example used a scenario in which three devices shared knowledge to control the temperature of a room. We acknowledge that the scenario presented in the paper is rather simple and more work in the immediate future is aimed at increasing the number and type of sensors in a more complex scenario than only heating the room, also considering more than one household. More future work could recreate the scenario we presented with other interoperability frameworks or using different ontologies. An empirical examination of consumer adoption of internet of things services: network externalities and concern for information privacy perspectives Created in close interaction with the industry: the Smart Appliances REFerence (SAREF) ontology Study of Existing Ontologies in the IoT-Domain Towards IoT Platforms' Integration Semantic Translations between W3C SSN and ETSI SAREF ETSI TS: 103 264 V3.1.1, SartM2M; Smart Applications; Reference Ontology and oneM2M Mapping IoT LSP Use Cases and Standards Gaps Study on Ensuring Interoperability for Demand Side Flexibility The SSN ontology of the W3C semantic sensor network incubator group SOSA: a lightweight ontology for sensors, observations, samples, and actuators W3C: Web of Things (WoT) Thing Description Methodology for the design and evaluation of ontologies Modeling smart sensors on Top of SOSA/SSN and WoT TD with the semantic smart sensor network (S3N) modular ontology Ontology of units of measure and related concepts Acknowledgements. This work is part of the Interconnect project (interconnectproject.eu/) which has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No 857237.