D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.2...2.1.2 Recommendation system platforms _ 10 2.1.3 Chatbot _ 18 ... customized/personalized and context-aware applications

D3.2

Integrated IoT platforms – Release 2

Editor: Rémi Druilhe (CEA)

Submission date:

Version 1.0

Contact: [email protected]

This document describes the second version of the Wise-IoT platform (architecture, concepts, first tests) including

the integrated platforms and components developed by the Wise-IoT consortium.

Editor: Rémi Druilhe, CEA

Deliverable nature: O

Dissemination level: PU

Contractual/actual delivery date: M16 M18

Disclaimer

This document contains material, which is the copyright of certain WISE-IOT consortium parties, and

may not be reproduced or copied without permission.

All WISE-IOT consortium parties have agreed to full publication of this document.

Neither the WISE-IOT consortium as a whole, nor a certain part of the WISE-IOT consortium, warrant

that the information contained in this document is capable of use, nor that use of the information is free

from risk, accepting no liability for loss or damage suffered by any person using this information.

This project has received funding from the European Union’s H2020 Program for research, technological

development and demonstration under grant agreement No 723156, the Swiss State Secretariat for

Education, Research and Innovation (SERI) and the South-Korean Institute for Information &

Communications Technology Promotion (IITP).

Copyright notice

2016 Participants in project WISE-IOT

Table of contents

Executive summary _________________________________________ 4

Glossary _____________________________________________________ 5

1 Introduction ______________________________________________ 6

2 The Wise-IoT integrated platform R2 ____________________ 8

2.1 Common platforms ______________________________________________ 8

2.1.1 The Federation Broker system ____________________________________ 9

2.1.2 Recommendation system platforms _____________________________ 10

2.1.3 Chatbot ___________________________________________________________ 18

2.2 IoT Devices _____________________________________________________ 22

2.2.1 LoRa tracker ______________________________________________________ 22

2.2.2 Crowd detector ___________________________________________________ 23

2.2.3 PIQ Robot _________________________________________________________ 24

2.3 The integration of the IoT platforms in the testbeds _________ 27

2.3.1 The smart cities testbeds ________________________________________ 27

2.3.2 The smart skiing testbeds ________________________________________ 31

2.3.3 The smart fitness testbed ________________________________________ 33

3 Interoperability tests ____________________________________ 35

3.1 Technical interoperability tests _______________________________ 35

3.1.1 Existing tests _____________________________________________________ 35

3.1.2 Futures tests _____________________________________________________ 36

3.2 Semantic interoperability tests ________________________________ 37

3.2.1 Overview __________________________________________________________ 37

3.2.2 Current Status and Roadmap _____________________________________ 38

4 Conclusion ______________________________________________ 39

5 References ______________________________________________ 40

Executive summary

This deliverable describes the second release of the Wise-IoT system integrating the platforms from the

partners. This integration is the first step towards the interconnection of various and heterogeneous

platforms: the Wise-IoT integrated platform aims at evolving and integrating off-the-shelf platforms in

order, for the end user, to consume data seamlessly of its location and of the platform providing it.

This second release proposes to extend the first release by creating a common system, including the

Integration and Management layer, the Information Access layer and the Knowledge Processing layer

from the D1.2 [2] and using it in the various and environment-dependents testbeds, i.e., smart city,

smart skiing and fitness.

The platforms integrated in this version have been detailed in the D3.1 [7]. Each platform has been

developed by the different partners prior to the project, without concertation, leading to an

incompatibility between the platforms and their respective protocols. The Morphing Mediation

Gateway, developed in the WP2, is in charge of the translation between those platforms, i.e., the specific

environment of the testbed and the common system of Wise-IoT.

The second section of this deliverable discusses about the ongoing interoperability test developments

that will lead to a functional and testable interoperability between the Wise-IoT system and the

testbeds. Those tests, i.e., technical and semantic tests, introduced in this document, will be fully

detailed in the D3.3.

Finally, all of the platforms will be deployed by the different partners on the testbeds to gather data and

allow the developers to create end users applications that will be used in the various use cases of the

project. The integration of the platforms are the first step towards the development of the use cases.

Glossary

Term or Abbreviation Definition (Source)

API Application Programming Interfaces

ASM Adaptive Semantic Module

CAG Context-Aware Auxiliary Gateway

CB Context Broker

GE Generic Enabler

IAL Information Access Layer

LoRa Long Range

MAPHIS Most Advanced Personalized Healthcare Intelligent Service)

MQTT MQ Telemetry Transport

MMG Morphing Mediation Gateway

NFC Near Field Communications

NGSI Next Generation Service Interface

OCEAN Open allianCE for iot stANdard

OLIOT Open Language for Internet of Things

OTAP Over-The-Air Programming

RDF Resource Description Framework

REST Representational State Transfer

RFID Radio-Frequency Identification

ZIG Z-Wave – oneM2M Interworking Gateway

Introduction

6

1 Introduction

The Wise-IoT project is composed of various partners owning a platform which are not compatible

between each other. This means that to create an application, the developer have to deal with various

API, technologies and semantic models. A similar data can be modeled in different way, depending on

the platform providing this information. This is an obstacle to the use of the data that is produced by

the IoT devices. But it is also a problem when a developer wants to create a cross-domain application,

e.g., an application targeting the smart city and the smart skiing resort.

To solve this issue, the Wise-IoT project proposes the Morphing Mediation Gateway that aims at

translating data between each platform (cf. D2.2 [3] for further details). For the developers of

applications, this means that they have to consider only one API, only one technology and only one

semantic model because the MMG will translate the data they need into the semantic model they use.

This deliverable describes the Wise-IoT system, i.e., the integration of the various platforms from the

partners. In this document, it is assumed that a platform can be an IoT device, i.e., hardware and

software module that is deployed on the field and provide data, an IoT platform, i.e., the software in

charge of gathering data from the devices, or a data processing platform, i.e., the software in charge of

processing the data to provide new data. The Table 1, Table 2 and Table 3 detail the platforms used in

this project.

Table 1 - List of the integrated devices

Devices Provider Deployment

LoRa band Solu-M Smart cities and smart skiing use cases

Crowd detector NEC Smart cities and smart skiing use cases

PIQ Robot PIQ Smart skiing and fitness use cases

Table 2 - List of the integrated IoT platforms

IoTPlatforms Provider Deployment

oneM2M Mobius KETI Busan, Santander

SmartSantander with Orion Context Broker

UC Santander

sensiNact CEA Chamrousse

oneM2M Insator Samsung SDS Busan, Alpensia

GS1 Oliot KAIST Busan

NEConfMan NEC Santander

Aeron Broker NEC Santander

MAPHIS KNU Daegu

Table 3 - List of the integrated data processing platforms

Data processing Platforms Provider Deployment

IoT Recommender IMT-TSP Smart cities and smart skiing use cases

Adherence Monitor FHNW Smart cities and smart skiing use cases

Web-based ontology and linked-data validator

EGM Smart cities and smart skiing use cases

Trust Management LJMU Smart cities and smart skiing use cases

Chatbot 1thefull Smart cities and fitness use cases

Introduction

7

From the previous deliverable, the D3.1 [7], the consortium worked on a more generic version of the

Wise-IoT system enabling to re-use platforms in all of the testbeds, i.e., the “common platforms”. It

enables to deploy a testbed by reusing part of the platforms provided by the partners and let the owner

