Social Internet of Things for domotics: A knowledge-based approach over LDP-CoAP

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. 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 [ 7 ]

1. Introduction

In the Ambient Intelligence (AmI) vision, built environments interact with their inhabitants in an “unobtrusive, interconnected, adaptable, dynamic, embedded and intelligent” way [44]. Personal requirements and preferences are grasped, deciphered and formalized 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 Things (IoT), where large numbers of everyday objects are augmented with communication and computation capabilities. People in their usual environments are increasingly surrounded by networks of micro-devices, endowed with embedded sensors for data capture as well as processing units for deriving context information. To create real cohesive AmI, such devices should communicate and coordinate autonomously, making decisions dynamically based on manifold factors, including the state of surrounding objects and places as well as user activities and profiles. While traditional human-computer interaction has been explicit and mediated by input peripherals, in AmI implicit, effortless interaction paradigms predominate, where relevant information about users’ goals and intentions is inferred automatically by analyzing their actions and context, through sensors integrated in the environment or in wearable things.

Current solutions for Home and Building Automation (HBA) are still far from the above levels of intelligence, automation and adaptivity. They grant limited flexibility, as devices are logically associated at the application level by means of static profiles, defined at system deployment stage. With most established HBA standards, changing the set of possible configurations or introducing new devices require the intervention of qualified practitioners. Recently, product manufacturers and system integrators have proposed more user-friendly “smart home” devices and platforms, leveraging the IoT [31]. Unfortunately, solutions are proprietary and centralized, and they still require manual configuration. This seemingly improved usability comes at the price of providing only very basic automation [32], typically using Event-Condition-Action (ECA) rules on simplistic threshold or on/off conditions.

Hence, significant technological advances are needed to fully accomplish the AmI vision. Flexible and meaningful relationships among devices in a given environment should be possible, established automatically to support articulate orchestration and coreography patterns. Recent research in the so-called Social Internet of Things (SIoT) [2] is starting to define models and architectures to reach this goal. Paradigms are often borrowed from Social Networking Services (SNS) for human users. If properly adapted to the peculiarities and requirements of Multi-Agent Systems (MAS), they can support powerful approaches. SIoT offers several benefits and interesting perspectives for the IoT. The adoption of a social model for object interchange makes structured (to some extent) the intrinsically unpredictable interaction in the IoT and therefore it gives an unquestionable added value in terms of interoperability, autonomicity, versatility and coordination. This is done in such a way not imposing intolerable constraints to the fundamental flexibility and variability of Internet of Things scenarios and then not limiting a priori their peculiarities. This is not enough, however, for true AmI: versatile cooperation, organization and integration can be achieved only if connected things can represent, discover and share information and services described in an articulate way by means of high-level formalisms. Semantic Web technologies are natural candidates for such a role, as they provide interoperable languages and tools grounded on formal logic semantics [46]. Semantic Web standards enable knowledge modeling, assertion, organization, querying and inference in distributed systems, but technologies and tools require proper adaptation to work efficiently in resource-constrained environments like the IoT. The Semantic Web of Things (SWoT) [39] aims at the convergence of the Semantic Web and IoT visions, endowing environments with intelligence by means of semantic metadata dynamically produced by ubiquitous micro-devices to characterize sensor data, detected events and phenomena, objects, places and other relevant entities in a context. Due to the volatility and unpredictability of mobile and IoT environments, device and service discovery are two major challenges in the SWoT. Achieving acceptable performance also requires attention, as Semantic Web tools, protocols and languages are typically too resource-consuming for current IoT devices. Application-level protocols and reasoning tools for the (Semantic) Web must be properly adjusted, tailoring their feature set to pervasive computing contexts.

This paper presents a possible approach for a Semantic Social Internet of Things grounded on Ambient Intelligence scenarios. According to the SWoT paradigm, standard technologies were adapted to provide a cohesive knowledge and service discovery architecture. The proposal leverages: i) the Linked Data Platform (LDP) [48] to annotate and organize information resources and ii) the Constrained Application Protocol (CoAP) [10] – a proposed IETF1

¹
Internet Engineering Task Force, https://www.ietf.org.

standard RESTful protocol – for resource exchange in constrained environments, as it is more efficient than HTTP. Above this knowledge/service interoperability layer, a semantic-enhanced application level enables social networking among “agentified” things. Entities and operations in domotics and IoT scenarios are mapped to a novel social multi-agent service-oriented architecture (SOA), supported by semantic-based capabilities. It should be noticed that the proposed framework addresses the specific needs of IoT systems both in terms of communication and computing standpoints, but also in terms of functional and/or architectural aspects. The proposed MAS is intrinsically general purpose and platform-independent in order to comply with a possible exploitation in different scenarios and contexts. Anyway, IoT constraints set the choice of a lightweight application protocol like CoAP (satisfying minimum functional requirements of a small device-oriented SN without excessive computational/bandwidth load at the application level), as well as they impose architectural and implementation choices devoted to keep under control the framework deployment in real-world micro-devices. This has been pursued through the adoption of compression strategies for language verbosity control, through the selection of a compact OWL syntax and via the targeted usage of both memory and data structures. Finally, the architectural approach followed aims to make modular and componentized the micro-SN fundamental elements in order to allow functional (high-level) properties to be enrolled on-demand following (low-level) device capabilities.

Borrowing core relationships and structure from popular SNSs, devices enable specific interaction patterns for information sharing and cooperative decentralized service/resource discovery. Such selective choreography is triggered autonomously, based on the kind of managed resources and other contextual factors; this capability enhances interoperability across heterogeneous platforms and scalability in dense multi-agent environments. Resource discovery exploits semantic matchmaking between ontology-based annotations which describe requests and available resources. Non-standard, non-monotonic inferences [38] implemented in the Mini-ME mobile matchmaker and reasoner [45] allow supporting approximated matches, resource ranking and aggregation for covering complex requests. The framework also supports basic and legacy devices, which do not have computational power enough for on-board reasoning, by allowing them to select a more capable friend as inference facilitator.

The general framework outlined above has been focused on smart HBA, to provide AmI experiences in residential and workplace settings. It was implemented and evaluated in a real prototypical testbed, encompassing diverse device types, communicating across different wired and wireless HBA protocols. Experimental evidences are reported and assess framework feasibility and effectiveness.

The remainder of the paper is as follows. Section 2 discusses the state of the art, while the framework is described in detail in Section 3. Section 4 introduces basics of the Linked Data Platform over CoAP and details the developed testbed. Section 5 presents a case study to further clarify the proposal and its benefits. Experimental evaluations in Section 6 provide an assessment of both practicability and efficiency of the proposed approach, before conclusion.

2. State of the art: Pervasive computing in the social networks epoch

In latest years, social networking services have changed personal interaction habits and relationships management on a global scale. Members of SNSs create personal profiles with basic information about themselves; connect with other users in either bidirectional (e.g., friendship, group) or unidirectional (e.g., follower) relationships; post text and/or multimedia items on their wall (i.e., log) for sharing with their contacts; flag (tag) some contacts to associate them and draw their attention to a certain element; respond to content published by other users with comments and reactions (e.g., like). SNS adopters generally manifest an intention to continue using them [35], because SNSs provide both utility (extrinsic value) and gratification (intrinsic value). Their usefulness also grows as they connect more users, and particularly complementary ones [35], since opportunities increase for discovering interesting information and services.

A social evolution of pervasive computing [2] envisions objects acting as independent agents, capable of establishing relationships and using them to share information and services more effectively. This may allow to reap the above benefits in advanced IoT scenarios; actually, it is reasonable to expect them to be higher in large and heterogeneous networks, such as in HBA. An in-depth analysis of object social networks can be found in [49], which discussed key metrics about nodes and links by adapting from and expanding upon the social network analysis literature. Definitions were formalized in an ontology objects can use to manage their policies, friends and reputation. The following differences exist w.r.t. the approach proposed in this paper: (i) both a symmetrical relationship (friend) and an asymmetrical one (follower) were modeled, whereas [49] includes only an asymmetrical friendship model; (ii) a reference ontology referring to several well-known Resource Description Framework (RDF) vocabularies was developed in order to improve and facilitate the interoperability among different systems; (iii) non-standard inference services were exploited to support a semantic-enhanced resource discovery and composition in social environments. Further ontology proposals exist to formalize models of the social networking domain, e.g., [6]. Particularly, in [2], things engage with one another in social networks independently from human SNSs and from user interactions. A relevant case [22] included social object capabilities in control networks, aiming at distributed Web Ontology Language (OWL) Knowledge Base (KB) management and inference. When connecting to the network, every object proactively exchanged information with other devices in a handshake process. “Requester” devices, equipped with reasoning facilities, could then distribute queries automatically among “known” devices. Unfortunately, the adopted query language supported only very simple inferences, limiting the practical usefulness of the proposal. Another research direction has been focusing on the integration of the IoT into the social context of human users [6], either to improve adaptivity in AmI [29] or to monitor users and assist them in personalizing their SNS experience and interactions [37]. In [28] semantic-based situation detection and goal retrieval were used for matchmaking with task profiles to recommend activities to users, based on their current context. Unlike our approach, social interactions occurred only between devices and users; furthermore, adopted rule-based reasoning could not retrieve approximate matches when exact ones did not exist. A further effort to achieve social capabilities is object blogging, defined as an object’s capability of annotating and publishing its history and context on the Web and/or in a mobile ad-hoc network, supporting intelligent machine-to-machine interactions. Some proposed approaches required user intervention [18], while others aimed at autonomous self-description and decision-making [12].

