Presentation of “A Semantic Service Creation Platform for Social IoT”

This blog presents our study on SIoT (Social IoT) and SCE.

  1. Context

Nowadays, more and more people talk about social network and Internet of Things (IoT).

This paper firstly introduces the SIoT, a paradigm, called the Social Internet of Things, which is a converging point for people, Web service, and devices. Since, objects can not only be part of traditional networks (IoT), they can also form a social Network (SN) of smart connected objects that tends to mimic human behavior towards a scalable and more effective service.


To achieve this service, automation is required to integrate SIoT to real life and ontologies are used to semantically describe Web service and enable the automatic invocation and composition of these services. This’s why, Semantic Web (SW) services are firstly considered as a good approach to manage SIoT services.  But the problem of SW services is that, over the last decade, these services have not yet been realized in current Web due to its complexity and the absence of attractive uses cases.

The goal of this paper, is to propose a SN, which is a Service Creation Environment (SCE), and in which users can create event-based actions involving their devices, friends, Semantic Web services as well as several Web APIs (e.g. Google,  Facebook, Twitter APIs), finally, to promote SIoT and bring SW applications into a familiar and easy-to-use platform.

  1. SCE: People, Web services and Devices — Communicate and Create

2.1 SN as a Service Creation Environment: Social things

The paper proposes the social network itself as a SCE. Inside SCE, devices and web services become social since they are integrated inside the SN, as a result, they are  both defined as “social thing”. And each social thing has a profile into the SN, and provides a graphical interface to users.

SIoT

Fig 1: Inside the user’s SN, there are people and social things(Web services and devices)

2.2 SN as a Service Creation Environment: Gateway

Through the proposed SN (SCE), users can browse their social things’ walls(interfaces) to check their status  or send commands. What’s more, users can also create Condition-Actions(CA) rules that invoke certain actions among social things.

To enable the above interactions, the SN needs a gateway with semantic RESTful APIs to receive and send commands/informations among social things and user.  The higher lever will process all requests, which is presented in architecture part.

2.3 SN as a Service Creation Environment: Functionality

The proposed SCE provides a user-friendly graphical interface that allows users to interact with their things and to create their own personalized automatic services, which containing the following functionalities:

  • Browse social things
  • Get the latest information from a social thing
  • Change the status of a thing
  • Create automatic actions interconnecting people and social things
  1. Architecture and Components

architecture

Ontology-Based Layer is the highest layer of the structure. Its 3 components are strongly relying on the ontology database.

  • Recommendation resoner:finds the recommandation about the possible automatic actions for users
  • Profile handler:manage the profils of users and social things
  • Rules handler:controls the event-triggered actions created by users

Control Layer contains the ontology data, a database of action rules and also 2 modules for the performance of the SCE. Ontology database is very important in the model because it defines the classes of information and their relationships in the system. Without it, we could not communicate with web services and users’ devices.

  • Context handler: gets newest informations from the external resources and update the ontology database.
  • Command executor: interacts with communication layer to execute user commands

Communication layer connect with the external services by means of RESTful interface. In 2013, 63% of the web services are RESTful based. We could use the ontologie Hydra to describe RESTful APIs and JSON-LD is Hydra’s serialization format. In communication layer, it is possible to communicate with the gateway or with a third-party Web Service. If the Service is not semantically annotated,such as Google Calendar, we might develop a social wrapper for it so it could be integrated into the system.

  • Semantic RESTful client: use to connect with the user by RESTful interface
  • Gateway:help the social network to  get information of user’s devices and control the devices. It also translate the data between ontological model to devices.
  • Third-party RESTful APIs : the others web services. (semantically annotated or not)

 

Authors:

Jiaying HUANG

Kai LI

Sining QU

Ce contenu a été publié dans Non classé, avec comme mot(s)-clé(s) . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *