D2.4

Semantic Interoperability

Components R1

Editor: Martin Bauer (NEC)

Submission date: 28/02/17

Version 1.0.2

Contact: martin.bauer@neclab.eu

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

Editor: Martin Bauer (NEC)

Deliverable nature: O

Dissemination level: PU

Contractual/actual delivery date: M09 M10

Disclaimer

This document contains material, which is the copyright of certain Wise-IoT consortium parties, and

may not be reproduced or copied without permission.

In case of Public (PU):

All Wise-IoT consortium parties have agreed to full publication of this document.

Neither the Wise-IoT consortium as a whole, nor a certain part of the Wise-IoT consortium, warrant

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

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

This project has received funding from the European Union’s H2020 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

Table of contents

Executive summary _________________________________________ 4

Authors ______________________________________________________ 5

Glossary _____________________________________________________ 6

1 Introduction ______________________________________________ 7

1.1 Positioning in the project _______________________________________ 7

1.2 Deliverable contribution ________________________________________ 8

2 Semantic Modelling ______________________________________ 9

2.1 Semantic Modelling in oneM2M _________________________________ 9

2.2 Semantic Modelling for NGSI __________________________________ 11

2.3 Semantic Modelling for Smart City Use Case _________________ 12

2.3.1 Smart Parking ____________________________________________________ 12

2.3.2 Bus Information System __________________________________________ 20

2.3.3 Crowd Modelling __________________________________________________ 27

2.4 Semantic Modelling for Smart Skiing Use Case _______________ 29

2.4.1 Crowd monitoring _________________________________________________ 30

2.4.2 Assets tracking ___________________________________________________ 31

2.4.3 “Conquer the slope” ______________________________________________ 31

3 Semantic Interoperability Components _________________ 32

3.1 oneM2M Resources and Interactions__________________________ 32

3.2 NGSI ____________________________________________________________ 34

3.3 Semantic Translation in Semantic Mediation Gateway R1 ___ 35

3.4 Semantic Annotator ____________________________________________ 36

4 Conclusion and Outlook _________________________________ 38

5 References ______________________________________________ 39

Executive summary

This deliverable describes the semantic interoperability components required for achieving semantic

interoperability between the platforms to be used in Wise-IoT. As part of this deliverable these

components are made available to the consortium to be used for implementing the Wise-IoT use

cases.

The basis for this are the underlying information models in the platforms used, i.e. the oneM2M Base

Ontology for the oneM2M platform and the NGSI context information model in the case of the FIWARE

platform. To achieve interoperability, the modelling of information has to be based on the core

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

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

cases of Wise-IoT. In the case of Smart Parking, an existing data model from FIWARE could be reused

as the basis for the Smart Parking Ontology. In the case of the Bus Information System use case, an

ontology has been developed deriving its domain-specific concepts from the concepts of Thing and

ThingPorperty of the oneM2M Base Ontology. The Crowd Modelling is based on the NGSI modelling of

entities and attributes. The ontology for the Smart Skiing use case had to be newly developed, but is

based on the existing OpenSnowMap data model.

The description of the functional semantic interoperability components first looks at how semantic

information is handled and used in the oneM2M platform. Existing oneM2M resources can be

annotated with semantic descriptor resources containing semantic descriptions in RDF. Then it is

shown how semantic information that is based on an ontology can be mapped into the NGSI data

structure, so the data structure logically can be seen as a non-standard representation of ontology

instances. There are current activities for developing a JSON-LD representation for NGSI, in which case

it would become a standard semantic representation. Then it is shown how the Semantic Mediation

Gateway, which will evolve to become the Adaptive Semantic Module of the Morphing Mediation

Gateway in Release 2 of the Wise-ioT components, uses semantic information for translating

information from oneM2M to the NGSI information model, so it can be used by the NGSI-based

enablers of the FIWARE platform.

The semantic interoperability components and ontologies will be used in the Wise-IoT use cases.

Based on the requirements and feedback from the use cases, they will be further developed towards

their second release, which will be provided in deliverable D2.5.

Authors

Chapter Author (Organisation)

1 Introduction Martin Bauer (NEC)

2.1 Semantic Modelling in

oneM2M

JaeSeung Song (SJU) / JaeYoung Hwang (SJU)

2.2 Semantic Modelling for NGSI Martin Bauer (NEC)

2.3.1 Smart Parking Carmen Lopéz (UC) / SeungMyeong Jeong (KETI)

2.3.2 Bus Information System Hoang Minh (KAIST)

2.3.3 Crowd Modelling Fang-Jing Wu (NEC)

2.4 Semantic Modelling for Smart

Skiing Use Case

Rémi Druilhe (CEA)

3.1 oneM2M Resources and

Interactions

JaeSeung Song (SJU) / JaeYoung Hwang (SJU)

3.2 NGSI Martin Bauer (NEC)

3.3 Semantic Translation in

Semantic Mediation Gateway R1

Martin Bauer (NEC)

4 Conclusions Martin Bauer (NEC)

Glossary

Term or Abbreviation Definition (Source)

oneM2M Partnership project of telecom standardization organizations

around the world that specify the IoT/M2M service layer

platform as a basis for developing IoT/M2M applications.

(OMA) NGIS Next Generation Service Interfaces – group of interfaces

originally developed by OMA. In this context only the Context

Interfaces NGSI-9 and NGSI -10 are relevant. These have been

further developed in FIWARE (FIWARE) NGSI

(FIWARE) NGSI REST-like binding for OMA NGSI Context Interfaces using a JSON

representation.

FIWARE “Future Internet-WARE” – Platform developed as part of the EU

F7 Future Internet PPP, which is now managed by the FIWARE

Foundation.

MMG Morphing Mediation Gateway – component that allows flexible

translation between information from different platforms. New

translation models can be dynamically deployed at run-time.

Introduction

7

1 Introduction

1.1 Positioning in the project

The Wise-IoT project creates openness by building technologies for Global IoT Systems (GIoTS) that

decouple devices and applications from locally deployed IoT technology stacks. According to the Wise-

IoT consortium, decoupling can only be achieved without imposing great effort on the application

developer or device manufacturer if the three following conditions hold. The IoT data collection,

formatting, and transformation must be managed, dynamically if necessary. Remote IoT systems must

be usable by an application or device irrespectively of the IoT technology for which the application or

device has originally been developed. Finally, mechanisms need to be deployed that offer security,

privacy, and trust in IoT infrastructure that, with the help of Wise-IoT, becomes globally interworking.

The Wise-IoT objectives and stakeholder needs are addressed with an integrated architectural

approach that builds on established IoT standards and features the following technological

contributions.

Morphing Gateway to offer interworking between heterogeneous IoT platforms: Data from multiple

sources is often delivered in different formats, semantics, time slicing, precisions, etc. Thus translation

is required before the data can be used by a single application. Different sources need to be

transformed in different ways. Hence enabling applications taking advantage of heterogeneous

sources of IoT requires versatile and flexible facilities for real-time processing and translation of

collected and stored data. Since in IoT the availability of sources and the technologies used

dynamically change over time, gateways need to adapt themselves or “morph” over time. The

Morphing Gateway is the technology proposed by Wise-IoT to provide a world-wide interoperable IoT

infrastructure.

Semantic interoperability components: IoT devices must be managed to be discoverable and deliver

data with appropriate quality. Wise-IoT aims at automating the discovery, provisioning, and

reconfiguration functions. Reliable semantic-based discovery features will alleviate the need for

human involvement and assistance and allow GIoTS to complete automated installations. The

semantic interoperability components will also support the creation of a world-wide interoperable IoT

infrastructure.

Monitoring and adaptation mechanisms: In a global interoperability and mobility context, user

behaviour, IoT systems capabilities, and data quality are difficult to predict. User goal fulfilment will

need to be monitored and the factors affecting user trust be identified. The results obtained from

monitoring and feedback collection will allow applications and systems to be adapted to meet the user

needs and the capabilities of the context the applications are run. The monitoring and adaptation

mechanism is the technology proposed by Wise-IoT to win and retain users’ trust for exploitation of

data offered by global IoT infrastructure.

Trust framework and end-to-end security: The introduction globally connected IoT systems increases

the sensitivity of the data that is being collected and the scale of risk exposure when the IoT system is

being attacked. Trust agents are needed to collect trust-related data, trust brokers to disseminate that

data, and analysis and management tools needed to assess the system state and establish policies. The

trust framework is the technology proposed by Wise-IoT to harden the security and dependability of

world-wide interoperable IoT infrastructure.

Introduction

8

The results obtained from conceptual design, implementation, and empirical evaluation of the Wise-

IoT contributions in the field pilots from the perspectives of the Wise-IoT stakeholders will be used to

contribute to international IoT standardization.

1.2 Deliverable contribution

This deliverable describes the first release of the Semantic Interoperability components developed by

WP2 to be used as part of the Wise-IoT use cases. In addition to the actual components used in the

project, this accompanying report provides an overview of the delivered components, their current

status, and, where applicable, an outlook on the planned development for the second release.

Please note that the first release focuses on providing an initial basis for achieving interoperability

between the IoT platforms used, in particular between the oneM2M platform and NGSI-based FIWARE

GEs. It is about making it work in a basic way with limited flexibility and no support for dynamic

aspects. The core components for this are described in D2.1 whereas the focus of D2.4 is on the

semantic aspects that are to be integrated. For this, the semantic modelling is of key importance and

the required initial step. Thus a big part of this deliverable is dedicated to describing this, including the

ontologies that will be used in the respective use cases and are now available as a first version, which

will evolve in during the development. The Semantic Mediation Gateway takes a semantic-driven

approach for translating between semantically annotated oneM2M information and NGSI context

information (as described in Section 3.3) and thus realizes semantic interoperability. However, this

does not yet provide the flexibility and dynamic adaptation that is envisioned for the Adaptive

Semantic Module of the Morphing Mediation Gateway in the second release. It is this second release

to be described in D2.5 that will use reasoner and processing flow components to achieve dynamic

adaptation and a higher flexibility. These components have already mentioned in the description of

D2.4 in the Description of Action, but they are not available yet as they will not be needed to make

things work in the first stage.

This document is structured as follows: Chapter 2 first introduces the semantic modelling in oneM2M

and in connection with FIWARE: the Thing concept in the oneM2M base ontology can be mapped to

the Entity concept, enabling the creation of use case ontologies that are suitable for both platforms

and thus provide a basis for semantic interoperability. The initial ontologies for the main use cases, i.e.

smart city and smart skiing are described in Section 2.3 and Section 2.4 respectively.

Chapter 3 looks at semantic functionalities provided by the underlying platforms, and how the

semantic information can be used to connect these platforms, e.g. in the Morphing Mediation

Gateway. Whereas the general architecture, as well as key components and interactions are described

in D2.1 [3], the semantic modelling and processing aspects are described here.

Chapter 4 provides conclusions and an outlook to future work, in particular with respect to the second

release of components as part of D2.5.

Semantic Modelling

9

2 Semantic Modelling

2.1 Semantic Modelling in oneM2M

In the oneM2M standard, the concepts of abstraction and semantics are applied for supporting

coherent methodology to user and developers [11]. For example, by using abstraction concepts an IoT

system can decouple IoT applications from specific end device implementations regardless of their

technologies. It means that users do not need to know about technologies that are used in an IoT

device for example a Zigbee light switch device. In addition, semantic technologies provide a

description of the relationship between things/data/information so that they can support finding

meaningful information between IoT devices. Figure 1 shows a basic concept of abstraction and

semantics in the IoT system.

Figure 1 - High-level concept of abstraction and semantics

Ontology and their OWL representations are used in the oneM2M platform to provide syntactic and

semantic level interoperability of the oneM2M system with other IoT systems using their own

ontologies [12]. oneM2M only provides the minimal ontology, i.e., the oneM2M Base Ontology,

describing entities composing the oneM2M Ssystem. This base ontology can be used by other

organizations and companies to contribute their specific ontology that can be mapped to the oneM2M