Table 1
IoT/HBA entities, social features and semantic capabilities

IoT/HBA feature Social environment Semantic capability Detailed description

Object/Device/Application Social agent LDP-CoAP server & client Section 3.1.1

Functional profile Service OWL service description Section 3.2

Object pairing Social relationship (friend/follower) LDP-CoAP interface Section 3.1.3

Object communication Social interaction LDP-CoAP interface Section 4.1

Object configuration update/adaptation Distributed service discovery Semantic matchmaking Section 3.1.2 & Section 3.1.4

Object log Wall LDP Basic Container Section 3.2

Object command Post LDP Basic Container Section 3.2

Object reply Comment LDP RDF Resource Section 3.2

Functionality activation/deactivation Tag & Like LDP PATCH method Section 3.1.4

IoT/HBA feature	Social environment	Semantic capability	Detailed description
Object/Device/Application	Social agent	LDP-CoAP server & client	Section 3.1.1
Functional profile	Service	OWL service description	Section 3.2
Object pairing	Social relationship (friend/follower)	LDP-CoAP interface	Section 3.1.3
Object communication	Social interaction	LDP-CoAP interface	Section 4.1
Object configuration update/adaptation	Distributed service discovery	Semantic matchmaking	Section 3.1.2 & Section 3.1.4
Object log	Wall	LDP Basic Container	Section 3.2
Object command	Post	LDP Basic Container	Section 3.2
Object reply	Comment	LDP RDF Resource	Section 3.2
Functionality activation/deactivation	Tag & Like	LDP PATCH method	Section 3.1.4

Many of the above works combine social networks of pervasive objects with semantic technologies. Indeed, semantic-based approaches have wide adoption in pervasive MAS, and smart building automation is one of the most relevant areas [23,40]. Ontologies have been used in all stages of the lifecycle of HBA systems, including design and deployment, infrastructure description, data modeling and access, and device control [9,19]. In [21] an ontology-based building automation system delivered context-aware information in a customized way to different kinds of users, e.g., upkeep and healthcare operators in a clinic. OWL device and user descriptions were matched through SPARQL queries and SWRL rules were used to combine logical constraints with context-dependent temporal and numerical ones, achieving capabilities similar to classical Complex Event Processing (CEP) systems. Nevertheless, the solution was affected from poor maintainability, because installing new devices required not only manual configuration, but also changes to the reference ontology. The proposed architecture in [9] included a reasoning module exploiting rule-based inferences. Unfortunately, the system state should fully match the rule head in order to trigger its body. Full matches seldom occur in realistic scenarios, whose entities are featured by detailed, heterogeneous and often contradictory information, unless one uses very basic rules. In our approach, non-monotonic inference services allow supporting approximate matches, which can yield “good enough” results whenever full matches are not available.

The proposed distributed Knowledge Base management and service discovery methods can be a foundation for developing further semantic SOA platform capabilities [30], including automated clustering [4], negotiation [40], composition [15] and substitution [43]. Finally, semantic alignment is often a problem in heterogeneous systems such as HBA and IoT. Several works, e.g., [17], propose mappings. This work leverages Linked Data principles to limit the issue, instead, by importing and reusing meaningful parts of other vocabularies in a larger social HBA model.

3. A social framework for smart linked objects

In what follows the proposed framework, architecture and technologies are described.

3.1. Knowledge-based architecture

The approach proposed here aims at object coordination in purposely infrastructured environments and particularly in domotics scenarios through interaction paradigms borrowed from social networks. The main goal is allowing devices (a.k.a. nodes) to gain wide agency and autonomy in sharing information and services, enabling them to distribute requests and obtain responses through fully decentralized peer-to-peer (P2P) interactions also assuming decisions. Table 1 outlines basic correspondences of concepts and features in the IoT and domotics domain with the proposed service-oriented social environment and the semantic capabilities devised to support it. They are discussed in detail in what follows.

3.1.1. Service-oriented architecture

Each object is a social agent, which exposes an individual profile, describing its basic features (device type, location, hardware details) and the resources/services it can provide, e.g., its possible configurations and functional profiles. agent is able to become friend and/or follower of other agents. It makes posts on either its wall or friend’s wall (according to the different types of interaction described later) when its settings or capabilities change, and also when it produces new or updated information through context sensing and analysis. Each post contains all sensed perceptions and events observed by the social agent and it is considered as a request for system reconfiguration through a distributed semantic service discovery process. Posts can be exploited by: (i) sensor agents, only able to observe the surrounding environment having no actuating capabilities (e.g., a weather station) with the goal of sharing observations with other agents on the network; (ii) actuator agents, only able to react to the environment change but presenting limited or absent sensing capabilities (e.g., a lamp or a fan). Reading the posts, they can be aware of current conditions and activate/deactivate some services; (iii) smart agents, presenting both sensing and actuating capabilities. If the agent is not able to satisfy autonomously the perceived changes, a discovery process is started to find potential agents providing further suitable services.

Agent profiles, service descriptions and requests are expressed as semantic annotations referred to concepts modeled within ontologies in Web Ontology Language (OWL 2) [25], formally grounded on Description Logics (DLs) semantics, resulting both machine understandable and human readable at the same time. Devices such as computers or smartphones can run multiple applications concurrently: each application participating in the social service-oriented environment will behave as an autonomous social agent. Functional profiles of agent instances running on the same physical device will typically have common elements – related e.g., to hardware capabilities – expanded with specific application-oriented information. The social relationship, interaction and distributed service discovery models outlined hereafter involve single-purpose physical objects (e.g., lamps, printers) as well as applications deployed on multi-purpose devices, integrating them in a single cohesive social space without conflicts. A decentralized service-oriented architecture (SOA) underlies the whole proposed social network model, where shared knowledge fragments about devices, functional profiles and context represent annotated service/resource advertisements.

3.1.2. Semantic matchmaking

Service/resource discovery conveys decision capabilities of social agents. As stated before, this collaborative process leverages semantic matchmaking, i.e., the overall process allowing the retrieval and ranking of the most relevant resources for a given request, where both resources and requests are satisfiable concept expressions w.r.t. a common ontology $T$ in a DL $L$ . This paper refers to the OWL 2 subset corresponding to the $ALN$ (Attributive Language with unqualified Number restrictions) Description Logics, as it is supported by an embedded matchmaking and reasoning engine which provides the required inference services [45]. Before applying any inference service, the loaded knowledge base is preprocessed performing unfolding and Conjunctive Normal Form (CNF) normalization, as detailed in [38]. Unfolding expands terminological axioms in concept expressions, allowing the reasoner to disregard the ontology in subsequent inference procedures. Normalization enables structural algorithms for both standard and non-standard reasoning tasks, with polynomial complexity for acyclic Terminological Boxes (TBoxes) under practical assumptions [45].

Table 2
Example descriptions for non-standard reasoning tasks

TBox $T$ axioms $LargeCapacity ⊑ \neg RegularCapacity$

$WasherDrier \equiv WashingMachine ⊓ Drier$

Request $R_{1} \equiv WasherDrier ⊓ LargeCapacity$

Resources $S_{1} \equiv WashingMachine$

$S_{2} \equiv WasherDrier ⊓ RegularCapacity$

Abduce( $R_{1}$ , $S_{1}$ , $T$ ) $H \equiv Drier ⊓ LargeCapacity$

Contract( $R_{1}$ , $S_{2}$ , $T$ ) $⟨ G, K ⟩ = ⟨ LargeCapacity, WasherDrier ⟩$

Standard reasoning tasks for matchmaking include Subsumption and Satisfiability. Given a request R and a resource S, Subsumption verifies whether all features in R are included in S: its outcome is either full match or not. For example, consider a TBox $T$ including axioms and individuals shown in Table 2. In case of $R_{1}$ and $S_{1}$ , Subsumption returns false since $S_{1} / ⊑ R_{1}$ , so $S_{1}$ is not deemed useful, even though it provides a washing machine which is a part of the request. Satisfiability checks whether any constraint in R contradicts some specification in S, hence it divides resources in compatible (a.k.a. potential matches) and incompatible (a.k.a. partial matches) w.r.t. the request. In the above example, $S_{2}$ is incompatible with $R_{1}$ and should be discarded, even though the requester might accept a smaller capacity if a larger one is unavailable. These binary outcomes are inadequate for advanced scenarios, because full matches are rare and incompatibility is frequent when dealing with articulated concept expressions from heterogeneous sources.

In order to produce a finer resource ranking and a logic-based explanation of outcomes, the framework proposed here extends the basic subsumption/satisfiability approach by exploiting the following non-standard inference services [45]:

Concept Abduction: whenever R and S are compatible, but S does not imply R, Abduction allows to determine what should be hypothesized in S in order to completely satisfy R. The solution H (for Hypothesis) to Abduction can be interpreted as what is requested in R and not specified in S (adopting an Open World Assumption). In the above example, Abduce( $R_{1}$ , $S_{1}$ , $T$ ) returns the H expression in Table 2. CNF allows defining a norm on concept expressions, so enabling a logic-based relevance ranking of a set of resources w.r.t. a given request based on the norm of their Hs.

Concept Contraction: if request R and resource S are not compatible, Contraction determines which part of R is conflicting with S. If one retracts conflicting requirements in R, G (for Give up), a concept K (for Keep) is obtained, representing a contracted version of the original request, such that $K ⊓ S$ is satisfiable w.r.t. $T$ . The solution G to Contraction represents “why” R and S are not compatible. In particular, a conflict occurs when concepts in the two descriptions clash; in the above example, Contract( $R_{1}$ , $S_{2}$ , $T$ ) produces the output shown in Table 2. Resource ranking is possible also in this case, based on the CNF norm measured on G.

Concept Covering: pervasive computing scenarios often require relatively large numbers of resources to be aggregated in order to satisfy a complex request. To this aim, a further non-standard reasoning task based on the solution of Concept Covering Problem (CCoP) has been defined. It allows to: (i) satisfy features expressed in a request as much as possible, through the conjunction of one or more small instances of a KB – seen as elementary knowledge blocks – and (ii) provide explanation of the uncovered part of the request itself. Given a request R and a set of available resources $S = {S_{1}, S_{2}, \dots, S_{n}}$ , all satisfiable in the reference ontology $T$ , Concept Covering aims to find a pair $⟨ S_{c}, H ⟩$ where $S_{c} \subseteq S$ contains concepts covering Rw.r.t. $T$ and H is the residual part of R not covered by concepts in $S_{c}$ . Concept Covering exploits Abduction to find at each step a concept to include in $S_{c}$ , which is the one producing the minimum residual uncovered part H. Also in this case, a CNF-based score is associated to the result $S_{c}$ as the obtained covering percentage. A Covering example can be found in the case study in Section 5.

The reader is referred to [45] for algorithms and further considerations on Concept Abduction and Contraction, as well as to [41] for Concept Covering.

3.1.3. Social entities and relationships

The above inference services are used to regulate the interactions between social agents. They are grouped in two families:

Smart: devices able to perform reasoning tasks exploiting non-standard deductions;

Basic: low-memory, low- (or no)-computing power devices. They can only provide sensing/acting services, but do not perform autonomous reasoning.

A pair of agents can establish a social relationship following the basic interaction pictured in Fig. 1. Two schemes are implemented:

Fig. 1.

Sequence diagram for social agent relationships: (a) friend; (b) follower.

Friend: a bidirectional relationship where nodes $N_{i}$ and $N_{j}$ can exchange both information and services. In particular, a device $N_{j}$ sends a friendship request; since the receiver $N_{i}$ 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 deactivate the friend’s services. A basic node, when becoming friend with a smart node, can select it as semantic facilitator i.e., reasoning supporter.

Follower: a unidirectional relationship where a node $N_{k}$ is interested only in receiving the updates published by $N_{i}$ on its wall. In other words, if $N_{k}$ sends a follower request to $N_{i}$ , $N_{k}$ becomes an observer of $N_{i}$ ’s behavior.

Following/Friendship criteria are automatically verified by means of a matchmaking process involving the device profile. Differences from being follower or friend of a device are related to the device characteristics which in turn reflect the adoption of proper concepts in the reference taxonomy. Basically, semantics of profiles refers to functional and non functional properties of devices influencing the compatibility among them. In other words, $N_{j}$ decides to become a friend or a follower of $N_{i}$ according to information in $N_{i}$ ’s profile. It contains all data about the device, e.g., location and type (according to the M3-lite taxonomy [1]), as described in Section 3.2. In particular, after retrieving the profile of the nearby object, $N_{j}$ evaluates the following relationship conditions – first outlined in [3] – to decide whether to send a friendship request to $N_{i}$ : (i) strong co-location, i.e., both devices are placed in the same room/area. The granularity of co-location can be enhanced at will in the profile definition: a co-location can be set for devices in the same wall or posed in the same shelf of a furniture item. This could restrain the friendship relation according to objects requirements and functions; (ii) parental or co-ownership, i.e., they are from the same manufacturer or belong to the same owner; (iii) co-work, i.e., nodes are able to cooperate closely as they share annotations referred to the same ontology and provide functionalities related to the same activity (e.g., room lighting) or observation (e.g., indoor temperature). Annotations are embedded at start-up on each social agent according to the memory availability. These can be either static, i.e., the same for the whole agent’s lifetime, or dynamic, e.g., changing after a sensor data gathering phase or when the agent’s internal state changes. On the other hand, $N_{j}$ asks to become a follower of $N_{i}$ if the following conditions are met: (i) weak or sporadic co-location, such that information produced by $N_{i}$ can still be useful to $N_{j}$ to characterize its own context but at the same time $N_{j}$ needs/prefers to start a discovery process completely independent from $N_{i}$ ; (ii) weak co-work relationship, i.e., there is low utility in a direct interaction, e.g., the two devices are deeply different. In this case, they could be defined as concepts belonging to different device categories or present partially incompatible definitions in the reference ontology; (iii) no co-ownership. For example, if a printer and a scanner are in the same room, they become friends because they share the same location, but also as they were both defined within the reference ontology as devices providing services for document management. In this case, friendship is preferred to a following relationship because the printing functionalities must be explicitly required by the scanner, e.g., after doing a document scan. The framework also allows $N_{j}$ to be both a friend and a follower of $N_{i}$ ; this enables a broader variety of interaction patterns between the two devices, which is useful in highly dynamic scenarios. In any case, $N_{i}$ can refuse the friendship/follow request if: (a) relationship constraints described above are not respected; (b) the maximum number of friends/followers has been reached. Every device sets limits according to its processing and memory capabilities. In practice, however, refusing a new friend or follower is rare, as a device increases its opportunities for useful cooperation by expanding its social network.

Like in SNSs, in the framework proposed here the object’s wall is the main channel for sharing knowledge. Both push and pull models are supported, through the above relationships. In a nutshell, if a node $N_{i}$ wants to receive updates from a node $N_{j}$ automatically, it will ask to become a follower. In this case, the follower $N_{i}$ can start a semantic matchmaking session when it receives a notification from the followed device $N_{j}$ (as in Fig. 1(b)); instead, if $N_{i}$ wants to be able to access the wall of $N_{j}$ on demand, it will ask to become a friend (and in doing so it will also grant access to its own wall). Then $N_{i}$ will start a semantic matchmaking process only if $N_{j}$ writes a post on $N_{i}$ ’s wall, e.g., during a distributed covering as reported in Fig. 2(b). Every agent will select either model – or even both – depending on its application requirements.

3.1.4. Collaborative adaptivity

When a node detects some change in internal or contextual conditions requiring adaptation i.e., a functional configuration update of itself and/or nearby devices, it writes a post on its own wall. A post P is modeled as a pair $⟨ R, L ⟩$ . R is the request issued by the node; L is the like value. The idea of the like reaction to a post is mutuated from human-oriented SNS, but with two important differences: it is a real value in $[0, 1]$ rather than a binary value; it represents the percentage of coverage and completion of the request R, as obtained from Concept Covering in the collaborative service discovery triggered by the post to reconfigure the environment. Specifically, if H is the uncovered part resulting from Concept Covering of R with a set of available services, the corresponding like value will be $\begin{matrix} L = 1 - \frac{norm (H)}{norm (R)} \end{matrix}$ using the CNF-induced norm on concept expressions [38]. The overall process is exemplified in Fig. 2. It consists of the following steps:

When a node $N_{i}$ detects a reconfiguration is needed, it writes a post $P_{i}$ on its own wall. Initially, $L_{i}$ is set to 0.

If $N_{i}$ is a basic device, go to step 3. Otherwise, $N_{i}$ executes the Concept Covering task on the local set of service descriptions S (section a) in Fig. 2). Upon completion, $N_{i}$ activates the selected services and adds a comment $C_{i}$ to $P_{i}$ as a pair $⟨ U_{i}, T_{i} ⟩$ , where $U_{i}$ is the uncovered part of $R_{i}$ and $T_{i}$ tags the local selected services/resources. Moreover, the value of $L_{i}$ is updated to the obtained covering score, as reported in Fig. 2(a).

If $R_{i}$ is not completely covered, $N_{i}$ selects a friend $N_{j}$ and writes a post $P_{j} = ⟨ R_{j}, L_{j} ⟩$ ) on its wall. Particularly, if $N_{i}$ has executed step 2, $R_{j}$ is set to the uncovered part $U_{i}$ , otherwise $R_{j}$ is equal to $R_{i}$ and $L_{j}$ is reset. Furthermore, $N_{i}$ requests to be notified when a comment is added to $P_{j}$ . $N_{j}$ recursively executes the steps 2)–3). This is illustrated in section b) of Fig. 2.

When $N_{i}$ receives the notification of $P_{j}$ , it reads the comment from the friend’s wall, which is appended to $P_{i}$ to update the status of the request. Finally, $N_{i}$ updates the like value according to the overall covering score.

Fig. 2.

Sequence diagram of distributed reconfiguration.

A full example is in the case study reported in Section 5. Some remarks may be useful:

The recursive discovery procedure can be applied in a depth search with no theoretical bounds. Practically, discovery can be limited by means of the following threshold values, modeled as device parameters: (i) max_depth, representing the maximum depth of the discovery w.r.t. the device starting the process, where a direct friend has depth 1, a friend of a friend has depth 2, etc.; (ii) minimum like value, to identify a satisfactory coverage from the discovery process: when a device reaches this like value, the covering procedure can be halted, also avoiding to forward the (possible) uncovered part of the request to further friends. Each device can use these parameters to prevent nodes over the network from being flooded with multiple and/or useless messages. Agents manage heuristics to decide the values of both parameters.

Message flooding is also managed by exploiting a simple caching mechanism implemented on each node. A request is identified by means of a unique key saved on the device cache when the message is accepted and processed. If the request message was previously received, it is discarded by the device.

The choice of friend(s) to call in the above step 3 also depends on heuristic preference criteria, such as the number and type of services exposed by the friend (known at friendship establishment time), network latency or friend’s computational resources.

Main purpose of comments is to keep track of the progressive fulfillment of an adaptation request, exploiting tagging to avoid duplication of service/resource selection.

3.2. Interoperability layer

All social features reported in Table 1 are modeled as RDF resource following the Linked Data Platform (LDP) guidelines in order to make the proposed approach general-purpose and independent from the particular protocol used at the application layer. The LDP W3C Recommendation [48] provides standard rules for accessing and managing Linked Data on the Web. Basically, it defines a set of communication patterns based on HTTP methods and headers for CRUD (Create, Read, Update, Delete) operations as well as different types of LDP Resources (LDPRs): RDF Source (LDP-RS), whose status corresponds to an RDF graph and can be fully represented in an RDF syntax; Non-RDF Source (LDP-NR), not represented in RDF (e.g., a binary or text document without useful RDF annotation); Basic (LDP-BC), Direct (LDP-DC) and Indirect (LDP-IC) containers, defining collections of LDP resources according to specific membership patterns.

This subsection, along with figures from 3 to 6, describes the models of core entities in the social framework: device profiles, service profiles, walls, posts and comments.

Fig. 3.

Ontology-based modeling of a device profile.

Device profiles. The profile resource exposes main device features as an RDF-based annotation. An example is reported in Fig. 3. In addition to well-known RDF vocabularies, a so-called Semantic Web of Social Things (SWST) ontology2

Available at http://sisinflab.poliba.it/swottools/onto/swst/.

has been defined to model basic elements of a social device. In particular, each profile contains the following properties:

type of device, according to the classification proposed by the M3-lite taxonomy [1], a lightweight version of the Machine-to-Machine Measurement (M3) ontology used to describe sensor measurements and observations;

device name, using the dcterms:title property of the DCMI Metadata Terms vocabulary [20];

supported ontologies (dcterms:requires) used as reference vocabularies to define the OWL-based annotations of the functionalities exposed by the device;

location of the device (e.g., in an area, building, department, apartment), exploiting the dogont:isIn property of DogOnt [9], a reference ontology proposed to model intelligent domotic environments. DogOnt also contains several concepts related to indoor and outdoor locations;

address of the device endpoints, on both the server (swst:serverEndpoint) and client (swst: clientEndpoint) side. Both properties were defined as sub-properties of iot-lite:endpoint contained in the IOT-lite ontology [5], a lightweight vocabulary based on SSN-XG [16] proposed to describe IoT concepts and relationships;

(possible) friend and followed devices exploiting the swst:friendOf and swst:followerOf relations, respectively.

Fig. 4.

Service container and device functionalities.

Friendship is an LDP-BC listing the friend devices of a social object. Sub-resources are identified by the name of the friend and are connected to the container through an ldp:contains property, according to the LDP guidelines [48]. Each of them corresponds to the object profile retrieved after the friendship was established.

Service profiles. As depicted in Fig. 4, the functionalities exposed by a device are described by means of a resource named services and characterized by a set of RDF properties: dcterms:title specifies the service name; rdfs:isDefinedBy indicates the IRI of the OWL individual modeling the service within the reference KB (examples of individual descriptions are provided in Fig. 11, Fig. 12 and Fig. 15 in Section 5); dcterms:modified reports the timestamp of the last modification applied to the individual description; swst:currentState and swst:activationValue identify the service current state and the specific value to be used to activate the functionality (set point), respectively.

Fig. 5.

Wall and posts.

Fig. 6.

Comment to a post.

Wall and posts. Fig. 5 shows the modeling of a device wall. It lists one or more posts defined as nested RDF resources and each post can include several comments. Post descriptions include: creation date (dcterms:created); creator device (swst:postedBy); content of the post (sioc:about), defined in the Semantically-Interlinked Online Communities (SIOC) Core Ontology [8], as IRI of the individual representing the received OWL annotation; like value (swst:likeValue).

Comments. Finally, a comment annotation (Fig. 6) consists of: creation date; creator device; content of the comment, corresponding to the part of the post the friend device is not able to cover; tagged (i.e., activated) services (sioc:topic), selected through the covering process.

Table 3

LDP-CoAP interface of a social device

Resource URI	Resource Type	LDP-CoAP Method	Description
/profile	LDP-RS	GET	Returns the device profile
/friendship	LDP-BC	GET	Returns the list of friend devices
/friendship	LDP-BC	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-RS	GET	Returns the RDF-based description of a specific functionality
		PATCH	Updates the status of a functionality according to the received command
		HEAD	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-BC	GET	Returns the device wall containing the list of published posts
/wall	LDP-BC	POST	Publishes on the wall a post received from a friend device
/wall/<post-id>	LDP-BC	GET	Returns the detailed description of a specific post
/wall/<post-id>	LDP-BC	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-RS	GET	Returns the description of a comment
/wall/<post-id>/<comment-id>	LDP-RS	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

4. Implementation

At the application layer, the above reference architecture is implemented on a LDP-CoAP framework [36]. Each agent in the social network is modeled as an LDP-CoAP node exposing the interface reported in Table 3. In what follows, basics of Linked Data Platform for the CoAP protocol will be introduced along with a detailed description of the developed prototypical testbed.

4.1. Framework implementation with LDP-CoAP

The LDP specification only supports the HTTP protocol, which requires not negligible bandwidth, processing and memory resources for most IoT devices. LDP-CoAP variant, on the contrary, aimed to integrate LDP in resource-constrained devices and networks just leveraging CoAP [10], a compact counterpart of HTTP conceived for machine-to-machine (M2M) communication. Some CoAP options are derived from HTTP header fields (e.g., content type, headers and proxy support), while some other ones have no analogous in HTTP. In any case, the HTTP-CoAP mapping, included in the LDP-CoAP framework, can be exploited to support all LDP features with CoAP.

Fig. 7.

Examples of basic device interactions over LDP-CoAP.

In the present case, social devices communicate over the network through CoAP messages. Basically, each message is composed of: (i) a 32-bit header, containing the request method code or response status; (ii) an optional token value, used to associate replies to requests, (iii) a sequence of option fields (containing information such as resource URI and payload media type), (iv) the payload data. CoAP adopts the CoRE Link Format specification [47] for resource discovery. A client accesses the reserved /.well-known/core URI on the server via GET to retrieve available resource entry points. Further GET requests will include URI-query options to retrieve only resources with given attributes. Standardized query attributes include resource type (rt), interface usage (if), content-type (ct), and MIME (Multipurpose Internet Mail Extension) type for a resource. Further non-reserved attributes can be freely used. CoAP also provides push notifications without polling [24], a useful feature when data have to be monitored over time (e.g., in case of follower relationship). CoAP also supports proxies, enabling Web applications (i.e., HTTP clients) to transparently access the resources hosted in devices based on CoAP.

Table 4

KNX devices in the testbed

Product ID	Description	Social Device
GW90707	KNP/IP router	—
GW90740	Switch actuator 4 channels	Air conditioner (2 ch.) + Garden watering system (2 ch.)
GW90740	Switch actuator 4 channels	n.4 Simple on/off lamp
GW12782	Push button 4 channels	n.4 Basic on/off button
GW90800	Weather Station with GPS	Weather Station
GW90746	Dimmer actuator	Dimming lamp
GW10948	Burglar alarm system interface	Alarm system
GW90754	Roller shutter actuator	Shutter controller

In order to clarify the proposed approach, some reference examples are shown in Fig. 7, reporting RDF annotations in Turtle syntax [14]. Alternately, they can be retrieved in JSON-LD [34], by setting the Accept header appropriately. In particular, it is possible to notice that:

GET requests are used to retrieve data (e.g., wall content, profile or service description) from a device. As shown in the example Nr. 8, OWL annotations are treated as LDP-NR resources, in order to support any OWL concrete syntax, not only RDF-based ones;

POST method allows to send data to a device, e.g., send friendship requests (example Nr. 2) or write posts/comments to the wall (example Nr. 5);

PATCH requests are used to update data, e.g., to tag a new device on an existing comment (example Nr. 6);

HEAD method is exploited to verify if a device service description has changed (example Nr. 9). It exploits the ETag value, defined in [11], i.e., a resource identifier differentiating representations of the same resource that vary over time. In the proposed framework, it is based on a given OWL annotation and changes every time the description is modified.

4.2. Developed testbed

