Semantic Web 0 (2017) 1 1 IOS Press Social Internet of Things for Domotics: a Knowledge-based Approach over LDP-CoAP Michele Ruta a,* , Floriano Scioscia a , Giuseppe Loseto a , Filippo Gramegna a , Saverio Ieva a , Agnese Pinto a , and Eugenio Di Sciascio a a Dept. of Electrical and Information Engineering, Polytechnic University of Bari, via E. Orabona 4, I-70125, Bari, Italy E-mail: [email protected]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 of the ambi- ent. 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 dissem- ination, 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. Keywords: Semantic Web of Things, Objects Social Networks, Building Automation, Linked Data Platform, Constrained Application Protocol Eventually everything connects – people, ideas, objects. The quality of the connections is the key to quality per se. Attributed to Charles Eames [1] 1. Introduction In the Ambient Intelligence (AmI) vision, built en- vironments interact with their inhabitants in an “un- obtrusive, interconnected, adaptable, dynamic, embed- ded and intelligent” way [2]. Personal requirements and preferences are grasped, deciphered and formal- ized as well as the environment can adapt to them, and even anticipate people’s needs and behaviors. The AmI idea leverages technological progress in the Internet of * Corresponding author. E-mail: [email protected]. Things (IoT), where large numbers of everyday objects are augmented with communication and computation capabilities. People in their usual environments are in- creasingly surrounded by networks of micro-devices, endowed with embedded sensors for data capture as well as processing units for deriving context informa- tion. To create real cohesive AmI, such devices should communicate and coordinate autonomously, making decisions dynamically based on manifold factors, in- cluding the state of surrounding objects and places as well as user activities and profiles. While traditional human-computer interaction has been explicit and me- diated by input peripherals, in AmI implicit, effortless interaction paradigms predominate, where relevant in- formation about users’ goals and intentions is inferred automatically by analyzing their actions and context, through sensors integrated in the environment or in wearable things. 1570-0844/17/$35.00 c 2017 – IOS Press and the authors. All rights reserved
Transcript
Semantic Web 0 (2017) 1 1IOS Press
Social Internet of Things for Domotics: aKnowledge-based Approach over LDP-CoAPMichele Ruta a,*, Floriano Scioscia a, Giuseppe Loseto a, Filippo Gramegna a, Saverio Ieva a,Agnese Pinto a, and Eugenio Di Sciascio a
a Dept. of Electrical and Information Engineering, Polytechnic University of Bari, via E. Orabona 4, I-70125, Bari,ItalyE-mail: [email protected]
Abstract. Ambient Intelligence aims at simplifying the interaction of a user with her surrounding context, minimizing the effortneeded to increase comfort and assistance. Nevertheless, especially in built and structured environments, current technologiesand market solutions are often far from providing the required levels of automation, coordination and adaptivity of the ambi-ent. 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 autonomouslyand sharing information, cooperating and orchestrating resources. A service-oriented architecture allows collaborative dissem-ination, discovery and composition of service/resource descriptions. The Semantic Web languages are adopted as knowledgerepresentation layer and mobile-oriented implementations of non-monotonic inferences for semantic matchmaking are used togive 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 frameworkhas been implemented and tested in a home automation prototype integrating several communication protocols and off-the-shelfdevices. Experiments advocate the effectiveness of the approach.
Keywords: Semantic Web of Things, Objects Social Networks, Building Automation, Linked Data Platform, ConstrainedApplication Protocol
Eventually everything connects – people, ideas,objects. The quality of the connections is thekey to quality per se.
Attributed to Charles Eames [1]
1. Introduction
In the Ambient Intelligence (AmI) vision, built en-vironments interact with their inhabitants in an “un-obtrusive, interconnected, adaptable, dynamic, embed-ded and intelligent” way [2]. Personal requirementsand preferences are grasped, deciphered and formal-ized as well as the environment can adapt to them, andeven anticipate people’s needs and behaviors. The AmIidea leverages technological progress in the Internet of
Things (IoT), where large numbers of everyday objectsare augmented with communication and computationcapabilities. People in their usual environments are in-creasingly surrounded by networks of micro-devices,endowed with embedded sensors for data capture aswell as processing units for deriving context informa-tion. To create real cohesive AmI, such devices shouldcommunicate and coordinate autonomously, makingdecisions dynamically based on manifold factors, in-cluding the state of surrounding objects and places aswell as user activities and profiles. While traditionalhuman-computer interaction has been explicit and me-diated by input peripherals, in AmI implicit, effortlessinteraction paradigms predominate, where relevant in-formation about users’ goals and intentions is inferredautomatically by analyzing their actions and context,through sensors integrated in the environment or inwearable things.
2 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
Current solutions for Home and Building Automa-tion (HBA) are still far from the above levels of intel-ligence, automation and adaptivity. They grant limitedflexibility, as devices are logically associated at the ap-plication level by means of static profiles, defined atsystem deployment stage. With most established HBAstandards, changing the set of possible configurationsor introducing new devices require the intervention ofqualified practitioners. Recently, product manufactur-ers and system integrators have proposed more user-friendly “smart home” devices and platforms, lever-aging the IoT [3]. Unfortunately, solutions are pro-prietary and centralized, and they still require man-ual configuration. This seemingly improved usabilitycomes at the price of providing only very basic au-tomation [4], typically using Event-Condition-Action(ECA) rules on simplistic threshold or on/off condi-tions.
Hence, significant technological advances are neededto fully accomplish the AmI vision. Flexible and mean-ingful relationships among devices in a given environ-ment should be possible, established automatically tosupport articulate orchestration and coreography pat-terns. Recent research in the so-called Social Internetof Things [5] is starting to define models and archi-tectures to reach this goal. Paradigms are often bor-rowed from Social Networking Services (SNS) for hu-man users. If properly adapted to the peculiarities andrequirements of Multi-Agent Systems (MAS), theycan support powerful approaches. This is not enough,however, for true AmI: versatile cooperation, organi-zation and integration can be achieved only if con-nected things can represent, discover and share infor-mation and services described in an articulate way bymeans of high-level formalisms. Semantic Web tech-nologies are natural candidates for such a role, as theyprovide interoperable languages and tools groundedon formal logic semantics [6]. Semantic Web stan-dards enable knowledge modeling, assertion, organi-zation, querying and inference in distributed systems,but technologies and tools require proper adaptation towork efficiently in resource-constrained environmentslike the IoT. The Semantic Web of Things [7] aims atthe convergence of the Semantic Web and IoT visions,endowing environments with intelligence by meansof semantic metadata dynamically produced by ubiq-uitous micro-devices to characterize sensor data, de-tected events and phenomena, objects, places and otherrelevant entities in a context. Due to the volatility andunpredictability of mobile and IoT environments, de-vice and service discovery are two major challenges
in the SWoT. Achieving acceptable performance alsorequires attention, as Semantic Web tools, protocolsand languages are typically too resource-consumingfor current IoT devices. Application-level protocolsand reasoning tools for the (Semantic) Web must beproperly adjusted, tailoring their feature set to perva-sive computing contexts.
This paper presents a possible approach for a Se-mantic Social Internet of Things grounded on Am-bient Intelligence scenarios. According to the SWoTparadigm, standard technologies were adapted to pro-vide a cohesive knowledge and service discovery ar-chitecture. The proposal leverages: i) the Linked DataPlatform (LDP) [8] to annotate and organize infor-mation resources and ii) the Constrained Applica-tion Protocol (CoAP) [9] –a proposed IETF1 stan-dard RESTful protocol– for resource exchange in con-strained environments, as it is more efficient thanHTTP. Above this knowledge/service interoperabil-ity layer, a semantic-enhanced application level en-ables social networking among “agentified” things.Entities and operations in domotics and IoT scenar-ios are mapped to a novel social multi-agent service-oriented architecture (SOA), supported by semantic-based capabilities. It should be noticed that the pro-posed framework addresses the specific needs of IoTsystems both in terms of communication and comput-ing standpoints, but also in terms of functional and/orarchitectural aspects. The proposed MAS is intrinsi-cally general purpose and platform-independent in or-der to comply with a possible exploitation in differ-ent scenarios and contexts. Anyway, IoT constraintsset the choice of a lightweight application protocol likeCoAP (satisfying minimum functional requirements ofa small device-oriented SN without excessive com-putational/bandwidth load at the application level), aswell as they impose architectural and implementationchoices devoted to keep under control the frameworkdeployment in real-world micro-devices. This has beenpursued through the adoption of compression strate-gies for language verbosity control, through the selec-tion of a compact OWL syntax and via the targeted us-age of both memory and data structures. Finally, thearchitectural approach followed aims to make modu-lar and componentized the micro-SN fundamental el-ements in order to allow functional (high-level) prop-erties to be enrolled on-demand following (low-level)device capabilities.
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 3
Borrowing core relationships and structure frompopular SNSs, devices enable specific interaction pat-terns for information sharing and cooperative de-centralized service/resource discovery. Such selec-tive choreography is triggered autonomously, basedon the kind of managed resources and other contex-tual factors; this capability enhances interoperabil-ity across heterogeneous platforms and scalability indense multi-agent environments. Resource discoveryexploits semantic matchmaking between ontology-based annotations which describe requests and avail-able resources. Non-standard, non-monotonic infer-ences [10] implemented in the Mini-ME mobile match-maker and reasoner [11] allow supporting approxi-mated matches, resource ranking and aggregation forcovering complex requests. The framework also sup-ports basic and legacy devices, which do not have com-putational power enough for on-board reasoning, byallowing them to select a more capable friend as infer-ence facilitator.
The general framework outlined above has been fo-cused on smart HBA, to provide AmI experiences inresidential and workplace settings. It was implementedand evaluated in a real prototypical testbed, encom-passing diverse device types, communicating acrossdifferent wired and wireless HBA protocols. Experi-mental evidences are reported and assess frameworkfeasibility and effectiveness.
The remainder of the paper is as follows. Section 2discusses the state of the art, while the framework isdescribed in detail in Section 3. Section 4 presents acase study to further clarify the proposal and its bene-fits. Experimental evaluations in Section 5 provide anassessment of both practicability and efficiency of theproposed approach, before conclusion.
2. State of the art: pervasive computing in thesocial networks epoch
In latest years, social networking services havechanged personal interaction habits and relationshipsmanagement on a global scale. Members of SNSscreate personal profiles with basic information aboutthemselves; connect with other users in either bidirec-tional (e.g., friendship, group) or unidirectional (e.g.,follower) relationships; post text and/or multimediaitems on their wall (i.e., log) for sharing with their con-tacts; flag (tag) some contacts to associate them anddraw their attention to a certain element; respond tocontent published by other users with comments and
reactions (e.g., like). SNS adopters generally mani-fest an intention to continue using them [12], becauseSNSs provide both utility (extrinsic value) and gratifi-cation (intrinsic value). Their usefulness also grows asthey connect more users, and particularly complemen-tary ones [12], since opportunities increase for discov-ering interesting information and services.
A social evolution of pervasive computing [5] envi-sions objects acting as independent agents, capable ofestablishing relationships and using them to share in-formation and services more effectively. This may al-low to reap the above benefits in advanced IoT sce-narios; actually, it is reasonable to expect them to behigher in large and heterogeneous networks, such asin HBA. An in-depth analysis of object social net-works can be found in [13], which discussed key met-rics about nodes and links by adapting from and ex-panding upon the social network analysis literature.Definitions were formalized in an ontology objects canuse to manage their policies, friends and reputation.The following differences exist w.r.t. the approach pro-posed in this paper: (i) both a symmetrical relation-ship (friend) and an asymmetrical one (follower) weremodeled, whereas [13] includes only an asymmetricalfriendship model; (ii) a reference ontology referring toseveral well-known Resource Description Framework(RDF) vocabularies was developed in order to improveand facilitate the interoperability among different sys-tems; (iii) non-standard inference services were ex-ploited to support a semantic-enhanced resource dis-covery and composition in social environments. Fur-ther ontology proposals exist to formalize models ofthe social networking domain, e.g., [14]. Particularly,in [5], things engage with one another in social net-works independently from human SNSs and from userinteractions. A relevant case [15] included social ob-ject capabilities in control networks, aiming at dis-tributed Web Ontology Language (OWL) KnowledgeBase (KB) management and inference. When connect-ing to the network, every object proactively exchangedinformation with other devices in a handshake pro-cess. “Requester” devices, equipped with reasoningfacilities, could then distribute queries automaticallyamong “known” devices. Unfortunately, the adoptedquery language supported only very simple inferences,limiting the practical usefulness of the proposal. An-other research direction has been focusing on the in-tegration of the IoT into the social context of hu-man users [14], either to improve adaptivity in AmI[16] or to monitor users and assist them in personal-izing their SNS experience and interactions [17]. In
4 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
[18] semantic-based situation detection and goal re-trieval were used for matchmaking with task profilesto recommend activities to users, based on their cur-rent context. Unlike our approach, social interactionsoccurred only between devices and users; furthermore,adopted rule-based reasoning could not retrieve ap-proximate matches when exact ones did not exist. Afurther effort to achieve social capabilities is objectblogging, defined as an object’s capability of annotat-ing and publishing its history and context on the Weband/or in a mobile ad-hoc network, supporting intelli-gent machine-to-machine interactions. Some proposedapproaches required user intervention [19], while oth-ers aimed at autonomous self-description and decision-making [20].
Many of the above works combine social networksof pervasive objects with semantic technologies. In-deed, semantic-based approaches have wide adoptionin pervasive MAS, and smart building automationis one of the most relevant areas [21, 22]. Ontolo-gies have been used in all stages of the lifecycleof HBA systems, including design and deployment,infrastructure description, data modeling and access,and device control [23, 24]. In [25] an ontology-based building automation system delivered context-aware information in a customized way to differentkinds of users, e.g., upkeep and healthcare operatorsin a clinic. OWL device and user descriptions werematched through SPARQL queries and SWRL ruleswere used to combine logical constraints with context-dependent temporal and numerical ones, achieving ca-pabilities similar to classical Complex Event Process-ing (CEP) systems. Nevertheless, the solution was af-fected from poor maintainability, because installingnew devices required not only manual configuration,but also changes to the reference ontology. The pro-posed architecture in [24] included a reasoning mod-ule exploiting rule-based inferences. Unfortunately,the system state should fully match the rule head inorder to trigger its body. Full matches seldom occurin realistic scenarios, whose entities are featured bydetailed, heterogeneous and often contradictory infor-mation, unless one uses very basic rules. In our ap-proach, non-monotonic inference services allow sup-porting approximate matches, which can yield “goodenough” results whenever full matches are not avail-able.
The proposed distributed Knowledge Base manage-ment and service discovery methods can be a foun-dation for developing further semantic SOA platformcapabilities [26], including automated clustering [27],
negotiation [22], composition [28] and substitution[29]. Finally, semantic alignment is often a problem inheterogeneous systems such as HBA and IoT. Severalworks, e.g., [30], propose mappings. This work lever-ages Linked Data principles to limit the issue, instead,by importing and reusing meaningful parts of other vo-cabularies in a larger social HBA modeled.
3. A social framework for smart linked objects
In what follows the proposed framework, architec-ture and technologies are described.
3.1. Knowledge-based architecture
The approach proposed here aims at object coordi-nation in purposely infrastructured environments andparticularly in domotics scenarios through interactionparadigms borrowed from social networks. The maingoal is allowing devices (a.k.a. nodes) to gain wideagency and autonomy in sharing information and ser-vices, enabling them to distribute requests and ob-tain responses through fully decentralized peer-to-peer(P2P) interactions also assuming decisions. Table 1outlines basic correspondences of concepts and fea-tures in the IoT and domotics domain with the pro-posed service-oriented social environment and the se-mantic capabilities devised to support it. They are dis-cussed in detail in what follows.
Table 1IoT/HBA entities, social features and semantic capabilities
IoT/HBA feature Social environment Semantic capability
Object/Device Social agent LDP-CoAP server &client
Functional profile Service OWL service descrip-tion
Object pairing Social relationship(friend/follower)
Service-oriented architecture. Each node is a so-cial object, which exposes an individual profile, de-scribing its basic features (device type, location, hard-ware details) and the resources/services it can provide,
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 5
e.g., its possible configurations and functional pro-files. A node makes posts on either its wall or friend’swall (according to the different types of interaction de-scribed later) when its settings or capabilities change,and also when it produces new or updated informationthrough context sensing and analysis. Each post con-tains all sensed perceptions and events observed by thesocial device and is considered as a request for systemreconfiguration through a semantic service/resourcediscovery process. Device profiles, service descrip-tions and requests are expressed as semantic annota-tions referred to concepts modeled within ontologiesin Web Ontology Language (OWL 2) [31], formallygrounded on Description Logics (DLs) semantics, re-sulting both machine understandable and human read-able at the same time. A decentralized service-orientedarchitecture (SOA) underlies the whole proposed so-cial network model, where shared knowledge frag-ments about devices, functional profiles and contextrepresent annotated service/resource advertisements.
Semantic matchmaking. Service/resource discov-ery conveys decision capabilities of nodes. As statedbefore, this collaborative process leverages semanticmatchmaking, i.e., the overall process allowing the re-trieval and ranking of the most relevant resources fora given request, where both resources and requests aresatisfiable concept expressions w.r.t. a common ontol-ogy T in a DL L. This paper refers to the OWL 2subset corresponding to the ALN (Attributive Lan-guage with unqualified Number restrictions) Descrip-tion Logics, as it is supported by an embedded match-making and reasoning engine which provides the re-quired inference services [11]. Before applying any in-ference service, the loaded knowledge base is prepro-cessed performing unfolding and Conjunctive NormalForm (CNF) normalization, as detailed in [10]. Un-folding expands terminological axioms in concept ex-pressions, allowing the reasoner to disregard the on-tology in subsequent inference procedures. Normal-ization enables structural algorithms for both stan-dard and non-standard reasoning tasks, with poly-nomial complexity for acyclic Terminological Boxes(TBoxes) under practical assumptions [11].
Standard reasoning tasks for matchmaking includeSubsumption and Satisfiability. Given a request R and aresource S , Subsumption verifies whether all featuresin R are included in S : its outcome is either full matchor not. For example, consider a TBox T includingthese axioms: LargeCapacity v ¬RegularCapacity,WasherDrier v WashingMachine u Drier. IfR1 ≡ WasherDrier u LargeCapacity and S 1 ≡
WashingMachine, then Subsumption returns falsesince R1 /vS 1, so S 1 is not deemed useful, even thoughit provides a washing machine which is a part of therequest. Satisfiability checks whether any constraint inR contradicts some specification in S , hence it dividesresources in compatible (a.k.a. potential matches) andincompatible (a.k.a. partial matches) w.r.t. the re-quest. In the above example, S 2 ≡ WasherDrier uRegularCapacity is incompatible with R1 and shouldbe discarded, even though the requester might accepta smaller capacity if a larger one is unavailable. Thesebinary outcomes are inadequate for advanced scenar-ios, because full matches are rare and incompatibil-ity is frequent when dealing with articulated conceptexpressions from heterogeneous sources.
In order to produce a finer resource ranking and alogic-based explanation of outcomes, the frameworkproposed here extends the basic subsumption/satisfiabilityapproach by exploiting the following non-standard in-ference services [11]:– Concept Abduction: whenever R and S are compat-ible, but S does not imply R, Abduction allows to de-termine what should be hypothesized in S in order tocompletely satisfy R. The solution H (for Hypothesis)to Abduction can be interpreted as what is requestedin R and not specified in S (adopting an Open WorldAssumption). In the above example, Abduce(R1, S 1,T ) returns H ≡ Drier. CNF allows defining a normon concept expressions, so enabling a logic-based rel-evance ranking of a set of resources w.r.t. a given re-quest based on the norm of their Hs.– Concept Contraction: if request R and resource Sare not compatible, Contraction determines which partof R is conflicting with S . If one retracts conflict-ing requirements in R, G (for Give up), a concept K(for Keep) is obtained, representing a contracted ver-sion of the original request, such that K u S is sat-isfiable w.r.t. T . The solution G to Contraction rep-resents “why” R and S are not compatible. In partic-ular, a conflict occurs when concepts in the two de-scriptions clash; in the above example, Contract(R1,S 2, T ) = 〈G,K〉 = 〈RegularCapacity,WasherDrier〉Resource ranking is possible also in this case, basedon the CNF norm measured on G.– Concept Covering: pervasive computing scenariosoften require relatively large numbers of resources tobe aggregated in order to satisfy a complex request. Tothis aim, a further non-standard reasoning task basedon the solution of Concept Covering Problem (CCoP)has been defined. It allows to: (i) satisfy features ex-pressed in a request as much as possible, through the
6 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
N1 N2
requestFriendship()
ACKaccept()
getProfile()
getServiceList()
service listgetList()
getServiceDescription()
service annotationgetDesc()
activateService()
ACKactivate()
N3
requestFollower()
writeInWall()
addFollower()ACK
a)
b)
readDeviceProfile()device profile
wall data
Fig. 1. Sequence diagram for device relationships: a) friend; b) fol-lower
conjunction of one or more small instances of a KB –seen as elementary knowledge blocks– and (ii) provideexplanation of the uncovered part of the request itself.Given a request R and a set of available resources S ={S 1, S 2, ... , S n}, all satisfiable in the reference ontol-ogy T , Concept Covering aims to find a pair 〈S c,H〉where S c ⊆ S contains concepts covering R w.r.t. Tand H is the residual part of R not covered by conceptsin S c. Concept Covering exploits Abduction to findat each step a concept to include in S c, which is theone producing the minimum residual uncovered partH. Also in this case, a CNF-based score is associatedto the result S c as the obtained covering percentage.A Covering example can be found in the case study inSection 4.
The reader is referred to [11] for algorithms and fur-ther considerations on Concept Abduction and Con-traction, as well as to [32] for Concept Covering.
Social entities and relationships. The above infer-ence services are used to regulate the interactions be-tween social objects. Nodes are grouped in two fami-lies:- Smart: devices able to perform reasoning tasks ex-ploiting non-standard deductions;- Basic: low-memory, low- (or no)-computing powerdevices. They can only provide sensing/acting ser-vices, but do not perform autonomous reasoning.A pair of objects can establish a social relationship fol-lowing the basic interaction pictured in Figure 1. Twoschemes are implemented:a) Friend: a bidirectional relationship where nodes Ni
and N j can exchange both information and services.In particular, a device N j sends a friendship request;since the receiver Ni accepts it, they became able to:(i) read and write on each other’s wall; (ii) request the
friend’s service descriptions; (iii) activate or deactivatethe friend’s services. A basic node, when becomingfriend with a smart node, can select it as semantic fa-cilitator i.e., reasoning supporter.b) Follower: a unidirectional relationship where a nodeNk is interested only in receiving the updates publishedby Ni on its wall. In other words, if Nk sends a followerrequest to Ni, Nk becomes an observer of Ni’s behavior.
The decision of N j to become a friend or a followerof Ni is based on information in Ni’s profile. In partic-ular, after retrieving the profile of the nearby object, N j
evaluates the following relationship conditions –firstoutlined in [33]– to decide whether to send a friendshiprequest to Ni: (i) strong co-location, i.e., both devicesare placed in the same room/area; (ii) parental or co-ownership, i.e., they are from the same manufacturer orbelong to the same owner; (iii) co-work, i.e., nodes areable to cooperate closely as they share annotations re-ferred to the same ontology. On the other hand, N j asksto become a follower of Ni if the following conditionsare met: (i) weak or sporadic co-location, such that in-formation produced by Ni can still be useful to N j tocharacterize its own context but at the same time N j
needs/prefers to start a discovery process completelyindependent from Ni; (ii) weak co-work relationship,i.e., there is low utility in a direct interaction, e.g., thetwo devices are deeply different; (iii) no co-ownership.The framework also allows N j to be both a friend anda follower of Ni; this enables a broader variety of in-teraction patterns between the two devices, which isuseful in highly dynamic scenarios. In any case, Ni
can refuse the friendship/follow request if: (a) relation-ship constraints described above are not respected; (b)the maximum number of friends/followers has beenreached. Every device sets limits according to its pro-cessing and memory capabilities. In practice, however,refusing a new friend or follower is rare, as a device in-creases its opportunities for useful cooperation by ex-panding its social network.
Like in SNSs, in the framework proposed here ob-ject’s wall is the main channel for sharing knowledge.Both push and pull models are supported, through theabove relationships. In a nutshell, if a node Ni wants toreceive updates from a node N j automatically, it willask to become a follower. In this case, the follower Ni
can start a semantic matchmaking session when it re-ceives a notification from the followed device N j (asin Figure 1(b)); instead, if Ni wants to be able to ac-cess the wall of N j on demand, it will ask to becomea friend (and in doing so it will also grant access to itsown wall). Then Ni will start a semantic matchmaking
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 7
process only if N j writes a post on Ni’s wall, e.g., dur-ing a distributed covering as reported in Figure 2(b).Every agent will select either model –or even both–depending on its application requirements.
Collaborative adaptivity. When a node detectssome change in internal or contextual conditions re-quiring adaptation i.e., a functional configuration up-date of itself and/or nearby devices, it writes a post onits own wall. A post P is modeled as a pair 〈R, L〉. Ris the request issued by the node; L is the like value.The idea of the like reaction to a post is mutuated fromhuman-oriented SNS, but with two important differ-ences: it is a real value in [0, 1] rather than a binaryvalue; it represents the percentage of coverage andcompletion of the request R, as obtained by the collab-orative service discovery triggered by the post to re-configure the environment. The process is exemplifiedin Figure 2. It consists of the following steps:1) When a node Ni detects a reconfiguration is needed,it writes a post Pi on its own wall. Initially, Li is set to0.2) If Ni is a basic device, go to step 3. Otherwise, Ni
executes the Concept Covering task on the local set ofservice descriptions S (section a) in Figure 2). Uponcompletion, Ni activates the selected services and addsa comment Ci to Pi as a pair 〈Ui,Ti〉, where Ui is theuncovered part of Ri and Ti tags the local selected ser-vices/resources. Moreover, the value of Li is updatedto the obtained covering score, as reported in Figure2(a).3) If Ri is not completely covered, Ni selects a friendN j and writes a post P j=〈R j, L j〉) on its wall. Partic-ularly, if Ni has executed step 2, R j is set to the un-covered part Ui, otherwise R j is equal to Ri and L j isreset. Furthermore, Ni requests to be notified when acomment is added to P j. N j recursively executes thesteps 2) - 3). This is illustrated in section b) of Figure2.4) When Ni receives the notification of P j, it reads thecomment from the friend’s wall, which is appended toPi to update the status of the request. Finally, Ni up-dates the like value according to the overall coveringscore.
A full example is in the case study reported in Sec-tion 4. Some remarks may be useful:– The recursive discovery procedure can be appliedin a depth search with no theoretical bounds. Practi-cally, discovery can be limited by means of the follow-ing threshold values, modeled as device parameters:(i) max_depth, representing the maximum depth of thediscovery w.r.t. the device starting the process, where
N1 N2
writeInWall(P1)
N3
covering(R1)
addComment(P1)
postInWall(P2)
covering(U1) activateServices(T2)
updatePostLike(P2)
updatePostLike(P1)
readComment(P2) comment
updatePostLike(P1) covering(U2)
addComment(P3)
updatePostLike(P3)
readComment(P3) comment
updatePostLike(P2) notify() readComment(P2)
updatePostLike(P1)
ACK
ACK postInWall(P3)
writeInWall(P2)
writeInWall(P3)
comment
addComment(P2)
addComment(P1)
addComment(P2)
activateServices(T3)
activateServices(T1)
a) Local discovery
b) Collaborative discovery
addComment(P1)
notify()
notify()
Fig. 2. Sequence diagram of distributed reconfiguration
a direct friend has depth 1, a friend of a friend hasdepth 2, etc.; (ii) minimum like value, to identify a sat-isfactory coverage from the discovery process: when adevice reaches this like value, the covering procedurecan be halted, also avoiding to forward the (possible)uncovered part of the request to further friends. Eachdevice can use these parameters to prevent nodes overthe network from being flooded with multiple and/oruseless messages. Agents manage heuristics to decidethe values of both parameters.– Message flooding is also managed by exploitinga simple caching mechanism implemented on eachnode. A request is identified by means of a unique keysaved on the device cache when the message is ac-cepted and processed. If the request message was pre-viously received, it is discarded by the device.– The choice of friend(s) to call in the above step 3also depends on heuristic preference criteria, such asthe number and type of services exposed by the friend(known at friendship establishment time), network la-tency or friend’s computational resources.– Main purpose of comments is to keep track of theprogressive fulfillment of an adaptation request, ex-ploiting tagging to avoid duplication of service/resourceselection.
8 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
3.2. Interoperability layer: LDP-CoAP interface
At the application layer, the above reference ar-chitecture is implemented on a LDP-CoAP frame-work [34]. The Linked Data Platform W3C Recom-mendation [8] provides standard rules for accessingand managing Linked Data on the Web. Basically,it defines a set of communication patterns based onHTTP methods and headers for CRUD (Create, Read,Update, Delete) operations as well as different typesof LDP Resources (LDPRs): RDF Source (LDP-RS),whose status corresponds to an RDF graph and can befully represented in an RDF syntax; Non-RDF Source(LDP-NR), not represented in RDF (e.g., a binary ortext document without useful RDF annotation); Basic(LDP-BC), Direct (LDP-DC) and Indirect (LDP-IC)containers, defining collections of LDP resources ac-cording to specific membership patterns.
LDP specification only supports the HTTP proto-col, which requires not negligible bandwidth, pro-cessing and memory resources for most IoT devices.LDP-CoAP variant, on the contrary, aimed to integrateLDP in resource-constrained devices and networks justleveraging CoAP [9], a compact counterpart of HTTPconceived for machine-to-machine (M2M) communi-cation. Some CoAP options are derived from HTTPheader fields (e.g., content type, headers and proxysupport), while some other ones have no analogousin HTTP. In any case, the HTTP-CoAP mapping, in-cluded in the LDP-CoAP framework, can be exploitedto support all LDP features with CoAP.
In the present case, social devices communicateover the network through CoAP messages. Basically,each message is composed of: (i) a 32-bit header,containing the request method code or response sta-tus; (ii) an optional token value, used to associatereplies to requests, (iii) a sequence of option fields(containing information such as resource URI andpayload media type), (iv) the payload data. CoAPadopts the CoRE Link Format specification [35] forresource discovery. A client accesses the reserved/.well-known/core URI on the server via GETto retrieve available resource entry points. FurtherGET requests will include URI-query options to re-trieve only resources with given attributes. Standard-ized query attributes include resource type (rt), inter-face usage (if), content-type (ct), and MIME (Multi-purpose Internet Mail Extension) type for a resource.Further non-reserved attributes can be freely used.CoAP also provides push notifications without polling[36], a useful feature when data have to be monitored
over time (e.g., in case of follower relationship). CoAPalso supports proxies, enabling Web applications (i.e.,HTTP clients) to transparently access the resourceshosted in devices based on CoAP.
The remainder of this subsection, along with figuresfrom 3 to 6 describes the models of core entities inthe social framework: device profiles, service profiles,walls, posts and comments.
Device profiles. Each device in the social networkis modeled as an LDP-CoAP node exposing the re-sources reported in Table 2. The /profile resource ex-poses main device features as an RDF-based annota-tion. An example is reported in Figure 3. In additionto well-known RDF vocabularies, a so-called Seman-tic Web of Social Things (SWST) ontology2 has beendefined to model basic elements of a social device. Inparticular, each profile contains the following proper-ties:– type of device, according to the classification pro-posed by the M3-lite taxonomy [37], a lightweight ver-sion of the Machine-to-Machine Measurement (M3)ontology used to describe sensor measurements andobservations;– device name, using the dcterms:title property of theDCMI Metadata Terms vocabulary [38];– supported ontologies (dcterms:requires) used as ref-erence vocabularies to define the OWL-based annota-tions of the functionalities exposed by the device;– location of the device (e.g., in an area, building, de-partment, apartment), exploiting the dogont:isIn prop-erty of DogOnt [24], a reference ontology proposed tomodel intelligent domotic environments. DogOnt alsocontains several concepts related to indoor and outdoorlocations;– address of the CoAP endpoints, on both the server(swst:serverEndpoint) and client (swst:clientEndpoint)side. Both properties were defined as sub-propertiesof iot-lite:endpoint contained in the IOT-lite ontology[39], a lightweight vocabulary based on SSN-XG [40]proposed to describe IoT concepts and relationships;– (possible) friend and followed devices exploiting theswst:friendOf and swst:followerOf relations, respec-tively.
Friendship is an LDP-BC listing the friend devicesof a social object. Sub-resources are identified by thename of the friend and are connected to the con-tainer through an ldp:contains property, according tothe LDP guidelines [8]. Each of them corresponds to
2Available at http://sisinflab.poliba.it/swottools/onto/swst/
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 9
Table 2LDP-CoAP interface of a social device
Resource URI Resource TypeLDP-CoAP
MethodDescription
/profile LDP-RS GET Returns the device profile
/friendship LDP-BCGET Returns the list of friend devices
POST Receives a friendship request/friendship/<device-name> LDP-RS GET Returns the profile of a specific friend device/services LDP-BC GET Returns the list of the functionalities exposed by the device
/services/<service-name> LDP-RSGET Returns the RDF-based description of a specific functionality
PATCH Updates the status of a functionality according to the received commandHEAD Returns the LDP-CoAP headers (e.g., Etag value) to verify the presence of updates
/services/<service-name>/owl LDP-NR GET Returns the OWL annotation related to a specific functionality
/wall LDP-BCGET Returns the device wall containing the list of published posts
POST Publishes on the wall a post received from a friend device
/wall/<post-id> LDP-BCGET Returns the detailed description of a specific post
POST Publishes on the wall a comment related to a post/wall/<post-id>/owl LDP-NR GET Returns the content of a post as OWL annotation
/wall/<post-id>/<comment-id> LDP-RSGET Returns the description of a comment
PATCH Tag a device functionality on a comment/wall/<post-id>/<comment-id>/owl LDP-NR GET Returns the content of a comment as OWL annotation
an LDP-BC named /services and characterized by aset of RDF properties: dcterms:title specifies the ser-vice name; rdfs:isDefinedBy indicates the IRI of theOWL individual modeling the service within the ref-erence KB; dcterms:modified reports the timestamp of
10 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
the last modification applied to the individual descrip-tion; swst:currentState and swst:activationValue iden-tify the service current state and the specific value tobe used to activate the functionality (set point), respec-tively.
Wall and posts. Figure 5 shows the modeling ofa device /wall. It is an upper LDP-BC containingone or more posts defined as nested containers. Eachpost can include several comments represented asLDP-RS. Post descriptions include: creation date (dc-terms:created); creator device (swst:postedBy); con-tent of the post (sioc:about), defined in the Semantically-Interlinked Online Communities (SIOC) Core Ontol-ogy [41], as IRI of the individual representing the re-ceived OWL annotation; like value (swst:likeValue).
Comments. Finally, a comment annotation (Figure6) consists of: creation date; creator device; content ofthe comment, corresponding to the part of the post thefriend device is not able to cover; tagged (i.e., acti-vated) services (sioc:topic), selected through the cov-ering process.
4. Case study: semantic web of (social) things forbuilding automation
This section presents a case study, devoted to clarifythe social and collaborative features of the proposedframework in terms of orchestration of smart devicesin a complex HBA context. Let us consider the ex-ample scenario depicted in Figure 8. Two apartmentson the same floor of a building, H1 and H2, include aset of semantic-enabled devices forming a home socialnetwork. In particular, H1 is configured with an alarmsystem (AS), a rolling shutter controller (SC1), an airconditioner (AC1) and a dimmer lamp (L1). A weatherstation (WS), a rolling shutter controller (SC2), an airconditioner (AC2) and a dimmer lamp (L2) are in-stalled in H2 instead. The blue arrows in Figure 8 spec-ify the existing friendship relations between the differ-ent devices. As said, when a friendship relation is es-tablished, each friend is able to directly read the wall ofan object, write a post on its wall and use the servicesof the device. Within the two apartments, each objecthas sensing and/or actuating capabilities and exposes aset of features to its friends. According to the resourcemodeling described in Section 3.2, all social networkinteractions can be implemented as request/responsemessages over LDP-CoAP. In order to clarify the pro-posed approach, some reference examples are shownin Figure 7, reporting RDF annotations in Turtle syn-
tax [42]. Alternately, they can be retrieved in JSON-LD [43], by setting the Accept header appropriately. Asshown in Example 8 and in Table 2, OWL annotationsare treated as LDP-NR resources, in order to supportany OWL concrete syntax, not only RDF-based ones.
It is evening, there is no one in the apartment H1
and the AS detects an intrusion in the house. Immedi-ately the AS writes a new post on its wall represent-ing what it has sensed as an OWL annotation. Figure9 shows a possible formalization of the post (reportedin OWL2 Manchester syntax [44] for the sake of read-ability) w.r.t. the reference ontology. Service requestsand descriptions are modeled in a general way, by ex-pressing the context conditions suitable for the activa-tion of a given service.
The AS starts a Concept Covering process using thepost content as request, whereas available resourcesare represented by the functionalities exposed by allthe devices directly involved into a friendship relation.The AS verifies if the services of the connected ob-jects, SC1 and L1 in our example, were modified byperforming a simple check: (i) AS sends a lightweightLDP-CoAP HEAD request (as shown in Example 9of Figure 7) to the service resources exposed by eachfriend and verifies if the retrieved ETag is differentfrom the value stored in its cache. As defined in [45],an ETag is a resource identifier used for differentiat-ing between representations of the same resource thatvary over time. In the proposed framework, it is basedon the specific OWL annotation and changes everytime the description is modified; (ii) only if the ETaghas changed (i.e., the OWL annotation was updated),the new service description will be retrieved through aGET request (Example 8 of Figure 7). Otherwise, theAS can directly use the cached service annotation. Thisprocedure ensures that the covering task is performedusing the latest descriptions of all available services.
According to the semantic service descriptions,listed in Figure 10 and 11 respectively, the match-making procedure highlights the shutter should befully closed and the dimmer lamp turned on to com-pletely satisfy the request. This is due to the factthe AS detects a low luminosity, no presence ofhumans and an intrusion event. All device percep-tions were modeled with the related concepts de-scribed within the reference ontology. In particular, theIntrusion class was defined as more specific thanIntrusionForLamp and IntrusionForShutter(i.e., it should require services both from a lamp and ashutter controller), as shown in Figure 12. These twoconcepts belong to the annotation of the Lamp_On and
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 11
Example 1. Read the profile of a social device
[REQ] GET coap://192.168.2.16:5683/profile Accept: text/turtle
Fig. 7. Examples of basic device interactions over LDP-CoAP
12 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
AS
AC1
SC1
WS
H1
SC2
L1
L2 AC2
Friend Follower
H2
Fig. 8. Case study scenario
AS_Request ≡ (detectsOutdoorLuminosity some)and (detectsOutdoorLuminosity onlyLowLuminosity) and (detectsIntrusion some)and (detectsIntrusion only Intrusion)and (detectsOccupancy some) and(detectsOccupancy only (not Presence))
Fig. 9. Post content (i.e., request) written by the alarm system
Full_Close ≡ (detectsPrecipitation some) and(detectsPrecipitation only Rain) and(detectsWindSpeed some) and (detectsWindSpeedonly StrongWind) and (detectsIntrusion some)and (detectsIntrusion onlyIntrusionForShutter) and (detectsOccupancysome) and (detectsOccupancy (not Presence))
Hal f_Close ≡ (detectsPrecipitation some) and(detectsPrecipitation only (not Rain)) and(detectsWindSpeed some) and (detectsWindSpeedonly ModerateWind)
Open ≡ (detectsPrecipitation some) and(detectsPrecipitation only (not Rain)) and(detectsWindSpeed some) and (detectsWindSpeedonly LightBreeze) and(detectsOutdoorLuminosity some) and(detectsOutdoorLuminosity onlyHighLuminosity)
Fig. 10. Shutter controllers SC1 and SC2 service annotations
Full_Close service annotations, respectively; more-over, Lamp_On is also useful in case of low luminos-ity. Due to this reason, they are selected during thecovering process as suitable functionalities to be acti-vated. With a modestly expressive DL likeALN , sucha modeling pattern allows activating functionalities ofdifferent devices that are fired when the same eventis detected. In the first step of Concept Covering, all
Lamp_On ≡ (detectsOutdoorLuminosity some)and (detectsOutdoorLuminosity onlyLowLuminosity) and (detectsIntrusion some)and (detectsIntrusion only IntrusionForLamp)
Lamp_Medium ≡ (detectsOutdoorLuminosity some)and (detectsOutdoorLuminosity onlyMediumLuminosity) and (detectsOccupancy some)and (detectsOccupancy only Presence)
Lamp_O f f ≡ (detectsOutdoorLuminosity some)and (detectsOutdoorLuminosity onlyHighLuminosity) and (detectsOccupancy some)and (detectsOccupancy only (not Presence))
Fig. 11. Dimmer lamps L1 and L2 service annotations
Fig. 12. Intrusion ontology class modeling
services in Figure 10 and Figure 11 undergo ConceptAbduction with the request: Full_Close is selected be-cause it yields the smallest uncovered part, reported inFigure 13. This becomes the new request for the sub-sequent Abduction round, when Lamp_On is selectedand AS_Request is fully covered. Therefore, the AS
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 13
writes on its wall a comment to the post, containingonly a tag for each service to activate, i.e., Full_Close(SC1) and Lamp_On (L1). The uncovered part of therequest is empty because the request was completelysatisfied. Finally, according to the covering results, thelike value of the post is automatically updated to 1 andno further operations are required.
Simultaneously, devices within the apartment H2
could exploit the knowledge shared by the home so-cial network in H1 to adapt their configuration accord-ing to the detected conditions. As shown in Figure 8,a follower relation exists between the weather stationand the alarm system. As explained in Section 3.1, theWS follows (i.e., continuously observes) the wall ofthe AS, so when the alarm system posts the intrusionmessage, it is immediately notified. The WS reads theannotation and shares it on its wall as a new post. Thisevent triggers also in H2 a Concept Covering processinvolving the services exposed by the friends of WS(SC2 and AC2), which are listed respectively in Figure10 and Figure 14.
AS_Req_Uncovered ≡ (detectsOutdoorLuminositysome) and (detectsOutdoorLuminosity onlyLowLuminosity) and (detectsIntrusion some)and (detectsIntrusion only IntrusionForLamp)
Fig. 13. OWL annotation of the uncovered part of AS_Request
AC_Cooling ≡ (detectsTemperature some) and(detectsTemperature only HighTemperature) and(detectsHumidity some) and (detectsHumidityonly MediumHumidity)
AC_Heating ≡ (detectsTemperature some) and(detectsTemperature only LowTemperature) and(detectsHumidity some) and (detectsHumidityonly LowHumidity)
AC_Dehumidi f ication ≡ (detectsTemperature some)and (detectsTemperature onlyMediumTemperature) and (detectsHumidity some)and (detectsHumidity only HighHumidity)
Fig. 14. Air conditioners AC1 and AC2 service annotations
WS_Req_Uncovered ≡ (detectsOutdoorLuminosityonly LowLuminosity) and (detectsIntrusiononly IntrusionForLamp)
Fig. 15. OWL annotation of the uncovered part of WS_Request
Only the Full_Close service, provided by SC2, is se-lected to partially satisfy the request. WS comments
its post including a tag to the shutter service and theuncovered part of the request as content. In this case,to further satisfy the post, the WS can forward the un-covered part to one of its friends. The WS selects theSC2, since it provided the highest contribution to cov-ering in the initial step, and posts on the wall of SC2the OWL annotation of the uncovered part reportedin Figure 15. Moreover, the WS starts observing thepost it just sent to the friend’s wall. SC2 in turn re-ceives the message, starts a covering process involvingthe services exposed by L2 (Figure 11) and selects theLamp_On functionality, which completely covers theremaining part of the initial request. SC2 comments itspost tagging the activated services and updates the likevalue with the percentage of covered features. The re-quest is fully satisfied so the uncovered part is emptyand no other posts are needed. Thanks to the observerpattern, the WS receives a notification about the post,reads the comment and understands the initial requesthas been completely served. As a consequence, it up-dates the like value of the post on its wall, not forward-ing further requests.
It is useful to point out how social capabilities al-lowed apartment H2 to compensate for the lack ofan alarm system, taking advantage of the sensing ca-pabilities of the one in H1 to appropriately config-ure and modify the status of its devices. This is justan obvious example of the benefits of the proposedsemantic-based social framework in information andservice/resource sharing in complex settings and het-erogeneous networks. Furthermore, request and ser-vice descriptions in the case study were kept short foreasier understanding of the proposed framework, butthe adopted inferences allow managing more detailedspecifications with articulated constraints.
5. Evaluation
A prototypical testbed was developed following theproposed social framework described in Section 3.The core goal of experimental evaluations was to ad-dress the interoperability problem among multiple IoTplatforms and standards. Therefore, the testbed im-plements a basic environment (similar to the one de-scribed in the above case study) consisting of a sub-set of home areas, i.e., a hall door, a living room, akitchen, and a small outdoor space. An IEEE 802.11network was exploited as a fast backbone including3 smart nodes, each implementing a single social de-vice. Performance evaluation of the proposed approach
14 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
was carried out developing the smart nodes on threereference platforms with different processing capabili-ties. Moreover, a KNX sub-network was connected tothe main area by means of an additional smart node,acting as gateway toward the social network, allow-ing KNX-based devices to interact with the other so-cial objects in a transparent way. As detailed in Ta-ble 3, KNX installation consisted of 8 off-the-shelf de-vices, produced by Gewiss Inc.3, connected through atwisted pair bus in a hierarchical network. Each device(except the KNX router, used only for the communica-tion over IP) corresponds to one or more LDP-CoAPendpoints, exposed by the gateway node, representingthe social objects in Table 3. In this way, all devicesin the home can interact through the proposed LDP-CoAP interface independently from the specific HBAprotocol. Particularly, multi-channel devices can man-age several functionalities, e.g., switch actuators canhandle up to 4 push buttons whereas the dimmer actua-tor can provide several functionalities according to thedifferent light level. Therefore, more than 30 serviceswere exposed overall by the KNX sub-network towardthe social framework.
Table 3KNX devices in the testbed
Product ID Description Social DeviceGW90707 KNP/IP router —
GW90740Switch actuator4 channels
Air conditioner (2 ch.) +Garden watering system (2 ch.)
GW90740Switch actuator4 channels
n.4 Simple on/off lamp
GW12782Push button4 channels
n.4 Basic on/off button
GW90800Weather Stationwith GPS
Weather Station
GW90746 Dimmer actuator Dimming lamp
GW10948Burglar alarmsystem interface
Alarm system
GW90754Roller shutteractuator
Shutter controller
According to Figure 16, a Java-based managementsoftware was implemented to run on each home de-vice. The main Java package it.poliba.sisinflab.swstwas partitioned in the following sub-packages to sep-arate developed classes in well-defined sections eachproviding the following specific functionality:- core: contains the HomeDevice reference imple-mentation. It extends the CoAPLDPServer providedby the LDP-CoAP library4 and exposes one or more
DeviceEndpoint managing the resources described inTable 2. At network level, LDP-CoAP provides also amodified version of the Californium CoAP framework[46] supporting LDP features over CoAP;- resources: several Java classes model the differ-ent device resources. LDP-CoAP RDFSource, Non-RDFSource and BasicContainer base classes were ex-tended, providing common attributes and methods tosave, retrieve and update the home data. All informa-tion is stored within an RDF repository based on theRDF4J 2.1.3 library5;- rdf.vocabulary: contains RDF ontology filesmapped as Java classes to simplify creation and query-ing of RDF triples. Ontologies cited in Section 3.2(e.g., SIOC, IoT-lite, M3-lite) were mapped throughthe Sesame Vocabulary Builder6 tool and included inthe package;- owl: provides basic functionalities to load the ref-erence KB, manage all generated OWL annotationsthrough the OWL-API 3.4.10 library [47] and invokethe Mini-ME reasoner [11] implementing inferenceservices;- knx: an additional package implemented to sup-port the communication over the ISO/IEC 14543-3EIB/KNX protocol stack [48]. Calimero-core library7
was exploited for network management and to ex-change data with KNX devices (e.g., read state valuesor send commands). An import utility was also imple-mented to parse data from an XML-based project fileexported from ETS48, the official software tool used todesign and configure home installations based on KNXsystems, and to model the same device features withinthe home social network.
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 15
24
287
29
14 20
28
337
26 14
162
5
48
8
1
6
13
92
10
5
38
7 11
7 7 5 7 6
9 5
7 8
84
6
2 5
7
102
7
3
71 39 35
15 8
48
20
107
12
82
24
1
10
100
1000
Read Profile Send Friendship Read Service Description
Read Service Annotation
Read Wall Read Post Write Post Tag Device Read Headers Activate Service
Tim
e (
ms)
Processing (RaspberryPi) Processing (Intel Edison) Processing (UDOO) Communication (Wi-Pi) Communication (Intel)
Fig. 17. Processing and communication time for the social tasks
The following embedded boards were used to im-plement the social devices:(a) Raspberry Pi Model B9, equipped with a single-core ARM11 CPU at 700 MHz, 512 MB RAM (sharedwith GPU), 8 GB storage memory on SD card, Rasp-bian Wheezy OS;(b) Intel Edison Kit10 equipped with an Intel Quark x86CPU at 400 MHz, 1 GB RAM, 4 GB eMMC flash stor-age and Yocto Poky Linux OS (32-bit kernel 3.10.98);(c) UDOO Quad11 equipped with quad-core ARMCortex A9 at 1 GHz clock frequency, ARM Cortex M3coprocessor, 1 GB DDR3 RAM, 32 GB storage mem-ory on SD card, UDOObuntu 2.0 Minimal Edition OS.All platforms included a 32-bit Java 8 SE Runtime En-vironment (JRE, build 1.8.0-b121).
Experiments have been carried out performing the10 reference tasks described in Figure 7, to identifyand evaluate specific features characterizing their per-formance. Each test was repeated five times and av-erage values were taken and reported in Figure 17. Inparticular, the processing time is defined as the timeelapsed on the device receiving a request to processthe message and send the related response, whereasthe communication time represents the time needed toexchange request/response data (i.e., CoAP packets)over the home network between the sender and thereceiver device. As expected, RaspberryPi required alonger time to process the requests due to the reducedcomputational capabilities. On the contrary, Intel Edi-son was the fastest platform in case of tasks only re-quiring simple I/O operations, thanks to the internalflash memory. Concerning communication time, a sig-nificant variation can be noticed, due to the differenthardware adopted for connecting to the home network.
In particular, RaspberryPi and UDOO were equippedwith a Wi-Pi IEEE 802.11 USB dongle, whereas IntelEdison exploited the on-board transceiver.
Test results about the Concept Covering task per-formed on a single node are reported in Figure 18. Ex-periments were conducted exploiting a shared datasetof 7 requests (see Table 4) with growing size and
0
30
60
90
120
150
180
R1 R2 R3 R4 R5 R6 R7
Tim
e (
ms)
RaspberryPi Intel Edison UDOO
Fig. 18. Processing time for the Concept Covering task
Fig. 19. Memory usage
16 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
restriction complexity. As a consequence, a differentnumber of services was selected (from a set of 50 in-stances) and tagged after the reasoning step. It canbe pointed out that like value was lower for simplerrequests and increased for more complex ones. Thisis due to the fact that ontology and service annota-tions are modeled to fit articulate and specific descrip-tions, such as device operating requirements; genericrequests result less significant, leading to a relativeloss of the semantic-based score. For all platforms, thecomplexity of the request affected time only slightly,showing a similar trend. As expected, the processingtime was longer for complex annotations, because ahigher number of services was retrieved to satisfy therequest. Moreover, memory usage values are shown inFigure 19. Framework requirements were low on allplatforms, with a memory peak always under 18.5 MBfor stack memory and 16.5 MB for heap memory, rep-resenting reasonable values for embedded systems.
Another relevant parameter of the social frameworkperformance is the amount of data exchanged overthe home network. In order to reduce the number ofpackets used to transmit each message over CoAP, theLDP-CoAP implementation described in [34] was ex-tended to support the following encoding algorithms,aiming to reduce the size of resource descriptions: (i)GZIP and BZIP2 (both included within the ApacheCommons Compress library12), general-purpose andsuitable for annotations described with RDF Turtle[42], JSON-LD [43] and all OWL syntaxes; (ii) Bi-nary JSON (BSON)13, Universal Binary JSON (UB-JSON)14 and Message Pack (MsgPack)15, specific forJSON-based annotations.
Selected algorithms were tested on three basic re-sources corresponding to the LDP-CoAP resourcetypes available in the proposed framework: RDFSource (LDP-RS, e.g., device profiles and comments):Basic Container (LDP-BC, e.g., walls and posts); Non-RDF Source (LDP-NR, e.g., OWL annotations ofposts, comments and services). LDP-RS and LDP-BCwere described with RDF Turtle and JSON-LD to testboth syntaxes supported by LDP-CoAP, whereas LDP-NR was described through the OWL 2 Manchestersyntax. Figure 20 reports on the size of the referenceannotations with and without compression. GZIP pro-vided better results, achieving a compression ratio of
about 48%. In this way, each device sends on averagethe half of CoAP packets (which must contain a maxi-mum of 64B as payload), so reducing the overall com-munication latency. On the contrary, JSON-specific al-gorithms were not particularly useful for short mes-sages, being designed to encode large documents.
0 150 300 450 600 750
LDP-RS (Turtle)
LDP-BC (Turtle)
LDP-RS (JSON-LD)
LDP-BC (JSON-LD)
LDP-NR (OWL-MS)
Size (Byte)
Plain GZIP BZIP2 BSON UBJSON MsgPack
Fig. 20. Size of encoded payload messages
Finally, benefits of the devised semantic social plat-form were assessed in a comparison w.r.t. the follow-ing IoT-oriented frameworks in the HBA market: KNXIoT16; IzoT Platform17, originally developed by Ech-elon Corporation for the Industrial IoT but also ex-ploited for building applications; Dog Gateway18 [24];Eclipse SmartHome19. Table 5 highlights that onlythe proposed approach combines fitness for resource-constrained environments (by using CoAP and a P2Parchitecture), expressiveness of device modeling (byexploiting RDF and OWL 2) and support for both exactand approximated matches, with formally groundedservice composition.
6. Conclusion and Future Work
This paper introduced a novel semantic-based frame-work for Social Internet of Things, particularly use-ful for home and building automation but inherentlygeneral-purpose. The proposal adopted a decentral-ized service-oriented architecture to manage, pub-lish, discover and compose semantically annotatedservice/resource descriptions. It adopted LDP-CoAPto join the benefits of efficient RESTful machine-to-machine communication and structured LinkedData organization. Non-standard, non-monotonic in-
Service compositionyes, through distributedcovering
no no no no
Message data formatRDF Turtle, JSON-LD,OWL 2
proprietary, accordingto KNX spec.
proprietary, XML-basedaccording to LonTalk spec.
OWL 2 XML
Standardised frameworkinterface
LDP-CoAP RESTfulinterface
KNX IoT Web Services HTTP RESTful APIWebSocket and HTTPRESTful API
HTTP RESTful API
ferences enabled semantic matchmaking for service/resourcediscovery with support for approximate matches, logic-based ranking and composition via request covering.The framework was developed on a multi-protocolHBA testbed with single-board computers and embed-ded home devices, exhibiting effectiveness in AmI sce-narios.
Future work includes a wider testbed implemen-tation and experimentation, to validate scalability ofthe proposal in very large object networks. Moreover,heuristics governing decisions about the creation andremoval of friend/follower relationships will be ex-plored, including behaviors based on agents’ past ex-perience, possibly by means of machine learning tech-niques. A similar approach can be adopted to endowsocial objects with proactive adaptivity to environmen-tal modifications.
A not negligible aspect to be further investigatedis related to cybersecurity risks of the proposed ap-proach: trust elements are strongly coupled to the needfor a device to prove its own identity to their poten-tial friends. This becomes even more relevant when de-vices networks increase their dimension, functions andpopulation.
Finally, additional message propagation modelsbased on different event priorities will be investigatedalong with further object interaction schemes accord-ing to the Linked Data Notifications protocol [49].
References
[1] G. Bizios, Architecture Reading Lists and Course Outlines,Eno River Press, 1998.
[2] F. Sadri, Ambient intelligence: A survey, ACM Computing Sur-veys (CSUR) 43(4) (2011), 36.
[3] W. Kastner, M. Jung and L. Krammer, Future Trends in SmartHomes and Buildings, in: Industrial Communication Technol-ogy Handbook, 2nd edn, R. Zurawski, ed., CRC Press/Taylor& Francis, 2014, pp. 1483–1502, Chap. 59.
[4] W. Kastner, L. Krammer and A. Fernbach, State of the Artin Smart Homes and Buildings, in: Industrial Communica-tion Technology Handbook, 2nd edn, R. Zurawski, ed., CRCPress/Taylor & Francis, 2014, pp. 1415–1434, Chap. 55.
[5] L. Atzori, A. Iera and G. Morabito, From "Smart Objects" to"Social Objects": The next evolutionary step of the Internet ofThings, Communications Magazine, IEEE 52(1) (2014), 97–105.
[6] N. Shadbolt, T. Berners-Lee and W. Hall, The semantic webrevisited, IEEE intelligent systems 21(3) (2006), 96–101.
[7] M. Ruta, F. Scioscia and E. Di Sciascio, Enabling the Seman-tic Web of Things: Framework and Architecture, in: SemanticComputing (ICSC), 2012 IEEE Sixth International Conferenceon, IEEE, 2012, pp. 345–347.
[8] S. Speicher, J. Arwe and A. Malhotra, Linked DataPlatform 1.0, W3C Recommendation, W3C, 2015,https://www.w3.org/TR/ldp/.
[9] C. Bormann, A. Castellani and Z. Shelby, CoAP: An Applica-tion Protocol for Billions of Tiny Internet Nodes, IEEE InternetComputing 16(2) (2012), 62–67.
[10] M. Ruta, E. Di Sciascio and F. Scioscia, Concept abduction andcontraction in semantic-based P2P environments, Web Intelli-gence and Agent Systems 9(3) (2011), 179–207.
[11] F. Scioscia, M. Ruta, G. Loseto, F. Gramegna, S. Ieva, A. Pintoand E. Di Sciascio, A mobile matchmaker for the UbiquitousSemantic Web, International Journal on Semantic Web and In-formation Systems 10(4) (2014), 77–100.
[12] K.-Y. Lin and H.-P. Lu, Why people use social network-ing sites: An empirical study integrating network externalitiesand motivation theory, Computers in Human Behavior 27(3)(2011), 1152–1161.
[13] O. Voutyras, P. Bourelos, S. Gogouvitis, D. Kyriazis andT. Varvarigou, Social Monitoring and Social Analysis in Inter-net of Things Virtual Networks, in: Intelligence in Next Gen-
18 M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP
eration Networks (ICIN), 2015 18th International Conferenceon, IEEE, 2015, pp. 244–251.
[14] G. Biamino, A semantic model for socially aware objects, Ad-vances in Internet of Things 2(3) (2012), 47–55.
[15] B. Ramis Ferrer, S. Iarovyi, L. Gonzalez, A. Lobov andJ.L. Martinez Lastra, Management of distributed knowledgeencapsulated in embedded devices, International Journal ofProduction Research (2015), 1–18.
[16] B. Jadhav and S. Patil, Wireless Home Monitoring using SocialInternet of Things (SIoT), in: Automatic Control and DynamicOptimization Techniques (ICACDOT), International Confer-ence on, IEEE, 2016, pp. 925–929.
[17] E. Papadopoulou, S. Gallacher, N.K. Taylor, M.H. Williams,F.R. Blackmun, I.S. Ibrahim, M.Y. Lim, I. Mimtsoudis,P. Skillen and S. Whyte, Combining pervasive computing withsocial networking for a student environment, in: Proceedingsof the Twelfth Australasian Symposium on Parallel and Dis-tributed Computing-Volume 152, Australian Computer Society,Inc., 2014, pp. 11–19.
[18] D. Hussein, S.N. Han, G.M. Lee, N. Crespi and E. Bertin, To-wards a dynamic discovery of smart services in the social in-ternet of things, Computers & Electrical Engineering (2016).
[19] D.N. Crowley, E. Curry and J.G. Breslin, Leveraging SocialMedia and IoT to Bootstrap Smart Environments, in: Big Dataand Internet of Things: A Roadmap for Smart Environments,Springer, 2014, pp. 379–399.
[20] E. Bove, Object (b)logging: semantically rich context min-ing and annotation in pervasive environments, in: Advances inSensors and Interfaces (IWASI), 2015 6th IEEE InternationalWorkshop on, IEEE, 2015, pp. 210–215.
[21] S.N. Han, G.M. Lee and N. Crespi, Semantic context-awareservice composition for building automation system, IEEETransactions on Industrial Informatics 10(1) (2014), 752–761.
[22] M. Ruta, F. Scioscia, G. Loseto and E. Di Sciascio, Semantic-based resource discovery and orchestration in Home and Build-ing Automation: a multi-agent approach, IEEE Transactionson Industrial Informatics 10(1) (2014), 730–741.
[23] H. Dibowski and K. Kabitzsch, Ontology-based device de-scriptions and device repository for building automation de-vices, EURASIP Journal on Embedded Systems 2011(1)(2011), 623461.
[24] D. Bonino, E. Castellina and F. Corno, The DOG gateway: en-abling ontology-based intelligent domotic environments, IEEETransactions on Consumer Electronics 54(4) (2008), 1656–1664.
[25] Y. Evchina, J. Puttonen, A. Dvoryanchikova and J.L.M. Lastra,Context-aware knowledge-based middleware for selective in-formation delivery in data-intensive monitoring systems, Engi-neering Applications of Artificial Intelligence 43 (2015), 111–126.
[26] K.P. Joshi, Y. Yesha and T. Finin, Automating cloud serviceslife cycle through semantic technologies, Services Computing,IEEE Transactions on 7(1) (2014), 109–122.
[27] B.T. Kumara, I. Paik and W. Chen, Web-service clustering witha hybrid of ontology learning and information-retrieval-basedterm similarity, in: Web Services (ICWS), 2013 IEEE 20th In-ternational Conference on, IEEE, 2013, pp. 340–347.
[28] C. Chang, S.N. Srirama and J. Mass, A Middleware for Dis-covering Proximity-based Service-Oriented Industrial Internetof Things, in: Services Computing (SCC), 2015 IEEE Interna-tional Conference on, IEEE, 2015, pp. 130–137.
[29] M. Ruta, G. Zacheo, L.A. Grieco, T. Di Noia, G. Boggia,E. Tinelli, P. Camarda and E. Di Sciascio, Semantic-based re-source discovery, composition and substitution in IEEE 802.11mobile ad hoc networks, Wireless Networks 16(5) (2010),1223–1251.
[30] Z. Cong and A.F. Gil, Enabling web service discovery in het-erogeneous environments, International Journal of Metadata,Semantics and Ontologies 4 8(2) (2013), 106–118.
[31] B. Parsia, S. Rudolph, M. Krötzsch, P. Patel-Schneiderand P. Hitzler, OWL 2 Web Ontology Language Primer(Second Edition), W3C Recommendation, W3C, 2012,http://www.w3.org/TR/owl2-primer.
[32] M. Ruta, F. Scioscia, G. Loseto, F. Gramegna, S. Ieva andE. Di Sciascio, Mini-ME 2.0: Powering the Semantic Web ofThings, in: OWL Reasoner Evaluation Workshop (ORE 2014),S. Bail, B. Glimm, E. JimÃl’nez-Ruiz, N. Matentzoglu, B. Par-sia and A. Steigmiller, eds, CEUR Workshop Proceedings,Vol. 1207, CEUR-WS, 2014, pp. 8–15.
[33] L. Atzori, A. Iera, G. Morabito and M. Nitti, The Social Inter-net of Things (SIoT) – When Social Networks Meet the Inter-net of Things: Concept, Architecture and Network Characteri-zation, Computer networks 56(16) (2012), 3594–3608.
[34] G. Loseto, S. Ieva, F. Gramegna, M. Ruta, F. Scioscia and E. DiSciascio, Linked Data (in low-resource) Platforms: a mappingfor Constrained Application Protocol, in: The Semantic Web- ISWC 2016: 15th International Semantic Web Conference,Proceedings, Part II, P. Groth and et al., ed., Lecture Notes inComputer Science, Vol. 9982, Springer International Publish-ing, Cham, 2016, pp. 131–139.
[35] Z. Shelby, Constrained RESTful Environments (CoRE) LinkFormat, Request for Comments, IETF, 2012, Internet Engineer-ing Task Force. http://www.ietf.org/rfc/rfc6690.txt.
[36] K. Hartke, Observing Resources in the Constrained Ap-plication Protocol (CoAP), Request for Comments, IETF,2015, Internet Engineering Task Force. http://www.ietf.org/rfc/rfc7641.txt.
[37] R. Agarwal, D.G. Fernandez, T. Elsaleh, A. Gyrard, J. Lanza,L. Sanchez, N. Georgantas and V. Issarny, Unified IoT Ontol-ogy to Enable Interoperability and Federation of Testbeds, in:3rd IEEE World Forum on Internet of Things, 2016.
[38] Dublin Core Metadata Initiative and others, Dublin core meta-data element set, version 1.1, Dublin Core Metadata Initiative,2012.
[39] M. Bermudez-Edo, T. Elsaleh, P. Barnaghi and K. Taylor, IoT-Lite: A Lightweight Semantic Model for the Internet of Things,in: 2016 Intl IEEE Conferences on Ubiquitous Intelligence &Computing, Advanced and Trusted Computing, Scalable Com-puting and Communications, Cloud and Big Data Computing,Internet of People, and Smart World Congress, IEEE, 2016,pp. 90–97.
[40] M. Compton, P. Barnaghi, L. Bermudez, R. Garcia-Castro,O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson,A. Herzog et al., The SSN Ontology of the W3C Semantic Sen-sor Network Incubator Group, Web Semantics: Science, Ser-vices and Agents on the World Wide Web 17 (2012).
[41] U. Bojars, J.G. Breslin and S. Decker, Porting social mediacontributions with SIOC, in: Recent Trends and Developmentsin Social Software, Springer, 2010, pp. 116–122.
[42] G. Carothers and E. Prud’hommeaux, RDF 1.1 Turtle (TerseRDF Triple Language), W3C Recommendation, W3C, 2014,http://www.w3.org/TR/turtle/.
M. Ruta et al. / Social IoT for Domotics: a Knowledge-based Approach over LDP-CoAP 19
[43] M. Lanthaler, M. Sporny and G. Kellogg, JSON-LD 1.0, W3CRecommendation, W3C, 2014, http://www.w3.org/TR/json-ld/.
[44] M. Horridge and P.F. Patel-Schneider, OWL 2 Web OntologyLanguage Manchester Syntax (Second Edition), W3C Work-ing Group Note, W3C, 2012, https://www.w3.org/TR/owl2-manchester-syntax/.
[45] C. Bormann and Z. Shelby, The Constrained Application Pro-tocol (CoAP), Request for Comments, IETF, 2016, Internet En-gineering Task Force. http://www.ietf.org/rfc/rfc7959.txt.
[46] M. Kovatsch, M. Lanter and Z. Shelby, Californium: Scalablecloud services for the Internet of Things with CoAP, in: Inter-net of Things, 2014 Int. Conf. on the, IEEE, 2014, pp. 1–6.
[47] M. Horridge and S. Bechhofer, The OWL API: A Java API forOWL Ontologies, Semantic Web 2(1) (2011), 11–21.
[48] M. Ruta, F. Scioscia, G. Loseto and E. Di Sciascio, KNX, aworldwide standard protocol for home and building automa-tion: state of the art and perspectives, in: Industrial Communi-cation Technology Handbook, 2nd edn, R. Zurawski, ed., CRCPress/Taylor & Francis, 2014, pp. 1463–1481, Chap. 58.
[49] S. Capadisli, A. Guy, C. Lange, S. Auer, A. Sambra andT. Berners-Lee, Linked Data Notifications: A Resource-Centric Communication Protocol, in: The Semantic Web: 14thInternational Conference, ESWC 2017, Portorož, Slovenia,May 28 – June 1, 2017, Proceedings, Part I, E. Blomqvist,D. Maynard, A. Gangemi, R. Hoekstra, P. Hitzler and O. Har-tig, eds, Springer International Publishing, Cham, 2017,pp. 537–553.