Base Ontology [8].

The Base Ontology only contains Classes and Properties but not instances because the base

ontology and derived ontologies are used in oneM2M to only provide a semantic description of the

entities. Figure 2 shows the essential Classes and Properties of the oneM2M Base Ontology.

The nodes (bubbles) denote Classes whereas edges (arrows) denote Object Properties.

Semantic Modelling

10

Device

hasService hasFunction

OperationInput

refersTo

ControllingFunction

consistsOf

OperationOutput

OperationState

hasOperationState

exposesFunction

InterworkedDevice

ThinghasThingProperty

hasThingRelationThing

Property

is-a

is-a

Variable

OutputDataPoint

is-a

is-a

FunctionService

Operation

hasOperation

Command

hasCommand

is-a

Aspect

MetaData

AreaNetwork

isPartOf

hasOutput hasInput

hasMetaData

describes

SimpleTypeVariable

MeasuringFunction

InputDataPoint

exposesCommand

is-a

GET_Input

DataPoint

is-a

SET_Output

DataPoint

Variable

Aspect

hasOutputDataPoint

hasInputDataPoint

hasSubService

hasOutputDataPoint

is-a

hasInputDataPoint

Variable

Legend: A class shown with grey shading indicates that the same class appears multiple times in the figure

Variable

hasSubStructure

VariableConversion

hasConversionis-a

convertsTo

Figure 2 – The oneM2M Base Ontology

Semantic Modelling

11

2.2 Semantic Modelling for NGSI

In 2009/2010 OMA specified a set of interfaces called Next Generation Service Interfaces (NGSI). The

idea behind these interfaces was to replace and enhance the Parlay-X interfaces. One extension area

was context management and OMA defined two interfaces the Context Federation APIs and the

Context Operation APIs [2], which were numbered NGSI-9 and NGSI-10 respectively – so the number is

not a version number but the number of the interface within the NGSI interfaces. When NGSI

interfaces and data models are mentioned in the context of this document, the context of FIWARE and

the context of Wise-IoT, this only refers to the context interfaces. In OMA NGSI, only the abstract

context interfaces were defined, i.e. the functions and parameters are defined, but not the protocols

to be used. During the development of FIWARE, a REST-like HTTP binding was defined (sometimes also

referred to as FIWARE NGSI) and some further extensions and modifications (sometimes also referred

to as NGSIv1 and NGSIv2) using JSON for representing information. With the establishment of the ETSI

ISG CIM (Context Information Management) in January 2017, it is planned to evolve the context

interfaces, providing again a new and complete formal specification.

The core concept in the NGSI context interfaces is the concept of entity as it had been used in the

context definition by Anind Dey, which is relatively popular in the context-awareness community:

Context is any information that can be used to characterize the situation of an entity. An entity is a

person, place, or object that is considered relevant to the interaction between a user and an

application, including the user and applications themselves (Dey, 2001). [1]

Figure 3- OMA NGSI Context Information Model

Figure 3 shows the OMA NGSI Context Information Model. The core concept is the Context Entity –

typical entities are physical objects like buildings, rooms, cars but also persons, groups, events and

more abstract things like the coverage area of a wireless network. Entities have an identifier and a

type. The aspects of interest about entities are modelled as attributes, which have a name, type, value

and possibly a number of meta data elements, which again have a name, a type and a value.

For example, if the entity represents a meeting room, its type could be meeting room, and it might

have an attribute with name indoor_temperature, whose value would be the actual temperature, e.g.

27, the type would be temperature and as meta information the unit (e.g Celsius) and the accuracy

(e.g. +/- 0.5°C) could be provided.

class Context Information Model

Context Entity

- EntityId: xsd:string

- EntityType: xsd:anyURI

Person Group Place Event Thing

Context Attributes

- Name: xsd:string

- Type: xsd:anyURI

- Value: xsd:any

Meta-Data

- Name: xsd:string

- Type: xsd:anyURI

- Value: xsd:any

*1 *1

Semantic Modelling

12

OMA NGSI does not use a semantic representation of information, but identifies the option of using

references to ontology concepts for defining the types. Logically one can interpret the information

represented according to the NGSI data model as ontology instances, albeit represented according to

its own structure and not in a typical semantic format like RDF. Nevertheless, basing the NGSI

information on ontology concepts, an example of which is shown in Figure 4, NGSI can be used to

represent semantic information and, doing some transformations, embed it in the world of semantics.

Figure 4 – NGSI data modelled based on a fitting ontology

In the ETSI ISG CIM it is under discussion to develop a JSON-LD representation for the context

interface, which would directly ground it in the semantic world and directly offer a semantic

representation, as JSON-LD is one way of representing RDF triples.

2.3 Semantic Modelling for Smart City Use Case

2.3.1 Smart Parking

The Wise-IoT Smart Parking use case can be defined as an application based solution which, making

use of the available parking information from Busan and Santander cities, aims to both demonstrate

the interoperability of data between Europe and Korea through the Wise-IoT platform, and to provide

a service to the users which suggests them a route to an empty parking lot in the city. A complete

description of the use case can be found in [4].

Aiming to achieve the data interoperability, both data from Santander and Busan cities related to

parking have to design a concrete data model in order to, before be finally stored in the Wise-IoT CIM

layer, be translated by the Wise-IoT Morphing Mediation Gateway.

Semantic Modelling

13

In the case of Santander city, numerous parking sensors have been deployed in the downtown to

indicate the number of parking spots that are available or occupied. However, this will not be the only

information to be provided to the user. As the Smart Parking use case embraces different

functionalities which complement the main purpose of simply find a parking lot in the city, different

kind of data will be required. For example, the Wise-IoT Recommendation System, which will be

integrated within the use case, will provide guidance to the best area to park depending on different

factors such as statistics of availability of free parking lots, traffic to arrive to it, crowd information, etc.

So, as the interest is focused on providing an area instead of providing a concrete parking lot, it will be

needed to define not only entities related to the parking lots but to parking areas. Besides, related to

this use case, traffic monitoring data have to be defined in order to bring inputs for the

