EUPont: High Level Representation for End User Programming in the IoT

Tracking #: 1566-2778

Fulvio Corno
Luigi De Russis
Alberto Monge Roffarello

Responsible editor: 
Guest Editors IoT 2017

Submission type: 
Ontology Description
The Internet of Things (IoT) is, nowadays, a well-established paradigm. However, as the number of available interconnected "things" grows, new challenges emerge, especially concerning interoperability and end-user personalization. In this field, various programming environments for end users allow the composition of IoT applications, i.e., simple connections between IoT devices and services, to personalize their joint behavior in the home, in the car, or for a healthy lifestyle. Unfortunately, current available programming environments mainly adopt excessively technology-dependent representation models (e.g., with manufacturer/brand categorizations) that are not suitable to face the expected growth of IoT devices, nor they allow to define rules that work with dynamically discovered IoT services. To overcome the defects of such low level of abstraction, this paper presents EUPont, an OWL ontology that defines an abstract, high-level representation model for end user programming in the IoT. The main use case of EUPont is the definition of generic and abstract IoT applications that fit different contextual situations. In addition to formally describing the ontology, we report a detailed use case, and we ensure EUPont consistency. Finally, we show the adoption of EUPont in a web-based system for composing of IoT applications.
Full PDF Version: 


Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 31/Mar/2017
Review Comment:

Within this submission the authors present an ontology for the description of IoT devices, their functionalities, and services that can be carried out based on data from the IoT devices.

While this is surely an interesting topic, the contributions of this submission do not justify publication within a journal. I have little concerns about the technical content of this paper, which is quite straightforward. However, one should ask where the theoretical challenges of the work presented in this submission actually are. It seems as if it was not really difficult to build the ontology.

The paper is mostly well-written and very easy to understand, which on the downside somehow points again to the fact that the actual technical contribution is not that interesting or surprisingly new.

The major weakness of this paper is however the evaluation. The authors claim themselves several times that the major goal of their work is to provide an easy-to-use interface to IoT devices and services. I agree with this and, therefore, actually I expect that the authors provide an in-depth user study showing that this claim is true. The authors state themselves that they are currently working on two user studies for this. Once these user studies are finished, the authors should present the results. Until then, the paper needs to be rejected. At the moment, the authors just present a generic, artificial use case study, which is not really convincing.

Please note that I would have opted for "Revise and Resubmit as New" if this option would be offered by the Semantic Web journal.

Review #2
Anonymous submitted on 21/Jun/2017
Review Comment:

This paper presents an ontology to define an abstraction layer that provides end users with a generic interface to describe their requirements.
The paper is well written and structured, and the idea well presented.
The ontology reuses most existing vocabularies, which is a good practice.
It is structured around three layers, namely trigger-action programming, IoT ecosystems, and contextual information.

The trigger-action level follows the IFTTT idea, which is very straightforward. Some additional complexity could be added here.
What happens when two users in the same room have different temperature preferences or sense different temperature values?

The contextual information part is limited to the "user" and "location" concepts, which is under-representing how context can be modeled in a rich way and is diminishing the complexity that is required to deal with context. However, it shows how context can contribute to drive event-based applications.

The IoT ecosystem part provides abstraction from devices but it is not explained how typical problems such as API heterogeneity can be addressed.
For example, two lamps can have very different APIs, one could have an on/off switch whereas the other has a progressive, linear switch (from 0 to 100).
It is not explained how this kind of heterogeneity is resolved and how the ontology contributes. The definition of different services just pushes the problem up to the service level, where the user still has to deal with different APIs. In this example, one way or another, the ontology alignment problem remains, and the high level "light on/light off" behavior does not really match the second API.

The following choices also should be better explained:
- A "eupont:value" property is defined, why not use RDF/OWL built-in constructs ?
- The abstraction level has a lot of implications: in the example of the paper, something that triggers in "all closed spaces" implies that all the vocabularies are defined in a way that it is possible to infer whether or not they belong to the "closed space" category. How to do that ?
- The benefits of the abstraction are lost if the user wants to define specific rules according to the location, which actually might be likely to happen in the example (temperature preferences for home and work). The developed example could be more convincing.
- Presence detection can also be tricky, associating user location with a space implies that it is possible to define the space according to GPS coordinates.

Overall, despite the fact that the work goes into the right direction, it seems to be at a too early stage to be accepted as it is. I recommend the authors to focus on one specific problem, to improve the structure of the ontology and provide a specific solution to the problem that have to be dealt with in this context, with theoretical support that relies (for example) on specific reasoning mechanisms, together with experiments and evaluations that make sense (the timings provided in the paper do not really make sense as the problem addressed here does not seem to be related to performance issues). That could improve the quality of the paper.

some typos :

event if => even if
entitiy => entity (several times over the paper)
eupont:Bulding => eupont:Building