d2 - home - wise-iotwise-iot.eu/wp-content/uploads/2017/11/d2.5... · 4.1 semantic modelling for...

D2.5

Semantic Interoperability

Components R2

Editor: Yasir Saleem (IMT-TSP), Martin Bauer (NEC), SeungMyeong Jeong (KETI)

Submission date: 17/11/17

Version 1.0

Contact: [email protected], [email protected],

[email protected]

This document describes the semantic modelling and the semantic interoperability components for Release 2.

mailto:[email protected]



Editor: Yasir Saleem, Institut Mines Telecom, Telecom SudParis

(IMT-TSP)

SeungMyeong Jeong, Korea Electronics Technology

Institute (KETI)

Deliverable nature: O

Dissemination level: PU

Contractual/actual delivery date: M14 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, 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 Programme 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

2017 Participants in project WISE-IOT

Revision History

Revision Date Description Author (Organisation)

V0.1 04.06.2017 Table of Content Yasir Saleem (IMT-TSP)

V0.2 25.07.2017 Updated structure, integrating contributions

- 4.1 Semantic Modelling for Smart City Use

Case

- 4.2 Semantic Modelling for Smart Skiing Use

Case

- Section 5.2 Semantic Annotator

Martin Bauer (NEC)

Carmen López (UC)

Rémi Druilhe (CEA)

SJU

V0.3 22.08.2017 Integrated contributions

- 2 Semantic Interoperability

- 3.2 Semantics in FIWARE

- 4.1.2 Bus Information System

- 4.3 Semantic Modeling for Crowd Mobility

- 5.1 Adaptive Semantic Module

Yasir Saleem (IMT-TSP)

Martin Bauer (NEC)

Martin Bauer (NEC)

Minh Hoang (KAIST)

Martin Bauer (NEC)

Martin Bauer (NEC)

v0.4 08.09.2017 Incorporated comments provided by the

reviewer

v0.5 28.09.2017 - 5.3 QoI Monitor

- Executive Summary

- 6 Conclusions

Addressed review comments + additional

reviewing

Hamza Baqa, Franck Le

Gall (EGM)

Martin Bauer (NEC)

Martin Bauer (NEC)

Martin Bauer (NEC)

v0.6 03.10.2017 - 5.4.1 IoT Recommender

Addressed 2nd reviewer comments



v0.7 30.10.2017 Added 5.3 Self-Adaptive Recommendation (SAR)

System & moved QoI Monitor to subsection

Updated Executive Summary and Introduction

to properly introduce discussion of SAR

components in this deliverable

Updated 4.2.2 ‘Asset Tracking’ to add missing

information related to asset tracking and added

Samuel Fricker (FHNW)

Martin Bauer (NEC)

Martin Bauer (NEC),

Rémi Druilhe (CEA),

LoRa-based asset tracking

Integrated new contributions into consolidated

version and created a final version

HyoKeun Choi (SDS)


V1.0 Final review and quality check Franck Le Gall (EGM)

Table of contents

Executive summary _________________________________________ 7

Authors ______________________________________________________ 8

Glossary _____________________________________________________ 9

1 Introduction _____________________________________________ 10

1.1 Positioning in the Project ______________________________________ 10

1.2 Deliverable Contribution _______________________________________ 10

2 Semantic Interoperability _______________________________ 11

3 Semantics in Underlying IoT Platforms _________________ 13

3.1 Semantics in oneM2M __________________________________________ 13

3.1.1 Semantic Modelling in oneM2M __________________________________ 13

3.1.2 Semantic Functionality in oneM2M ______________________________ 15

3.2 Semantics in FIWARE __________________________________________ 17

3.2.1 Semantic Modelling in FIWARE ___________________________________ 17

3.2.2 Semantic Functionality in FIWARE _______________________________ 19

4 Enhanced Semantic Modelling __________________________ 21

4.1 Semantic Modelling for Smart City Use Case _________________ 21

4.1.1 Smart Parking ____________________________________________________ 21

4.1.2 Bus Information System __________________________________________ 32

4.2 Semantic Modeling for Smart Skiing Use Case _______________ 40

4.2.1 Traffic monitoring ________________________________________________ 41

4.2.2 Asset tracking ____________________________________________________ 41

4.2.3 Conquer the slope ________________________________________________ 42

4.3 Semantic Modeling for Crowd Mobility ________________________ 43

5 Components Enabling and Utilizing Semantics _________ 49

5.1 Adaptive Semantic Module ____________________________________ 49

5.1.1 Architectural Overview __________________________________________ 50

5.1.2 General ASM Interactions in Semantic-driven Approach ________ 51

5.1.3 ASM for Plain Information from Semantically Annotated oneM2M

Resources ________________________________________________________________ 52

5.1.4 ASM for Semantic Source Information ___________________________ 53

5.1.5 Semantic Information Discovery and Dynamic Self-adaptation _ 54

5.2 Semantic Annotator ___________________________________________ 55

5.3 Self-Adaptive Recommendation (SAR) System _______________ 56

5.3.1 QoI Monitor _______________________________________________________ 57

5.3.2 IoT Recommender ________________________________________________ 59

5.3.3 Adherence and Trust Monitors ___________________________________ 60

6 Conclusions _____________________________________________ 62

7 References ______________________________________________ 63

Executive summary

This deliverable describes both the semantic models, in the form of ontologies, and the semantic

interoperability components required for achieving semantic interoperability between the platforms

used in Wise-IoT. As part of this deliverable the respective components and ontologies are made

available to the consortium to be used for implementing the Wise-IoT use cases.

The key component for interoperability between the platforms is the Morphing Mediation Gateway

whose architecture and general modules are described in Deliverable D2.2, whereas this deliverable

focuses on the semantic aspects of the Morphing Mediation Gateway (MMG), in particular the use of

semantics for flexible and dynamic translation between representations in the Adaptive Semantic

Module (ASM). The core platforms used in Wise-IoT are the oneM2M platform, which instantiates the

Integration and Management Layer, and the NGSI-based FIWARE Broker GEs, which instantiate the

Information Access Layer. The layers have been identified in the Wise-IoT Layered Architecture View,

which is described in detail in Deliverable D1.2.

This deliverable presents the ontologies that have been developed or re-used for the different use

cases and the Self-Adaptive Recommendation System (SAR) of Wise-IoT. The role of the ontologies is

to enable semantic interoperability across platforms. The most important aspect is to agree on the

underlying concepts, which is what an ontology is used for. In addition, there needs to be alignment

with the underlying information models of the respective platforms. For oneM2M this is the oneM2M

Base Ontology; for the FIWARE platform it is the NGSI context information model. To achieve

interoperability, the modelling of information has to be based on the core concepts of these

information models. This is especially relevant for the NGSI Context Information model, which is based

on the concepts of Entity and Attribute. Fortunately, the corresponding concepts of Thing and

ThingProperty exist in the oneM2M Base Ontology, so a common model can be achieved. In summary,

as long as the underlying concepts are the same and these are in line with the information model

assumptions of the underlying platforms, a translation between different representations is possible.

Finally, the actual semantic components are introduced. The focus is on the components providing

semantics and enabling semantic interoperability, but the deliverable also introduces platform

components utilizing the semantic information, in particular the components of the SAR. The key

component for supporting semantic interoperability is the Adaptive Semantic Module (ASM) of the

Morphing Mediation Gateway that in Release 2 replaces the standalone Semantic Meditation Gateway

(SMG) used in Release 1. In its initial configuration, it is used to translate semantically annotated

information from a oneM2M source system to an NGSI-based FIWARE target system. The Semantic

Annotator can be used to semantically annotate existing information in a oneM2M system, enabling

the ASM to do its automatic translation from oneM2M to the NGSI information model used in FIWARE.

The SAR consists of a number of components which enable or utilize semantics. The QoI Monitor

enables semantics by providing a semantic web quality framework that classifies the data quality and

calculates an information quality score. The IoT Recommender utilizes semantics for offering

recommendations for points of interest such as parking spots and pathways. The Adherence Monitor is

a sensor to detect invalid assumptions in the IoT recommendations, the user’s preferences, the

pathway network, and the functioning of IoT sensors. Finally, the Trust Monitor is a sensor to obtain

users’ trust ratings and feedback.

Authors

Chapter Author (Organisation)

Executive Summary Martin Bauer (NEC)

1 Introduction SeungMyeong Jeong (KETI)

2 Semantic Interoperability Martin Bauer (NEC)

3.1 Semantics in oneM2M SeungMyeong Jeong (KETI)

3.2 Semantics in FIWARE Martin Bauer (NEC)

4.1 Semantic Modelling for Smart City Use Case Carmen López (UC)

4.2 Semantic Modelling for Smart Skiing Use Case Rémi Druilhe (CEA), HyoKeun Choi

(SDS)

5.1 Adaptive Semantic Model Martin Bauer (NEC)

5.2 Semantic Annotator Komal Gilani (SJU)

5.3 Self-Adaptive Recommender (SAR) with QoI Monitor and IoT

Recommender

Hamza Baqa (EGM),

Samuel Fricker (FHNW),


6 Conclusions Martin Bauer (NEC)

Glossary

Term or Abbreviation Definition (Source)

ASM Adaptive Semantic Module

GSMA Groupe Speciale Mobile Association

MMG Morphing Mediation Gateway

NGSI Next Generation Service Interface

OMA Open Mobile Alliance

Introduction

10

1 Introduction

Among a variety of IoT technologies, semantics is one of the most promising ones that is being studied

in many research areas and bodies involving standardization. One of the strengths of using semantic

technology is to enhance interoperability. However, many of the interworking technologies do not rely

on semantics or are not being used in the field as opposed to non-semantic interoperability schemes.

Wise-IoT aims to fulfil interoperability between different IoT technologies, especially two major IoT

platforms oneM2M and FIWARE, with the help of semantics and demonstrates it with use case

deployments. With this approach, it will be proved how semantics in different technologies can be

leveraged to realise interoperability of heterogeneous IoT technologies.

1.1 Positioning in the Project

As the project name - Worldwide Interoperability for Semantics IoT (WISE-IoT) states, the semantic

interoperability is one of the biggest goals and so the components specified in this deliverable play the

pivotal roles in the whole project as well as in WP2.

The semantic components are integrated with the other Wise-IoT components in WP3 with improved

dynamicity and flexibility in R2. Then those are deployed in real sites and assessed in WP4.

1.2 Deliverable Contribution

This deliverable describes the second release of the semantic interoperability components developed

in WP2 to be used as part of the Wise-IoT use cases.

This document is organized as follows:

Chapter 2 defines the concept of semantic interoperability in the Wise-IoT project perspective. It

points out the importance of semantic modeling in each of the IoT technologies (i.e. oneM2M and

FIWARE) and the use of a common ontology definition for interoperability.

Chapter 3 illustrates semantic modeling and functionalities supported by oneM2M and FIWARE. This is

the starting point of interworking components using semantics in this deliverable.

Chapter 4 specifies information modeling of Wise-IoT use cases (e.g. smart parking). This has been

updated from R1 with further modeling details (e.g. data formats) and minor model updates.

Chapter 5 explains Wise-IoT components in detail that enable or utilize semantic information. The

Adaptive Semantic Module as a core concept of R2 dynamic self-adaptive interoperability is described

for its architecture overview and work flows including the use of semantic functionalities illustrated in

Chapter 3. The oneM2M semantic annotator component is also described to show how the annotation

is being done complying to the oneM2M specification. The SAR consists of a number of components

which enable or utilize semantics, including the QoI Monitor, the IoT Recommender, the Adherence

Monitor and the Trust Monitor.

Chapter 6 provides the conclusions of this deliverable.


11

2 Semantic Interoperability

Semantic interoperability is a key element of the Wise-IoT approach to enable the integration of

standard-based IoT platforms and technologies.

Interoperability is “the ability of two or more systems or components to exchange data and use

information” [1]. Semantic interoperability more specifically “means enabling different agents,

services, and applications to exchange information, data and knowledge in a meaningful way, on and

off the Web” [2].

Semantics is the study of meaning, so “Semantic interoperability is achieved when interacting systems

attribute the same meaning to an exchanged piece of data, ensuring consistency of the data across

systems regardless of individual data format.” [3]

So the important aspect about semantic interoperability is that the same meaning is attributed to

information, even if the respective representation is different. The underlying idea of using semantic

interoperably for integrating different platforms thus is: given that the semantics is known, the

transformation between different known representations can be automated. Information from one

platform in one representation can be automatically made available in a different representation on

another platform.

For this purpose, the semantic modelling has to be made explicit when storing the information in the

respective platforms. This can be done in the form of semantic annotations in the oneM2M platform

