## 4 Social Awareness in the Semantic Web of Things
### Cooperative Service/Resource Discovery  
The social network of things exists to support cooperative service discovery and configuration. Exploiting the non-standard inferences recalled in Section 2, whenever a device requires new services or a change to its current settings, its request is formalized as a DL annotation \(R\). The proposed framework does not constrain _when_ a device should issue a request, neither _how_ to derive a proper request annotation. As outlined in [7], smart objects are expected to execute data mining and inference on perceptions collected from on-board or nearby sensors in order to characterize the environment and detect relevant events and changes (details on the data mining aspect are out of the scope of this paper). When the request is formulated, a cooperative multi-hop discovery process starts, using _Concept Covering_ to satisfy it as much as possible through aggregation of available services/resources. Figure 4 shows the sequence diagram for a canonical discovery example. Three devices are considered: \(D_{1}\) is the requester and \(D_{2}\) is a friend to both \(D_{1}\) and \(D_{3}\). When \(D_{1}\) generates its request \(R_{1}\), it will post it on its wall (post \(P_{1}\)). A local covering process starts, where \(D_{1}\) exploits its embedded matchmaking engine to cover \(R_{1}\) as much as possible with the services it can access: this set is formed by \(D_{1}\)'s own services and the ones belonging to \(D_{1}\)'s friends, which were read via LDP-CoAP at friendship establishment: the CoAP  
Figure 3: Reference ontology-based data modeling. Observe option [48] is adopted to notify the device whenever a friend's service set changes. The covering result consists of a set of selected services and possibly the uncovered part \(U_{1}\) of the request. This information is appended to \(P_{1}\) as comment \(C_{1}\) on \(D_{1}\)'s wall, along with the covering degree associated with \(P_{1}\) as the _like_ value \(L_{1}\). If there is some uncovered part \(U_{1}\), then \(D_{1}\) picks some friends to help find further services. Selection criteria include the number of friend's services referring to the same ontology of the request and historical performance data concerning the number and relevance of retrieved services, as well as communication latency and bandwidth. In the reference figure, \(D_{1}\) picks \(D_{2}\) and POSTs a new post \(P_{2}\) on \(D_{2}\)'s wall, attaching \(U_{1}\) as the new request. \(D_{2}\) computes semantic matchmaking using its friends' service descriptions while excluding its own services as they have already been considered by \(D_{1}\). The new covering process yields (possibly) further selected services, a new (smaller) uncovered part \(U_{2}\) and an updated (higher) like value. \(D_{2}\) adds this result as a comment to \(P_{2}\). Complying with LDN, this update is notified to \(D_{1}\) through the Observe CoAP pattern (actually, a node writing a post on a friend's wall is automatically added to the list of CoAP observers for the post, so that it is notified when a comment is added; this is an extension of the standard CoAP Observe pattern, which is normally available for GET requests only; otherwise, after a POST on a friend's wall, a further GET request would be needed to start observing). Then, \(D_{1}\) GETs the content of the comment and updates the like value associated with its own original request on its own wall. Supposing the request has not been fully covered yet, \(D_{2}\) repeats the process recursively, writing a new post \(P_{3}\) on its friend \(D_{3}\)'s wall (which is not a friend of \(D_{1}\)). \(D_{3}\) executes matchmaking with cached service descriptions of its friends (except \(D_{2}\)). The outcome leads to a comment and updated like value on \(P_{3}\): they are notified to \(D_{2}\), which GETs the content of the comment  
Figure 4: Distributed service/resource discovery. and reports it as a new comment \(C_{2}\) on post \(P_{2}\) into its own wall. This in turn activates notification for \(D_{1}\), which GETs the comment.