of the testbed deploy specific platform at the edge to handle the heterogeneity of the environment and

the specificities of the use cases.

This document is structured as follow: Section 2 completes the description of the platforms provided by

the partners in the D3.1 [7] and explains how they have been integrated all together. In detail, section

2.1 describes the common platforms used in most of the testbeds of the project. Section 2.2 details the

IoT devices deployed in the testbeds. And section 2.3 presents the specifics platforms used in each

testbed enabling to gather data from the IoT device and send them to the upper layers of the Wise-IoT

system. Section 3 outlines the first interoperability tests that are under development to validate the

integration of each platform in the Wise-IoT system. Finally, section 4 concludes this document.

The Wise-IoT integrated platform R2

8

2 The Wise-IoT integrated platform R2

2.1 Common platforms

To understand how the platforms, i.e., IoT devices, IoT platforms and data processing platforms, are

integrated, it is important to propose a quick overview of the Wise-IoT architecture (cf. Figure 1). The

detail of this architecture is available in the D1.2 [2].

oneM2M Mobius is used in the Integration and Management Layer because it provides all of the

functionalities for IoT devices, including registration, data management and repository, device

management, security, communication management and delivery handling, discovery, subscription and

notification, etc. Refering to the device management, the D2.4 [4] discusses the oneM2M resources

architecture and their interactions. In the other hand, FIWARE enables smarter, more

customized/personalized and context-aware applications and services by the means of a set of Generic

Enablers (GEs) able to gather, publish, exchange, process and analyze massive data in a fast and efficient

way.

The Adaptive Semantic Module (ASM) component of the Morphing Mediation Gateway (MMG)

component dynamically discovers semantically annotated information in oneM2M system. The

semantic annotation is attached to a oneM2M container resource that contains sensor readings as

content instances. The ASM subscribes to the sensor readings and whenever a new sensor reading

becomes available, it uses its value and meta information together with the semantic annotation to

create a NGSI data structure that is used to update a NGSI-based FIWARE Generic Enabler (GE), e.g. the

Orion Context Broker or the Aeron IoT Broker.

Figure 1 - Overview of the architecture of the Wise-IoT integrated platform

This architecture is a template for the implementation and integration of each platform used in the

various testbeds, i.e., Santander, Busan, Chamrousse, Alpensia and Daegu. It means, that a common


9

infrastructure is used for each testbeds. This deliverable presents the real integration for each testbeds

based on this template.

For this second release of the Wise-IoT platform, we extended the integration to the others platforms

of the partners, e.g., sensiNact, GS1, LoRa, etc. The interconnection is done with the Morphing

Mediation Gateway system allowing to instantiate at runtime new semantic translation modules.

2.1.1 The Federation Broker system

The federation approach proposed in Wise-IoT to support the Service Roaming and Cross-Domain Data

Reuse Use Case (see Section 4.6 in D1.2 [2]) is based on the use of Federation IoT Brokers on the

Information Access Layer in the layered architecture view as shown in Figure 1.

The NGSI interface is suitable for enabling this architecture using two relevant concepts, the use of

scopes, in this case location scopes, and the registration of information source using different

granularities. Figure 2 shows a deployment example with a Federation IoT Broker.

Figure 2 - Federation Broker Scenario

The main idea, from an application perspective, is that the application can request all information

regardless of location using one single point of access: the Federation IoT Broker. For example, to

request crowd information, it would query or subscribe to information providing a location scope. If the

user is in Santander, the location scope would cover an area in Santander and the user would receive

the crowd information for this area. If the same user moves to Busan, the application request would be

the same except for the requested location scope, which would now cover an area in Busan and the user

would receive the crowd information for this area.

To enable this, the local brokers are registered as information sources with the federation-level registry,

providing the area for which they can provide information. Whereas locally, the detailed source

information is registered, i.e., each crowd detector with its ID and exact geographic location, the local

broker would register only on a type-basis with an area covering all available crowd detectors, i.e., “I

have information from crowd detectors in the area of Santander” or “I have information from crowd

detectors in Busan” – where areas are given using geographic coordinates. On a location-scoped request

from an application, the Federation IoT Broker would then discover suitable sources, i.e., local brokers,


10

that cover an area that overlaps with the one specified in the location scope and would forward the

request there, possibly aggregating results and returning these to the requesting application.

The Federation IoT Broker is realized using the Aeron IoT Broker [11] implementation that is a FIWARE

GE. The Registry is realized using the NEConfMan FIWARE GE [12]. Both FIWARE GEs are available as

open source implementation. In order to use them on the Federation Layer, the use of location scopes

is required. The other important point is the coarse-granular registration of local brokers, i.e.,

aggregating the individual entities at specific locations into a coarse-grained entity type and location

area registration. In a first step, this registration is done by a third-party application, which may also be

useful in cases, where only a subset of the locally available information is to be made available on the

federation level. Both FIWARE GEs have been extended to serve as Federation IoT Brokers in the context

of the Wise-IoT project.

The use of the Federation IoT Brokers currently has some limitations as they only support the FIWARE

NGSIv1, whereas some Orion Context Broker installations use advanced features of FIWARE NGSIv2 like

complex JSON datatypes. Also the NGSI-9 interface, required for registration and discovery, has not been

made available in a FIWARE NGSIv2 version. This means that only information compatible to FIWARE

NGSIv1, e.g., the crowd information, can be accessed using the Federation IoT Broker, but, e.g., not the

parking spot information that uses a complex JSON datatype.

The mid-term solution to this problem is the current work in the ETSI ISG CIM [13] that works on the

evolution of the NGSI interface, taking into account the requirements of distributed and federated

architecture. The goal of all participants is to upgrade their implementation to the API version defined

in ETSI ISG CIM, thus resolving the current compatibility problems and resulting limitations.

2.1.2 Recommendation system platforms

The Self-Adaptive Recommender (SAR) is the Wise-IoT platform for offering recommendations. SAR is

one of the consumers of IoT data and is used as a means to assure the quality of the data. The IoT-facing

SAR components are the IoT recommender and the Quality-of-Information (QoI) monitor. The IoT data

is consumed by the IoT recommender for offering end-users with context-based recommendations.

Quality assurance is offered by the Quality-of-Information (QoI) monitor. The analysis of these two

components allows understanding how SAR interacts with the underlying IoT platforms.

The other SAR components, the adherence monitor and the trust monitor, have a circumstantial role in

the IoT integration context. The adherence monitor is a tool used to understand the value of

recommendations, the trust monitor to understand the trust in the information and recommendations

offered to end-users. These two SAR components are end-user-facing, rather than IoT system-facing,

thus have been excluded from the discussion here.

The recommendation system (SAR) is positioned in the Knowledge Processing Layer of the Wise-IoT

architecture. As a default, the IoT recommender interacts through the SAR Façade with the FIWARE

Context Broker. As a default, the QoI monitor interacts through the SAR Façade with oneM2M Möbius.

Figure 3 illustrates the current implementation; the SAR Façade acts as a pass-through for enabling the

components to interact with the right component instances in the information access layer.


11

Figure 3 - Architecture of the SAR system

As part of the Wise-IoT experimentation, the Morphing Mediation Gateway will be used to translate

oneM2M data into a FIWARE representation. This work will enable to retrieve data from various data

sources and make them available to the IoT recommendations. The use of the QoI monitor will increase

the trust in the quality of the data.

This section summarises the integration of the IoT recommender and the QoI monitor with the

underlying IoT platforms FIWARE and Möbius.

2.1.2.1 IoT Recommender

The IoT Recommender, which is a component of Self-Adaptive Recommendation (SAR) system is

developed for rich parking and smart skiing use cases into two iterations. The first iteration is completed

in the first release of SAR in which IoT Recommender is developed for rich parking use case. In this

release, the IoT Recommender provides the recommendation of a nearest trusted parking spot and a

least crowded route from user’s current location to the recommended parking spot. Figure 4 presents

the integration and interaction of IoT Recommender with other components/platforms.


12

Figure 4 - Integration and interaction of IoT Recommender with other components/platforms.

The IoT Recommender interacts with four components: rich parking use case application, Brouter

routing engine, FIWARE Orion Context Broker and trust monitoring. When IoT Recommender receives a

request from use case application to provide a recommendation of a parking spot and a route to the

recommended parking spot from user’s current location, it firstly accesses the Context Broker to get the

data of parking spots and traffic sensors in Santander city. Subsequently, it exploits the data of parking

sensors to find the nearest available parking spot from user’s current location. Secondly, IoT

Recommender obtains the trust score for its recommended parking spot for the current user. If the trust

score meets the minimum threshold, IoT Recommender considers the selected parking spot. Otherwise,

it finds another nearest parking spot and obtains its trust score from Trust Monitoring component. It

repeatedly performs this step until it finds a parking spot which fulfils the threshold of trust score.

Thirdly, IoT Recommender uses Brouter routing engine, a third-party routing API, for getting all the

possible routes from user’s current location to the recommended parking spot and then uses the data

of traffic sensors to analyse the level of the crowd on the routes, obtained through Brouter routing

engine. Finally, IoT Recommender sends the coordinates of a parking spot and the least crowded route

to the use case application.

With the second release, the IoT recommender calculates the statistics of individual parking spots and

generate the aggregated statistics for parking areas, comprised of multiple parking spots in the

OnStreetParking. OnStreetParking is explained in detail in deliverable D2.5 [6]. This statistics will be

provided to the user to give two choices to the user: i) either get the nearest trusted parking spot from

our system or ii) decide a parking area to go by himself/herself by using the statistics shown on his/her

screen. Additionally, in the second release, IoT Recommender will be developed for smart skiing use

case.

During the full lifecycle of the IoT recommender, the following scenarios allow exploitation of the

Context Broker:

- Browsing all types and detailed information on a type: the IoT recommender queries the Context

Broker with the entity types that are registered in the Context Broker. Of interest are traffic, crowd,


13

and parking data. The result is used to create the settings that determine the type of IoT data

considered in the recommendations.

- Getting all entities and filtering: the IoT recommender queries the Context Broker for all entities of

a given type. The result is used for updating the world model with the set of sensors available for

recommendations. Since many entities may be returned, pagination is used.

- Query entity: the IoT recommender queries the values of entities of interest in a current end-user

session. The returned values are used as parameters in the IoT recommendations.

- Subscription: the IoT recommender subscribes to changes in the IoT data, e.g. the occupation of an

originally recommended parking may lead to an update of the recommendation to the user.

The complete details about the IoT Recommender, including overview, functionality, interfaces,

positioning in SAR and interaction with other SAR components is provided in detail in D2.6 [5].

2.1.2.2 Quality of Information (QoI) Monitor: Web-based Ontology and Linked-data Validation

A sufficient level of Quality of IoT data is a basic factor in the success of an IoT system. Wrong

representation of data and a lack of understanding of the meaning of the data will lead to

misinterpretations of that data and failures of services and applications.

Wise-IoT provides a Semantic Web Information Quality Framework that classifies data quality problems

and calculates information quality (IQ) scores for the IQ dimensions, which are independent of the user’s

context. Five dimensions are part of this group, which are syntactic validity, semantic accuracy,

consistency, conciseness and completeness. These dimensions focus on whether information correctly

(syntactically and semantically), compactly and completely represents the real world data and whether

the information is logically consistent in itself.

Syntactic Validity. Flemming [14] defined the term validity of documents as “the valid use of the

underlying vocabularies and the valid syntax of the documents”. Fürber et al. [15] classified accuracy

into syntactic and semantic accuracy. We explained that a “value is syntactically accurate when it is part

of a legal value set for the represented domain, or it does not violate syntactical rules defined for the

domain”. We associate the validity of documents defined by Flemming to syntactic validity. We

distinguish between the two types of accuracy defined by Fürber et al. and form two dimensions:

Syntactic validity (syntactic accuracy) and Semantic accuracy. Additionally, Hogan et al. [16] identify

syntax errors such as RDF/XML syntax errors, malformed datatype literals and literals incompatible with

datatype range, which we associate with syntactic validity.

Example: In one of our use cases (rich parking use case), let us assume that the ID of a specific parking

spot is ParkingSpot1 while in the trust platform the same parking spot is represented as ParkingSpot01.

Since this ID is included in one of the datasets, it is considered to be syntactically accurate since it is a

valid ID (even though it is incorrect).

Semantic Accuracy. Bizer [17] adopted the definition of accuracy from Wang et al. [18] as the “degree

of correctness and precision with which information in an information system represents states of the

real world”. Furthermore, Furber et al. [15] classified accuracy into syntactic and semantic accuracy. He

explained that values are semantically accurate when they represent the correct state of an object.

Based on this definition, we also considered the problems of spurious annotation and inaccurate

annotation (inaccurate labelling and inaccurate classification) identified in Lei et al. [19] related to the

semantic accuracy dimension.

Example: In the rich parking use case, let us assume that the ID of a specific parking spot is ParkingSpot1

while in the trust platform the same parking spot is represented as ParkingSpot01. In this case, the


14

instance is semantically inaccurate since the parking spot ID does not represent its real-world state, i.e.,

ParkingSpot1.

Consistency. Bizer [17] adopted the definition of consistency from Mecella et al., [20] as when “two or

more values do not conflict with each other”. Similarly, Hogan et al. [16] defined consistency as “no

contradictions in the data”. Another definition was given by Mendes et al. [21] where “a dataset is

consistent if it is free of conflicting information”. Additionally, Böhm et al. [22] and Mostafavi et al. [23]

present metrics to assess consistency. However, it should be noted that for some languages such as OWL

DL, there is clearly defined semantics, including clear definitions what inconsistency means. In

description logics, model-based semantics are used: a knowledge base is a set of axioms. A model is an

interpretation, which satisfies all axioms in the knowledge base. A knowledge base is consistent if and

only if it has a model.

Example: Let us assume a client looking for parking spot status on the 26th of September, 2017. Its query

returns the following results:

ParkingSpot LastUpdate Status

ParkingSpot1 20170926 06:25 free

ParkingSpot1 20170926 06:25 occupied

The results show that the parking spot ParkingSpot1 has two different status at the same time, which is

inconsistent with the ontology definition that one parking spot can only have one status at a specific

time and date. This contradiction arises due to inconsistency in data representation, which is detected

by using inference and reasoning.

Conciseness. Mendes et al. [21] classified conciseness into schema and instance level conciseness. On

the schema level (intentional), “a dataset is concise if it does not contain redundant attributes (two

equivalent attributes with different names)”. Thus, intentional conciseness measures the number of

unique schema elements (i.e. properties and classes) of a dataset in relation to the overall number of