and by using an ontology-based typing in the NGSI-based FIWARE enablers. The details of the

modelling and storage of information in the respective platforms is discussed in Section3.

To enable semantic interoperability across platforms, common concepts need to be agreed, which is

done in the form of ontologies. For each of the FIWARE use cases, an ontology has been defined plus

how the modelled information is represented on the respective platforms. In some cases, the

information already exists in given deployments or there are existing domain specific models like those

of GSMA [4] and schema.org [5] on which FIWARE built some harmonized schemas for the Internet of

Things [6] [7]. These efforts have resulted in the availability of some data models for differentkinds of

entities such as environmental, parking [6], parks and gardens, street lighting, points of interest,

transportation [7], weather or waste management. In these cases, the Wise-IoT ontologies

conceptually follow and, where necessary, enhance these models to be compliant with the state-of-

the-art in the respective domain. So, even though, all ontologies model entity types and their

attributes and thus have a consistent structure, consistency with existing domain ontologies is

considered more important than complete consistance across Wise-IoT domain ontologies.

The components of the Self-Adaptive Recommender system (SAR) have a diverse set of roles. The IoT

Recommender is comparable to a use case application and utilizes a subset of the use case

applications’ ontologies, combine them with concepts from the FIESTA-IoT ontology, and introduce

concepts reflecting insights about the IoT system that are obtained during the runtime of the use case

applications. The Adherence and Trust monitors are sensors that produce insights into the validity of

IoT recommendations and IoT data displayed to the user. The QoI Monitor is a framework for

classifying data quality problems and calculating information quality scores according to the five

dimensions syntactic validity, semantic accuracy, consistency, conciseness, and completeness.

As a start, we work with the assumption that each use case models its own concepts. In particular,

there has been existing information on the use case sites, which was used as a basis for the conceptual


12

modelling. However, it is clear that the broader the use cases become, the more likely there are

common concepts. In this case. a mapping between the concepts would be defined and reasoning

would allow us finding instances of a given concept even if they were defined according to another

concept, following the mapping between the concepts. This enables the reuse of information across

use cases and application domains, enabling a true Internet of Things.

Semantics in Underlying IoT Platforms

13

3 Semantics in Underlying IoT Platforms

The main IoT Platforms used in Wise-IoT to instantiate the Integration and Management Layer and the

Information Access Layer [8] respectively are oneM2M and FIWARE. In the following the semantic

modelling and the semantic functionalities supported by each platform are described.

3.1 Semantics in oneM2M

Section 3.2.1 illustrates how information can be semantically modelled and Section 3.2.2 explains

semantic functionalities that enable access to semantic information in oneM2M platforms.

3.1.1 Semantic Modelling in oneM2M

The oneM2M platform, which resides in the Integration and Management Layer in the Wise-IoT

system, provides semantic information management.

Information modeling with oneM2M provided resource types depends on the design of each service.

The oneM2M specification provides flexibility in structuring resources according to different resource

hierarchiesin order to represent different services. In general, the resource tree consists of <AE>

resource on top of its service as the service application representation and it has one more more

<container> resources to contain different service/sensing data. Real service/sensing data is stored in

<contentInstance> resource. It is also supported to represent nested <container> resources which

allows structured data concepts in usage case (e.g. a building data container has each floor container,

and it has room containers for room temperature data instances).

In oneM2M, semantic and non-semantic information are stored seperated in different resources.

Semantic information is stored in a <semanticDescriptor> resource while non-semantic information is

stored in other resource instances (e.g. <AE>, <container>, <contentInstance> resource). As the name

says, a <semanticDescriptor> resource describes the other non-semantic resource. In oneM2M

resource hierarchy and relation, a child <semanticDescriptor> resource describes its parent resource

(e.g. <AE>, <container>, <contentInstance> resource).

The following figure shows the oneM2M resource tree design example of Wise-IoT smart parking use

case including <semanticDescriptor> resources. ParkingSpot, OnStreetParking and OffStreetParking

information models designed in Section 4.1.1 are mapped to individual containers under the parking

service application. Semantic information for each model is stored as a child <semanticDescriptor>

resouce.

For instance, each parking spot (e.g. <spot> resource) consists of status and info sub-containers. This

shows the flexiblity of oneM2M resource tree design and it was chosen for applications requirements.

Sometimes an applications just wants to get the occupancy status of a parking spot, and it may want to

retrieve meta information (e.g. allowed permit) of the parking spot. For this application need, though

the information of one model is split into more than one sub-container hence different content

instances, semantic annotation for one is contained in a single resource. The semantic annotator in

Section 5.2 creates and updates the <semanticDescriptor> resources. Each semantic annotation for

parking spot and lot isinterpreted and stored in the targeted system (e.g. FIWARE Context Broker) by

aMorphing Mediation Gateway using an appropriate MMG Module, e.g. the Adaptive Semantic

Module (ASM) for mapping from oneM2M to FIWARE.


14

Note that names that are not in pointy brackets are fixed names by service design to ease

implementation involving different oneM2M APIs and interaction with the other components in Wise-

IoT. Also note that parkingSpot, onStreetParking, offStreetParking are collection resources that are

widely used in RESTful designs.

Figure 1. oneM2M resource tree for smart parking use case including semantic annotations

As explained already, it is flexible to design which information or resource can be semantically

annotated. In this parking example, each object (i.e. parking spot, on street parking lot, off street

parking lot) has one semantic annotation as described in the figure above. The following is the

example of semantic description that is contained the descriptor attribute of <semanticDescriptor>

resource of a parking pot in RDF/XML format. Note that this description follows the ontology given in

Section 4.1.1.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:owl="http://www.w3.org/2002/07/owl#"


15

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:park="http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl" xmlns:xsd="http://www.w3.org/2001/XMLSchema#"> <park:ParkingSpot rdf:about="http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#parkingSpot1"> <park:hasId rdf:datatype="http://www.w3.org/2001/XMLSchema#string">abcded</park:hasId> <park:hasType rdf:datatype="http://www.w3.org/2001/XMLSchema#string">ParkingSpot</park:hasType> <park:hasDateModified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTimeStamp">2017-04-18T02:23:30Z</park:hasDateModified> <park:hasCategory rdf:datatype="http://www.w3.org/2001/XMLSchema#string">onstreet</park:hasCategory> <park:hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string">parkingSpot1</park:hasName> <park:hasRefParkingSite> <park:OnStreetParking rdf:about="http://www.semanticweb.org/wise-iot/ontologies/2017/1/parkingOntology.owl#ketiLobbyPark"/> </park:hasRefParkingSite> <park:hasLocation> <park:hasLocationType rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Point</park:hasLocationType> <park:hasCoordinates> <park:hasLongitude rdf:datatype="http://www.w3.org/2001/XMLSchema#double">127.160729</park:hasLongitude> <park:hasLatitude rdf:datatype="http://www.w3.org/2001/XMLSchema#double">37.404143</park:hasLatitude> <park:hasCoordinates> </park:hasLocation> <park:hasStatus> <park:hasStatusValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string">free</park:hasStatusValue> <park:hasStatusTimeStamp rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2017-04-18T02:23:30Z</park:hasStatusTimeStamp> </park:hasStatus> </park:ParkingSpot> </rdf:RDF>

Figure 2. Example of semantic description stored into the descriptor attribute of a <semanticDescriptor> resource

3.1.2 Semantic Functionality in oneM2M

The oneM2M platform provides filtering/discovery and update functionalities on semantic description

using SPARQL [9] as well as semantic annotation in <semanticDescriptor> resources.

Annotated semantic information is stored in <semanticDescriptor> resource and it is defined as below

[10]. Most importantly, the descriptor attribute contains semantic annotation in standard formats (e.g.

RDF/XML) and its format information is indicated in the descriptorRepresentation attribute. The

ontologyRef explains the reffered ontology for annotation. If it is omitted, the same attribute value of

the parent resource is used to determine the ontology. When the semanticOpExec attribute value is

carried in an UPDATE request targeting this descriptor resource, the value which is a SPARQL query is

performed by the platform and it updates the descriptor attribute value as a result.


16

<semanticDescriptor>

1descriptor

0..1 (L)

0..1ontologyRef

<subscription>

relatedSemantics

0..n

1descriptorRepresentation

0..1semanticOpExec

Figure 3. onem2M semanticDescriptor resource type definition

For the semantic filtering/discovery, oneM2M provides the specific filter condition (i.e. semanticFilter)

in Filter Criteria reqeust paramter. This filter condition carries a SPARQL query and in HTTP binding it

appears in query component along with the other filter conditions. The below is the example for the

partial oneM2M request primitive and HTTP binding of discovering resources whichcontain

information about a Thing of type Car based on the concept defined in the "myOnt" ontology.

Resource address(es) that includes child <semanticDescriptor> resource(s) which matches the SPARQL

query will be returned and accessed by the other requests on them (e.g. RETRIEVE) for further

processing.

To: CSE1234/RCSE78 Filter Criteria: semanticsFilter = PREFIX rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# PREFIX myOnt: http://www.onem2m.org/ontology/myontology# SELECT ?car WHERE { ?car rdf:type myOnt:Car }

Figure 4. SPARQL query in oneM2M primitive

Request-Target: /CSE1234/RCSE78?smf=PREFIX%20rdf%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23%3E%20PREFIX%20myOnt%3A%20%3Chttp%3A%2F%2Fwww.onem2m.org%2Fontology%2Fmyontology%23%3E%20SELECT%20%3Fcar%20WHERE%20%7B%20%3Fcar%20%20rdf%3Atype%20myOnt%3ACar%20%7D

Figure 5. SPARQL query in oneM2M HTTP binding

The discovery target can be all sub-resources of a targeted resource as above example or specific

grouped resources. To support the latter case, applications can create a group with members which

has <semanticDescriptor> child resource(s) and send the SPARQL query in semanticsFilter condition

targeting the child <semanticFanOutPoint> resource of the <group> resource. When semantic

annotations are distributed in a resource tree or even placed in different platforms, it can be beneficial

to use a <semanticFanoutPoint> resource as well as a <group> resource.

For instance, if the semantic discovery request is sent targeting the “iotParking” resource in Section

3.1.1 example resource tree, the platform will perform matching/filtering for all <semanticDescriptor>

resources in the tree. This can be used to find out interested parking spots or parking lots stored in

oneM2M platform using SPARQL.


17

In Release 3, which is the latest version and estimated to be published in January 2018, of oneM2M

specification includes extended semantic functions such as semantic query, mashup, and semantic

validation.

Semantic query in Release 3 is different from semantic discovery in previous release. Semantic query

returns matching semantic triple data while semantic discovery returns addresses of parent resource(s)

of which contains the interested semantic description. Semantic query is more advanced since it

derives knowledge from distributed semantic information in different <semanticDescriptor> resources.

Also, it may be inconvenient relying on semantic discovery because there should be additional

procedures to retrieve interested <semanticDescriptor> resources by applications in the end.

Semantic validation provides triple data validation against a specific ontology which can be stored in

oneM2M platform or externally. By semantic mashup, existing semantic information mash up can be

executed and stored for further usages.

Note that in Wise-IoT semantic functions of Release 3, which is not completed and published yet, are

not implemented but filtering and discovery are supported for oneM2M and FIWARE interworking.

3.2 Semantics in FIWARE

In Section 3.2.1 it is shown how information can be modelled on a semantic basis and in Subsection

3.2.2 how semantics is used in FIWARE, in particular in the context of the NGSI interfaces [1].

3.2.1 Semantic Modelling in FIWARE

The FIWARE Broker GEs that Wise-IoT utilizes to implement the Information Access Layer are based on

the OMA NGSI context information model shown in Figure 6 [11]. According to this model, the world

consists of (context) entities. Entities have a type and they are described by (context) attributes which

have a name, a type, a value and can have meta data.

Figure 6. NGSI context information model

Even though NGSI does not enforce a concrete modelling approach for types, attribute names,

attribute types, metadata etc., these can be modelled as an ontology. The entity types can be


18

modelled in a type hierarchy with Context Entity being the root of the hierarchy. Figure 6shows Person,

Group, Place, Event and Thing as high level entity types, which can be further refined by subtypes. The

EntityType URI in the entity representation then refers to the ontology concept defining this type. The

entity type can also define what attributes of what type an entity can have, e.g. a car can have a

current speed(represented as a float, measured in km/h), whereas a house may have a water

consumption.

Figure 7. Example entity type hierarchy for Smart Parking use case

Figure 7 shows an example of an entity type hierarchy for the Smart Parking use case, whose semantic

modelling will be detailed in Section4.1.1. The ContextEntity and Parking classes shown in italics are