A prototypical testbed was developed following the proposed social framework described in Section 3. The core goal was to address the interoperability problem among multiple IoT platforms and standards. Therefore, the testbed implements a basic environment (similar to the one described in the case study in Section 5) consisting of a subset of home areas, i.e., a hall door, a living room, a kitchen, and a small outdoor space. An IEEE 802.11 network was exploited as a fast backbone including 3 smart nodes, each implementing a single social device. The smart nodes were developed on three reference platforms with different processing capabilities. Moreover, a KNX sub-network was connected to the main area by means of an additional smart node, acting as gateway toward the social network, allowing KNX-based devices to interact with the other social objects in a transparent way. As detailed in Table 4, the KNX installation consisted of 8 off-the-shelf devices, produced by Gewiss Inc.,3

³
http://www.gewiss.com

connected through a twisted pair bus in a hierarchical network. Each device (except the KNX router, used only for the communication over IP) corresponds to one or more LDP-CoAP endpoints, exposed by the gateway node, representing the social objects in Table 4. In this way, all devices in the home can interact through the proposed LDP-CoAP interface independently from the specific HBA protocol. Particularly, multi-channel devices can manage several functionalities, e.g., switch actuators can handle up to 4 push buttons whereas the dimmer actuator can provide several functionalities according to the different light level. Therefore, more than 30 services were exposed overall by the KNX sub-network toward the social framework.

Fig. 8.

Reference software modules.

According to Fig. 8, a Java-based management software was implemented to run on each home device. The main Java package it.poliba.sisinflab.swst was partitioned in the following sub-packages to separate developed classes in well-defined sections each providing the following specific functionality:

core: contains the HomeDevice reference implementation. It extends the CoAPLDPServer provided by the LDP-CoAP library4

⁴

https://github.com/sisinflab-swot/ldp-coap-framework

and exposes one or more DeviceEndpoint managing the resources described in Table 3. At network level, LDP-CoAP provides also a modified version of the Californium CoAP framework [33] supporting LDP features over CoAP;

resources: several Java classes model the different device resources. LDP-CoAP RDFSource, NonRDFSource and BasicContainer base classes were extended, providing common attributes and methods to save, retrieve and update the home data. All information is stored within an RDF repository based on the RDF4J 2.1.3 library;5

⁵

http://rdf4j.org/

rdf.vocabulary: contains RDF ontology files mapped as Java classes to simplify creation and querying of RDF triples. Ontologies cited in Section 3.2 (e.g., SIOC, IoT-lite, M3-lite) were mapped through the Sesame Vocabulary Builder6

⁶

http://github.com/tkurz/sesame-vocab-builder

tool and included in the package;

owl: provides basic functionalities to load the reference KB, manage all generated OWL annotations through the OWL-API 3.4.10 library [26] and invoke the Mini-ME reasoner [45] implementing inference services;

knx: an additional package implemented to support the communication over the ISO/IEC 14543-3 EIB/KNX protocol stack [42]. Calimero-core library7

⁷

http://github.com/calimero-project

was exploited for network management and to exchange data with KNX devices (e.g., read state values or send commands). An import utility was also implemented to parse data from an XML-based project file exported from ETS4,8

⁸

http://www.knx.org/knx-en/software/ets/about/

the official software tool used to design and configure home installations based on KNX systems, and to model the same device features within the home social network.

The following embedded boards were used to implement the social devices:

Raspberry Pi Model B,9

⁹

http://www.raspberrypi.org/products/model-b/

equipped with a single-core ARM11 CPU at 700 MHz, 512 MB RAM (shared with GPU), 8 GB storage memory on SD card, Raspbian Wheezy OS;

Intel Edison Kit10

¹⁰

http://www.intel.com/content/www/us/en/do-it-yourself/edison.html

equipped with an Intel Quark x86 CPU at 400 MHz, 1 GB RAM, 4 GB eMMC flash storage and Yocto Poky Linux OS (32-bit kernel 3.10.98);

UDOO Quad11

¹¹

http://www.udoo.org/udoo-dual-and-quad

equipped with quad-core ARM Cortex A9 at 1 GHz clock frequency, ARM Cortex M3 coprocessor, 1 GB DDR3 RAM, 32 GB storage memory on SD card, UDOObuntu 2.0 Minimal Edition OS.

All platforms included a 32-bit Java 8 SE Runtime Environment (JRE, build 1.8.0-b121).

5. Case study: Semantic Web of (social) things for building automation

Fig. 9.

Case study scenario.

This section presents a case study, devoted to clarify the social and collaborative features of the proposed framework in terms of orchestration of smart devices in a complex HBA context. Let us consider the example scenario depicted in Fig. 9. Two apartments on the same floor of a building, H₁and H₂, include a set of semantic-enabled devices forming a home social network. In particular, H₁ is configured with an alarm system (AS), a rolling shutter controller (SC₁), an air conditioner (AC₁) and a dimmer lamp (L₁). A weather station (WS), a rolling shutter controller (SC₂), an air conditioner (AC₂) and a dimmer lamp (L₂) are installed in H₂ instead. The blue arrows in Fig. 9 specify the existing friendship relations between the different devices. In particular, according to the criteria reported in Section 3.1.3, each pair of devices in the same apartment establishes a friendship relation because they are in the same location and share functionalities useful to improve comfort or security in the house. As said, when a friendship relation is established, each friend is able to directly read the wall of an object, write a post on its wall and use the services of the device. Within the two apartments, each object has sensing and/or actuating capabilities and exposes a set of features to its friends. According to the resource interface described in Section 4.1, all social network interactions can be implemented as request/response messages over LDP-CoAP.

Fig. 10.

Post content (i.e., request) written by the alarm system.

It is evening, there is no one in the apartment H₁and the AS detects an intrusion in the house. Immediately the AS writes a new post on its wall representing what it has sensed as an OWL annotation. Figure 10 shows a possible formalization of the post (reported in OWL2 Manchester syntax [27] for the sake of readability) w.r.t. the reference ontology. Service requests and descriptions are modeled in a general way, by expressing the context conditions suitable for the activation of a given service.

The AS starts a Concept Covering process using the post content as request, whereas available resources are represented by the functionalities exposed by all the devices directly involved into a friendship relation. The AS verifies if the services of the connected objects, SC₁ and L₁ in our example, were modified by performing a simple check: (i) AS sends a lightweight request (as shown in Example 9 of Fig. 7) to the service resources exposed by each friend; (ii) only if the resource has changed (i.e., the OWL annotation was updated), the new service description will be retrieved (Example 8 of Fig. 7). Otherwise, the AS can directly use the cached service annotation. This procedure ensures that the covering task is performed using the latest descriptions of all available services.

According to the semantic service descriptions, listed in Figs 11 and 12 respectively, the matchmaking procedure highlights the shutter should be fully closed and the dimmer lamp turned on to completely satisfy the request. This is due to the fact the AS detects a low luminosity, no presence of humans and an intrusion event. All device perceptions were modeled with the related concepts described within the reference ontology. In particular, the Intrusion class was defined as more specific than IntrusionForLamp and IntrusionForShutter (i.e., it should require services both from a lamp and a shutter controller), as shown in Fig. 13. These two concepts belong to the annotation of the Lamp_On and Full_Close service annotations, respectively; moreover, Lamp_On is also useful in case of low luminosity. Due to this reason, they are selected during the covering process as suitable functionalities to be activated. With a modestly expressive DL like $ALN$ , such a modeling pattern allows activating functionalities of different devices that are fired when the same event is detected. In the first step of Concept Covering, all services in Fig. 11 and Fig. 12 undergo Concept Abduction with the request: Full_Close is selected because it yields the smallest uncovered part, reported in Fig. 14. This becomes the new request for the subsequent Abduction round, when Lamp_On is selected and AS_ Request is fully covered. Therefore, the AS writes on its wall a comment to the post, containing only a tag for each service to activate, i.e., Full_Close (SC₁) and Lamp_On (L₁). The uncovered part of the request is empty because the request was completely satisfied. Finally, according to the covering results, the like value of the post is automatically updated to 1 and no further operations are required.

Fig. 11.

Shutter controllers SC₁ and SC₂ service annotations.

Fig. 12.

Dimmer lamps L₁ and L₂ service annotations.

Fig. 13.

Intrusion ontology class modeling.

Simultaneously, devices within the apartment H₂ could exploit the knowledge shared by the home social network in H₁ to adapt their configuration according to the detected conditions. As shown in Fig. 9, a follower relation exists between the weather station and the alarm system. As explained in Section 3.1.3, the WS decided to follow (i.e., continuously observes) the wall of the AS because: (i) they are in different houses; (ii) AS is an alarm device providing services not directly useful for a sensing device as WS; (iii) at the same time, AS provides further sensing capabilities (i.e., intrusion detection) useful for WS to better characterize the surrounding environment. So when the alarm system posts the intrusion message, it is immediately notified. The WS reads the annotation and shares it on its wall as a new post. This event triggers also in H₂ a Concept Covering process involving the services exposed by the friends of WS (SC₂ and AC₂), which are listed respectively in Fig. 11 and Fig. 15.

Fig. 14.

OWL annotation of the uncovered part of AS_Request.

Fig. 15.

Air conditioners AC₁ and AC₂ service annotations.