schema elements in a schema. On the data (instance) level (extensional), “a dataset is concise if it does

not contain redundant objects (two equivalent objects with different identifiers)”. Thus, extensional

conciseness measures the number of unique objects in relation to the overall number of objects in the

dataset. This definition of conciseness is very similar to the definition of ‘uniqueness’ defined by Fürber

et al. [17][19] as the “degree to which data is free of redundancies, in breadth, depth and scope”. This

comparison shows that uniqueness and conciseness point to the same dimension. Redundancy occurs

when there are equivalent schema elements with different names/identifiers (in case of intentional

conciseness) and when there are equivalent objects (instances) with different identifiers (in case of

extensional conciseness) in a dataset.

Example: An example of intentional conciseness would be a particular parking spot, say ParkingSpot1,

being represented by two different properties in the same dataset:

- http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#ParkingSpotID

- http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#name

This redundancy (‘ParkingSpotID’ and ‘name’ in this case) can ideally be solved by merging the two

properties and keeping only one unique identifier. On the other hand, an example of extensional

conciseness is when both identifiers of the same parking spot have the same information associated

with them in both the datasets, thus duplicating the information.

Completeness: Bizer [17] adopted the definition of completeness from Pipino et al. [14][17][19] as “the

degree to which information is not missing”. Fürber et al. [15] further classified completeness into: (i)


15

Schema completeness, which is the degree to which classes and properties are not missing in a schema;

(ii) Column completeness, which is a function of the missing property values for a specific

property/column; and (iii) Population completeness, which refers to the ratio between classes

represented in an information system and the complete population. Mendes et al. [21] distinguish

completeness on the schema and the data level. On the schema level, a dataset is complete if it contains

all of the attributes needed for a given task. On the data (i.e. instance) level, a dataset is complete if it

contains all of the necessary objects for a given task. As can be observed, Pipino et al. provided a general

definition whereas Fürber et al. provided a set of sub-categories for completeness. On the other hand,

the two types of completeness defined in Mendes et al. can be mapped to the two categories (i) Schema

completeness and (iii) Population completeness provided by Fürber et al.

Example: In our use case, the IoT recommender requires complete information to include all the parking

spots and parking spots codes such that it allows a user to find an optimal route from the start to the

end destination.

Following, as an example, we will address the full image in how the component work in the smart city

use case and the different interactions with this component. Figure 5 shows an overview of the smart

city case architecture. The architecture is composed of three layers, i.e., IoT devices, IoT platforms and

IoT services. The IoT device layer contains field IoT devices (such as parking spot sensors and actuators)

and IoT gateway. The layer for IoT Platforms manages IoT Devices and provides common service

capabilities to IoT Services. In our implementation, we use Möbius, an open source implementation of

the oneM2M standard, as a southbound IoT platform. We use the FIWARE IoT platform northbound. On

the top of these platforms, we implement MMG component that enables cross-platform and even cross-

domain application developments. The knowledge processing layer, implemented with the self-adaptive

recommender (SAR), provides intelligence for trust-enabling quality assurance and end-user

recommendations.


16

Figure 5 - Smart City use case architecture

In this project, the core aspect to achieve this semantic interoperability between the IoT platforms

(oneM2M and FIWARE), and make data available to the application layer is the ontology and the data

annotation using ontology (rich parking ontology). In this perspective, we include the QoI monitor as a

SAR component to classifies data quality problems and calculates Information Quality (IQ) scores for the

IQ dimensions, which are independent of the user’s context. It is implemented as follows in the rich

parking use case.

Figure 6 describes the different interactions with the QoI module. In the first iteration, the QoI will

capture all the observations (semantic annotation) sent by the parking spot sensors and perform a

validation of these semantic data against the parking spot ontology. The component will then send the

score to the Trust Evaluator and a detailed validation report to the owner of the data. In the second

iteration, instead of capturing all the data, the QoI module will subscribe to oneM2M Mobius to get

notified if there is an update in a oneM2M resource, in this manner, the system will be more performant

and less processing resource consuming. So the scenario will be as described in Figure 7.


17

Figure 6 - QoI module interactions (1st iteration)

Figure 7 - QoI module interactions (2nd iteration)

The QoI module is available as Docker image in the Docker repository (the deployment of the component

is described in D2.6 [5], section 3.2.3). It is fully integrated with SAR components (D2.6 [5] again

describes all interactions). The various examples mentioned above are concrete examples that are

detected during the rich parking use case demo. So, the QoI module, which checks the semantically

annotated data and calculates information quality (IQ) scores for the IQ dimensions, will affect the trust

index of a parking spot and as a consequence, the recommendation provided to the user.


18

2.1.3 Chatbot

2.1.3.1 Chatbot before Wise-IoT project

The Chatbot platform developed by Wonderful Platform makes it relatively easy to use a new technology

called Chatbot and makes it possible to expand functions by linking with restful API provided from the

outside. The image or menu composition for the Chatbot can be designed to fit the user's intention.

Moreover, if data is trained using Machine learning and Deep Learning, and if algorithm that analyze

user’s input contents effectively based on trained data is applied, Chatbot can provide the best answer

to the user wishes.

The Chatbot created with this Chatbot platform can be useful for providing information and guiding on

actual ski resort facilities. Basic conversation design can be configured more easily than expected. The

Figure 8 is a possible scenario of creating an application that interlinks Chatbot based on information of

nearby resort facilities.

Figure 8 - Simple Scenario category when chatbot used for resort service

Large categories are based on database which stores peripheral data, and provide a user’s most wanted

facility information in the order of the closest distance from a user. Chatbot will provide relevant

information when a user mentions comments like "I want to buy a lift ticket", and the Chatbot can also

deliver finalized purchase history to the user after the actual purchase and payment. Chatbot’s dialogue

with users can be composed of a variety of messages. In the case of implementing restaurant reservation

as one of the functions of Chatbot, Chatbot can be configured based on the Chatbot flow chart as shown

below (Figure 9). Other sub-functions do not deviate much from this type of operation. Also, in addition

to this process-oriented configuration, information can be input through web view interface and gives

users an answer accordingly.


19

Figure 9 - Flowchart about restaurant reservation service of chatbot

Furthermore, the desired design can be implemented to the Chatbot and applied to homepage or to a mobile device as an app. In the Figure 10, the Chatbot on the left is a simple form created with our Chatbot platform, and the Chatbot on the right is a sample Chatbot that has been designed with a simple Chatbot shape like the one shown on the left.


20

Figure 10 - Normal chatbot (left one) and chatbot with specific design in Korean (right one).

2.1.3.2 Chatbot for Wise-IoT project

The Chatbot of the Wonderful Platform shown above can be implemented in two different models in

Wise-IoT. First model is “merging model with FIWARE” (cf. Figure 11). Simply put, this is a model that

combines Chatbot of Wonderful Platform with the FIWARE system. Second one is “merging model with

oneM2M Mobius”, which combines the Chatbot of Wonderful Platform and oneM2M system (cf. Figure

12). Although the name is different, since the model is divided into two types according to the data

collection, there is not much difference in the driving method thereafter.

Figure 11 - Inbichat with FIWARE System


21

Figure 12 - Inbichat with OneM2M System

First of all, the Chat-Gate system is built on the layer where FIWARE or oneM2M Mobius is implemented.

Then, the data is processed and transferred to the InbiChat system. After receiving the data, InbiChat