treated as abstract, i.e. there will not be direct instances, but attributes defined for them are inherited

by all subclasses and they can be used in requests.

Note that the ContextEntity type can be defined as equivalent to the Thing class in the oneM2M Base

Ontology [12]. In this way the same classes can be used in FIWARE and in the oneM2M semantic

modelling. This provides the foundation for achieving semantic interoperability.

Figure 8 shows the entity type OnStreetParking with the names of all the attributes it can have. The

attribute names in italics show the ones that are inherited from super types, i.e. Parking(e.g.

chargeType, requiredPermit) and ContextEntity(e.g. dateModified, location).


19

Figure 8. Names of attributes an entity of type OnStreetParking can have

3.2.2 Semantic Functionality in FIWARE

The OMA NGSI context interfaces are built on the context information model shown in Figure 6 [11].

Applications can specify what information they require, according to this model.

Figure 9. OMA NGSI – synchronous query

Figure 9 shows the synchronous query interaction, whereas Figure 10 shows the asynchronous

subscription/notification based interactions. In both cases, applications can specify the entities and

attributes they are interested in. In case the entities are already known, they can be specified using

their entity identifier. If not, entities can be discovered using their entity type and, possibly, an entity

identifier pattern. To limit the result set for a discovery operation, scopes can be used. Of particular

importance is the location scope, i.e. specifying a geographic area, as geographic coordinates, in which

the specified entities are to be found.


20

Figure 10. OMA NGSI – asynchronous subscription/notification

Both the Orion Context Broker and the Aeron IoT Broker implement this interface. Since entity types

and attributes can be semantically modelled, it can be argued that NGSI enables a semantic

specification of entities and offers both synchronous query-based interactions as well as asynchronous

subscription/notification-based interactions.

The Aeron IoT Broker, in combination with the Knowledge Server, enables the support of sub-type

matching, i.e. when requesting entities of a certain type, entities of all subtypes are also returned. For

example, if entities of the (abstract) type Parking as shown in Figure 7, entities of both type

OnStreetParking and OffStreetParking are returned. The Knowledge Server directly uses ontology

information to enable this, i.e. the Knowledge Server requires the Smart Parking ontology.

Enhanced Semantic Modelling

21

4 Enhanced Semantic Modelling

In this section, the semantic modelling for the different use cases is presented. The idea is to define

the respective underlying concepts according to an ontology. The information modelled according to

these concepts can then be mapped to different representations, allowing the automatic translation

between these representations using a Morphing Mediation Gateway module. Each model is use case

focused, taking into account existing information from the relevant sites, i.e. the adaption effort

should be minimized. For cross-use case use, additional mappings, supported by reasoning will be

needed.

4.1 Semantic Modelling for Smart City Use Case

4.1.1 Smart Parking

The Smart Parking use case in Wise-IoT provides an application based solution which, based on the

parking information from Busan and Santander cities, has the purpose of demonstrating data

interopreability betweenKorea and Europe through the Wise-IoT platform. Thosepilots were designed

to enhance the parking experience of the user by providing them parking information and route

recommendations. A complete description of the use case can be found in D1.1 [13].

These applications will provide different information to the user such as the availability of parking

spots, routes to recommended parking spots based on different parameters such as traffic, parking

areas information, etc. Aiming to achieve the previously mentioned data interoperability, this parking

related information hasto be designed under a concrete data model in order tobe translated by the

Wise-IoT Morphing Mediation Gateway, before be finally stored in the Wise-IoT Information Access

layer.

As it was specified in the previous document D2.4 [14], the model used to structure the information is

NGSI, which allows the representation of the entity (the parking lot, the parking area, traffic flow

observation) by defining its entity id and its entity type. Also, the entity is defined with a set of

attributes that represent the properties of the entities (status, location, category, etc.), defined by a

name, a type and a value. Finally, each attribute can include metadata (if required), which provides

extra information of the entity such as timestamp, unit of measurement, etc. In addition, the

underlying format used to represent this data structure is JSON.

Looking at the semantic representation of the information, FIWARE is developing a Data Model,

inspired by the GSMA data models and schema.org, in order to produce harmonized schemas for the

Internet of Things. These efforts have been translated in the availability of some data models for

different nature kind of entities such as environmental, parking, parks and gardens, street lighting,

points of interest, transportation, weather or waste management. However, there are multiple entities

that at the time of writing have not yet been defined. In the case of parking information, the FIWARE

Data Model specifies the semantic representation of all entities of Wise-IoT interest: the parking spot,

the parking area and the traffic information (parkingSpot, OnStreetParking and OffStreetParking, and

TrafficFlowObserved).

In D2.4, it was provided the specification of the data model to be used for these entities, with their

types and descriptions. In the following lines there will be provided the update of these previous

specifications. The attributes to be used and their description will not change significantly in this


22

update. However, it will be added a new column in order to specify the type. In the previous version of

the document, the “Expected Type” column provided the type to be expected for the attribute: String,

List<Text>, Integer, etc. The issue found when injecting (registering) these entities to the Orion Context

Broker in the Information Access layer was that the broker uses a concrete set of types: Text, Boolean,

Number and Structured Value. Because of that, we are going to add a new column in order to specify

the type to be used to register and update the attributes of the entities in the Context Broker, and we

will maintain the previous “expected type” column as “Type format” in order to explain exactly how

the attribute will look like, since the “Structured Value” does not provide too much information about

the format.

Starting with the definition of the ParkingSpot entity, the FIWARE Data Model provides a complete list

of attributes for defining many parking spot characteristics. In addition, each of the attributes are

described with its name, its description, its type and an indication about whether the attribute is

mandatory or optional for the correct entity description. From this list, a concrete set of attributes

have been selected to describe the resources deployed in the Santander and Busan facilities: identifier,

type, dateModified, name, status, location, category and refParkingSite. The following description of

these attributes has been extracted from [6]. Note that except for id and type, the properties in the

following tables (i.e., Table 1, Table 2, Table 3 and Table 4) areattribute names in the FIWARE data

models.Table 1 below presents the properties of ParkingSpot entity.

Table 1. Properties of ParkingSpot entity

Property Type Type format Description

id Text String Entity’s unique identifier

type Text String Entity’s type. For this case of parking spot definition the value for this attribute is “ParkingSpot”

dateModified ISO8601 DateTime (ISO 8601) Indicates the last update of the entity (e.g. 2017-06-30T06:22:00.00Z)

name Text String The name used to identify the parking spot

status Text String Indicates the status of the parking spot in terms of occupancy. Its possible values are “occupied”, “free”, “closed” or “unknown”

location geo:json geo:json Provides the geolocation of the parking spot

category StructuredValue String Indicates the category of the parking spot. Possible values can be onstreet (onstreet parking site), offstreet (offstreet parking site), or other value that can be needed by the application

refParkingSite Text String Provides a reference to an entity OnStreetParking or OffStreetParking depending on the value of the category property.


23

Figure 11 depicts an example of a parking spot entity in JSON representation following the FIWARE

Data Model.

In order to provide more valuable information to the user, the specification of different parking areas

in Santander is needed. In that way,the parking areas covered with sensors in the city are registered

following the FIWARE Data Model specified for this type of entity: OnStreetParking. This data model

provides, among others, the needed attributes for the correct description of the parking area entity:

identifier, type, location, category, dateModified, name, chargeType, requiredPermit, permitActive

Hours, allowedVehicleType, areBordersMarked, totalSpotNumber and occupancyDetectionType.

{

"id": "urn:entity:santander:parking:parkingSpot:3601",

"type": "ParkingSpot",

"category": {

"type": "StructuredValue",

"value": ["onstreet"],

"metadata": {}

},

"dateModified": {

"type": "ISO8601",

"value": "2017-06-30T06:22:00.00Z",

"metadata": {}

},

"location": {

"type": "geo:json",

"value": {

"type": "Point",

"coordinates": [-3.798970208, 43.46305129]

},

"metadata": {}

},

"name": {

"type": "Text",

"value": "parkingSpot3601",

"metadata": {}

},

"refParkingSite": {

"type": "Text",

"value": "urn:entity:santander:parking:onStreet:StaLuciaEast",

"metadata": {}

},

"status": {

"type": "Text",

"value": "free",

"metadata": {}

}

}

Figure 11. Example of ParkingSpot entity following FIWARE Data Model


24

Following a brief description of these attributes is provided, but the complete description and the rest

of the list of attributes provided by FIWARE Data Model for OnStreetParking can be found in [6].Table

2 presents the properties of OnStreetParking entity.

Table 2. Properties of OnStreetParking entity



type Text String Entity’s type. For this case of parking area it will be “OnStreetParking”

dateModified ISO8601 DateTime Indicates the last update of the entity (e.g. 2017-06-30T05:28:05.00Z)

name Text String The name used for identify the parking area

location geo:json geo:json Provides the geolocation of the parking area

category StructuredValue List<Text> Indicates the category of the parking area. Possible values can be: forDisabled, forResidents, forLoadUnload, onlyWithPermit, forELectricalCharging, free, feeCharged, blueZone, greenZone, taxiStop, shortTerm, mediumTerm, or other value that can be needed by the application.

chargeType StructuredValue List<Text> Provides the type of charge/s performed by the parking site. Possible values can be: flat, minimum, maximum, additionalIntervalPrice, seasonTicket, temporaryPricefirstIntervalPrice, annualPayment, monthlyPayment, free, unknown, other, or other value that can be needed by the application.

requiredPermit StructuredValue List<Text> Indicates the permit/s that could be needed to park in that area. Possible values are: fairPermit, governmentPermit, residentPermit, disabledPermit, blueZonePermit, careTakingPermit, carpoolingPermit, carSharingPermit, emergencyVehiclePermit, maintenanceVehiclePermit, roadWorksPermit, taxiPermit, transportationPermit, noPermitNeeded; or other value that can be needed by the app. Also null is possible if no permit is required.

permitActiveHours StructuredValue StructuredValue This property allows pointing to situations when a permit is only required at concrete hours/days. This structure must provide a value per each required permit, indicating when the


25

permit is active. More info about the syntax can be found in [6].

allowedVehicleType

Text String Allowed vehicle type. Possible values are: bicycle, bus, car, caravan, carWithCaravan, carWithTrailer, constructionOrMaintenanceVehicle, lorry, moped, motorcycle, motorcycleWithSideCar, motorscooter, tanker, trailer, van, anyVehicle.

areBordersMarked Boolean Boolean This attribute display if the parking spots are delimited or not (for example with painted lines)

totalSpotNumber Number Integer Number of spots offered by the parking area. Possible values are any positive integer >=0.

occupancyDetectionType

StructuredValue List<String> Methods for detecting the occupancy of the parking spot. Possible values for this property are: none, balancing, singleSpaceDetection, modelBased, manual, or other value needed by the application.

Figure 12 provides an example of an on-street parking area entity in JSON representation following the

FIWARE Data Model.

{ "id": "urn:entity:santander:parking:onStreet:StaLuciaEast", "type": "OnStreetParking", "allowedVehicleType": { "type": "Text", "value": "car", "metadata": {} }, "areBordersMarked": { "type": "Boolean", "value": false, "metadata": {} }, "availableSpotNumber": { "type": "Number", "value": 13, "metadata": {} }, "category": { "type": "StructuredValue", "value": [“feeCharged", "blueZone"], "metadata": {} }, "chargeType": { "type": "StructuredValue", "value": ["temporaryFee"], "metadata": {}


26

}, "dateModified": { "type": "DateTime", "value": "2017-06-30T05:28:05.00Z", "metadata": {} }, "name": { "type": "Text", "value": "Sta Lucia East", "metadata": {}

}, "location": { "type": "geo:json", "value": { "type": "LineString", "coordinates": [ [-3.79858, 43.464448], [-3.796919, 43.464694] ] }, "metadata": {} }, "occupancyDetectionType": { "type": "StructuredValue", "value": ["singleSpaceDetection"], "metadata": {} }, "permitActiveHours": { "type": "StructuredValue", "value": { "blueZonePermit": "Mo, Tu, We, Th, Fr 10:00-14:00 16:00-20:00 Sa 10:00-14:00" }, "metadata": {} }, "refParkingSpot": { "type": "StructuredValue", "value": [ "urn:entity:santander:parking:parkingSpot:3856",

"urn:entity:santander:parking:parkingSpot:3857" ], "metadata": {} }, "requiredPermit": { "type": "StructuredValue", "value": ["blueZonePermit"], "metadata": {} }, "totalSpotNumber": { "type": "Number", "value": 29, "metadata": {}


27

} }

Different from Europe, in South Korea, most of the parking lots are off street parking type. Data from

parking lots in Busan, for example, will be represented as OffStreetParking entity which is also defined

in FIWARE Data Model [6]. When users search for empty parking spots, it is expected that available

parking spots per (off street) parking lot is shown on applications. The OffStreetParking data model

specifies parking lot meta data as well as available sport number. This data model includes the

attributes listed in the following table with brief descriptions. The complete description and the rest of

the list of attributes provided by FIWARE Data Model for OffStreetParking can be found in [6].Table 3

presents the properties of OffStreetParking entity.

Table 3. Properties of OffStreetParking entity



type Text String Entity’s type. For this case of parking area it will be “OffStreetParking”

dateModified ISO 8601 DateTime (ISO 8601)

Indicates the last update of the entity (e.g. 2017-01-29T11:23:53.000Z)

name Text String The name used for identify the parking area


category StructuredValue List<Text> Indicates the category of the parking area. Possible values can be: forDisabled, forResidents, forLoadUnload, onlyWithPermit, forELectricalCharging, free, feeCharged, blueZone, greenZone, taxiStop, shortTerm, mediumTerm, or other value that can be needed by the application.

chargeType StructuredValue List<Text> Provides the type of charge/s performed by the parking site. Possible values can be: flat, minimum, maximum, additionalIntervalPrice, seasonTicket, temporaryPricefirstIntervalPrice, annualPayment, monthlyPayment, free, unknown, other, or other value that can be needed by the application.

requiredPermit StructuredValue List<Text> Indicates the permit/s that could be needed to park in that area. Possible values are: fairPermit, governmentPermit, residentPermit, disabledPermit, blueZonePermit, careTakingPermit, carpoolingPermit, carSharingPermit, emergencyVehiclePe

Figure 12. Example of on street parking entity definition


28

rmit, maintenanceVehiclePermit, roadWorksPermit, taxiPermit, transportationPermit, noPermitNeeded; or other value that can be needed by the app. Also null is possible if no permit is required.

allowedVehicleType

Text String Allowed vehicle type. Possible values are: bicycle, bus, car, caravan, carWithCaravan, carWithTrailer, constructionOrMaintenanceVehicle, lorry, moped, motorcycle, motorcycleWithSideCar, motorscooter, tanker, trailer, van, anyVehicle.

availableSpotNumber

Boolean Boolean The number of spots available (including all vehicle types or reserved spaces, such as those for disabled people, long term parkers and so on)

totalSpotNumber Number Integer Number of spots offered by the parking area. Possible values are any positive integer >=0.

occupancyDetectionType

StructuredValue List<String> Methods for detecting the occupancy of the parking spot. Possible values for this property are: none, balancing, singleSpaceDetection, modelBased, manual, or other value needed by the application.

openingHours Text String Opening hours of the parking site. E.g. "Mo,Tu,We,Th 09:00-12:00"

refParkingSpot StructuredValue List of <references>

Individual parking spots belonging to this offstreet parking site

aggregateRating Text String Aggregated rating for this parking site

contactPoint Text String Parking site contact point

Figure 13 provides an example of an off-street parking area entity in JSON representation following the

FIWARE Data Model.


29

The traffic information provided within the use case is gathered from different traffic sensors

{

"id": "urn:entity:busan:parking:areaABC",

"type": "OffStreetParking",

"location": {

"type":"Point",

"coordinates":[-3.798427, 43.464039]

},

"category":[

"underground",

"public",

"feeCharged",

"mediumTerm",

"barrierAccess"

],

"dateModified": "2017-01-29T11:23:53.000Z"

"chargeType":["additionalIntervalPrice"],

"requiredPermit":[],

"allowedVehicleType":"car","totalSpotNumber":25,

"availableSpotNumber":5,

"occupancyDetectionType":["singleSpaceDetection"],

"openingHours": "Mo,Tu,We,Th 09:00-12:00",

"refParkingSpot": ["spot1", "spot2"],

"aggregateRating": "3",

"contactPoint": "+82-51-123-4567”

}

Figure 13. Example of off street parking entity definition


30

deployed in the city of Santander. This information is modelled following the Data Model provided by

FIWARE Data Model with the TrafficFlowObserved entity type. This modelling offers the description of

a set of attributes related to traffic flow in a city. From this set of attributes some of them have been

selected to describe the deployed traffic sensors in Santander: identifier, type, location, dateModified,

dateObserved, intensity and occupancy. roadLoad attribute has been added since it is not in the set

provided by the TrafficFlowObserved FIWARE data model. This attribute represents an estimation of

the degree of congestion based on an algorigthm using the intensity and occupancy factors. Following,

a brief description of these attributes is provided, but the complete description and the rest of the list

of attributes provided by FIWARE Data Model can be consulted in [7].Table 4 below presents the

properties of TrafficFlowObserved entity.

Table 4. Properties of TrafficFlowObserved entity



type Text String Entity’s type. For this case of parking area it will be “TrafficFlowObserved”

dateModified ISO8601 DateTime (ISO 8601)

Indicates the last update of the entity (e.g. 2017-07-17T15:04:00.00Z)


dateObserved ISO8601 Duration or DateTime (ISO8601)

Date and time of the observation. It can be represented as a time instant or a duration.

intensity Number Number Number of vehicles detected during the observation period.

occupancy Number Integer Fraction of the observation time where vehicles are occupying the road.

roadLoad Number Integer Estimation of the congestion degree based on an algorithm which uses some parameters such as the intensity and the occupancy


31

Figure 14 provides an example of a traffic sensor entity in JSON representation following the FIWARE Data Model.

{

"id": "urn:entity:santander:traffic:TrafficFlowObserved:1001",

"type": "TrafficFlowObserved",

"dateModified": {

"type": "ISO8601",

"value": "2017-07-17T15:04:00.00Z",

"metadata": {}

},

"intensity": {

"type": "Number",

"value": 480,

"metadata": {}

},

"location": {

"type": "geo:json",

"value": {

"type": "Point",

"coordinates": [-3.8295937,43.4535859 ]

},

"metadata": {}

},

"occupancy": {

"type": "Number",

"value": 18,

"metadata": {}

},

"roadLoad": {

"type": "Number",

"value": 31,

"metadata": {}

}

}

Figure 14. Example of traffic sensor entity


32

Figure 15 represents the ontology schema for the Smart Parking use case.

Figure 15. Ontology schema for Smart Parking use case

4.1.2 Bus Information System

The Bus Information System will provide bus information data to passengers in real-time, which

includes information about buses, bus stops, bus lines, real-time data on current bus locations, and

arrival estimations bus stop in both Busan and Santander. The information will be modelled following

the structure utilized for the semantic modelling in oneM2M and NGSI, respectively. As there are

currently no available semantic representations for bus properties defined in neither oneM2M and

FIWARE, we have developed a general semantic modelling for the bus system. As the semantic

modelling work has already been performed for D2.4, we have included here all necessary semantic

information with updates.

In order to keep the semantic modelling general, we have collaborated to develop a common bus

system dictionary with properties, expected types, and descriptions. Furthermore, to keep the


33

semantic modelling consistent with the required structures from oneM2M and FIWARE, the oneM2M

semantic modelling is based largely upon oneM2M Base Ontology and the FIWARE one follows

FIWARE Data Model. Thus, we have presented within this document two major components of the

Semantic Modelling, which are a dictionary of entities and semantic modelling information including a

figure and JSON examples.

- Dictionary: four entities (set of properties) are designed, including ‘busLine’, ‘busStop’, ‘bus’,

and ‘estimation’. The entity ‘busLine’ defines a bus line, ‘busStop’ defines a bus stop, ‘bus’

defines a bus, and ‘estimation’ defines the arrival estimations of the buses to a bus stop in a

bus line. The entities to use can be chosen depending on the data contents of different sites

(e.g. Busan or Santander).

- Semantic Modelling: a figure which shows the semantic modelling of the bus system in

oneM2M (based on oneM2M Base Ontology) and examples in JSON format for both oneM2M

and FIWARE cases are presented.

As the bus data acquired in Busan and Santander can be different from each other, we have decided to

make the dictionary of entities and semantic modelling general enough to cover the data information

from both sides. As a result, some entities or semantic modelling details may be seen in only one of

the site and not the other.

Dictionary:

busLine: a bus line in which there are bus stops (mandatory) and buses (optional)

Table 5.Properties of busLine entity


refBusStops StructuredValue List<String> The list of all bus stops belonging to the bus line (using the IDs of bus stops, e.g. urn:entity:busan:transport:bus:busStop:<busStopId>)

localID Text String The local ID (shorter form) of the bus line (e.g. ‘104’)

shortID Text String The ID of the bus line (e.g. ‘5200104000’)

name Text String The name of the bus line (e.g PENACASTILLO – PLAZA DE ITALIA)

refStartBusStop

Text String The starting stop of the bus line (using the ID of the bus stop, e.g. urn:entity:busan:transport:bus:busStop:<busStopId>)

refEndBusStop Text String The ending stop of the bus line (using the ID of the bus stop, e.g. urn:entity:busan:transport:bus:busStop:<busStopId>)

busLineType Text String The type of the buses that run on the bus line (e.g. standard)

startTime ISO8601 ISO 8601 (DateTime)

The starting time from which the bus line operates in ISO 8601 date and time format (e.g. 2017-02-05T08:15:30-05:09)

endTime ISO8601 ISO 8601 (DateTime)

The ending time until which the bus line operates, in ISO 8601 date and time format (e.g. 2017-02-05T08:15:30-05:09)

intervalNorm ISO8601 ISO 8601 The interval of buses arrival at a bus stop along


34

(Duration) the bus line in normal days, in ISO 8601 duration format (e.g. P3Y6M4DT12H30M5S)

intervalHoli ISO8601 ISO 8601 (Duration)

The interval of buses arrival at a bus stop along the bus line in holidays, in ISO 8601 duration format (e.g. P3Y6M4DT12H30M5S)

intervalPeak ISO8601 ISO 8601 (Duration)

The interval of buses arrival at a bus stop along the bus line at rush hour, in ISO 8601 duration format (e.g. P3Y6M4DT12H30M5S)

dateModified ISO8601 ISO 8601 (DateTime)

The dateTime when the data has been last modified (e.g. 2017-02-05T08:15:30-05:09)

busStop: a bus stop which belongs to a bus line and in which buses can run

Table 6: Properties of busStop entity


refBuses StructuredValue List<String> The list of all buses heading towards the bus stop (using the IDs of the buses, e.g. urn:entity:busan:transport:bus:bus:<busId>)

shortID Text String The ID of the bus stop (e.g. ‘11161’)

busStopCount StructuredValue List<Integer> The counting number of the bus stop in the bus lines that pass by the bus stop (e.g. in a bus line the first bus stop will be numbered 1, the second one numbered 2, the third one numbered 3, and so on until the last bus stop)

name Text String The name of the bus stop (e.g. city hall)

location geo:json GeoJSON The location of the busStop defined by the GPS coordinates, in GeoJSON format (e.g. [36.372,127.363]).

address StructuredValue Structured Value

The bus stop civic address. The values of this property follows the structure defined in https://schema.org/PostalAddress

direction Text String Indicates the direction of the driving by using the name of an area in that direction

refBusLines StructuredValue List<String> The list of all bus lines that pass by the bus stop

dateModified ISO8601 ISO 8601 (DateTime)

The dateTime when the data has been last modified (e.g. 2017-02-05T08:15:30-05:09)

estimation: estimation of arrivals of buses in relation to a combination of busStop-busLine

Table 7.Properties of estimation entity

Property Type Type format

Description

refBusStop Text String Reference to the correspondent busStop entity (using the ID of the bus stop, e.g. urn:entity:santander:transport:tus:busLine:<busLineId>)

refBusLine Text String Reference to the correspondent busLine entity (using the ID of the bus line, e.g.


35

urn:entity:santander:transport:tus:busLine:<busLineId>)

remainingDistances StructuredValue Array<Integer>

Each value of the array describes the remaining distance of each bus of the line to the busStop. It will have as many positions as buses from the line passing by the busStop. The position in the array indicates the order of arrival (eg. [bus1Distance, bus2Distance, bus3Distance])

remainingTimes StructuredValue Array<Duration>

Each value of the array describes the remaining time of each bus of the line to the busStop. It will have as many positions as buses from the line passing by the busStop. The position in the array indicates the order of arrival (eg. [bus1Time, bus2Time, bus3Time])

endBusStopNames destinationBusLines

StructuredValue Array<String>

Each value of the array describes the destination of each bus of the line to the busStop. It will have as many positions as buses from the line passing by the busStop. The position in the array indicates the order of arrival (eg. [bus1Destination, bus2Destination bus3Destination])

shortID Text String The ID of the bus (e.g. ‘2915’)

remainingStations Number Integer The remaining number of bus stops left until the bus reaches the bus stop specified in refBusStop (e.g. 4)

companyName Text String The name of the company that owns the bus (e.g. SamHoa)

location Text String The location of the bus defined by the GPS coordinates, in GeoJSON format (e.g. [36.372,127.363]).

dateModified ISO8601 DateTime Entity's last update date

FIWARE Semantic Modeling in JSON representation:

The following figure provides an example of an estimation representation.

{ "id": "urn:entity:santander:transport:bus:busArrivalEstimation:7:2", "type": "BusArrivalEstimation", "dateModified": { "type": "ISO8601", "value": "2017-08-01T08:51:33.00Z", "metadata": {} }, "destinationBusLines": { "type": "StructuredValue", "value": [ "CONSUELO BERGES", "CONSUELO BERGES" ], "metadata": {}


36

}, "refBusLine": { "type": "Text", "value": "urn:entity:santander:transport:bus:busLine:2", "metadata": {} }, "refBusStop": { "type": "Text", "value": "urn:entity:santander:transport:bus:busStop:7", "metadata": {} }, "remainingDistances": { "type": "StructuredValue", "value": [ 3363, 3450 ], "metadata": { "uom": { "type": "string", "value": "http://ontology.fiesta-iot.eu/ontologyDocs/m3-lite.owl#Metre" } } }, "remainingTimes": { "type": "StructuredValue", "value": [ "P0DT0H17M12S", "P0DT0H36M46S" ], "metadata": {} } }

Figure 16.Bus-related information modelled according to JSON-based NGSI representation used in FIWARE


37

Semantic Modeling:

Figure 17.Ontology schema for Bus Information use case

Bus schema:

{ "$schema": "http://json-schema.org/draft-04/schema#", "id": "urn:entity:busan:transport:bus:busId:<busId>", "type": "object", "title": "Bus schema.", "description": "An explanation about the purpose of this instance.", "properties": { "refBusStop": { "type": "string", "title": "RefBusStop schema.", "example": "urn:entity:busan:transport:bus:busStopId:<busStopId>", "description": "Reference to the correspondent busStop entity." }, "refBusLine": { "type": "string", "title": "RefBusLine schema.", "example": "", "description": "Reference to the correspondent busLine entity." }, "shortID": { "type": "string",


38

"title": "Bus ID", "example": "2915", "description": "The ID of the bus ." }, "direction": { "type": "string", "title": "Direction schema.", "example": "0", "description": "The direction of the bus ." }, "companyName": { "type": "string", "title": "CompanyName schema.", "example": "Samhoa", "description": "The name of the company that owns the bus ." }, "remainingTime": { "type": "string", "title": "RemainingTime schema.", "example": "PT5M", "description": "The remaining amount of time left until the bus reaches the bus stop specified in refBusStop." }, "remainingDistance": { "type": "integer", "title": "RemainDistance schema.", "example": "100", "description": "The remaining amout of distance left until the bus reaches the bus stop specified in refBusStop, in meters.” }, "remainingStations": { "type": "integer", "title": "RemainStation schema.", "example": "4", "description": "The remaining number of bus stops left until the bus reaches the bus stop specified in refBusStop." }, "location": { "type": "array", "title": "Location schema.", "example": "", "description": "The GPS XY coordination of the bus, in GeoJSON format.", "items": { "type": "GeoJSON", "title": "1 schema.", "example": "[36.372,127.363]", "description": "The GPS XY coordination of the bus." } }, "dateModified": { "type": "string", "title": "DateModified schema.",


39

"example": "2017-11-05T08:15:30-05:00", "description": "The dateTime when the data has been last modified, in ISO8601 DateTime format" } }, "required": ["refBusStop", "refBusLine", “shortID”, "direction", "remainingTime", "remainingDistance", "remainingStation", “dateModified” ] }

Figure 18.JSON schema for bus information

An example of a bus instance:

{ "shortid": "urn:entity:busan:transport:bus:busId:<busId>", "refBusStop":"urn:entity:busan:transport:bus:busStopId:<busStopId>", "refBusLine":"urn:entity:busan:transport:bus:buslineId:<buslineId>", "direction":"0", "remainingTime":"PT5M", "remainingDistance":100, "remainingStations":2, "dateModified":"2017-02-05T08:15:30-05:09”, "locationCoordinates":[36.372,127.363] }

Figure 19.Bus information in JSON


40

4.2 Semantic Modeling for Smart Skiing Use Case

The Smart Skiing environment is a quite new environment in which everything has to be done,

especially the semantic aspect. In the public semantic model repositories, e.g., FIESTA IoT project [15],

W3C, the skiing resort environment, and its specificities, does not exist. Some part of the public

ontologies can be reused, e.g., devices, or adapted, e.g., traffic, but others needs to be defined, e.g.,

ski lifts, ski slopes or even mountain climate or relief.Thus, the proposed ontology in Wise-IoT is far

from being complete and may look limited at a first glance.This project aims at proposing a first

semantic model for this new environment.

Before providing a semantic model for each use cases, a base for the various elements available in this

environment is defined. The proposed semantic model is based on the OpenSnowMap data model

[16]. This model considers specific elements related to the skiing resort equipment such as the aerial

way (e.g., chair lift, drag lift) or the pistes (e.g., downhill, halfpipe). A visual of the semantic model is

proposed in the Figure 20. The full textual semantic model is available in an OWL file in the repository

of the project.

Figure 20. The smart skiing ontology in Protégé

Small modifications have been provided from the previous version, in the D2.4 [14]. Most of the

modification imply the reuse of existing ontologies for various element, especially the devices. Each

smart skiing use case can reuse this ontology. This particular ontology enables to make the link

between the on-the-ground devices, i.e., LoRa band, crowd detector and PIQ Robot, provided by the

edges gateways and the semantic model proposed to model a skiing resort stored in the upper layers

platforms of the project.


41

4.2.1 Traffic monitoring

Due to a strong similarity between the Smart City and Smart Skiing Resort traffic use cases, we assume

that the semantic model is the same with minor variations. The traffic is no more related to the cars

but to the skiers that are at the entrance of the ski lifts. See the Table 8 for further details about this

representation.

Table 8. Properties of TrafficFlowObserved entity


id Text String Entity’s unique identifier.

type Text String Entity’s type. For this case of parking area it will be “TrafficFlowObserved”.

dateModified ISO8601 DateTime (ISO 8601)

Indicates the last update of the entity (e.g. 2017-07-17T15:04:00.00Z).

location geo:json geo:json Provides the geolocation of the monitored area.

dateObserved ISO8601 Duration or DateTime (ISO8601)

Date and time of the observation. It can be represented as a time instant or a duration.

intensity Number Number Number of persons detected during the observation period.

occupancy Number Integer Fraction of the observation time where persons are occupying the road.

skiLiftLoad Number Integer Estimation of the congestion degree based on an algorithm which uses some parameters such as the intensity and the occupancy

4.2.2 Asset tracking

The “assets tracking” use cases is mainly based on the location of the device that is attached to the

asset. This kind of use cases is a known use cases that is described in various semantic models. For the

purpose of the Wise IoT project, we choose to use the semantic model proposed in the FIESTA IoT

project [15]. This includes the definition of GPS Sensor as a Sensing Device. The Coordinates were

introduced as a new Unit. The unit Coordinates is used as metadata for the location.

<owl:Class rdf:about="http://purl.org/iot/vocab/m3-lite#GPSSensor"> <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/> <rdfs:comment xml:lang="en">Device that allows an object to localize itself.</rdfs:comment> <rdfs:label xml:lang="en">GPS Sensor</rdfs:label> </owl:Class>

Figure 21. Semantic model for GPS Sensor

The LoRa-based Asset Tracking device modelled as an Entity is described, which is a specialization of

the AssetTracker entity, i.e. it is modelled as a subclass. Table 9 list the properties, including those

inherited from AssetTracker.


42

Table 9. Properties of LoRaAssetTracker entity


id Text String Entity’s unique identifier.

type Text String Entity’s type. For this case of the asset tracker, it will be “assetTracker / visitorTracker”.

location unit

geo:json Coordinates

geo:json Label

Provides the geolocation of the tracked Asset. Metadata providing the unit for the geographic location.

battery Number Integer Provides the battery level of trackers.

speed Number Integer Provides speed of the accelerate sensor on the trackers.

status Text String Provides the status of tracked Asset, it will be “connected / on / emergency”

4.2.3 Conquer the slope

The “conquer the slope” use cases is based on the data provided by the LoRa band and the PIQ Robot

devices, i.e., location, accelerometer, button, gyroscope. Those sensors already have a semantic model

proposed in the FIESTA IoT project. Thus, the project will use those semantic model for this use case.

<owl:Class rdf:about="http://purl.org/iot/vocab/m3-lite#Accelerometer"> <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://purl.org/iot/vocab/m3-lite#hasDomainOfInterest"/> <owl:someValuesFrom rdf:resource="http://purl.org/iot/vocab/m3-lite#Transportation"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:comment xml:lang="en"> Accelerometers are used to automatically determine the orientation in which the user is holding the IoT Object (portrait or landscape).</rdfs:comment> <rdfs:label xml:lang="en">Accelerometer</rdfs:label> <rdfs:seeAlso rdf:resource="http://casas.wsu.edu/owl/cose.owl#Accelerometer"/> </owl:Class>

Figure 22. Semantic model for “Accelerometer”

<owl:Class rdf:about="http://purl.org/iot/vocab/m3-lite#GyroscopeSensor"> <rdfs:subClassOf rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensingDevice"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://purl.org/iot/vocab/m3-lite#hasDomainOfInterest"/> <owl:someValuesFrom rdf:resource="http://purl.org/iot/vocab/m3-lite#BuildingAutomation"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://purl.org/iot/vocab/m3-lite#hasDomainOfInterest"/>


43

<owl:someValuesFrom rdf:resource="http://purl.org/iot/vocab/m3-lite#Transportation"/> </owl:Restriction> </rdfs:subClassOf> <rdfs:comment xml:lang="en">A gyroscope is a device for measuring or maintaining orientation.</rdfs:comment> <rdfs:label xml:lang="en">Gyroscope Sensor</rdfs:label> <rdfs:seeAlso rdf:resource="http://casas.wsu.edu/owl/cose.owl#Gyroscope"/> </owl:Class>

Figure 23. Semantic model for “gyroscope”

4.3 Semantic Modeling for Crowd Mobility

The Wise-IoT crowd detection is defined as a cross-domain service which can provide crowd mobility information for different applications to enable semantic interoperability across worldwide IoT platforms. We aim to deploy Wi-Fi sniffers as crowd detectors in Santander, Chamrousse and Busan and the crowd detection service will provide the levels of crowdedness in the city required by different applications. The complete description of crowd service can be found in [4].

To achieve semantic interoperability, data from Santander, Chamrousse and Busan will be converted into an NGSI-based context information model by the Wise-IoT Morphing Mediation Gateways. In Santander, we will deploy Wi-Fi sniffers in some points of interests such as the Camel beach, the Magdalena entrance, and the Porticada Square. The crowd detection service will provide (1) crowd estimation and (2) stay durations in the targeted areas for multiple use cases. For example, the Smart Parking use case can request for the number of estimated crowds in targeted areas so that people can avoid driving to the crowded areas to park their cars. Meanwhile, when the stay durations of crowd are requested by the Smart Parking use case, it can help users to make a decision on parking lot search so they can drive to the areas with lower stay durations of crowds.

The NGSI-based context information model described in Section 3.2.1 is used for the crowd detection services. It will represent an entity (crowd detector, mobile devices) with its entity ID and its type. Furthermore, a set of attributes (crowd estimation, stay duration average, stay duration count) is defined to represent the data analytical results as the properties of the entity. Moreover, entity has other properties such as the id of crowd detector and the location of the crowd detector (latitude, longitude). For each attribute, it can include its own properties (metadata) in which additional further information can be provided such as a timestamp, the unit of timestamps, and the corresponding time string which is readable text for humans. Finally, the whole defined structure can be converted to JSON. We will explain the major entity: crowd detector and its attributes: crowd estimation, and stay duration. The first one represents a crowd detector device, while the latter two represent the data analytics results.

Crowd detector:

First, we explain the attributes of a crowd detector. Table 10 illustrates the data model of the crowd detector entity.

Below we define the properties of the crowd detector. A crowd detector device is formally defined as “nle:WifiMote” in the ontology and also in the NGSI data structure. Crowd detector has “nle:CrowdEstimation” property for keeping the data analytical results. The relations of different data analytical results will be shortly explained.


44

Table 10. The properties of the crowd detector entity

Property Expected Type Description

id String Entity’s unique identifier.

type String The type of entity. In this case, the defined value for crowd estimation is “nle:WifiMote”.

macAddress String Mac address of the crowd detector device

nle:SimpleGeolocation JSON Contains latitude and longitude information (location) of the crowd detector device. Latitude and longitude are defined as “double” values

nle:CrowdEstimation JSON Attributes of the nle:WifiMote where data analytical results reside

domainMetadata JSON The detailed location of crowd detector.

The below figure provides an example of a crowd detector (nle:WifiMote) entity in JSON

representation following the FIWARE NGSI Data Model.

"entityId": { "id": "ch-wfmote-0001", "type": "nle:WifiMote", "isPattern": false }, "domainMetadata": [{ "name": "SimpleGeolocation", "value": "{ \"latitude\":-43.533417,\"longitude\":172.63426}" }, { "name": "MacAddress", "value": "0013a2004103ae2b" }] { "attributes": [{ "name": "StayDurationAverage", "type": "nle:StayDurationAverage", "metadata": [{ "name": "Unit", "value": "Seconds" }, { "name": "StartTime", "value": "2015.11.13 20:09:00:000 +1300" }, { "name": "EndTime", "value": "2015.11.13 20:14:00:000 +1300" }, { "name": "Threshold", "value": "300"


45

}], "contextValue": "529" }], }}

Figure 24. Crowd detector entity example using NGSI data structure

The above example does not include all type information of all metadata for simplicity. Please refer to the given properties tables of the crowd detector model and the data analytical information models (crowd estimation and stay duration models) to find the proper type information for each metadata (e.g., integer, string, JSON).

Crowd data analytical results:

Below, we define the properties for the two key attributes (1) crowd estimation and (2) stay durations of crowd detector regarding to the crowd data analytics results in the crowd detection service. First, the properties (e.g. metadata) of crowd estimation are explained. Table 11 illustrates the defined properties of crowd estimation results. There main properties: are the name, the number of people plus start time, end time, which is modelled as metadata and is not shown in Table 11.

Table 11.The properties of the crowd estimation entity.

Property Expected Type

Description

name String The attribute’s identifier. “CrowdEstimation” is used as the name.

type String The type of entity. In this case, the defined value for crowd estimation is “nle:CrowdEstimation”.

numberOfPeople Integer The estimated size of the crowd. It is represented as an integer value.

The figure below shows an example NGSI structure for crowd detector which has the CrowdEstimation

attribute.

{ "attributes": [{ "name": "CrowdEstimation", "type": "nle:CrowdEstimation", "metadata": [{ "name": "StartTime", "value": "2015.11.13 20:09:57:000 +1300" }, { "name": "EndTime", "value": "2015.11.13 20:14:57:000 +1300" }], "contextValue": "188" }], "entityId": { "id": "ch-wfmote-0001", "type": "nle:WifiMote", "isPattern": false


46

}, "domainMetadata": [{ "name": "SimpleGeolocation", "value": "{ \"latitude\":-43.533417,\"longitude\":172.63426}" }, { "name": "MacAddress", "value": "0013a2004103ae2b" }] }}

