Social Internet of Things for Domotics: a Knowledge-based Approach over LDP-CoAP

Tracking #: 1818-3031

Authors: 
Michele Ruta
Floriano Scioscia
Giuseppe Loseto
Filippo Gramegna
Saverio Ieva
Agnese Pinto
Eugenio Di Sciascio

Responsible editor: 
Guest Editors ST Built Environment 2017

Submission type: 
Full Paper
Abstract: 
Ambient Intelligence aims at simplifying the interaction of a user with her surrounding context, minimizing the effort needed to increase comfort and assistance. Nevertheless, especially in built and structured environments, current technologies and market solutions are often far from providing the required levels of automation, coordination and adaptivity. Devices should interact autonomously, should reach opportunistic decisions and take actions accordingly. In particular, user activities and profiles should be among the manifold implicit factors to be taken into account in that process. Home and Building Automation (HBA) is one of the most relevant scenarios suffering from the poorness of the allowed system intelligence, automation and adaptivity. Devices are logically associated through static profiles defined at system deployment stage. The large majority of solutions are proprietary and centralized, and require manual configuration. This paper proposes a novel semantic-based framework complying with the emerging Social Internet of Things paradigm. Infrastructured spaces can be intended as populated by device agents organized in social networks, interacting autonomously and sharing information, cooperating and orchestrating resources. A service-oriented architecture allows collaborative dissemination, discovery and composition of service/resource descriptions. The Semantic Web languages are adopted as knowledge representation layer and mobile-oriented implementations of non-monotonic inferences for semantic matchmaking are used to give decision capabilities to software agents. Finally, the Linked Data Platform (LDP) over the Constrained Application Protocol (CoAP) provides the knowledge organization and sharing infrastructure underpinning social object interactions. The framework has been implemented and tested in a home automation prototype integrating several communication protocols and off-the-shelf devices. Experiments advocate the effectiveness of the approach.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Accept

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 21/Mar/2018
Suggestion:
Accept
Review Comment:

The paper is ready for publications. However, the reviewer is still not totally convinced about the social aspect and interactions between devices in the paper.

Review #2
By Dörthe Arndt submitted on 06/Apr/2018
Suggestion:
Minor Revision
Review Comment:

I see many of my comments addressed and think that in particular the example of the washer-dryer helped to answer most of my questions. Nevertheless I still have two main concerns which stop me from accepting this paper or at least let me hesitate:

1. Your ontology is not clearly defined and needs careful review.
2. Even though you explained the ideas of your non-standard reasoning, I am still not sure what is given/detected and what is derived. So what is “true” here and represents “the world”. I only see equivalence classes and I assume that you can create instances by activating services.

The first point is the most crucial for me and I apologize that I did not pay that much attention to that in my previous review. For the second point I would at least like to get some explanation of what is given and what is derived.

Below my more detailed comments:

Ontology:
- According to your ontology, your data properties swst:followerOf and swst:friendOf have xsd:anyURI as range, but in Figure 3 the values they are actually taking are of type xsd:string, these two types are disjoint. In Figure 7, example 1, these data properties become object properties. Please stay consistent and decide for one range. I would suggest to go for object properties since you want to refer your social objects and not the URIs they have.
- If swst:clientEndpoint and swst:serverEndpoint are sub-properties of iot-lite:endpoint then their range is xsd:anyURI, in Figure 3 these are strings, in Figure 7, example 1, these properties become object properties.
- swst:activationValue has range xsd:string. The values in Figure 4 and 7 are integers.
- swst:likeValue: range xsd:decimal, examples (Figure 5 and 7) xsd:double.
- swst:postedBy, similar problem.

OWL-examples:
As far as I understand, you start with a request, which is simply a declaration of an owl equivalence. In you text you state that the request is what the AS sensed (detects). Even though I think I understand your idea behind the process, it confuses me that you use owl here which already has a fixed meaning. So when something is “sensed” I would expect in owl that an instance of that would be created. Instead, your process searches for a subclass of that request which can also be a union of classes. Once that class is found (or partially found) an instance of that class is created. My problem with the creation of an instance, for example by performing a full close, is that, at least as I would understand the logical representation, it should make the subclass be true. So in your example I would expect that the creation of a Full_Close instance would cause rain or at least the detection of rain (because of the equivalence instead of a subclass relation), but rain is not mentioned anywhere in the text. I guess your argumentation here would be that, as long as we do not know otherwise, we can assume rain and therefore create the instance. Nevertheless, I still have the feeling that you change the semantics of an existing Semantic Web Logic - OWL – which I consider harmful since the Semantic Web is based on mutual agreement. If my understanding is right, maybe you can simply replace “detects” by “covers”? I think that would already help. Is that then still correct in your understanding?

Some more questions here:
- you say that the request causes a Concept Covering process, is such a process always started when we have a request or what triggers the process? How does your system know what request is? Everything which is posted on the wall? Everything which belongs to the class “request”?
- You introduce service requests and service descriptions, there seems to be a fundamental difference between those even though the have a similar form: requests need to be “covered”. It could be good to emphasize that.
- Page 14 left: you say that available resources are represented by there functionalities and I think you mean as in Figures 11 and 12, but before you have some “functionalities” described in Figure 4 which is a different kind of descriptions. Since that caused confusion for me, I would suggest to be a little bit more consistent with your terminology. Are service annotations the same as service descriptions?

More (mostly minor) comments:
- Abstract: “the Semantic Web languages are adopted” → all of them?
- General: I often had the feeling that you used OWL and RDF synonymously, please check carefully when you mean what in the paper
- Page 2: According to the SwoT paradigm, standard technologies were adapted… → Standard technologies were adapted according to…
- Page 6: “since the receiver N_i accepts it, they became able to...” → if the receiver N_i accepts it, they become able to...”
- Page 7, no co-ownership. The example is more for friendship not for a follower relation based on no co-ownership.
- Page 8, Definition of like value: can you add a reference where to find the definition of that CNF-induced norm on concept expressions?
- Page 10: LDP specification only supports… → The LDP specification only ….