performs analysis and then runs the Chatbot service. The two models described above can provide a

better service, both by implementing a Chat-Gate model.


22

2.2 IoT Devices

The Wise-IoT project is a good framework to create new devices and test new technologies in existing

devices. Thus, some partners of the project propose their devices to be deployed in the testbeds and be

integrated by upper layer platforms. In this project, three partners are bringing those on-the-ground

devices that will be used in various use cases, both in the smart city and in the smart resort.

This section details the IoT devices and their integration with the Wise-IoT platform.

2.2.1 LoRa tracker

A LoRa band device is developed for the Wise-IoT that aims at tracking assets or users. It detects the

location using the GNSS, and then send data through the LoRa network (cf. Figure 13). It supports both

EU868 and KR920 in order to allow the roaming between Korea and Europe. If the device does not move,

according to the motion embedded sensors, it goes into sleep mode. However, if it moves, the device

will send the GPS data on the LoRa network.

Figure 13 - LoRa band hardware diagram

This device also support Bluetooth Low Energy 4.2 for the followings functions: a) communicate

between LoRa band and the PIQ Robot (cf. section 2.2.3); b) configure time to report and c) upgrade

firmware.

LoRa band is working with a main scheduler to handle each function and hardware. Moreover, the

software is using secured coding and secure booting to protect the device from a malicious hacker.

Figure 14 - LoRa Band software architecture


23

Users can easily wear it with accessory such as band, hook and so on. The battery life is about 3 days

when the device sends data every 2 minutes.

Figure 15 - LoRa Band outdrawing and final version on a user

2.2.2 Crowd detector

A crowd detection service is developed for the Wise-IoT. The crowd detection service consists of front-

end crowd detectors, back-end data analytics, NGSI-based crowd modelling, and its APIs for application

developers. The crowd detection service is used in the smart-city testbeds such as in the smart skiing

testbeds. The service will provide the estimated number of crowds detected in a sensing zone covered

by each crowd detector.

A front-end crowd detector consists of a Raspberry Pi 3, a Wi-Fi antenna which can support monitor

mode, a 3G dongle for sending data to back-end infrastructure, and multiple power banks for powering

up the device during non-charging period if there is no directly electricity to the device. The Figure 16

shows the prototype of the device.

Figure 16 - A prototype of crowd detector


24

Crowd detectors collect Wi-Fi probe request packets from mobile devices. Each crowd detector has the

Wi-Fi sniffing software running. The back-end data analytics conduct the experiments and analyze

pedestrian mobility based on the data collected by crowd detectors. The crowd detectors report the

following information to the back-end system for further data analytics.

- Anonymous MAC address (processed by 2-stage privacy protection process); - Anonymous SSID that the mobile device is looking for (processed by 2-stage process privacy

protection); - Mobile devicebrand; - Observed RSSI; - Timestamp; - Name and Mac address of the crowd detector.

The data flows processed by the crowd detector are explained as follows.

- Sensing: the crowd detector captures the Wi-Fi probe request packets only and drops other types of Wi-Fi packets.

- Filtering: only the aforementioned data is recorded and other information inside the Wi-Fi probe request packets is dropped.

- Salting and Hashing: salting and SHA3-256 hashing algorithms are applied to the MAC addresses and SSIDs.

- Salting changing period: the key for generating salting results is changed periodically. The period of changing key depends on requirements. A short changing period leads to higher level of privacy protection.

- Reporting: the gathered and anonymized data is reported to the server together with an ID of the crowd detector through a secure SSL-Channel.

- Storing and retention period: the transmitted data records will be stored in the backend infrastructure in a secured environment during the project period.

The back-end data analytics include two modules: people detection and crowd estimation. The people

detection module is to determine if a mobile device appears in the zone covered by a particular crowd

detector based on “uncertain” and “intermittent” Wi-Fi probes. The crowd estimation module computes

how many mobile devices detected by a crowd detector. Finally, the crowd estimation results is

converted to a NGSI-based format and is further published to an IoT broker so that multiple application

developers can access the crowd estimation results for developing various applications.

2.2.3 PIQ Robot

2.2.3.1 PIQ Robot existing product before Wise-IoT project

PIQ Robot is a consumer market wearable device dedicated to sport activities. By now, five sports are

supported: Golf, Tennis, Ski, Kite Surf and Boxing. PIQ Robot is embedding multiple sensors, i.e.,

accelerometer, gyroscope, magnetometer, pressure, to detect and categorize (automatic recognition of

the type of motion) a specific motion (cf. Figure 17). Then, it computes key metrics related to the

performance of the user: speed, effect, altitude of a jump, is the motion/trajectory well done, etc. The

goal is to provide interesting data to the user for him to better know how he plays in order to improve

him and better enjoy his preffered sport. The user can also compare himself with other users, create

challenges, define a training session, etc.


25

Figure 17 - PIQ Robot internal hardware architecture

To provide a good user experience PIQ Robot comes with a complete suite of software organized in 3

main parts located physically in different locations: see the following diagramm

Figure 18 - PIQ Robot global software architecture

2.2.3.2 PIQ Robot use case for Wise-IoT project

PIQ Robot is on the market since 2016 as a consumer product interacting with a smartphone (Android

and iOS compatible) with a specific communication protocols using BLE and a user interface dedicated

to this case. In the existing product, the users have a feedback about their ski session only after the end

of the session when they synchronizes the PIQ Robot with the smartphone.


26

In the case of Wise-IoT project a new configuration is required as the PIQ Robot needs to communicate

this time with the LoRa band device detailled in section 2.2.1. The LoRa band device is acting as a BLE-

LoRa gateway and provide ski metrics after each descent or ski event (curve, jump). This new way of

communication has to coexist with the current mode in order to not modify the user experience: PIQ

Robot maintains the current user experience while being able to communicate data metrics after each

descent or ski event (curve, jump) with the LoRa band.

The issues to consider are a dilemma between the big amount of data to be theoretically transmitted

and the LoRa network with limited bandwidth and high latency. The standard data flow from the PIQ

Robot requires a continuous data rate of around 100 kbps corresponding to the sensors data resulting

from the skier activity. For Wise-IoT, a new messaging protocol has to be put in place between the PIQ

Robot and the LoRa band device, without impacting the standard ski application. The messaging system

content has to be adapted in order to allow the LoRa band device to transmit to the LoRa network the

information coming from the PIQ Robot as well as its own information like the time and the location.


27

2.3 The integration of the IoT platforms in the testbeds

The IoT platforms are the platforms in charge of the access to the data provided by the sensors from the

IoT devices. They usually own their own data model that has been built upon various concepts, i.e., each

data model tends to propose a representation of the world. But, like human language, there is some

incompatibility amongst them. The main idea of the Wise-IoT project is to propose a system able to

interconnect, at different layers, the various IoT platforms at runtime, i.e., the Morphing Mediation

Gateway.

This section describes how the IoT platforms have been integrated all together, based on the template

provided in Figure 1. It details for each testbed the IoT platforms involved and how they are integrated

with the others platforms, i.e., IoT devices, IoT platforms or data processing platforms.

2.3.1 The smart cities testbeds

2.3.1.1 Integration of the use cases in Santander

WISE-IoT project provides a unique opportunity to SmartSantander infrastructure for extending

interoperability with oneM2M platform. Also, the project has allowed the integration of new radio

interfaces, LoRa, by relying also on oneM2M enablers. This way, SmartSantander is enhanced and more