Recommendation System. This way, this data will be used to provide recommendations of parking

areas avoiding those routes with higher occupation.

The model to be used to structure the information will be the aforementioned NGSI (Section 2.2),

which will allow representing an 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 entity (status, location, category, etc.), defined by a name, a type and a

value. Finally, each attribute can include metadata, which provides extra information about it

(timestamp, unit of measurement, etc.). In addition, the underlying format to be used to represent this

data structure is JSON.

Regarding the semantic representation of information, FIWARE provides a Data Model, inspired by

GSMA data models and schema.org, developed to produce harmonized schemas for the Internet of

Things. In the case of parking information, the FIWARE Data Model specifies the semantic

representation of all entities of interest: the parking spot, the parking area and the traffic information

(parkingSpot, OnStreetParking, TrafficFlowObserved respectively).

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 facility: identifier, type,

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

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

tables are attribute names in the FIWARE data models

Table 1 – Properties of ParkingSpot entity

Property Expected Type Description

id String Entity’s unique identifier

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

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

name String The name used to identify the parking spot

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

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

category String Indicates the category of the parking spot. Possible

Semantic Modelling

14

values can be onstreet (onstreet parking site), offstreet (offstreet parking site), or other value that can be needed by the application.

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

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

Model.

As already mentioned, for the Smart Parking use case, different parking areas in Santander will be

specified. In order to do that, the parking area covered with sensors in the city will be 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.

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 [5].

Table 2 – Properties of OnStreetParking entity

Property Expected Type

Description

id String Entity’s unique identifier

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

dateModified DateTime (ISO 8601)

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

name String The name used for identify the parking area

location geo:json Provides the geolocation of the parking area

{

"id": "urn:entity:santander:parking:np3703",

"type": "ParkingSpot",

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

"name":"parking3703"

"status": "occupied",

"location": {

"type": "Point",

"coordinates": [

-3.80076, 43.4627

]

},

"refParkingSite":"urn:entity:santander:parking:areaABC ",

"category":["onstreet"]

}

Figure 5. Example of ParkingSpot entity following FIWARE Data Model

Semantic Modelling

15

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

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 permit is active. More info about the syntax can be found in [5]

allowedVehicleType 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 This attribute display if the parking spots are delimited or not (for example with painted lines)

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

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

Semantic Modelling

16

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

FIWARE Data Model.

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

words, vehicles are parked inside the building after passing through entrances. Data from parking lots

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

Data Model [5]. 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 [5].

Table 3 – Properties of OffStreetParking entity

Property Expected Type

Description

id String Entity’s unique identifier

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

dateModified DateTime (ISO 8601)

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

name String The name used for identify the parking area

{

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

"type": "OnStreetParking",

"location": {

"type":"Polygon",

"coordinates":[

[-3.798427, 43.464039],

[-3.796961, 43.464171],

[-3.796850, 43.464010],

[-3.798389, 43.463850]

]

},

"category":["blueZone", "shortTerm"],

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

"chargeType":[temporaryPrice],

"requiredPermit":["blueZonePermit"],

"permitActiveHours":{

"blueZonePermit":"Mo, Tu, We, Th, Fri, Sa 9:00-20:00"

},

"allowedVehicleType":"car",

"areBordersMarked":false,

"totalSpotNumber":25,

"occupancyDetectionType":[singleSpaceDetection]

}

Figure 6. Example of on street parking entity definition

Semantic Modelling

17

location geo:json Provides the geolocation of the parking area

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

allowedVehicleType 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 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 Integer Number of spots offered by the parking area. Possible values are any positive integer >=0.

occupancyDetectionType 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 String Opening hours of the parking site. E.g. "Mo,Tu,We,Th 09:00-12:00"

refParkingSpot List of <references>

Individual parking spots belonging to this offstreet parking site

aggregateRating String Aggregated rating for this parking site

contactPoint String Parking site contact point

Semantic Modelling

18

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

FIWARE Data Model.

The traffic information to be provided within the use case will be gathered from different traffic

sensors deployed in the city of Santander. This information will be 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. 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 [15].

Table 4 – Properties of TrafficFlowObserved entity

Property Expected Type Description

id String Entity’s unique identifier

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

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

location geo:json Provides the geolocation of the parking area

dateObserved Duration or Date and time of the observation. It can be represented