Only the Full_Close service, provided by SC₂, is selected to partially satisfy the request: this is basically due to commonality with the request of concepts (detectsOccupancy some) and (detectsOccupancy (not Presence)). WS comments its post including a tag to the shutter service and the uncovered part of the request as content. In this case, to further satisfy the post, the WS can forward the uncovered part to one of its friends. The WS selects SC₂, since it provided the highest contribution to covering in the initial step, and posts on the wall of SC₂ the OWL annotation of the uncovered part reported in Fig. 16. Moreover, the WS starts observing the post it just sent to the friend’s wall. SC₂ in turn receives the message, starts a covering process involving the services exposed by L₂ (Fig. 12) and selects the Lamp_On functionality, which completely covers the remaining part of the initial request. SC₂ comments its post tagging the activated services and updates the like value with the percentage of covered features. The request is fully satisfied so the uncovered part is empty and no other posts are needed. Thanks to the observer pattern, the WS receives a notification about the post, reads the comment and understands the initial request has been completely served. As a consequence, it updates the like value of the post on its wall, not forwarding further requests.

Fig. 16.

OWL annotation of the uncovered part of WS_Request.

Fig. 17.

Processing and communication time for the social tasks.

It is useful to point out how social capabilities allowed apartment H₂ to compensate for the lack of an alarm system, taking advantage of the sensing capabilities of the one in H₁ to appropriately configure and modify the status of its devices. This is just an obvious example of the benefits of the proposed semantic-based social framework in information and service/resource sharing in complex settings and heterogeneous networks. Furthermore, request and service descriptions in the case study were kept short for easier understanding of the proposed framework, but the adopted inferences allow managing more detailed specifications with articulated constraints.

6. Evaluation

A performance and functionality assessment of the proposed framework and implementation are outlined hereafter. Experiments have been carried out performing the 10 reference tasks described in Fig. 7, to identify and evaluate specific features characterizing their performance. Each test was repeated five times and average values were taken.

Fig. 18.

Processing time for the Concept Covering task.

6.1. Performance

Time. Time results are reported in Fig. 17. In particular, the processing time is defined as the time elapsed on the device receiving a request to process the message and send the related response, whereas the communication time represents the time needed to exchange request/response data (i.e., CoAP packets) over the home network between the sender and the receiver device. As expected, RaspberryPi required a longer time to process the requests due to the reduced computational capabilities. On the contrary, Intel Edison was the fastest platform in case of tasks only requiring simple I/O operations, thanks to the internal flash memory. Concerning communication time, a significant variation can be noticed, due to the different hardware adopted for connecting to the home network. In particular, RaspberryPi and UDOO were equipped with a Wi-Pi IEEE 802.11 USB dongle, whereas Intel Edison exploited the on-board transceiver.

Table 5
Request Dataset

Processing Time (ms)

ID Size (Byte) Tagged Services Like Value Rasp. Pi Intel Edison UDOO

R1 1381 1 28.57 89.2 20.8 12.8

R2 1967 2 61.54 122.2 30.8 14.2

R3 2468 3 73.68 132.0 37.6 17.8

R4 2902 4 79.17 140.2 47.0 18.0

R5 3309 5 82.76 146.4 64.4 23.2

R6 3651 6 84.85 154.6 78.8 29.8

R7 4202 7 87.18 160.8 81.4 35.4

				Processing Time (ms)
R1	1381	1	28.57	89.2	20.8	12.8
R2	1967	2	61.54	122.2	30.8	14.2
R3	2468	3	73.68	132.0	37.6	17.8
R4	2902	4	79.17	140.2	47.0	18.0
R5	3309	5	82.76	146.4	64.4	23.2
R6	3651	6	84.85	154.6	78.8	29.8
R7	4202	7	87.18	160.8	81.4	35.4

Test results about the Concept Covering task performed on a single node are reported in Fig. 18. Experiments were conducted exploiting a shared dataset of 7 requests (see Table 5) with growing size and restriction complexity. As a consequence, a different number of services was selected (from a set of 50 instances) and tagged after the reasoning step. It can be pointed out that like value was lower for simpler requests and increased for more complex ones. This is due to the fact that ontology and service annotations are modeled to fit articulate and specific descriptions, such as device operating requirements; generic requests result less significant, leading to a relative loss of the semantic-based score. For all platforms, the complexity of the request affected time only slightly, showing a similar trend. As expected, the processing time was longer for complex annotations, because a higher number of services was retrieved to satisfy the request.

Memory. Memory usage values are shown in Fig. 19. Framework requirements were low on all platforms, with a memory peak always under 18.5 MB for stack memory and 16.5 MB for heap memory, representing reasonable values for embedded systems.

Data compression. Another relevant parameter of the social framework performance is the amount of data exchanged over the home network. In order to reduce the number of packets used to transmit each message over CoAP, the LDP-CoAP implementation described in [36] was extended to support the following encoding algorithms, aiming to reduce the size of resource descriptions: (i) GZIP and BZIP2 (both included within the Apache Commons Compress library12

¹²

http://commons.apache.org/proper/commons-compress/

), general-purpose and suitable for annotations described with RDF Turtle [14], JSON-LD [34] and all OWL syntaxes; (ii) Binary JSON (BSON),13

¹³

http://bsonspec.org/

Universal Binary JSON (UBJSON)14

¹⁴

http://ubjson.org/

and Message Pack (MsgPack),15

¹⁵

http://msgpack.org/

specific for JSON-based annotations.

Selected algorithms were tested on three basic resources corresponding to the LDP-CoAP resource types available in the proposed framework: RDF Source (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 of posts, comments and services). LDP-RS and LDP-BC were described with RDF Turtle and JSON-LD to test both syntaxes supported by LDP-CoAP, whereas LDP-NR was described through the OWL 2 Manchester syntax. Figure 20 reports on the size of the reference annotations with and without compression. GZIP provided better results, achieving a compression ratio of about 48%. In this way, each device sends on average the half of CoAP packets (which must contain a maximum of 64B as payload), so reducing the overall communication latency. On the contrary, JSON-specific algorithms were not particularly useful for short messages, being designed to encode large documents.

Fig. 19.

Memory usage.

Fig. 20.

Size of encoded payload messages.

6.2. Functionality

Table 6
Comparison with current IoT-oriented frameworks for HBA

Features Proposed Approach KNX IoT IzoT Platform Dog Gateway Eclipse SmartHome

Home Area Network reference protocol multi-protocol over CoAP EIB/KNX LonTalk multi-protocol over HTTP multi-protocol over HTTP

Network architecture full P2P centralized centralized centralized centralized

Network/devices configuration autonomous social agents configuration via ETS software via LonBuilder software or XML configuration files XML configuration files Domain Specific Language (DSL) configuration files

Add/remove devices agents self-configuration edit network/devices configuration edit network/devices configuration edit network/devices configuration edit network/devices configuration

Multi-protocol communication smart node acting as gateway KNX gateway IzoT gateway Dog gateway node acting as gateway

Device binding dynamic, based on friendship relationships static, defined during network configuration static, defined during network configuration dynamic, based on device profile static, defined during device configuration

Scenarios configuration dynamic, exploiting non-standard inferences static, defined during network configuration static, defined during network configuration dynamic, exploiting rule-based reasoning static, based on an ECA rule engine

Service composition yes, through distributed covering no no no no

Message data format RDF Turtle, JSON-LD, OWL 2 proprietary, according to KNX spec. proprietary, XML-based according to LonTalk spec. OWL 2 XML

Standardised framework interface LDP-CoAP RESTful interface KNX IoT Web Services HTTP RESTful API WebSocket and HTTP RESTful API HTTP RESTful API

Features	Proposed Approach	KNX IoT	IzoT Platform	Dog Gateway	Eclipse SmartHome
Home Area Network reference protocol	multi-protocol over CoAP	EIB/KNX	LonTalk	multi-protocol over HTTP	multi-protocol over HTTP
Network architecture	full P2P	centralized	centralized	centralized	centralized
Network/devices configuration	autonomous social agents configuration	via ETS software	via LonBuilder software or XML configuration files	XML configuration files	Domain Specific Language (DSL) configuration files
Add/remove devices	agents self-configuration	edit network/devices configuration	edit network/devices configuration	edit network/devices configuration	edit network/devices configuration
Multi-protocol communication	smart node acting as gateway	KNX gateway	IzoT gateway	Dog gateway	node acting as gateway
Device binding	dynamic, based on friendship relationships	static, defined during network configuration	static, defined during network configuration	dynamic, based on device profile	static, defined during device configuration
Scenarios configuration	dynamic, exploiting non-standard inferences	static, defined during network configuration	static, defined during network configuration	dynamic, exploiting rule-based reasoning	static, based on an ECA rule engine
Service composition	yes, through distributed covering	no	no	no	no
Message data format	RDF Turtle, JSON-LD, OWL 2	proprietary, according to KNX spec.	proprietary, XML-based according to LonTalk spec.	OWL 2	XML
Standardised framework interface	LDP-CoAP RESTful interface	KNX IoT Web Services	HTTP RESTful API	WebSocket and HTTP RESTful API	HTTP RESTful API

Benefits of the devised semantic social platform were assessed in a comparison w.r.t. the following IoT-oriented frameworks in the HBA market: KNX IoT;16

¹⁶

http://www.knx.org/knx-en/Landing-Pages/KNX-IoT