attractive to different stakehoders interested to interact with the platform.

The D3.1 [7] presents and explains the SmartSantander platform previous to the integration of WISE-IoT

developments, which provides to external users (either hardware and/or software experimenters or

service developers) standardized access to manage the information generated from the facility,

including both the sensor deployments and the applications used by the citizens.

Figure 19 provides the vision of the Santander architecture where it is represented the legacy

SmartSantander infrastructure integrated with WISE-IoT developments.

At the botton, it is shown the new LoRa deployment complementing the legacy IoT node tier already

composed by diverse heterogeneous devices such as sensors of different purposes, tailor-made devices

for specific services, RFID and NFC tags, etc. As it can be seen in the LoRa deployment part, the

integration of this technology relies on oneM2M in two different ways. On one hand, the parking sensors

have been integrated through oneM2M using the LoRa gateway which is in charge of translating the

information received from the sensors to oneM2M in order to be stored in the deployed oneM2M

Mobius instance. On the other hand, other sensors such as the LoRa bands are configured to send the

information to a LoRa backbone which will send the information to the aforementioned oneM2M

gateway in order to adapt the information to be stored in Mobius.


28

Figure 19 - Wise-IoT Santander architecture

Moving to the second layer, integration and management layer, it can be observed (in addition to the

aforementioned oneM2M gateways and oneM2M Mobius instance) the semantic adaptation

introduced in order to make all the information follow the agreed data model in Wise-IoT, collaborating

on the achievement of the expected data interoperability with the different data sets available through

the Santander infrastructure. In this layer, it is performed the integration of two of the main components

which allow the interoperability between FIWARE and oneM2M in the Santander architecture. The

Morphing Mediation Gateway is integrated in order to be able to instantiate the Adaptive Semantic

Module (ASM) and the Context-Aware Auxiliary Gateway (CAG). The instantiation of the ASM allows the

translation and storage of oneM2M data available in Mobius into the Orion Context Broker. On the other

hand, the instantiation of the CAG enables the translation and storage of the information available in

the Orion Context Broker into the oneM2M Mobius instance. This way, although the information will be

primarly provided through Orion Context Broker, as main interface of the Information Access Layer, it

will be also available if it is needed for already developed oneM2M based services or applications.

At the top of the architecture it is integrated the Knowledge Processing Layer in charge of providing

recommendations services to the Santander use cases. From the information available at the


29

Information Access Layer and with other context information provided by the use case application (e.g.

GPS information) the recommendations services provides new functionalities directly to the applications

such as the route recommendations, the adherence monitoring or the feedback provision, or indireclty

such as the trust or QoI monitoring.

This enhanced Santander platform, as a result of the integration of the WISE-IoT developments, is tested

and evaluated through the use cases to be deployed in the city. The Rich Parking use case developed in

Santander gets the information related to parking and traffic through the Orion Context Broker in the

Information Access Layer, being irrelevant if the information comes originally from Orion or if it cames

from oneM2M. Thanks to the Morphing Mediation Gateway, all the information can be gathered

through a common interface and following a common data model, so the developer do not have to

worry about the source of the information (oneM2M or FIWARE).

2.3.1.2 Integration of the smart parking in Busan

To provide parking service continuity between Busan and Santander, the following service architecture

has been designed and deployed. In case of Busan, which has already deployed parking infrastructure

feeding data to Busan smart city platform, due to governance issue, the parking sensor data gets

collected into oneM2M Mobius platform. The oneM2M Mobius platform is provided by KETI and

extended in terms of semantic interoperability in Wise-IoT project.

Figure 20 - WISE-IoT Korean parking service architecture

Existing parking data from legacy sensors are reported to Parking Gateway (G/W) which has oneM2M

application on it. Starting from this gateway application, data is delivered to oneM2M platform using

oneM2M standard interface. The data collected in Busan oneM2M platform are copied into Mobius

platform using subscription/notification scheme by oneM2M standard. Then, the data is semantically

annotated and stored in Mobius, also this uses oneM2M semantics features provided by Mobius. When


30

the new parking event occurs, new data is stored in Mobius and semantic annotation gets updated. This

semantically annotated parking data is sent to ASM and translated/stored into FIWARE Context Broker.

From the user point of view, both oneM2M Mca and FIWARE NGSI compatible parking application are

available to get parking service in Korea.

2.3.1.3 Integration of the bus information in Busan

GS1-Oliot is an open source IoT platform which extends the GS1 code system. By supporting various IoT

connectivity protocols, Oliot aims at implementing the GS1/EPC global standards. In the WISE-IoT

project, GS1-Oliot is used to collect bus information from Busan city. For world wide interoperability,

the bus information gathered through Oliot is translated and published into the WISE-IoT platform, more

specifically into oneM2M server which is then translated into FIWARE.

The translation from GS1-Oliot to oneM2M is performed by GS1-oneM2M MMG component developed

as part of the WISE-IoT project. The component contains a GS1-oneM2M Accessing Application module

and a GS1-oneM2M Capturing module. The first one uses EPCIS querying interface to get data from GS1

and publish it to oneM2M using oneM2M interface with MQTT binding. The second module subscribes

to the oneM2M server to get information collected by other platforms and store it back to GS1-Oliot.

The position of the MMG in integrating GS1-Oliot with WISE-IoT platform is shown in Figure 21.

Figure 21 - GS1 - oneM2M integration


31

2.3.2 The smart skiing testbeds

The smart skiing testbed, both in Europe and in Korea, are inspired from the architecture presented in

the D1.2 [2] and detailed in the Figure 22. In those testbeds, the applications are directly bound to the

IoT platforms, i.e., Eclipse sensiNact for Europe and oneM2M Insator for Korea. The data are also sent

to the upper layers to be finally processed by the Knowledge processing layer (cf. Figure 22).

Figure 22 - Integration of the IoT platforms for the skiing testbeds

2.3.2.1 Integration of the smart skiing use case in Chamrousse

The oneM2M specifications propose multiple ways to connect to a oneM2M platform, i.e., HTTP, MQTT.

The Eclipse sensiNact platform already proposes a module based on MQTT. The Wise-IoT project

participates to the extension of the sensiNact platform to include the oneM2M architecture and to

extend the MQTT protocol. This bridge, i.e., the module allowing the translation between the Eclipse

sensiNact data model and the one from oneM2M, has been placed into our open source repository,

allowing others users to deploy it to integrate oneM2M platforms.

Eclipse sensiNact allows to connect several instances of the gateway is a distributed manner. Thus, a

sensiNact gateway instance is dedicated to the translation of the data model from Eclipse sensiNact to

oneM2M through MQTT (cf. Figure 23).


32

Figure 23 - Integration sensiNact with oneM2M

This installation is deployed in the smart skiing use case (cf. D1.1 [1] and D1.2 [2]). In practice, it is

deployed in Chamrousse where the experimentation will be lead.

2.3.2.2 Integration of the smart resort use case in Alpensia

Figure 24 - Integration oneM2M Insator with the LoRa tracker

In order to support the smart resort use case, LoRa trackers send the data to Kerlink gateway over LoRa network and the data is sent to the IPE to translate it to oneM2M standard message format. Once the data over oneM2M standard is ready on top of the platform, Insator allows the applications such as Insator Portal, Resort Admin Portal and Mobile Application to access the trackers data via OAuth2 and user based authentication mechanism (cf. Figure 24).