{

"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 7. Example of off street parking entity definition

Semantic Modelling

19

DateTime (ISO8601) as a time instant or a duration.

intensity Integer Number of vehicles detected during the observation period.

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

Figure 8 provides an example of a traffic sensor entity in JSON representation following the FIWARE

Data Model.

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

{

"id": "urn:entity:santander:traffic:3052",

"type": "TrafficFlowObserved",

"location": {

"type": "geo:json",

"value": {

"type": "Point",

"coordinates": [

-3.82288, 43.4633

]

}

},

"dateObserved": "2017-02-09T08:29:00.000Z",

"intensity": 71,

"occupancy": 0.33

}

Figure 8 – Example of traffic sensor entity

Semantic Modelling

20

hasCharge

Type

chargeType

requiredPermit

permiteActive

Hours

Allowed

VehicleType

areBorders

Marked

totalSpot

Number

Occupancy

DetectionType

dateObserved

intensity

occupancyid

type

location

dateModified

dateModified

status

refParkingSite

location

OnStreetParking parkingSpot

TrafficFlow

Observed

hasRequired

Permit

hasPermite

ActiveHours

hasAllowed

VehicleType

hasAreBorders

Marked

hasTotal

SpotNumber

hasOccupancy

DetectionType

hasDate

Observed

hasIntensity

hasOccupancy

hasId

hasType

hasLocation

hasDate

Modified

hasId

hasType

hasLocation

hasDateModified

id

type

category

name

hasDateModified

hasStatus

hasLocation

hasId

hasType

hasCategory

hasName

hasRef

ParkingSite

Thing

is-a is-a

is-a

hasName

hasCategory

OffStreetParki

ng

hasCharge

Type

hasRequired

Permit

hasAllowed

VehicleType

hasTotal

SpotNumber

hasOccupancy

DetectionType

hasLocation

is-a

is-a

is-a

hasDate

Modified

hasId

hasType

hasName

hasCategory

hasDateModified

availableSpot

Number

openingHoursaggregateRati

ng

contactPoint

hasAvailableSpotNumber

hasOpeningHourshasAggregateRating

hasContactPoint

Figure 9 – Ontology schema for Smart Parking use case

2.3.2 Bus Information System

The Bus Information System aims to provide bus information data to passengers in real-time. This

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

arrival estimations to bus stops from both Busan and Santander[4]. This information will be modelled

following the structure utilized for the semantic modelling in oneM2M (Section2.1) and NGSI

(Section2.2), respectively. However, since there is currently no available semantic representation for

bus properties defined in both oneM2M and FIWARE, it has been developed a general semantic

modelling for the bus system.

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

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

Semantic Modelling

21

FIWARE Data Model (Section 2.2). Thus, we present within document two major components of the

Semantic Modelling:

- 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’ focuses on the arrival information of the buses to a bus stop in

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

(e.g. Busan and 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.

Dictionary:

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

Table 5 – Properties of busLine entity

Property Expected Type Description

refBusStops 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 String The local ID (shorter form) of the bus line (e.g. ‘104’)

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

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

refStartBusStop 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 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 String The type of the buses that run on the bus line (e.g. standard)

startTime 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 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 ISO 8601 (Duration) The interval of buses arrival at a bus stop along the bus line in normal days, in ISO 8601 duration format (e.g. P3Y6M4DT12H30M5S)

intervalHoli 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 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 ISO 8601 (DateTime) The dateTime when the data has been last modified (e.g. 2017-02-05T08:15:30-05:09)

Semantic Modelling

22

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

Table 6 – Properties of busStop entity

Property Expected Type Description

refBuses 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 String The ID of the bus stop (e.g. ‘11161’)

busStopCount 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 String The name of the bus stop (e.g. city hall)

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

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

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

dateModified ISO 8601 (DateTime)

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

bus: a bus which runs towards a bus stop on a bus line

Table 7 – Properties of bus entity

Property Expected Type Description

refBusStop String The bus stop that the bus is heading towards (using the ID of the bus stop, e.g. urn:entity:busan:transport:bus:busStop:<busStopId>)

refBusLine String The bus line that the bus belongs to (using the ID of the bus line, e.g. urn:entity:busan:transport:bus:busLine:<busLineId>)

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

direction String The direction of the bus, in text format to accommodate different cases including number (0 or 1) and text (the name of the next next bus stop)

remainingTime ISO 8601 (Duration)

The remaining amount of time left until the bus reaches the bus stop specified in refBusStop, in ISO 8601 Duration format (e.g. PT5M)

remainingDistance Integer The remaining distance left until the bus reaches the bus stop specified in refBusStop, in meters (e.g. 3862)

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

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

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

Semantic Modelling

23

dateModified 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 8 – Properties of estimation entity

Property Expected Type Description

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

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

remainingDistances 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 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 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])

dateModified DateTime Entity's last update date

FIWARE Semantic Modeling in JSON representation:

The following table provides an example of an estimation representation.

{ "id": "urn:entity:santander:transport:tus:<busStopId>:<buslineId>", "type": "busArrivalEstimation", "dateModified": { "value": "2017-02-06T16:10:17.000Z", "type": "DateTime" }, "refBusStop": { "value": "urn:entity:santander:transport:tus:busStop:74", "type": "String" }, "refBusLine": { "value": "urn:entity:santander:transport:tus:busLine:5C1", "type": "String",

Semantic Modelling

24

}, “remainingDistances”: { "value":[100, 300], "type": "Array<Integer>", "metadata": { "uom":{ "value": "http://ontology.fiesta-iot.eu/ontologyDocs/m3-lite.owl#Metre", "type": "String", }, "timestamp": { "value": "2017-02-06T16:10:17.000Z", "type": "DateTime" } } }, “remainingTimes”: { "value":["PT35S", "PT8M5S"], "type": "Array<Duration>", "metadata": { "timestamp": { "value": "2017-02-06T16:10:17.000Z", "type": "DateTime" } } }, “destinationBusLines”: { "value":["destino1", "destino2"], "type": "Array<String>", "metadata": { "timestamp": { "value": "2017-02-06T16:10:17.000Z", "type": "DateTime" } } } }

oneM2M Semantic Modeling:

Semantic Modelling

25

Figure 10 - 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", "title": "Bus ID", "example": "2915",

Thing

Ref BusStops

LocalID ShortID NameRefStart BusStop

RefEnd BusStop

BusLine Type

Start Time

EndTimeInterval Norm

Interval Holiday

Interval Peak

BusLine

BusStopBus

Date Modified

Ref BusLines

Location

name

BusStop Count

ShortID

RefBuses

Date Modified

Location

CompanyName

Remaining Stations

RemainingDistance

RemainingTime

Direction

Date Modified

ShortID

Ref BusLine

Ref BusStop

Thing Property

Thing Property

Variable Variable

Thing Property

Variable

hasRef BusStop

hasRef BusLine

has ShortID

has Direction

hasRemaining Time

hasRemaining Distance

hasRemaining Stations

hasCompany Name

hasLocation

hasDate Modified

is-a is-a

is-a

hasRef BusStops

has LocalID

has ShortID

has Name

hasRefStartBusStop

hasRefEnd BusStop

hasBusLineType

hasStart Time

hasEnd Time hasInterval

NormhasInterval

HolidayhasInterval

PeakhasDate Modified

hasDate Modified

hasRef BusLines

hasLocation

hasName

hasBusStopCount

hasShortID

hasRefBuses

is-a

is-a

is-a

is-a

is-a

is-ais-a is-a is-a is-a

is-a

is-a

is-a

is-a

is-ais-a

Thing Property

Thing

hasThing Property

Thing Property

Thing

hasThing Property

Thing Property

Thing

hasThing Property

Thing Property

Thing

hasThing Property

is-ais-a