IzoT Platform,17

¹⁷

http://www.echelon.com/izot-platform

originally developed by Echelon Corporation for the Industrial IoT but also exploited for building applications; Dog Gateway18

¹⁸

http://dog-gateway.github.io/

[9]; Eclipse SmartHome.19

¹⁹

http://www.eclipse.org/smarthome/index.html

Table 6 highlights that only the proposed approach combines fitness for resource-constrained environments (by using CoAP and a P2P architecture), expressiveness of device modeling (by exploiting RDF and OWL 2) and support for both exact and approximated matches, with formally grounded service composition.

7. Conclusion and future work

This paper introduced a novel semantic-based framework for Social Internet of Things, particularly useful for home and building automation but inherently general-purpose. The proposal adopted a decentralized service-oriented architecture to manage, publish, discover and compose semantically annotated service/resource descriptions. It adopted LDP-CoAP to join the benefits of efficient RESTful machine-to-machine communication and structured Linked Data organization. Non-standard, non-monotonic inferences enabled semantic matchmaking for discovery with support for approximate matches, logic-based ranking and composition via request covering. The framework was developed on a multi-protocol HBA testbed with single-board computers and embedded home devices, exhibiting effectiveness in AmI scenarios.

Future work includes a wider testbed implementation and experimentation, to validate scalability of the proposal in very large object networks. Moreover, heuristics governing decisions about the creation and removal of friend/follower relationships will be explored, including behaviors based on agents’ past experience, possibly by means of machine learning techniques. A similar approach can be adopted to endow social objects with proactive adaptivity to environmental modifications.

A not negligible aspect to be further investigated is related to cybersecurity risks of the proposed approach: trust elements are strongly coupled to the need for a device to prove its own identity to their potential friends. This becomes even more relevant when devices networks increase their dimension, functions and population.

Finally, additional message propagation models based on different event priorities will be investigated along with further object interaction schemes according to the Linked Data Notifications protocol [13].

References

Agarwal,

Gómez Fernandez,

Elsaleh,

Gyrard,

Lanza,

Sánchez,

Georgantas and

Issarny, Unified IoT ontology to enable interoperability and federation of testbeds, in: 3rd IEEE World Forum on Internet of Things, WF-IoT 2016, Reston, VA, USA, December 12–14, 2016, IEEE Computer Society, 2016, pp. 70–75. doi:10.1109/WF-IoT.2016.7845470.

Atzori,

Iera and

Morabito, From “smart objects” to “social objects”: The next evolutionary step of the Internet of things, IEEE Communications Magazine52(1) (2014), 97–105. doi:10.1109/MCOM.2014.6710070.

Atzori,

Iera,

Morabito and

Nitti, The social Internet of things (siot) – when social networks meet the Internet of things: Concept, architecture and network characterization, Computer Networks56(16) (2012), 3594–3608. doi:10.1016/j.comnet.2012.07.010.

Banage ,

T.G.S.

Kumara,

Paik and

Chen, Web-service clustering with a hybrid of ontology learning and information-retrieval-based term similarity, in: 2013 IEEE 20th International Conference on Web Services, Santa Clara, CA, USA, June 28–July 3, 2013, IEEE Computer Society, 2013, pp. 340–347. doi:10.1109/ICWS.2013.53.

Bermúdez-Edo,

Elsaleh,

P.M.

Barnaghi and

K.L.

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 Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), Toulouse, France, July 18–21, 2016, IEEE Computer Society, 2016, pp. 90–97. doi:10.1109/UIC-ATC-ScalCom-CBDCom-IoP-SmartWorld.2016.0035.

Biamino, A semantic model for socially aware objects, Advances in Internet of Things2(3) (2012), 47–55. doi:10.4236/ait.2012.23006.

Bizios, Architecture Reading Lists and Course Outlines, Eno River Press, 1998. ISBN 978-0-88-024155-7.

Bojars,

J.G.

Breslin and

Decker, Porting social media contributions with SIOC, in: Recent Trends and Developments in Social Software – International Conferences on Social Software, BlogTalk 2008, Cork, Ireland, March 3–4, 2008, and BlogTalk 2009, Jeju Island, South Korea, September 15–16, 2009. Revised Selected Papers,

J.G.

Breslin,

T.N.

Burg,

Kim,

Raftery and

Schmidt, eds, Lecture Notes in Computer Science, Vol. 6045, Springer, 2009, pp. 116–122. doi:10.1007/978-3-642-16581-8_12.

Bonino,

Castellina and

Corno, The DOG gateway: Enabling ontology-based intelligent domotic environments, IEEE Transactions on Consumer Electronics54(4) (2008), 1656–1664. doi:10.1109/TCE.2008.4711217.

10.

Bormann,

A.P.

Castellani and

Shelby, CoAP: An application protocol for billions of tiny Internet nodes, IEEE Internet Computing16(2) (2012), 62–67. doi:10.1109/MIC.2012.29.

11.

Bormann and

Shelby, Block-Wise Transfers in the Constrained Application Protocol (CoAP). RFC 7959, August 2016. doi:10.17487/RFC7959.

12.

Bove, Object (b)logging: Semantically rich context mining and annotation in pervasive environments, in: Daniela de Venuto, Editor, Proceedings of the 2015 6th IEEE International Workshop on Advances in Sensors and Interfaces (IWASI), Galipoli, Italy, June 18–19, 2015, IEEE, 2015, pp. 210–215. doi:10.1109/IWASI.2015.7184965.

13.

Capadisli,

Guy,

Lange,

Auer,

A.V.

Sambra and

Berners-Lee, Linked data notifications: A resource-centric communication protocol, in: The Semantic Web – 14th International Conference, ESWC 2017, Proceedings, Part I, Portorož, Slovenia, Slovenia, May 28–June 1, 2017,

Blomqvist,

Maynard,

Gangemi,

Hoekstra,

Hitzler and

Hartig, eds, Lecture Notes in Computer Science, Vol. 10249, Springer, 2017, pp. 537–553. doi:10.1007/978-3-319-58068-5_33.

14.

Carothers and

Prud’hommeaux (eds), RDF 1.1 Turtle: Terse RDF Triple Language. W3C Recommendation, 25 February 2014. http://www.w3.org/TR/turtle/.

15.

Chang,

S.N.

Srirama and

Mass, A middleware for discovering proximity-based service-oriented industrial Internet of things, in: 2015 IEEE International Conference on Services Computing, SCC 2015, New York City, NY, USA, June 27–July 2, 2015, IEEE Computer Society, New York City, NY, USA, 2015, pp. 130–137. doi:10.1109/SCC.2015.27.

16.

Compton,

P.M.

Barnaghi,

Bermudez,

Garcia-Castro,

Ó.

Corcho,

S.J.D.

Cox,

Graybeal,

Hauswirth,

C.A.

Henson,

Herzog,

V.A.

Huang,

Janowicz,

David Kelsey,

Le Phuoc,

Lefort,

Leggieri,

Neuhaus,

Nikolov,

K.R.

Page,

Passant,

A.P.

Sheth and

Taylor, The SSN ontology of the W3C semantic sensor network incubator group, Journal of Web Semantics17 (2012), 25–32. doi:10.1016/j.websem.2012.05.003.

17.

Cong and

Fernández Gil, Enabling web service discovery in heterogeneous environments, International Journal of Metadata, Semantics and Ontologies8(2) (2013), 106–118. doi:10.1504/IJMSO.2013.056604.

18.

D.N.

Crowley,

Curry and

J.G.

Breslin, Leveraging social media and iot to bootstrap smart environments, in: Big Data and Internet of Things: A Roadmap for Smart Environments,

Bessis and

Dobre, eds, Studies in Computational Intelligence, Vol. 546, Springer, 2014, pp. 379–399. doi:10.1007/978-3-319-05029-4_16.

19.

Dibowski and

Kabitzsch, Ontology-based device descriptions and device repository for building automation devices, EURASIP Journal on Embedded Systems2011 (2011), 623461. doi:10.1155/2011/623461.

20.

Dublin Core Metadata Initiative, Dublin Core Metadata Element Set, Version 1.1: Reference Description. DCMI Recommendation, 2012-06-14. http://dublincore.org/documents/dces/.

21.

Evchina,

Puttonen,

Dvoryanchikova and

J.L.

Martínez Lastra, Context-aware knowledge-based middleware for selective information delivery in data-intensive monitoring systems, Engineering Applications of Artificial Intelligence43 (2015), 111–126. doi:10.1016/j.engappai.2015.04.008.

22.

B.R.

Ferrer,

Iarovyi,

Gonzalez,

Lobov and

J.L.

Martinez Lastra, Management of distributed knowledge encapsulated in embedded devices, International Journal of Production Research54(18) (2015), 5434–5451. doi:10.1080/00207543.2015.1120902.

23.

S.N.

Han,

G.M.

Lee and

Crespi, Semantic context-aware service composition for building automation system, IEEE Transactions on Industrial Informatics10(1) (2014), 752–761. doi:10.1109/TII.2013.2252356.

24.

Hartke, Observing Resources in the Constrained Application Protocol (CoAP). RFC 7641, September 2015. doi:10.17487/RFC7641.

25.

Hitzler,

Krötzsch,

Parsia,

P.F.

Patel-Schneider and