33

2.3.3 The smart fitness testbed

The smart fitness testbed is divided into two specific use cases : the Tennis Show Room and the Tennis

recommendation use cases which are leading to two different configurations and developments.

2.3.3.1 Tennis Show Room

The purpose is to create in the Daegu global healthcare center living lab (technology show room) of the

Kyungpook National University (KNU) a real time tennis demonstrator able to automatically recognise

and compute the metrics associated to the user motion. Then, the corresponding data, i.e., speed,

effect, preparation and global score, will be displayed in real time on a TV screen.

The installed PIQ device communicates with the MAPHIS (Most Advanced Personalized Healthcare

Intelligent Service) platform which is based on oneM2M standard. MAPHIS also complies with ISO/IEEE

11073 DIM (Domain Information Model) and HL7 (Health-Level 7) specifications for interoperability of

various healthcare devices for connectivity. In order to support smart fitness use case, tennis activity

data is sent to the PIQ server and the data is then stored at MAPHIS healthcare platform (cf. Figure 25).

Figure 25 - Integration of the IoT platforms for the fitness testbed

In the testbed, the setup will consist in the following steps

- The user provides his credentials (name, phone number, mail, left or right hand) and then places

PIQ Robot on his wrist using a specific accessory;

- PIQ Robot recognizes the motions and computes the metrics (fusion algorithms and AI powered)

and sends the data to a tablet using a BLE connectivity;

- The tablet runs a dedicated application and is connected to a TV display;

- The tablet is also used to create a short video of the user during his motion (it can be disabled);

- The TV display shows in real time the recognized motion and the associated metrics;

- The motions and video can then be sent to the user. The overall data of the users can be used

for other analysis.

The Figure 26 shows an example of a setup to demonstrate Golf and Tennis: the global motion score can

be seen on the display. The Figure 27 shows the setup configuration in Daegu Living Lab, in this example

the displays are showing the screen generated by the application in Tennis session mode.


34

Figure 26 - Example of a setup to demonstrate Golf and Tennis

Figure 27 - PIQ Device installed in Daegu fitness testbeds

2.3.3.2 Tennis recommender

The purpose is to create a recommender system based on a partial or complete tennis session. New

developments are under process for the Wise-IoT project: add new features to the existing application

in order to share the tennis session data. Those shared data will then be used by 1theFull to extract key

data and build individual recommendations valuable for the user. This specific recommender created by

1theFull is developped in the framework of Wise-IoT.

Concerning the data flow, the steps are the following (cf. Figure 28):

- The user places the PIQ Robot on his wrist for a tennis session and activates it. The user has

nothing to do during the tennis session (except if the user wants to see data in real time);

- At the end of the tennis session, the user synchronizes his PIQ Robot with his smartphone and

all the data (context, date, motions types, associated metrics) are sent to the PIQ database;

- 1theFull will access, using REST protocol to the PIQ database to retrieve the pertinent data;

- Based on the data, the Chatbot of 1theFull will compute recommendations specific to the user;

- The Chatbot recommendations will be displayed on a dashboard and potentially (not in the

scope of the program but will be demonstrated) sent by mail or SMS to the user.

Figure 28 - Global data flow for recommendation system

Interoperability tests

35

3 Interoperability tests

3.1 Technical interoperability tests

Technical interoperability tests validates that all the components in the systems are interacting correctly

as per the requirements. Figure 29 shows the technical interoperability architecture based on Wise-IoT

architecture. In the testing architecture, bottom layer shows the IoT devices based on various standards

and protocols which sends data to specific MMG component in the MMG manager which then translate

the data into oneM2M standard and send to oneM2M service layer. On top of oneM2M service layer,

ASM will get the data from oneM2M service layer and convert into NGSI format and send to the

Information Access Layer (IAL). Refer to D2.2 [3] for further details about the Morphing Mediation

Gateway and its components.

Figure 29 - Architecture for testings the interoperability

3.1.1 Existing tests

3.1.1.1 oneM2M ASM NGSI

For sending data from oneM2M service layer to IAL, ASM gets the data from oneM2M service and

convert it into NGSI format and store in IAL layer. Following test cases validate the interoperability of

oneM2M service layer and IAL in the presence of ASM.

• ASM Discover oneM2M

• ASM Subscribe oneM2M

• oneM2M Notify ASM

• ASM Update NGSI


36

3.1.1.2 NGSI CAG oneM2M

For sending data from NGSI platform to oneM2M service layer, CAG gets the data from NGSI platform

and converts into oneM2M resource structure and store in oneM2M service layer. Following test cases

validate the interoperability of oneM2M service layer and NGSI platform in the presence of CAG

component of MMG manager.

• CAG Discover NGSI

• CAG Create oneM2M

• CAG Subscribe NGSI

• NGSI Notify CAG

• CAG Update oneM2M

3.1.1.3 ZWave ZIG oneM2M

For sending data from ZWave devices to oneM2M service layer, ZIG gets the data from ZWave controller

and converts it into oneM2M resource structure and store it in oneM2M service layer. Following test

cases validate the interoperability of oneM2M service layer and ZWave based devices in the presence

of ZIG component of MMG manager.

• ZIG Register oneM2M

• ZWave Sends ZIG

• ZIG Create oneM2M

3.1.2 Futures tests

For validating the technical interoperability between all components of Wise-IoT architecture, following

test cases are in progress and will be part of D3.3 in future.

• GS1 GS1 MMG oneM2M

• sensiNact sensiNact MMG oneM2M

• LoRa LoRa MMG oneM2M

• OIC OIC MMG oneM2M


37

3.2 Semantic interoperability tests

3.2.1 Overview

The semantic interoperability tests will be performed through the semantic ontology validator tool. The

ontology validator is a web service integrated within a web-based client-server architecture. This simple

web client tool offers an easy and intuitive user interface to access the service. Through the GUI, users

will be able to upload their ontology or semantically annotated data stream to be validated against one

or several reference ontologies, such as W3C SSN ontology and oneM2M base ontology. The validator

tool detects syntactic and semantic issues if any, and produces a detailed test report at the end of the

process which will help the user to correct the issues.

This tool combines three main functionalities that we can find in separate tools nowadays: a) lexical

validation of XML/JSON format, b) syntactic validation of an ontology or RDF data regarding to standard

specifications (RDFS, OWL, etc) and against a given reference ontology, and c) semantic validation. But

all these current tools suffer from several limitations, such as the need of desktop sofware installation

and configurations (e.g., Fluent Editor [8] and Protégé [9]), and even the web based solutions require to

set up an appropriate environment (e.g., Moki [10]: wiki system).

This tool offers a user-friendly, intuitive and web-based interface. We also provide RESTful API for M2M

validation for this tool, which makes the service a relevant input for more advanced technologies, e.g.,

ontology alignment. Additionally, it provides a validation example with explanation on the validation

report in order to help the user to understand the validation result. Following the report, user can make

corrections to the reported error and make his ontology or RDF linked data valid. In this manner, it is a

good support to achieve interoperability.

The architecture of the semantic ontology validation tool is based on two major parts: the front end and

the back end (cf. Figure 30). The front end takes most of the popular RDF serialization formats as input

in order to produce a set of evaluation results. In response to user interaction, the back end parses the

initial file, using either an XML or JSON parser. If no error is found, the RDF parser receives the result as