Figure 25.Crowd estimation example using NGSI data structure

nle:CrowdEstimation is a super type for all data analytical results. In other words, all types of crowd mobility-related data analytical results belong to the crowd detector. For instance, Stay Duration is a type of Crowd Estimation.

Next, we define the stay durations which are of type crowd estimation. The nle:StayDuration is a subtype of nle:CrowdEstimation and it is a super type of the following two attributes: nle:StayDurationAverage and nle:StayDurationCount. Stay duration average is the average time people spend in the area detected by the crowd detector. Stay duration count is the number of stays (visits) detected by the crowd detector. A “stay” is defined with a threshold, meaning that if a person stays longer than a certain threshold, then it is considered as a stay (visit).Table 12 and Table 13 list the properties of stay duration average and stay duration count respectively. Please note that these two attributes already inherit the properties of nle:CrowdEstimation, which are listed in the previous table. The listed properties are the additional properties of these two subtypes. Moreover, the “threshold” property is shared by two of these attributes and it actually belongs to the “nle:StayDuration” (super type of the two stay duration results).

Table 12.The properties of stay durations average attribute


threshold integer The threshold value (in seconds) which is used for the computation of the stay durations average. The visits (stays) which are shorter than this duration defined by the threshold are ignored in the stay duration average computation.

