In recent years, there has been an increasing number of sensors embedded in smart devices (e.g. smartphones, smartwatches and smart glasses). These smart devices are becoming increasingly connected to the internet, and the data is sent to the Internet to create the “Internet of Things” (IoT) applications (also known as the “Web of Things”). This requires the design and deployment of new services that are capable of supporting multiple, scalable and interoperable (multi-domain) applications, in addition to other fundamental requirements such as software engineering and infrastructure. The interconnection and interoperability of connected devices is a challenge regarding the IoT. Moreover, the semantics and exchange of information between these devices vary significantly, resulting in a rich but also heterogeneous IoT sphere. Semantic reasoning is a solution for this issue. In the subsequent paragraphs, we explain the semantic reasoning and key technologies used, including ETSI Smart M2M SAREF and SPARQL.

Semantic reasoning

A semantic reasoner is also known as a rule engine, reasoning engine or reasoner. This software tool can infer logical consequences from a set of available axioms or asserted facts. Semantic reasoners generalize the notion of an inference engine by providing a richer set of mechanisms for performing operations.

An ontology language and a description logic language are typically used to specify the inference rules used by semantic reasoners. Many semantic reasoners perform reasoning tasks using first-order predicate logic. This implies that inference is performed via forward chaining and backward chaining. Probabilistic reasoners such as probabilistic logic networks and non-axiomatic reasoning systems also exist.

The reasoner used in this demo

In general, a reasoning cycle can be divided into five steps:

W3C SPARQL covers the first three steps (the SELECT query for selection and CONSTRUCT for transformation). By extending the SPARQL query language, the fourth step can also be covered by adding rules. Therefore, the reasoner developed in this demo uses SPARQL. It takes an instance generated by the semantic annotator and several predefined rules as input. Next, a query is executed on the graph that represents this instance. Finally, the result of the reasoning is serialized into a graph.

Use cases

Use case 1:

This use case includes a temperature sensor, ventilator and heater. The reasoner manages the information coming from these devices and suggests actions according to the temperature measurement. The rules are as follows:

  • If the temperature is lower than a low threshold, the room is considered
  • If the temperature is greater than a high threshold, the room is considered HIGH.
  • Otherwise, the temperature is considered NORMAL.
  • The ventilator is ON when the temperature exceeds a ventilation threshold.
  • The heater is ON when the temperature is lower than a heating threshold.

Use case 2:

This use case includes a washing machine that can be used during off-peak hours. Washing machines are one of the most energy-intensive appliances, therefore, it is more economical to use them during off-peak hours. Depending on parameters such as washing duration, off-peak hours, available power, timestamp,etc., the reasoner decides whether to use the washing machine or not. The rules of this use case are as follows:

  • If the actual time and wash duration are within the off-peak hours interval, then the washing machine can be used.
  • If the first rule is verified and the available power is greater than the power required, the machine is activated, and the following message is displayed: “Available power is sufficient”.
  • Otherwise, the following message is displayed: “Not enough power”.

Custom scenario

In this case, the user is provided with a choice to try reasoning on a personal example by loading a custom dataset and writing a new query. Only the following formats are supported for uploading data to the demo: TURTLE, RDF/XML, N3, N-TRIPLES, TRIX and JSON-LD. Conversely, the output can be formatted to HTML, JSON, TXT or XML.

Trilab

The demonstrator is available online Try it out!

You will discover the above-mentioned scenarios.

In scenario 1 you can:

  • Define the values of the temperature thresholds.
  • Simulate a temperature value by moving the slider that represents the temperatures in the range [0°C, 60°C].

In scenario 2 you can define the:

  • Electricity prices.
  • Corresponding hours.
  • Available power
  • Wash duration

In both cases, the application updates and redisplays the SAREF-compliant input model. A SPARQL query is then executed on this model according to the predefined rules, and the file containing the result is updated and redisplayed. Finally, an animation is performed that shows the status of the heater and ventilator.

You also have the possibility to reason using your own model.

  • The user chooses the file containing his/her personal dataset.
  • By clicking on the Load button, this file is loaded by the application.
  • The user writes the query to be executed, including all the rules.
  • By clicking on the Save Query button, the query written by the user is downloaded to his/her local directory.
  • Next, the user chooses the format of the result from the following formats: XML, JSON, HTML or txt.
  • By clicking on the Query button, the query is executed on the instance and the result is displayed on a separate page. The result can be saved directly to the local directory if Download Response is selected before clicking on the Query
Said Lourhaoui
Said Lourhaoui
Dune Sebilleau
Dune Sebilleau
Amélie Gyrard
Amélie Gyrard