input. If it respects the specification of RDF model, triples in this model are extracted to serve as the

input for the next validation step which is the “validation” module.

Figure 30 - The architecture of the EGM validator web app


38

Finally, the validation module takes the reference ontology which is constructed from various checked

ontologies. The checked ontologies are merged into a single ontology and the triples are also passed as

input of the validation module. According to the predefined reference ontology, it checks the syntactic

errors in the document which is based on the functionalities implemented in Eyeball, a JENA ontology

validator. A reasoner is used to enable the logical level verification of the RDF document such as the

respect of subsumption relationships between classes, restrictions on class properties and cardinality.

The validation results are sent to a reporting server showing a list of errors (syntax, lexical and logical)

in JSON format, as well as explanations regarding the ontology affected elements. Once the report is

ready in the database, the frontend will receive a notification in order to get the available ontology

validation report related to the user.

3.2.2 Current Status and Roadmap

This tool was originally developed as a syntactic and semantic ontology validator within the H2020

FIESTA project. Currently, it has been extended and new evaluation dimension of Quality of Information

(QoI) has been added for self-adaptive recommendation system. Additionally, the semantic ontology

validator tool has been extended to be usable as a service.

The future roadmap of semantic ontology validator for achieving semantic interoperability tests include:

• Integration of new evaluation dimension of QoI evaluation into semantic ontology validator

(October 2017) ;

• Building the missing interfaces (for performance enhancement) (November 2017) ;

• Perform semantic validation for each use case ontology and semantic description using semantic

ontology validator and send results to use case owners:

o Smart Parking (completed)

o Bus information (Mid of November 2017)

o Crowd modelling (Mid of November 2017)

o Smart skiing (Mid of November 2017)

• Recheck semantic validation after ontology designers (use case owners) fix the errors in their

ontologies/semantic descriptions (December 2017) ;

• Present the results for semantic interoperability tests in D3.3 (end of project).

Conclusion

39

4 Conclusion

This deliverable describes the second release of the Wise-IoT. It presents the common IoT platforms,

i.e., the Integration and Management layer, the Information Access layer, and the Knowledge Processing

layer. It also presents, for each testbed, how the specifics platforms used, i.e., IoT devices or IoT

platform, have been integrated with the Wise-IoT system based on the architecture provided in the D1.2

[2]. This integration work is the first step toward the development of the applications for the use cases.

In this second release, we created a more independent and generic system, i.e., the common platforms,

that has been deployed and integrated in specifics environments. Moreover, to test that the

interoperability is effective between the common platforms and the testbeds platforms, interoperability

tests are created. Some of them, the existings ones, have been described in this document.

This second release demonstrates that the interoperability approach carried by this project is interesting

in a world in which the set of available platforms is increasing, adressing more and heterogeneous

environments. The addition of new environments, i.e., smart skiing and fitness, shows that the

interoperability approach of this project can even be applied to others environments that are not related

to smart cities.

The next deliverable, the D3.3, will describe the interoperability tests that consider three aspects of

interoperability: (1) technical interoperability, (2) semantic interoperability and (3) security

interoperability.

References

40

5 References

[1] Deliverable 1.1 – Wise-IoT Pilot Use Case Technical Description, Business Requirements, and

Draft High-Level Architecture, Wise-IoT, 2016.

[2] Deliverable 1.2 – Wise-IoT High-Level Architecture Reference Technologies and Standards,

Wise-IoT, 2017.

[3] Deliverable 2.2 – Morphing Mediation Gateway with Management and Configuration

Functions R2, Wise-IoT, 2017.

[4] Deliverable 2.4 – Semantic Interoperability Components R1, Wise-IoT, 2017

[5] Deliverable 2.6 – Self-Adaptive Recommendation System, Wise-IoT, 2017.

[6] Deliverable 2.5 – Semantic Interoperability Components R2, Wise-IoT, 2017.

[7] Deliverable 3.1 – Integrated IoT Platforms R1, Wise-IoT, 2017.

[8] FluentEditor, http://www.cognitum.eu/semantics/FluentEditor/ , October 2017.

[9] Protégé, http://protege.stanford.edu/, October 2017.

[10] M. Rospocher, C. Ghidini, V. Pammer, L. Serafini and S. N. Lindstaedt, “Moki: the modelling

wiki,” in Proceedings of the Forth Semantic Wiki Workshop (SemWiki 2009), co-located with

6th European Semantic Web Conference (ESWC 2009), 2009.

[11] Aeron IoT Broker FIWARE GE, https://github.com/Aeronbroker, last accessed 27.10.2017

[12] NEConfMan IoT Discovery FIWARE GE, https://github.com/Aeronbroker/NEConfMan, last

accessed 27.10.2017

[13] ETSI ISG CIM, https://portal.etsi.org/tb.aspx?tbid=854&SubTB=854, last accessed 27.10.2017

[14] Flemming, A.: Quality characteristics of linked data publishing datasources. Master’s thesis,

Humboldt-Universität zu Berlin (2010)

[15] Fürber, C., Hepp, M.: SWIQA - a semantic web information quality assessment framework. In:

ECIS (2011)

[16] Hogan, A., Harth, A., Passant, A., Decker, S., Polleres, A.: Weaving the pedantic web. In: LDOW

(2010)

[17] Bizer, C.: Quality-Driven Information Filtering in the Context of Web-Based Information

Systems. PhD thesis, Freie Universität Berlin (March 2007)

[18] Wand, Y., Wang, R.Y.: Anchoring data quality dimensions in ontological foundations.

Communications of the ACM 39(11), 86–95 (1996)

[19] Lei, Y., Uren, V., Motta, E.: A framework for evaluating semantic metadata. In: 4th

International Conference on Knowledge Capture, K-CAP 2007, vol. (8), pp. 135–142. ACM

(2007)

[20] Mecella, M., Scannapieco, M., Virgillito, A., Baldoni, R., Catarci, T., Batini, C.: Managing data

quality in cooperative information systems. In: Meersman, R., Tari, Z. (eds.) CoopIS/-

DOA/ODBASE 2002. LNCS, vol. 2519, pp. 486–502. Springer, Heidelberg (2002)

[21] Mendes, P., Mühleisen, H., Bizer, C.: Sieve: Linked data quality assessment and fusion. In:

LWDM (March 2012)

[22] Böhm, C., Naumann, F., Abedjan, Z., Fenz, D., Grütze, T., Hefenbrock, D., Pohl, M., Sonnabend,

D.: Profiling linked open data with ProLOD. In: ICDE Workshops, pp. 175– 178. IEEE (2010)

[23] Mostafavi, M.A., Edwards, G., Jeansoulin, R.: Ontology-based method for quality assessment

of spatial data bases. In: International Symposium on Spatial Data Quality, vol. 4, pp. 49–66

(2004)

http://www.cognitum.eu/semantics/FluentEditor/

http://protege.stanford.edu/

https://github.com/Aeronbroker

https://github.com/Aeronbroker/NEConfMan

https://portal.etsi.org/tb.aspx?tbid=854&SubTB=854

Documents

D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.2...2.1.2 Recommendation system platforms _____ 10 2.1.3 Chatbot _____ 18 ... customized/personalized and context-aware applications

D3 - Wise-IoTwise-iot.eu/wp-content/uploads/2018/09/D3.2...2.1.2 Recommendation system platforms _ 10 2.1.3 Chatbot _ 18 ... customized/personalized and context-aware applications