unit string The time unit for the stay duration average results. Examples: “second”, “minute”, etc.

The threshold value, which is used for the computation of the stay durations average, is used as

follows. The visits (stays) which are shorter than this duration defined by the threshold are ignored in

the stay duration average computation. For instance, if a person comes to the area detected by the

crowd detected and spends only a couple of seconds there, this is not considered as a stay, but it is

considered more of a passing by behaviour.

Table 13. The properties of stay durations count attribute


threshold integer The threshold value (in seconds) which is used for the computation of the stay durations count (or visit


47

count). The visits (stays) which are shorter than this duration defined by the threshold are ignored in the computation.

remainderCount integer The number of “passing by” actions, which are ignored in the stay duration count.

Figure 26 illustrates example data which includes stay duration average as well as stay duration count. Similar to the previous examples, JSON format is used with the FIWARE NGSI structure. In this example, domain metadata of the entity is not shown for simplicity. Similarly, type of metadata is not shown, while those can be seen in the properties tables.

Lastly, the ontology is defined in the proper format (in an .owl file).Figure 27 provides an illustration of

the ontology for the data models of crowd detector and the data analytical results. The tool “Protégé”

is used to define this ontology. For visualization, the online tool “WebVOWL” is used. InFigure 27,

some of the property namesare not shown completely for the visualization purpose. This figure

provides an overall view.

{"attributes": [{ "name": "StayDurationAverage", "type": "nle:StayDurationAverage", "metadata": [{ "name": "Unit", "value": "Seconds" }, { "name": "StartTime", "value": "2015.11.13 20:09:00:000 +1300" }, { "name": "EndTime", "value": "2015.11.13 20:14:00:000 +1300" }, { "name": "Threshold", "value": "300" }], "contextValue": "529" },{ "name": "StayDurationCount", "type": "nle:StayDurationCount", "metadata": [{ "name": "StartTime", "value": "2015.11.13 20:09:00:000 +1300" }, { "name": "EndTime", "value": "2015.11.13 20:14:00:000 +1300" }, { "name": "Threshold",


48

"value": "300" }, { "name": "RemainderCount", "value": "403" }], "contextValue": "14" }, ],"entityId": { "id": "ch-wfmote-0001", "type": "nle:WifiMote", "isPattern": false } }

Figure 26.Stay duration average and stay duration count examples using NGSI data structure

Figure 27.Crowd-related entities and attributes modelled as an ontology

Components Enabling and Utilizing Semantics

49

5 Components Enabling and Utilizing Semantics

This section describes the components related to semantics, in particular the Adaptive Semantic

Module (ASM) of the Morphing Mediation Gateway that uses semantic information as the basis for

discovering information and translating the information from its oneM2M representation to the NGSI-

based representation used in FIWARE. The Semantic Annotator creates the pre-condition for the

semantic translation by semantically annotating content information stored in the oneM2M system.

The Self-Adaptive Recommender system (SAR) offers one component that enables semantic

interoperability: the QoI Monitor enables the quality assessment of the semantic information.

5.1 Adaptive Semantic Module

The architecture of the Adaptive Semantic Module (ASM) as one of the Modules of the Morphing

Mediation Gateway (MMG) is described in detail in Wise-IoT Deliverable D2.2 [17]. In this section the

focus is on how semantic information is used in the process of translating information from a source

system to a target system, how semantics enables adaptivity, and in particular how the ASM can

discover new information in the source system and dynamically enhance its translation capabilities to

provide this information to the target system. Nevertheless a short overview of the internal ASM

architecture is given to make this section understandable on its own.

The ASM is not a fixed module that is once programmed and then instantiated, but rather a framework

that can have different components for different source and target systems and also for different kinds

of information stored in the respective source systems. Furthermore, it can be adapted or even adapt

itself at runtime. Thus it provides a much more fine-grained adaptivity as the Morphing Mediation

Gateway as a whole. It is intended to utilize semantic information to drive the translation and adapt

itself.

Figure 28. MMG ASM Module in the Wise-IoT Layered Architecture

Given the information-agnostic approach of oneM2M (information is handled as “blackbox”), the

information-centric FIWARE platform and the key importance of both in the Wise-IoT instantiation of

the layered architecture, the focus of the ASM in Wise-IoT is to apply it to oneM2M as a source system


50

and FIWARE as a target system with the semantic annotations in the oneM2M system providing the

necessary basis for driving the translation. This position in the Wise-IoT architecture is depicted in

Figure 28.

After the architectural overview, the general interactions for a semantic-driven approach are

presented, before two concrete example instantiations for Wise-IoT are presented.

5.1.1 Architectural Overview

Figure 29: Architecture overview of Adaptive Semantic Module

Figure 29 [17] gives an overview of the internal architecture of the Adaptive Semantic Module. The

ASM translates information from an external (source) system – shown on the left side of the figure – to

one (or more) external target system(s) – shown on the right side. The Source Adapter is responsible

for interacting with the source system, i.e. it needs to understand the respective protocols and

interfaces for discovering and retrieving the relevant information contained in the source system. It

forwards the retrieved information to a suitable Input Translator which translates the retrieved

information into an internal data format. The Input Translator can utilize one or more Context

Providers to retrieve additional information required for the translation. The Context Providers may

utilize external information sytems. The Input Translator forwards the information to one (or more)

Output Translators that translates into the data format required for the target system. The Target

Adapter then interacts with the external target system. As multiple target system instances can be

supported at the same time, the relation between Target Adapter and external target system is one to

many. The Mediation Manager is responsible for setting up and adapting the translation chains

reaching from source to target systems. This can happen at runtime and be triggered externally by an

administrator, or by a Source Adapter that has discovered new information. New components can be

instantiated from the Component Repository. New component implementations can be dynamically


51

added to the Component Repository at runtime. More details on the components and their

interactions can be found in D2.2 [17].

5.1.2 General ASM Interactions in Semantic-driven Approach

Figure 30 visualizes the initialization of the ASM Module. The MMG first instantantiates the ASM

Module as a whole and configures it (A). The MMG Manager provides the communication endpoints of

the source and target system, in this case the oneM2M system instance and the FIWARE Broker

instance respectively, plus additional configuration information. Then the Mediation Manager in two

steps creates the translation chain. First, the individual components, i.e. the Source Adapter, Input

Translator, Output Translator and Target Adapter are created and individually configured (B). Second,

they are linked together by providing the Source Adapter, Input Translator and Output Translator, with

the respective next element in the chain, i.e. the Input Translator, Output Translator and Target

Adapter respectively. As discussed in Section 5.1.5, there can be more complex structures dynamically

set up that have more than one Input Adapter. Different target systems can be supported with

multiple Target Adapters and multiple target system instances, e.g. a FIWARE Context Broker and a

FIWARE IoT Broker can also be simultaneously supported.

Figure 30: ASM Initialization

Figure 31 visualizes the general operation of the ASM. The Source Adapter discovers new information

in the source system (1). In this case, it discovers resources in the oneM2M system that are

semantically annotated in a way fitting to what was specified in the configuration. As discussed in

Sections 5.1.3, 5.1.4 and 5.1.5, the discovery may take into account different aspects and may be more

or less specific. If the discovered resources fit the specification, the Source Adapter checks whether a

suitable Input Translator is available or not.

In more static cases, this may be automatically given the way the ASM is set up, but in Section 5.1.5 a

dynamic, self-adaptive case is described. Only in such a case, the second step is needed, in which the

Source Adapter requests the Mediation Manager to instantiate a fitting Input Translator (2).

Given that a fitting Input Translator is available, the Source Adapter retrieves the information and

passes the information on to the Input Tranlator. The input translates it into an internal format, which


52

the Output Translator translates to the target format and provides it to the Target Adapter(s) to

update the target system (3).

Figure 31: General ASM Interactions

In the case of oneM2M, the retrieved information typically consists of the combination of actual values

published in contentInstance resources and semantic annotations made available as

semanticDescriptor resources, typically as child resources of the container resources that holds the

contentInstances. Sections 5.1.3 and 5.1.4 describe two different example cases in more detail. For the

retrieval process, typically subscriptions are used, so notifications informing about new values are

automatically provided. If for some reason this is not possible in a given situation, periodic polling can

be used.

5.1.3 ASM for Plain Information from Semantically Annotated oneM2M

Resources

This type of instantiation is suitable for use cases, where information is published in the oneM2M

system by sources that are not semantically enabled themselves. For example, in Wise-IoT the Asset

Tracking use case can be supported in this way. It assumes the simplest setting, more advanced

approaches are described in the following subsections. For example, a simple sensor publishes its

values to the oneM2M system into a container resource as contentInstance resources. The sensor

values as such are not sufficient for translating to NGSI in a meaningful way – for that at least the

entity type, a suitable entity identifier and the name of the entity attribute need to be available. But

such information can be put as an annotation into a semantic descriptor child resource of the

container resource. The semantic annotation could be made by the source itself, but more likely would


53

be done by a third-party with the respective permissions. The Semantic Annotator R1 as described in

Wise-IoT Deliverable D2.4 [14] can be used for this purpose.

In this case the discovery step (1) as shown in Figure 31 can be realized as follows:

• The oneM2M Source Adapter for Plain Information discovers container resources with semantic descriptor child resources using the discovery operation of the oneM2M Mca interface. Ideally a semantic discovery operation is used where the semantic filter is specified in the form of a SPARQL query. The SPARQL query would only match suitable resources, i.e. those whose information can be handled by the translation chain. If the oneM2M implementation does not provide the semantic discovery feature yet, all resources of type semantic descriptor can be discovered, then checked whether they are suitable and finally the parent resource can be retrieved in a separate step.

• The oneM2M Source Adapter retrieves the semantic descriptor resource and extracts the relevant information needed for the translation. This step can be done by applying a SPARQL request to the semantic information. The SPARQL variables are then matched to the relevant entity information.

Assuming, a suitable Input Translator is available, the retrieval step (3) in Figure 31 can then be

realized as follows:

• The Source Adapter for each discovered container resource retrieves the latest contentInstance and then uses the oneM2M Mca subscription operation to subscribe for any new contentInstance child resources of the container resource being created. On receiving a notification, the new contentInstance is retrieved.

• The retrieved information, together with the semantic information previously retrieved, is provided to the oneM2M Input Translator that translates it into the internal format.

• The result is passed to the NGSI Output Translator that translates from the internal format to the NGSI format.

The NGSI information is passed to the NGSI Target Adapter that, using the NGSI Context API, invokes

the NGSI update operation of the FIWARE Broker used, i.e. either the Orion Context Broker or the

Aeron IoT Broker.

5.1.4 ASM for Semantic Source Information

This type of instantiation is suitable for use cases where the original source already provides semantic

information. It writes entity-related meta information as well as the attribute values directly into the

semantic descriptor – instead of or in addition to providing them as contentInstance resources. This

means the semantic descriptor needs to be updated whenever a new value becomes available.

Alternatively, a Semantic Annotator R2 as described in Section 5.2 can be used, which subscribes to

new contentValue resources becoming available, translates them into semantic format and updates

the semantic descriptor child resource of the container accordingly. As described below, this approach

simplifies the task of the ASM, but requires that a Semantic Annotator is permanently running in order

to update the semantic descriptor for each new value. Whereas in the case described in Section 5.1.3,

the semantic annotation only needs to be done once. For example, this approach is used for the Smart

Parking use case in Busan, in order to make the parking information available to NGSI-based

applications.

In this case, the discovery step (1) as shown in Figure 31 can be realized as follows:


54

• The oneM2M Source Adapter for Known Semantic Information discovers semantic descriptor resources using the discovery operation of the oneM2M Mca interface. Ideally a semantic discovery operation is used where the semantic filter is specified in the form of a SPARQL query. The SPARQL query would only match suitable resources, i.e. those whose information can be handled by the translation chain. If the oneM2M implementation does not provide the semantic discovery feature yet, all resources of type semantic descriptor can be discovered, then checked whether they are suitable.

Assuming, a suitable Input Translator is available, the retrieval step (3) in Figure 31 can then be

realized as follows:

• The Source Adapter subscribes to each semantic descriptor resource, requesting to receive all resource attributes, which includes the semantic description.

• Whenever a notification is received, the semantic content is provided to the oneM2M Input Translator that translates it to the internal format and passes it to the NGSI Output Translator.

• The NGSI Output Translator translates from the internal format to the NGSI format.

The NGSI information is passed to the NGSI Target Adapter that, using the NGSI Context API, invokes

the NGSI update operation of the FIWARE Broker used, i.e. either the Orion Context Broker or the

Aeron IoT Broker.

5.1.5 Semantic Information Discovery and Dynamic Self-adaptation

Whereas the translation chains described in Section 5.1.3 and Section 5.1.4 are configured and set up

once and are useful for more static use cases, this case targets more forward-looking horizontal use

cases, e.g. in a smart city, where the available information changes over time and the idea is to make

new kinds of information dynamically available at runtime.

The discovery step is generalized as follows:

• The oneM2M Source Adapter for All Semantic Information discovers all resources of type SemanticDescriptor. Using the semantic descriptor attribute ontologyRef, it identifies according to what ontology the semantic annotation has been made1. It checks whether it has an InputTranslator that can handle semantic content according to this ontology. If this is the case it continues with step (3) as in the other cases, otherwise with step (2).

The setup translation chain works as follows:

• The oneM2M Source Adapter for All Semantic Information requests the Mediation Manager to instantiate a translation chain for semantic content as identified by value of the ontologyRef attribute.

• The Mediation Manager first checks whether a fitting Input Translator implementation is available locally, otherwise it checks the Component Repository, where somebody may have provided a fitting Input Translator implementation.

• If a fitting Input Translator implementation has been found, the Mediation Manager instantiates it, connects it to the required Output Translator instance(s) and notifies the oneM2M Source Adaptor for All Semantic Information that it can proceed with step (3), i.e. start the translation process.

1 The assumption is that the onotology specified by ontologyRef is sufficently specific for enabling the translation.


55

• If no fitting Input Adaptor implementation has been found, the request is kept in a backlog to check periodically, whether a suitable Input Translator implementation has become available.

The retrieval step is handled as follows:

• The oneM2M Source Adapter for All Semantic Information subscribes for the creation of new contentInstance resources as well as for any changes to the semantic descriptor. On receiving a notification, it passes the latest contentInstance as well as the semantic information to the Input Translator that can handle the information identified by the ontologyRef.

• The Input Translator translates the provided information to the internal format. Not all information required may be directly and explicitly be available in the information provided by the oneM2M Source Adapter for All Semantic Information. In this case the Input Translator can interact with one or more Context Providers and utilize additional semantic functionalities to derive the required information.

• The NGSI Output Translator translates from the internal format to the NGSI format.

• The NGSI information is passed to the NGSI Target Adapter that, using the NGSI Context API, invokes the NGSI update operation of the FIWARE Broker used, i.e. either the Orion Context Broker or the Aeron IoT Broker.

5.2 Semantic Annotator

The Semantic Annotator is a component that can dynamically receive information of resources in a

oneM2M system and create semantic descriptions accordingly. Then end user of the Semantic

Annotator can vary from a user with some knowledge about semantics and ontologies to the

administrator who provides semantic IoT services. The Semantic Annotator creates semantic

description resources based on ontology and data modelling that can vary for each use case due to

different ontologies. The Semantic Annotator at first subscribes to the oneM2M container resources

for selected data models such as smart parking and creates/updates the semantic descriptions

according to new sensor readings becoming available as content Instances. These updates (e.g.

<contentInstance> creation) represent the new data provided by other applications. The semantic

description is stored as a <semanticDescriptor> resource in RDF format on the oneM2M server

platform. It has been developed in NodeJs and uses the HTTP binding for interaction with oneM2M

CSE. The MQTT broker is used for subscribing to resources in order to receive notifications on resource

updates. Figure 32 illustrates the interactions of the Semantic Annotator. It works in following manner:

• The precondition is that the ontologies defining the concepts needed for the semantic

annotation as well as the mappings from the underlying data to the semantic representation

exist.

• Based on the user selected data model such as Smart Parking, it subscribes to the oneM2M

containers resources for parking spot, offStreetParking and onStreetParking by creating

<subscribed-to-resources>. The subscription is carried out by creating the <subscribed-To-Be>

resources of each existing container resource on the oneM2M server platform instance, e.g.,

Mobius.

• After the <subscribed-to-resources> creation, these resources are subscribed as subjects in

MQTT to receive notification of further updates.

• On resource update (e.g., add new sensor value represented as content Instance resource or

new container resource creation) in the oneM2M system from any other application, it

receives notification and creates the semantic description resource for updated resource to


56

which the new <contentInstance> resource belongs. For Instance, in the case of a parking spot,

a notification of a new <spot> resource creation which represent the parking spot is handled

by creating a subscription resource to receive a new data update inside that <spot> resource.

For that, it subscribes the existing <spot> resource then it defines child container resources

(i.e. status and info) along with creation of semantic description resource under the <spot>

resource. As a first step, the semantic descriptor resource is created with the default semantic

data model.

• When the new content Instance resource notification is received, the already created semantic

descriptor instance of target container resource is to update its attribute(s) according to data

contained in the content instance resource. The resource name of the newly received content

instance should correspond to some attribute in the default data model of the semantic

descriptor for updating new value in it correspondingly.

• Finally, the semantic descriptor resource gets updated according to new data and stored under

container resource which can be utilized by other components in oneM2M system for data

structuring.

The semantic descriptor resources represent the semantic information transformed into semantic data

format based on different ontologies and respective data models (e.g. Smart Parking) presented in

D2.4 [14].

Figure 32. Interaction of Semantic Annotator.

5.3 Self-Adaptive Recommendation (SAR) System

One component of the Self-Adaptive Recommender (SAR) enables semantics, and three components

of the Self-Adaptive Recommender system (SAR) utilize semantics that is offered by the information

access layer and required by the use case applications.


57

• The QoI Monitor enables semantics by providing a semantic web quality framework that classifies the data quality and calculates an information quality score.

• The IoT Recommender utilizes semantics for offering recommendations for points of interest such as parking spots and pathways such as a city’s streets and a ski resort’s slopes.

• The Adherence Monitor is a sensor to detect invalid assumptions in the IoT recommendations, the user’s preferences, the pathway network, and the functioning of IoT sensors.

• The Trust Monitor is a sensor to obtain users’ trust ratings and feedback.

This section describes the enablement of semantics by the QoI Monitor, the data models used by the

other SAR components components, and how the data models relate to relevant ontologies.

5.3.1 QoI Monitor

We provide 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. There are five dimensions that 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 information is logically consistent in itself.

Syntactic Validity. Flemming [18] defined the term validity of documents as “the valid usage of the

underlying vocabularies and the valid syntax of the documents”. Fürber et al. [19] 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. [20] 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 our use case (smart 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 [21] adopted the definition of accuracy from Wand et al. [22] as the “degree

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

real world”. Furthermore, Fürber et al. [19] 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 labeling and inaccurate classification) identified in Lei et al. [23] related to the

semantic accuracy dimension.

Example: In our use case (smart 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 instance is semantically inaccurate since the parking spot ID does not represent its real-world

state i.e. ParkingSpot1.


58

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

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

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

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

[27]present metrics to assess consistency. However, it should be noted that for some languages such

as OWL DL, there are 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 [28].

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 free

ParkingSpot1 20170926 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. [25] classified conciseness into schema and instance level conciseness. On

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

equivalent attributes with different names)”. Thus, intensional 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. [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

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

case of extensional conciseness) in a dataset.

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

being represented by two different properties in the same dataset, such as

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

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 fusing the two properties

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

when both these identifiers of the same parking spot have the same information associated with them

in both the datasets, thus duplicating the information.

Completeness: Bizer [21] adopted the definition of completeness from Pipino et al. [29]as “the degree

to which information is not missing”. Fürber et al. [19] further classified completeness into: (i) 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


59

represented in an information system and the complete population. Mendes et al. [25] 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. [19]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 contains 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.

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

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

again describes all interactions). The various examples mentioned above are mainly some concrete

examples that are detected during the smart 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 parking spot and as a consequence the recommendation provided to the

user.

5.3.2 IoT Recommender

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

semantic information of smart parking and smart skiing use cases in Wise-IoT. At this moment, the first

release of the SAR is launched in which IoT recommender is developed for smart parking use case. In

this release, IoT recommender exploits the ontology schema for smart parking use case which is

presented in Figure 15 in semantic modelling for smart city use case for smart parking. IoT

Recommender uses the semantic data of parking sensors (which properties are defined in Table 1 and

example is presented in Figure 11) from NGSI context broker to find the nearest available parking spot

from user’s current location. Additionally, it uses the semantic data of traffic sensors deployed in

Santander (which properties are defined in Table 4 and example is presented in Figure 14) from NGSI

context broker to calculate the level of crowd on the streets in order to recommend the least crowded