is-a

is-ais-ais-ais-ais-a

is-ais-a

is-a

is-a

Semantic Modelling

26

"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.", "example": "2017-11-05T08:15:30-05:00",

Semantic Modelling

27

"description": "The dateTime when the data has been last modified, in ISO8601 DateTime format" } }, "required": ["refBusStop", "refBusLine", “shortID”, "direction", "remainingTime", "remainingDistance", "remainingStation", “dateModified” ] }

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] }

2.3.3 Crowd Modelling

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 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 both Santander and Busan will be converted into a

NGSI-based context information model by 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 decision on parking lot search so they can drive to

the areas with the lower stay durations of crowds.

The NGSI-based context information model in Section 2.2 is used for the crowd detection services. It

will represent an entity (crowd detector, mobile devices, crowd measurements, and stay durations)

with its entity ID and its type. Furthermore, a set of attributes is defined to represent the properties of

the entity such as the name of crowd detector and the location of the crowd detector. For each

attribute, it can include its 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 three major

entities: crowd detector, crowd estimation, and stay duration. The first one represents a crowd

detector, while the latter two represent the data analytics results.

Semantic Modelling

28

First we explain the attributes of a crowd detector. Table 9 illustrates the data model of crowd

detector.

Crowd detector:

Table 9- The properties of the crowd detector entity

Property Expected Type Description

id String Entity’s unique identifier. In this case, the entity ID for a crowd detector is the MAC of crowd detector

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

domainMetadata JSON The detailed location of crowd detector.

Crowd data analytical results:

Below, we define the following attribute for the two key entities (1) crowd estimation and (2) stay

durations regarding to the crowd data analytics results in the crowd detection service. Frist, the

attributes of crowd estimation is explained. Table 10 illustrates the defined attributes of crowd

estimation results. There are four basic properties: "ID", "type", "domainMetadata", and

"CrowdEstimation".

Table 10- The properties of the crowd estimation entity.

Property Expected Type Description

id String Entity’s unique identifier. The entity id structure: Name of The REsult + CrowdDectectorMacAdress+ StartTime + EndTime. For example, "id": "WifiStayEstimation-0ab2132abc1231-1111170000-11111800000"

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

domainMetadata JSON The detailed location of crowd detector and the query time window. An example is provided in Figure 11. The purpose of this property is to speed up query.

CrowdEstimation String The estimated number of mobile devices captured by this crowd detector.

Next, we define the attributes of the stay durations as follows. Table 11 illustrates the attributes of

stay durations. Similarly, four basic attributes represent the distribution of stay durations.

Table 11 – The properties of stay durations entity

Property Expected Type Description

id String Entity’s unique identifier. The entity id structure: Name of The Result + CrowdDectectorMacAdress+ StartTime + EndTime. For example, "id": "WifiStayDuration-0ab2132abc1231-1111170000-11111800000"

type String The type of entity. In this case, the defined value for stay duration is “WifiStayDuration”.

Semantic Modelling

29

domainMetadata JSON The detailed location of crowd detector and the query time window. An example is provided in Figure 11. The purpose of this property is to speed up query.

StayDuration JSON The distribution of stay durations for crowds captured by this crowd detector.

Figure 11 - An example of domainMetadata data for WifiCrowdEstimation

2.4 Semantic Modelling for Smart Skiing Use Case

In the public semantic model repositories, e.g., FIESTA IoT project [6], W3C, the ski resort

environment, does not exist. Thus, 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 [6]. This model considers specific elements related to the ski resort

equipment such as the aerial way (e.g., chair lift, drag lift) or the pistes (e.g., downhill, halfpipe). A

subset of the semantic model is proposed in the Figure 12. The complete semantic model is available

in an OWL format in the repository of the project.

"domainMetadata": [

{

"name": "SimpleGeolocation",

"value": {

"latitude": -43.533418,

"longitude": 172.634259

}

},

{

"name": "AbstractionLevel",

"value": "0"

},

{

"name":"StartDate",

"value": "2016.11.17 12:05:22:910 +0200"

},

{

"name":"EndDate",

"value": "2016.11.17 12:05:22:910 +0200"

}

]

Semantic Modelling

30

Figure 12 - Subset of the semantic model for the skiing resort

For each use case, we reuse existing semantics models from various sources to model the devices, e.g.,

the sensors of the LoRa band or the crowd detector. The next step is to include them in the semantic

model of the ski resort proposed previously.

This enables to make the conjunction between the on the ground devices, i.e., LoRa band and crowd

detector, provided by the edges gateways and the semantic model proposed to model a ski resort

stored in the upper layers Context Information Management layer of the project.

The next sections describe the first drafts of the semantic model for the ski resort use cases. The

devices used in those use cases also appear in other environments, e.g., smart city. However, we first

need to finalize the skiing resort semantic model to make bridges between those devices and the

characteristics of the mountains during winter. This linkage will be done in the release 2 version of this

deliverable.

2.4.1 Crowd monitoring

The crowd monitoring use cases reuse the devices deployed in the Smart City use cases, except that

the goal is to monitor the crowd traffic at the ski lifts. This information is then provided to skiers to

adapt their route in the skiing area and to the ski resort manager to adapt the skiing area accordingly

For the release 1, the devices are first deployed and tested in the Smart City, the semantic model will

not be presented in this document. However, due to a strong similarity between the Smart City and

Smart Skiing crowd monitoring use cases, we assume that the semantic model will be the same. as in

Section 2.3.3.

Semantic Modelling

31

2.4.2 Assets tracking

The “Assets Tracking” use cases is mainly based on the location of the trackingdevice that is attached

to the asset. This kind of use cases is a well-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 [6].

<owl:Class rdf:about="http://purl.org/iot/vocab/m3-lite#Coordinates">

<rdfs:subClassOf rdf:resource="http://purl.org/NET/ssnx/qu/qu#Unit"/>

<rdfs:comment xml:lang="en">Triples for location in the (Latitude, Longitude, Altitude)

format.</rdfs:comment>

<rdfs:label xml:lang="en">Coordinates</rdfs:label>

</owl:Class>

2.4.3 “Conquer the slope”

The “Conquer the Slope” use cases is based on the data provided by the LoRa band device and its

sensors, i.e., location, accelerometer, button. Using data-fusion, it is possible to provide upper layer

data, such as airtime, carving, turns, speed. Those data are then used to sort the players according to

their performance.

The sensors deployed in the LoRa band are well known sensors and thus they already have a semantic

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

case. An example is provided below for the accelerometer:

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

Semantic Interoperability Components

32

3 Semantic Interoperability Components

This chapter first discusses the aspects of the IoT platforms used in Wise-IoT that are related to

semantics and then the components developed in Wise-IoT that are used to perform the semantic

annotation and mapping to enable the semantic interoperability.

3.1 oneM2M Resources and Interactions

In oneM2M specifications Application Entities (AEs),and Common Service Entitites (CSEs) are

represented as resources and are uniquely addressable via their resource identifiers [14]. In addition,

semantic information can be added through a specific resource (i.e. <semanticDescriptor>), if

users want to add a certain meaning to resources. This section provides a brief description of oneM2M

semantic resource structure and how oneM2M semantic resources are used in oneM2M systems.

Figure 13- < SemanticDescriptor > resource structure

The <semanticDescriptor> resource is used to store a semantic description potentially related

to other resource or sub-resources. One or more semantic resource can be added to several resource

types (e.g. <AE>, <container>, <contentInstance> resources) [13]. Figure 13 shows the basic

resource structure of <semanticDescriptor> resource.

Figure 14 - Resource structure of smart street light AE

<semanticDescriptor>

1descriptor

0..1 (L)

0..1ontologyRef

<subscription>

relatedSemantics

0..n

1descriptorRepresentation

0..1semanticOpExec

Semantic Interoperability Components

33

Figure 14 shows an example of semantic descriptor for a smart street light that can be installed in a

smart city. In this example, a smart street light is assumed as an AE using the Mca reference point to

access the resource on a CSE. The <AEstreetLight1>, which is one of the specializations of

<flexContainer> resource resource includes an ontologyRef attribute which contains the URI