Rudolph (eds), OWL 2 Web Ontology Language Primer (Second Edition). W3C Recommendation, 11 December 2012. http://www.w3.org/TR/owl2-primer.

26.

Horridge and

Bechhofer, The OWL API: A Java API for OWL ontologies, Semantic Web2(1) (2011), 11–21. doi:10.3233/SW-2011-0025.

27.

Horridge and

P.F.

Patel-Schneider, OWL 2 Web Ontology Language Manchester Syntax (Second Edition). W3C Working Group Note, 11 December 2012. https://www.w3.org/TR/owl2-manchester-syntax/.

28.

Hussein,

S.N.

Han,

G.M.

Lee,

Crespi and

Bertin, Towards a dynamic discovery of smart services in the social Internet of things, Computers & Electrical Engineering58 (2017), 429–443. doi:10.1016/j.compeleceng.2016.12.008.

29.

Jadhav and

S.C.

Patil, Wireless home monitoring using social Internet of things (SIoT), in: International Conference on Automatic Control and Dynamic Optimization Techniques (ICACDOT 2016), 9th & 10th September 2016, IEEE, 2016, pp. 925–929. doi:10.1109/ICACDOT.2016.7877722.

30.

K.P.

Joshi,

Yesha and

Finin, Automating cloud services life cycle through semantic technologies, IEEE Transactions on Services Computing7(1) (2014), 109–122. doi:10.1109/TSC.2012.41.

31.

Kastner,

Jung and

Krammer, Future trends in smart homes and buildings, in: Industrial Communication Technology Handbook,

Zurawski, ed., 2nd edn, CRC Press/Taylor & Francis, 2014, pp. 1483–1502, chapter 59. ISBN 978-1-4822-0733-0.

32.

Kastner,

Krammer and

Fernbach, State of the art in smart homes and buildings, in: Industrial Communication Technology Handbook,

Zurawski, ed., 2nd edn, CRC Press/Taylor & Francis, 2014, pp. 1415–1434, chapter 55. ISBN 978-1-4822-0733-0.

33.

Kovatsch,

Lanter and

Shelby, Californium: Scalable cloud services for the Internet of things with coap, in: 4th International Conference on the Internet of Things, IOT 2014, Cambridge, MA, USA, October 6–8, 2014, IEEE, 2014, pp. 1–8. doi:10.1109/IOT.2014.7030106.

34.

Lanthaler,

Sporny and

Kellogg, JSON-LD 1.0. W3C Recommendation, W3C, January 2014, http://www.w3.org/TR/json-ld/.

35.

Lin and

Lu, Why people use social networking sites: An empirical study integrating network externalities and motivation theory, Computers in Human Behavior27(3) (2011), 1152–1161. doi:10.1016/j.chb.2010.12.009.

36.

Loseto,

Ieva,

Gramegna,

Ruta,

Scioscia and

Di Sciascio, Linked data (in low-resource) platforms: A mapping for constrained application protocol, in: The Semantic Web – ISWC 2016 – 15th International Semantic Web Conference, Proceedings, Part II, Kobe, Japan, October 17–21, 2016,

P.T.

Groth,

Simperl,

A.J.G.

Gray,

Sabou,

Krötzsch,

Lécué,

Flöck and

Gil, eds, Lecture Notes in Computer Science, Vol. 9982, 2016, pp. 131–139. doi:10.1007/978-3-319-46547-0_14.

37.

Papadopoulou,

Gallacher,

N.K.

Taylor,

Howard Williams,

F.R.

Blackmun,

I.S.

Ibrahim,

Yii Lim,

Mimtsoudis,

Skillen and

Whyte, Combining pervasive computing with social networking for a student environment, in: Proceedings of the Twelfth Australasian Symposium on Parallel and Distributed Computing (AusPDC 2014), Auckland, New Zealand,

Javadi and

S.K.

Garg, eds, CRPIT, Vol. 152, Australian Computer Society, 2014, pp. 11–19, http://crpit.com/confpapers/CRPITV152Papadopoulou.pdf .

38.

Ruta,

Di Sciascio and

Scioscia, Concept abduction and contraction in semantic-based P2P environments, Web Intelligence and Agent Systems9(3) (2011), 179–207. doi:10.3233/WIA-2011-0214.

39.

Ruta,

Scioscia and

Di Sciascio, Enabling the semantic web of things: Framework and architecture, in: Sixth IEEE International Conference on Semantic Computing, ICSC 2012, Palermo, Italy, September 19–21, 2012, IEEE Computer Society, 2012, pp. 345–347. doi:10.1109/ICSC.2012.42.

40.

Ruta,

Scioscia,

Loseto and

Di Sciascio, Semantic-based resource discovery and orchestration in home and building automation: A multi-agent approach, IEEE Transactions on Industrial Informatics10(1) (2014), 730–741. doi:10.1109/TII.2013.2273433.

41.

Ruta,

Scioscia,

Loseto,

Gramegna,

Ieva and

Di Sciascio, Mini-ME 2.0: Powering the semantic web of things in: Informal Proceedings of the 3rd International Workshop on OWL Reasoner Evaluation (ORE 2014) Co-Located with the Vienna Summer of Logic (VSL 2014), Vienna, Austria, July 13, 2014,

Bail,

Glimm,

Jiménez-Ruiz,

Matentzoglu,

Parsia and

Steigmiller, eds, CEUR Workshop Proceedings, Vol. 1207, CEUR-WS.org, 2014, pp. 8–15, http://ceur-ws.org/Vol-1207/paper_6.pdf .

42.

Ruta,

Scioscia,

Loseto and

E.D.

Sciascio, KNX, a worldwide standard protocol for home and building automation: State of the art and perspectives, in: Industrial Communication Technology Handbook,

Zurawski, ed., 2nd edn, CRC Press/Taylor & Francis, 2014, pp. 1463–1481, chapter 58.

43.

Ruta,

Zacheo,

L.A.

Grieco,

Di Noia,

Boggia,

Tinelli,

Camarda and

Di Sciascio, Semantic-based resource discovery, composition and substitution in IEEE 802.11 mobile ad hoc networks, Wireless Networks16(5) (2010), 1223–1251. doi:10.1007/s11276-009-0199-5.

44.

Sadri, Ambient intelligence: A survey, ACM Computing Surveys43(4) (2011), 36:1–36:66. doi:10.1145/1978802.1978815.

45.

Scioscia,

Ruta,

Loseto,

Gramegna,

Ieva,

Pinto and

Di Sciascio, A mobile matchmaker for the ubiquitous Semantic Web, International Journal on Semantic Web and Information Systems10(4) (2014), 77–100. doi:10.4018/ijswis.2014100104.

46.

Shadbolt,

Berners-Lee and

Hall, The semantic web revisited, IEEE Intelligent Systems21(3) (2006), 96–101. doi:10.1109/MIS.2006.62.

47.

Shelby, Constrained RESTful Environments (CoRE) Link Format, RFC6690 (2012). doi:10.17487/RFC6690.

48.

Speicher, John Arwe, and Ashok Malhotra, editors. Linked Data Platform 1.0. W3C Recommendation, 26 February 2015, https://www.w3.org/TR/ldp/.

49.

Voutyras,

Bourelos,

S.V.

Gogouvitis,

Kyriazis and

T.A.

Varvarigou, Social monitoring and social analysis in Internet of things virtual networks, in: 18th International Conference on Intelligence in Next Generation Networks, ICIN 2015, Paris, France, February 17–19, 2015, IEEE, 2015, pp. 244–251. doi:10.1109/ICIN.2015.7073838.

TBox $T$ axioms	$LargeCapacity ⊑ \neg RegularCapacity$
TBox $T$ axioms	$WasherDrier \equiv WashingMachine ⊓ Drier$
Request	$R_{1} \equiv WasherDrier ⊓ LargeCapacity$
Resources	$S_{1} \equiv WashingMachine$
Resources	$S_{2} \equiv WasherDrier ⊓ RegularCapacity$
Abduce( $R_{1}$ , $S_{1}$ , $T$ )	$H \equiv Drier ⊓ LargeCapacity$
Contract( $R_{1}$ , $S_{2}$ , $T$ )	$⟨ G, K ⟩ = ⟨ LargeCapacity, WasherDrier ⟩$

				Processing Time (ms)

ID	Size (Byte)	Tagged Services	Like Value	Rasp. Pi	Intel Edison	UDOO
R1	1381	1	28.57	89.2	20.8	12.8
R2	1967	2	61.54	122.2	30.8	14.2
R3	2468	3	73.68	132.0	37.6	17.8
R4	2902	4	79.17	140.2	47.0	18.0
R5	3309	5	82.76	146.4	64.4	23.2
R6	3651	6	84.85	154.6	78.8	29.8
R7	4202	7	87.18	160.8	81.4	35.4

Social Internet of Things for domotics: A knowledge-based approach over LDP-CoAP

Abstract

Keywords

1. Introduction

1 Internet Engineering Task Force, https://www.ietf.org.

3.1. Knowledge-based architecture

3.1.1. Service-oriented architecture

3.1.2. Semantic matchmaking

4.1. Framework implementation with LDP-CoAP

3 http://www.gewiss.com

References

¹
Internet Engineering Task Force, https://www.ietf.org.

³
http://www.gewiss.com