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
Eventually everything connects – people, ideas, objects. The quality of the connections is the key to quality per se.
Attributed to Charles Eames [ 7 ]
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.
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.
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].
IoT/HBA entities, social features and semantic capabilities
IoT/HBA entities, social features and semantic capabilities
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.
In what follows the proposed framework, architecture and technologies are described.
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.
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.
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
Example descriptions for non-standard reasoning tasks
Example descriptions for non-standard reasoning tasks
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
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(
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
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
The reader is referred to [45] for algorithms and further considerations on Concept Abduction and Contraction, as well as to [41] for Concept Covering.
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:

Sequence diagram for social agent relationships: (a) friend; (b) follower.
Friend: a bidirectional relationship where nodes
Follower: a unidirectional relationship where a node
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,
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
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
When a node
If
If
When

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

Ontology-based modeling of a device profile.
Available at
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.

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.

Wall and posts.

Comment to a post.
LDP-CoAP interface of a social device
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.
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.

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
KNX devices in the testbed
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.
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
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.
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:
The following embedded boards were used to implement the social devices:
Raspberry Pi Model B,9
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
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
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).

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 1 and H 2 , include a set of semantic-enabled devices forming a home social network. In particular, H1 is configured with an alarm system (AS), a rolling shutter controller (SC1), an air conditioner (AC1) and a dimmer lamp (L1). A weather station (WS), a rolling shutter controller (SC2), an air conditioner (AC2) and a dimmer lamp (L2) are installed in H2 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.

Post content (i.e., request) written by the alarm system.
It is evening, there is no one in the apartment H 1 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, SC1 and L1 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

Shutter controllers SC1 and SC2 service annotations.

Dimmer lamps L1 and L2 service annotations.

Simultaneously, devices within the apartment H2 could exploit the knowledge shared by the home social network in H1 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 H2 a Concept Covering process involving the services exposed by the friends of WS (SC2 and AC2), which are listed respectively in Fig. 11 and Fig. 15.

OWL annotation of the uncovered part of AS_Request.

Air conditioners AC1 and AC2 service annotations.
Only the Full_Close service, provided by SC2, 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 SC2, since it provided the highest contribution to covering in the initial step, and posts on the wall of SC2 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. SC2 in turn receives the message, starts a covering process involving the services exposed by L2 (Fig. 12) and selects the Lamp_On functionality, which completely covers the remaining part of the initial request. SC2 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.

OWL annotation of the uncovered part of WS_Request.

Processing and communication time for the social tasks.
It is useful to point out how social capabilities allowed apartment H2 to compensate for the lack of an alarm system, taking advantage of the sensing capabilities of the one in H1 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.
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.

Processing time for the Concept Covering task.
Request Dataset
Request Dataset
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.
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.

Memory usage.

Size of encoded payload messages.
Comparison with current IoT-oriented frameworks for HBA
Comparison with current IoT-oriented frameworks for HBA
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
IzoT Platform,17 originally developed by Echelon Corporation for the Industrial IoT but also exploited for building applications; Dog Gateway18 [9]; Eclipse SmartHome.19 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.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].