of the ontology concept of the smart street light, (e.g. "http://ontology.wise-

iot.net/smart-city#StreetLight".) The <onOffContainer> and the

<stateContainer> resources represent the functional interface aspects of the street light.

Semantic annotation is a process of providing and inserting semantic description into a semantic

structure for example the <semanticDescriptor> resource in oneM2M. Figure 15 shows a

semantic annotation example stored in the descriptor attribute of the <semanticDescriptor>

resource. The information provides the link between the operations of the washing machines and the

containers of the smart washing machine AE and describes the REST methods that can be executed on

the containers.

<rdf:RDF

<rdf:Description rdf:about="http://ontology.wise-iot.net/smart-city#STREET_L_SJU_123">

<rdf:type rdf:resource="http://ontology.wise-iot.net/smart-city#Streetlight"/>

<wise:hasManufacturer>SJU</wise:hasManufacturer>

<wise:hasDescription>Very smart Street Light</wise:hasDescription>

<wise:hasLocation rdf:resource="http://ontology.wise-iot.net/smart-city#Sejong_Univ_Campus"/>

<msm:hasService rdf:resource="http://ontology.wise-iot.net/smart-city#LighteningService_123"/>

<msm:hasService rdf:resource="http://ontology.wise-iot.net/smart-city#StateService_123"/>

</rdf:Description>

<rdf:Description rdf:about="http://ontology.wise-iot.net/smart-city#LighteningService_123">

<rdf:type rdf:resource="http://ontology.wise-iot.net/smart-city#LighteningService"/>

<msm:hasOperation rdf:resource="http://ontology.wise-iot.net/smart-city#TurnOnOperation_123"/>

</rdf:Description>

<rdf:Description rdf:about="http://ontology.wise-iot.net/smart-city#TurnOnOperation_123">

<rdf:type rdf:resource="http://ontology.wise-iot.net/smart-city#LighteningOperation"/>

<hr:hasMethod>Create</hr:hasMethod>

<hr:hasURITemplate>/CSE1/STREET_L_SJU_123/onOffContainer</hr:hasURITemplate>

<msm:hasInput rdf:resource="http://ontology.wise-iot.net/smart-city#Action"/>

</rdf:Description>

<rdf:Description rdf:about="http://ontology.wise-iot.net/smart-city#StateService123">

<rdf:type rdf:resource="http://ontology.wise-iot.net/smart-city#StateService"/>

<msm:hasOperation rdf:resource="http://ontology.wise-iot.net/smart-city#StateOperation123"/>

</rdf:Description>

</rdf:RDF>

Figure 15 – Semantic resource description of smart street light AE

Once semantic description is annotated to a resource, it can be used to discover the resource with its

semantic description. Figure 16 shows the general resource retrieve operation in oneM2M. This

operation can also be applied to the <semanticDescriptor> resource. Four operations, i.e.

Create, Retrieve Update and Delete are also applied to <semanticDescriptor>

resources like to other resources such as <remoteCSE>, <AE>, or <Container> resources.

Semantic Interoperability Components

34

Figure 16 - Procedure for RETRIEVING a Resource in oneM2M

In the case of an UPDATE operation, as shown in Figure 17, a simple overwrite can be applied. For

example, in order to change (i.e. update) semantic instances in the <semanticDescriptor> resources,

the system has to change the whole descriptor attribute value. If part of semantic information needs

to be updated, then a SPARQL query can be sent in an Update request.

Figure 17 – Example of managing a semantic instance in the oneM2M system

3.2 NGSI

The Semantic Mediation Gateway as defined in D2.1 [3], Section2.2.1, which will evolve into a

Morphing Mediation Gateway module in the next phase, uses an ontology that models all the aspects

relevant for NGSI to enable the transformation from information provided in the oneM2M system to

NGSI, i.e. making the information available to FIWARE Generic Enablers (GEs).

Semantic Interoperability Components

35

Figure 18 – Ontology representation and mapping to NGSI structure

Figure 18 shows how ontology instances are represented based on an ontology modelling a car, for

which environmental light is being measured in the unit lux. This semantic information can, for

example, be stored in a oneM2M system. The bold red elements in Figure 18 show how the semantic

elements can be mapped to the NGSI data structure to be stored and made available by FIWARE GEs

like the Orion Context Broker or the Aeron IoT Broker.

3.3 Semantic Translation in Semantic Mediation Gateway

R1

In Section 3.1 it has been described how semantically annotated information can be provided in

oneM2M and what mechanisms are available for discovering the resources containing this

information. In Section 3.2 it was shown how the semantic information can be mapped to the NGSI

context information model. This section presents how the semantic translation in the Semantic

Mediation Gateway as defined in D2.1 [3], Section2.2.1 uses the available functionalities and

information.

Semantic Interoperability Components

36

Figure 19 – Representation of sensor data and semantic annotation in the oneM2M system

Figure 19 shows the resource structure in a oneM2M system representing the information described

in Figure 18. There is a container resource for storing the measured light values represented as

content instances (23, 24, 23). Semantic annotation is stored in the semantic descriptor resource

attached to the container resource that provides information about the values being measured. This

includes meta information like the unit of measurement, but also contextualization information, i.e.

that the light value represents the light in the environment of a particular car.

The Semantic Mediation Gateway uses Semantic Discovery to discover the container resources whose

semantic descriptor resources fit the semantic filter expressed as a SPARQL query. An example could

be the following:

SELECT ?car

WHERE {

?car rdf:type carOnt:car .

?car carOnt:hasEnvironmentLight ?light

}

On discovering the container resource, the Semantic Mediation Gateway subscribes to the creation of

a new child resource. Thus the Semantic Mediation Gateway is informed whenever a new child

resource becomes available. i.e. typically when a new content instance is created. The Semantic

Mediation Gateway also retrieves the semantic annotation contained in the semantic descriptor

resource. Together, all the information necessary for the transformation is available and the Semantic

Mediation Gateway sends a notification to the Context Information Management layer, e.g. the

Context Broker or the IoT Broker.

3.4 Semantic Annotator

When a resource is created in a oneM2M platform instance, it may not come with any semantic

description. Then there needs to be a mechanism allowing developers or users to add semantic

information (called semantic annotation) to existing oneM2M resources.

Semantic Interoperability Components

37

A semantic annotator is a tool allowing users to use the semantic annotation feature. The tool is

developed to support interactions for semantic interworking, transforming semantic information into a

standardized semantic data format.

The annotation tool is being developed based on an assumption that the oneM2M platform supports a

resource for semantic description. The tool allows users to create a semanticDescriptor

resource under the oneM2M resource to be annotated, for example contentInstance. In order to

support interactions with the oneM2M platform, the annotation tool will contain various user

interfaces, for example, obtaining the IP address of the IN-CSE server, a list of available resources for

semantic annotation and selection for CRUD operations. Figure 20 shows the initial UI for the

annotation tool.

Figure 20 A potential UI for semantics annotation tool

Conclusion and Outlook

38

4 Conclusion and Outlook

In this deliverable we have described how semantic information can be used in the core of Wise-IoT

target platforms, i.e. oneM2M and FIWARE. In FIWARE the modelling is based on the NGSI context

information model as used in the NGSI context interfaces. In oneM2M, the oneM2M Base Ontology

provides a reference that can be used as the basis for deriving domain-specific ontologies.

Based on the requirements of the target 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 ontologies described in this

deliverable will be applied in the Wise-IoT use cases. Based on the experience gained in using the

ontologies, they will be enhanced and modified. The result will be presented in deliverable D2.5.

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 Semantic Mediation Gateway, which will evolve into the Adaptive Semantic

Module of the Morphing Mediation Gateway in release 2 of the Wise-IoT components.

Deliverable D2.5 will describe the evolution of the semantic interoperability components. These will

become more flexible and support dynamic adaptation, which will be needed to support the IoT use

cases during their life time. It is to be expected that devices, technologies and also information models

and semantic descriptions change over the deployment lifetime. In a global setting, IoT systems have

to dynamically adapt to these changes and deal with the constantly changing set of devices with which

users move through the different deployments. To support these cases, the advanced semantic

components including reasoners, data transformation functions and processing flows will be needed.

References

39

5 References

[1] Dey, Anind K. (2001). "Understanding and Using Context". Personal Ubiquitous Computing. 5

(1): 4–7. doi:10.1007/s007790170019

[2] Open Mobile Alliance, NGSI Context Management, Candidate Version 1.0 – 03 Aug 2010

[3] Wise-IoT D2.1 – Morphing Mediation Gateway with Management and Configuration Functions

R1, March 2017

[4] Wise-IoT D1.1 – Wise-IoT Pilot Use Case Technical Description, Business Requirements and

Draft High-Level Architecture

[5] FIWARE Datamodels for Smart Parking, http://fiware-

datamodels.readthedocs.io/en/latest/Parking/doc/introduction/index.html

[6] FIESTA-IoT, http://ontology.fiesta-iot.eu, 2017

[7] OpenSnowMap, http://opensnowmap.org, 2017

[8] oneM2M Base Ontology, http://www.onem2m.org/ontology/Base_Ontology

[9] ISO 8601 – Time and date format, http://www.iso.org/iso/home/standards/iso8601.htm

[10] GeoJSON, http://geojson.org/

[11] TR-0007-Study on Abstraction and Semantics Enablement-V2_11_1,

http://onem2m.org/technical/published-documents

[12] TS-0012-oneM2M-Base-Ontology-V2_0_0, http://onem2m.org/technical/published-

documents

[13] TR-0033-Study_on_Enhanced_Semantic_Enablement-V0_3_0,

http://onem2m.org/technical/published-documents

[14] TS-0001-Functional Architecture, http://onem2m.org/technical/published-documents

[15] FIWARE Datamodels for Traffic Flow, http://fiware-

datamodels.readthedocs.io/en/latest/Transportation/TrafficFlowObserved/doc/spec/index.ht

ml