route from user’s current location to the nearest available parking spot.

In the second release, IoT Recommender plans to use the OnStreetParking (which properties are

defined in Table 2 and example is presented in Figure 12) to calculate the statistics of individual

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

spots in the OnStreetParking. This statististics will be provided to the user in order to give two choices

to the user: i) either get the nearest parking spot from our system or ii) decide a parking area to go by

himself/herself from the statistics shown on his/her screen. Additionally, in the second release, IoT

Recommender will be developed for smart skiing use case and for this purpose, IoT Recommender will

use the ontology schema of smart skiing use case which is presented in Figure 20 and the traffic at ski

slopes which properties are defined in Table 8. 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 [30].


60

5.3.3 Adherence and Trust Monitors

The role of the Adherence and Trust Monitors for semantics is two-fold depending on the context in

which these components are considered. From the context of IoT, the two components allow

observations about the validity of recommendations and IoT data offered to the user. At the same

time, they are monitoring tools for gathering data about system utilization and user feedback. The

former context may be described by the FIESTA-IoT ontology. The latter context may be described by

the Supersede ontology2. The dual nature of the concepts reflects the unification of the two underlying

domains, IoT systems engineering and requirements engineering.

The Adherence and Trust Monitors are sensors that detect invalid assumptions in recommendations,

the user’s preferences, the pathway network, and in the functioning of IoT sensors. This scenario is

described by the FIESTA-IoT ontology as described in Table 14.

Table 14: Mapping of Adherence and Trust Monitor Concepts to the FIESTA-IoT Ontology.

SAR Adherence and Trust Monitor Concepts Mapping to the FIESTA-IoT Ontology

Adherence Monitor and Trust Monitor Are types of Sensors that produce Observations.

Deviation: ActionDeviation, LocationDeviation, DurationDeviation

Are types of Observations that are produced by the Adherence Monitor Sensor at the Instant and Point where the deviation happens.

Success: GoalReached, PathwayAchieved Are types of Observations that are produced by the Adherence Monitor Sensor at the Instant and Point when a user goal or a pathway are achieved.

Feedback Is a type of Observation that is produced by the Adherence Monitor Sensor at the Instant and Point when a user offers feedback.

The Adherence and Trust Monitor concepts relate also to the Supersede ontology. Supersede is a

framework supporting the evolution and adaptation of personalized software by exploiting contextual

data and end-user feedback. The mapping to the Supersede ontology is as described in Table 15.

Table 15: Mapping of Adherence and Trust Monitor Concepts to the Supersede Ontology.

SAR Adherence and Trust Monitor Concepts Mapping to the Supersede Ontology

Adherence Monitor and Trust Monitor Are types of MonitoringTools.

Deviation, Success, Feedback Are types of MonitoredData that offer information contained in DataItems.

The properties of the Deviation, Success, and Feedback properties are more complex than the

structure of the Observations that the FIESTA-IoT ontology suggests. The reason is that the SAR system

aims at offering developers insights about an IoT system and application that are more complex than a

simple value of a device sensor.

A Deviation has the attributes “is,” “should,” “difference,” and “differenceUnit.” For example, when

the user has abandoned a pathway that the IoT recommender suggested, the Adherence Monitor

records a LocationDeviation with (is: point of the user, should: point of the to-be street segment’s

endpoint, difference: the difference between the is and should, differenceUnit: meters).

2 Horizon2020 ICT-09-2014 Project SUPSERSEDE, Grant Agreeement 644018, www.supersede.eu.


61

A Success has the same attributes as a FIESTA-IoT Observation. For example, when the user has

reached a parking space, the Adherence Monitor records GoalReached with (geo:location: the point of

the parking, ssn:observationSamplingTime: the instant of when the parking space has been reached).

A Feedback has the attribute “Rating” and a set of “Comment,” which are qualitative statements that

may be used to develop hypotheses about system changes or to support these hypotheses. The

Feedback has also an optional reference to a “User” who acts as a trustor when providing feedback

and an “Observation” who acts as a trustee. For example, when the user offers feedback about the

successful reaching of a parking space (GoalReached) and depending on the user inputs, the

Adherence Monitor records a Feedback with (optional truster: user-ID, trustee: the reaching of the

parking, rating: the user’s quality of experience of the pathway recommendation, first comment:

qualitative feedback about the parking space).

The Adherence Monitor Concepts are used to structure the stream of insights that is produced by the

SAR system and can be used by engineers to understand problems and strengths of the IoT system and

application that they monitor with the SAR system. SAR R1 implemented the insight stream with a

dedicated Context Broker instance. The detailed data model for the SAR R1 version has been

documented in the deliverable D2.6, appendix B.

Conclusions

62

6 Conclusions

In this deliverable we have described how semantic information can be used to achieve semantic

interoperability between IoT platforms, in particular between the oneM2M platform that instantiates

the Integration and Management Layer of the Wise-IoT Layered Architecture View [8] and the NGSI-

based FIWARE Broker GEs that instantiates the Information Access Layer.

Based on the requirements of the use cases, the existing information and the requirements of the

platforms, domain-specific ontologies have been developed, as in the case of the bus information

system, crowd modelling and smart skiing, or existing ontologies have been re-used/enhanced as in

the case of smart parking. The focus has been on re-using existing information for each use case, i.e. as

much as possible map existing information to ontology concepts, making sure that consistent

modelling for each use case can be achieved. As a result, the modelling across different use cases may

appear less consistent.

Nevertheless, it is clear that the broader the use cases become, the more likely there are common

concepts. In this case. a mapping between the concepts would be defined and reasoning would allow

us finding instances of a given concept even if they were defined according to another concept,

following the mapping between the concepts. This enables the reuse of information across use cases

and application domains, enabling a true Internet of Things.

The ontologies described in this deliverable will be applied in the Wise-IoT use cases and used by the

SAR components: IoT Recommender, Adherence Monitor and Trust Monitor. Based on the experience

gained in using the ontologies, they will be enhanced and modified. The final result will be presented

in deliverable D2.7.

Finally, it has been described how the ontology-based information can be used in the context of

oneM2M and NGSI, and how the semantic information can be used for the translation between

oneM2M and NGSI in the Adaptive Semantic Module of the Morphing Mediation Gateway.

Furthermore, tools for semantic annotation in the oneM2M platform and the SAR QoI Monitor for

assessing the quality of information have been presented.

Enabling applications to directly specify and request the information they need on a semantic level

helps in decoupling them from specific, site and use-case dependent sources. Thus it will become

easier to develop applications that seamlessly work on different sites. In Wise-IoT this will be shown

for parking use cases in Santander and Busan, as well as skiing-related use cases in Chamrousse and

Alpensia. As part of the evaluation in the specific use cases, we will investigate which efforts need to

be spent on different aspects related to achieving semantic interoperability, i.e. semantic annotation,

creating components (in particular for the ASM), configuration and the respective influence on

developing the applications.

References

63

7 References

[1] H. Van der Veer and A. Wiles, “ETSI White Paper No. 3, Achieving Technical Interoperability - the ETSI

Approach,” April 2008. [Online]. Available:

http://www.etsi.org/images/files/ETSIWhitePapers/IOP%20whitepaper%20Edition%203%20final.pdf.

[Accessed 14 August 2017].

[2] M. Ushold and C. Menzel, “Semantic Integration & Interoperability Using RDF and OWL,” 3 November 2005.

[Online]. Available: https://www.w3.org/2001/sw/BestPractices/OEP/SemInt/. [Accessed 14 August 2017].

[3] P. Murdock, L. Bassbouss, A. Kraft, M. Bauer, O. Logvinov, M. Ben Alaya, T. Longstreth, R. Bhomwmik, P.

Matigne, P. Brett, C. Mladin, R. Chakraborty, T. Monteil, M. Dadas, J. Davies, P. Nappey, W. Diab, D. Raggett,

K. Drira, J. Roes, B. Eastham, M. Serrano, C. El Kaed, N. Seydoux, O. Elloumi, E. Simmon, M. Girod Genet, R.

Subramaniam, N. Hernandez, J. Swetina, M. Hoffmeister, M. Underwood, J. Jiménez and C. Wang, “Semantic

Interoperability for the Web of Things,” 2016. [Online]. Available:

https://www.researchgate.net/publication/307122744_Semantic_Interoperability_for_the_Web_of_Things.

[Accessed 14 August 2017].

[4] GSM Association, “IoT Big Data Harmonised Data Model,” GSM Association, 2016.

[5] schema.org, [Online]. Available: http://schema.org. [Accessed 22 09 2017].

[6] “FIWARE Datamodels for Smart Parking,” http://fiware-

datamodels.readthedocs.io/en/latest/Parking/doc/introduction/index.html.

[7] “FIWARE Datamodels for Traffic Flow,” http://fiware-

datamodels.readthedocs.io/en/latest/Transportation/TrafficFlowObserved/doc/spec/index.html.

[8] “Wise-IoT D1.2 - Wise-IoT high level architecture and reference technologies and standards,” 2017.

[9] “SPARQL 1.1 Query Language”.

[10] “oneM2M Technical Specification TS-0001, Functional Architecture”.

[11] NGSI Context Management, Candidate Version 1.0, Open Mobile Alliance, 03 Aug 2010.

[12] oneM2M Technical Specification TS-0012, Base Ontology.

[13] “Wise-IoT D1.1 – Wise-IoT Pilot Use Case Technical Description, Business Requirements and Draft High-Level

Architecture,” http://wise-iot.eu/wp-content/uploads/2016/12/D1.1-Use-Cases-PU-V1.0.pdf, 2016.

[14] “Wise-IoT D2.4 – Semantic Interoperability Components R1,” http://wise-iot.eu/wp-

content/uploads/2017/03/D2.4-Semantic-Interoperability-Components-R1-1.0.2.pdf, 2017.

[15] “FIESTA-IoT,” 2017. [Online]. Available: http://ontology.fiesta-iot.eu.

[16] “OpenSnowMap,” 2017. [Online]. Available: http://opensnowmap.org.

[17] “Wise-IoT D2.2 - Morphing Mediation Gateway with Management and Configuration Functions R2,” 2017.

References

64

[18] A. Flemming, Quality Characteristics of Linked Data Publishing Datasources, Berlin: Humboldt-Universität,

2010.

[19] C. Fürber and M. Hepp, “Swiqa - a semantic web information quality assessment framework,” in Proceedings

of European Conference on Information Systems (ECIS), 2011.

[20] A. Hogan, A. Harth, A. Passant, S. Decker and A. Polleres, “Weaving the Pedantic Web,” in Proceedings of the

WWW 2010, Workshop on Linked Data on the Web (LDOW), Raleigh, USA, 2010.

[21] C. Bizer, Quality-Driven Information Filtering in the Context of Web-Based Information Systems, 2007.

[22] Y. Wand and R. Y. Wang, “Anchoring data quality dimensions in ontological foundations,” Communications

of the ACM, vol. 39, no. 11, pp. 86-95, 1996.

[23] Y. Lei, V. Uren and E. Motta, “A framework for evaluating semantic metadata,” in Proceedings of the 4th

international conference on Knowledge capture (K-CAP '07), Whistler, BC, Canada, 2007.

[24] M. Mecella, M. Scannapieco, A. Virgillito, R. Baldoni, T. Catarci and C. Batini, “Managing Data Quality in

Cooperative Information Systems,” in On the Move to Meaningful Internet Systems, Lecture Notes in

Computer Science, Berlin, Heidelberg, Springer, 2002.

[25] P. Mendes, H. Mühleisen and C. Bizer, “Sieve: linked data quality assessment and fusion,” in Proceedings of

the 2012 Joint EDBT/ICDT Workshops, Berlin, 2013.

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

linked open data with ProLOD,” in IEEE 26th International Conference on Data Engineering Workshops

(ICDEW), Long Beach, CA, USA, 2010.

[27] M. A. Mostafavi, G. Edwards and R. Jeansoulin, “Ontology-based method for quality assessment of spatial

databases,” in Proceedings of the International Symposium on Spatial Data Quatlity (ISSDQ'04), 2004.

[28] F. Baader, D. Calvanese, B. L. McGuinness, D. Nardi and P. F. Patel-Schneider, The description logic

handbook: theory, implementation, and applications, New York, USA: Cambridge University Press, 2003.

[29] L. L. Pipino, Y. W. Lee and R. Y. Wang, “Data quality assessment,” Communications of the ACM, 2002.

[30] “Wise-IoT D2.6 – Self-Adaptive Recommendation System,” 2017.

d2 - home - wise-iotwise-iot.eu/wp-content/uploads/2017/11/d2.5... · 4.1 semantic modelling for...

Documents