H2020-EUJ-02-2016
H2020 Grant Agreement Number 723076
NICT Management Number 18302

Deliverable D6.4

Holistic Data Management:
Refined Concepts and Models
Version V2.2
November 29th, 2018

ABSTRACTThis document describes a model developed in the context of the CPaaS projectthat provides the foundation for a holistic data management view on heterogeneous data. The model aims to provide a unified view on data and data quality
in the context of IoT platforms such as CPaaS.io. The approach addresses thesemantic interoperability problem with respect to personal data managed bytechnologically different platform instances in different regions of the world. The
focus is on managing and exchanging data between the European FIWARE-based
CPaaS.io instance and the Japanese U2-based instance.

This work is licensed under the Creative Commons Attribution 4.0 International License.
To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Disclaimer
This document has been produced in the context of the CPaaS.io project which is jointly funded by theEuropean Commission (grant agreement n° 723076) and NICT from Japan (management number 18302).
All information provided in this document is provided "as is" and no guarantee or warranty is given thatthe information is fit for any particular purpose. The user thereof uses the information at its sole risk andliability. For the avoidance of all doubts, the European Commission and NICT have no liability in respectof this document, which is merely representing the view of the project consortium. This document issubject to change without notice.

Document Information
Editors
Authors
Reviewers
Delivery Type
Dissemination
Level
Contractual
Delivery Date
ActualDelivery Date
Keywords

H2020 EUJ-02-2016

Eduard Klein (BFH), Patrizio Collovà (BFH)
Patrizio Collovà (BFH), Adrian Gschwend (BFH), Eduard Klein (BFH)
Stefan Gessler
Kazuma Asai
ReportPublic30/11/2018
29/11/2018
Semantic models, ontologies, semantic integration layer, data quality,
linked data, heterogeneous data, privacy, GDPR

CPaaS.io

Page 2 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Revision History
Rev.
0.2
0.5
0.7
0.8
0.9
0.10
0.11
0.12
0.13
0.14
0.15
0.16
0.17
0.18
1.0
2.0

Date
03.05.201808.05.201807.06.2018
29.06.2018
03.07.201804.07.201805.07.2018
17.07.2018
03.09.2018
11.09.2018
14.09.2018
19.09.2018
21.09.2018
19.09.2018
30.09.201809.11.2018

2.1
2.2

15.11.2018
29.11.2018

Description
Initial document, First ToC
Integrating requirements based on previous deliverables
First layout of Data Quality Model
Adding model overview, base classes, base properties
Remaining properties for Data Quality Model
Remaining properties for Data Quality Model
Adding initial work for Privacy Support Mechanism
Final Privacy Support Mechanism
Review, adding OWL properties, comments
Answering open comments
Adjusting Data Quality Model based on comments
Minor fixes
Adding GitHub repository link for OWL file
Minor fixes
Open comments closed
Call for contribution to project partners; Integrating
discussions on open topics from D6.3, incl. GDPR aspects
Final editing before internal review
Final editing, without open comments from internal review

Contributors
Stephan Haller (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Patrizio Collovà (BFH)
Adrian Gschwend (BFH)
Patrizio Collovà (BFH)
Adrian Gschwend (BFH)
Adrian Gschwend (BFH)
Adrian Gschwend (BFH)
Adrian Gschwend (BFH)
Patrizio Collovà (BFH)
Eduard Klein (BFH)
Eduard Klein (BFH)
Eduard Klein (BFH)

List of Acronyms
Acronym
DCAT
DDD
GDPR
ICAT
IDM
IoT
LOD
M2M
NGSI
OBDA
OGD
OWL
RDF
SEDAQ
SDR
SPARQL
SSN
TurtleDefinition
Data Catalog Vocabulary
Domain Driven Design
General Data Protection Regulation
IoT Catalog
IoT Domain Model
Internet of Things
Linked Open Data
Machine to Machine
Next Generation Service Interface
Ontology Based Data Access
Open Governmental Data
Web Ontology Language
Resource Description Framework
Ontology for sensor data quality assessment
Semantic Data Repository
SPARQL Protocol and RDF Query Language
Semantic Sensor Network
Terse RDF Triple Language

H2020 EUJ-02-2016

CPaaS.io

Page 3 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Table of Contents
1

Introduction............................................................................................................................................................................... 52

A Model for Data Quality Assessment ............................................................................................................................ 6
2.1

Problem Description ..................................................................................................................................................... 7

2.2

Requirements Fulfilment ............................................................................................................................................. 7

2.3

Design Options ............................................................................................................................................................... 8

2.4

Solution Approach ......................................................................................................................................................... 9

2.5

Sensor Data Quality Model ...................................................................................................................................... 13

2.5.1

2.6
3

4

Entity Description................................................................................................................................................ 14

2.5.1.1

Entities Representing Sensors ................................................................................................................... 14

2.5.1.2

Entities Representing Measurements ..................................................................................................... 15

2.5.1.3

Entities Representing Other Devices....................................................................................................... 18

The SEDAQ ontology .................................................................................................................................................. 19

Privacy Support Mechanisms............................................................................................................................................ 20
3.1

Requirements Concerning Privacy......................................................................................................................... 20

3.2

Privacy in the Model Context .................................................................................................................................. 21

Conclusion ............................................................................................................................................................................... 22

References ......................................................................................................................................................................................... 23

H2020 EUJ-02-2016

CPaaS.io

Page 4 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

1 Introduction
According to the Description of Work (DoW), this deliverable contains refined concepts and models for aholistic data management approach which have been developed in the respective tasks of work package
6 (WP6), considering the experiences and learnings from the first use case trials and feedback fromstakeholders. Based on the preceding WP6 deliverables on holistic data management D6.1 (Fraefel et al.,2016) and D6.3 (Strohbach et al., 2018) and reflective discussions on its contents as well as learnings fromthe ongoing CPaaS.io project, the current results on holistic data management are presented in thisdeliverable.
According to the CPaaS.io core objectives,(1) managing personal data and providing full control to citizens about their data, and(2) exchanging data between different platforms (here: FIREWARE/EU and u2/Japan)
is strictly followed by defining an appropriate ontology for data quality assessment. Guided by the General
Data Protection Regulation (GDPR), the proposed approach gives control to individuals (formerly called"data subjects") over their personal data.
From a data management and interoperability perspective, the initial concepts from earlier project phases
have been refined and unified in the SEDAQ ontology (Sensor Data Quality Assessment) which is(1) based on W3C standards,(2) builds on wide-spread ontologies such as SSN and schema.org,(3) has an extension to support privacy mechanisms, and(4) is embedded in the general IoT Domain Model.
Following the core principles of CPaaS.io, data protection by design and by default as required by the
GDPR has been considered resulting in appropriate privacy concepts in the proposed ontology. Specifically,for personal data access control mechanisms are provided on a fine-granular basis to protect data fromunauthorized access. Theses privacy principles are not only followed in the proposed ontology but also in
implemented smart city platform components which are developed in other CPaaS.io work packages suchas the citizen dashboard from Task 5.3.
The proposed concept allows smart city platform applications to protect data such that they are notavailable publicly without explicit, informed consent of the data owner. A timeframe can be added to thedata in which they are accessible publicly. Moreover, the data subject can access, read, change and revokeconsent on "his" data at any time, be it on specific data or on the complete data set.
The contents of this deliverable builds on previous deliverables, such that basic concepts are not repeated
but referenced in this document instead. In D6.1, the state of the art in holistic data management withregard to several categories of data is presented such as IoT/sensor data, open data, crowd-sourced data,
linked data and social media data. In D6.3, initial concepts and models that were likely to be useful within
the project context have been developed, ranging from a model for assessing data quality, linking datafrom various sources and privacy support mechanisms to user empowered master data management.

H2020 EUJ-02-2016

CPaaS.io

Page 5 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

This deliverable D6.4 provides a refined version of concepts and models for holistic data management,
whose central outcome is a data model for sensor data quality and privacy. This model takes into accountthe core objectives of WP6 and provides the following output in relation to WP6 tasks:•

A model for data quality assessment and respective ontology for data annotation (Task 6.1, Data
quality).

•

Privacy governance mechanisms taking into account user consent aspects, access control policies
and possibilities for context-dependent access control e.g. in life-critical or recreational scenarios(Task 6.3, Privacy governance).

•

A data model and mechanisms for managing personal data by individuals, allowing users to change
or delete data (access) that is managed by the CPaaS.io platform (Task 6.4, User empowered masterdata management).

Based on reflective discussions, stakeholder feedback and developed use cases, only few ideas from the
proposed concepts of D6.3 had to be dropped, such as the prospected integration of the Shapes Constraint
Language SHACL (Strohbach et al., 2018, section 2.4). Most of the ideas of the concepts and models
proposed in D6.3 however have proven to have the potential to be further developed, so that they weretransferred into the proposed concept including the SEDAQ ontology, which will be explained extensively
in this deliverable.
The document is structured as follows: in section 2, a model for sensor data quality is developed, based onan adapted IoT Domain Model, and resulting in the SEDAQ ontology. In section 3, an extension of the
ontology is presented with focus on privacy support mechanisms.
This document is accompanied with a technical annex containing the SEDAQ ontology, both as RDF data
model and in Turtle1 notation.

2 A Model for Data Quality Assessment
Depending on the data category (IoT data, open data, …), a broad variety of technical and conceptual data
quality categories and corresponding assessment methods are proposed in the literature (Fraefel et al.,2016). The approach presented here focuses on IoT data, specifically sensor data which is the main data
source for most CPaaS.io use cases under consideration. Since the to be assessed data are inherently
unreliable, the proposed ontology allows to describe data quality and data source quality throughmetadata. This information can be used for assessment or other purposes in higher layers of the CPaaS.io
architecture or in other end user applications.

1

https://www.w3.org/TR/turtle

H2020 EUJ-02-2016

CPaaS.io

Page 6 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

2.1 Problem Description
In Deliverable D6.1 (Fraefel et al., 2016), the state of the art of data quality with respect to Smart City
solutions has been addressed. Deliverable D6.3 (Strohbach et al., 2018) describes the basic concepts andchallenges related to data quality in the context of sensor data in smart cities.
Smart City applications use data from heterogeneous sources such as IoT data, data from social networks,
crowd-sourced data and open (government) data. In this multi-modal information approach, data quality
is crucial for the quality of smart city applications. IoT data rely on the quality of sensor devices and on
local conditions. They are inherently unreliable regarding accuracy, timeliness and provenance. Measurements obtained from such devices can exhibit errors in measurement or precision, mostly due to technicallimitations, noise in the environment or different problems arising from data communication or processing
activities.
To perform data quality assessment tasks and being able to take informed decisions about the appropriate
data usage, a model for data quality assessment is presented in this document.

2.2 Requirements Fulfilment
The requirements defined in Deliverable D2.1 (Requirements Specification) and in Deliverable 3.1 (Requirement Collection Analysis) related to the data quality assessment model are referenced and discussed in
the table below. These are the same Requirements which have been presented in the preceding Deliverable
D6.3, only that the fulfilment of the requirements is discussed subsequently.
Table 1: Requirements related to model for data quality assessment

UNI ID

Description

Challenge

It should be possible to set-up data quality constraints Contributes to trust and reputation.
NFREQ.28 for data producers to comply with. In the same way, it Data quality constraints are based
should be possible to monitor/verify data quality.
on quality measures to be defined.
Any data at the platform level shall have data quality
annotations

The semantic description of data
sources must contain appropriate
metadata.

Data search and retrieval shall be achieved upon acollection of criteria that includes location (of the phyFREQ.11 sical entity concerned), characteristics of the underlying IoT resource reputation and the quality of information.

The semantic description of data
sources must contain appropriate
metadata.

FREQ.10The CPaaS.io platform must provide publish/subscribe
The semantic description of data
functionality and criteria for filtering incoming or outFREQ.90
sources must contain appropriate
going data based (at least) on geographical area, data
metadata.
type and data source.
The semantic description of data
The CPaaS.io platform should offer means for synFREQ.113
sources must contain appropriate
chronizing clocks between IoT devices.
metadata.
The semantic description of data
FREQ.116 It should be possible to publish data about actuation. sources must contain appropriate
metadata.
H2020 EUJ-02-2016

CPaaS.io

Page 7 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Discussion:- NFREQ.28: SEDAQ allows to define constraints as types and value ranges- All other mentioned requirements in Table 1 are fulfilled by the SEDAQ metadata approach

As a prerequisite for the requirements in Table 1, implementations of the requirements concerning thesemantic layer (Table 2) must be available:
Table 2: Prerequisite Requirements

UNI ID

Description

Data must be interoperable across the different parties and domains (data/service providers)
The architecture must favor the reuse of widespread standards for
NFREQ.36
data and API.
NFREQ.27

FREQ.13

Any data at the CPaaS.io platform level shall be following an accepted set of standard schemas (ontologies) for annotation.

The CPaaS.io platform shall be able to aggregate data fromvarious sources using LOD principles.
The CPaaS.io platform must provide mechanisms for collecting,
FREQ.110
publishing and storing semantic data (historical data).
FREQ.14

Discussion: all requirements of Table 2 are fulfilled by implementation activities in other work packages.
Among others, the requirements in Table 3 must be also considered when integrating the data quality
assessment model into the CPaaS.io platform.
Table 3: Benefitting Requirements

UNI ID

Description

The CPaaS.io platform must be able to perform analytics,
FREQ.80 and event detection/prediction using live and historical data.
The CPaaS.io platform may provide data validation serviFREQ.92
ces.
The CPaaS.io platform should be able to collect and manaFREQ.118
ge user feedback.
Discussion: the implementation of the benefitting requirements of Table 3 is not part of work package
WP6. However, the SEDAQ ontology provides information through its metadata concept which
contributes to the fulfilment of these requirements.

2.3 Design Options
Data quality assessment is based on data and metadata attributes in a data stream and on subsequent
processing using assessment criteria.
H2020 EUJ-02-2016

CPaaS.io

Page 8 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

The proposed model for sensor data quality assessment is based on the following design choices:
1. The partial model describing empirical data, that is, data collected from sensors in active state, as
well as the partial model describing the sensors as physical devices and the one on metadata about
the quality of data gathered by such sensors are part of a complete ontology about sensors in smart
cities.
2. Existing ontologies are used as far as possible, eventually integrating and adapting different approaches into a consistent model.
3. Additionally, other information sources related to sensors (especially in the context of smart cities)
are considered in the design of the final model. Technical standards and norms such as ISO/DIN
and data schemas (e.g. from http://schema.org), can provide valuable ideas to be incorporated into
the proposed model.
4. The model for data quality is embedded in an information architecture based on a layered architectural model.
5. On each layer, additional information is added to the data obtained from the lower layer, generating enriched data with context-dependent semantical information (semantically enriched data entities)
6. On each layer, available data (original and additional data) can be assessed for quality according
to available metadata. Using the metadata from the ontological model required in this context, acontext-dependent quality assessment component evaluates the data of this layer.

2.4 Solution Approach
The proposed ontology for sensor data quality assessment (in short SEDAQ) has been inspired by a wide
range of approaches, specifically from ontologies and ideas proposed by (Debattista, Lange, & Auer,
2014), (Debattista et al., 2016) and (Iggena, Fischer, & Kümper, 2016). It is based on the following models
and standards:•••

Basic W3C standards used for ontology modelling: RDF, RDFS, OWL.
Existing vocabularies either directly related to the domain of sensors or related to machineto-machine communication (M2M):
o Semantic Sensor Network (SSN)o DCAT for static data set description and data catalogues.
o OneM2M and M2M Ontology
o PROV-O for data provenance information.
Existing schemas from schema.org.

Such an ontology is best realized using an RDF triple store accessible through a SPARQL endpoint.
However, exposing such an endpoint as public interface requires from the consumer the capability of
formulating SPARQL queries. Because this requirement could be too restrictive for a wide use of SEDAQ,
an additional layer of query services is added on the top of the ontological layer.
Our solution is based on the core ideas of the Hexagonal Architecture and the Ports and Adapters
Architecture from Alistair Cockburn (Freeman & Pryce, 2009) which are illustrated in Figure 1. The
Hexagonal Architecture realizes a pattern which promotes the separation of concerns by encapsulating
logic in different layers of the application. Through this onion-style architecture (Palermo, 2008), theinner core does not know anything about the outer layers and thus the application is agnostic to theoutside world.
H2020 EUJ-02-2016

CPaaS.io

Page 9 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

application layer(on the top of theservice layer)

service layer
based onSPARQL
ontology as
domain model

Figure 1: The SEDAQ Ontology, embedded in Hexagonal Architecture (Freeman & Pryce, 2009)

When mapped to the SEDAQ ontology, the ontology itself becomes the domain model in terms of
Domain-Driven Design (DDD) (Evans, 2003). This model is accessible from outside through a service layer,
offering public services to the consumers of the ontology. This layer is based on SPARQL queries.
The resulting architecture offers two different ways of accessing information from the ontology model:••

A SPARQL endpoint for consumers aware of this query language and capable of interpreting
the graph-based results.
REST-based services based on API design based on best practices and delivering results in
JSON format. These services internally use the information from the ontology (the entity
MeasurementInfo, see chapter 2.5.1.2 "Entities Representing Measurements") and transformthe query into a SPARQL query. This mechanism is illustrated in Figure 2.

H2020 EUJ-02-2016

CPaaS.io

Page 10 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Figure 2: Accessing information from the ontology model

The SEDAQ ontology is embedded in the general IoT Domain Model (in short, IDM) (Bauer et al., 2013,
Figure 10), which is integrated in the CPaaS.io system architecture (Carrez, 2018, Figure 3) . Some changes
had to be introduced, allowing a seamless transition between the physical sub model of IDM about devices(sensors, actuators and tags) and the core entities of SEDAQ.
After applying the following changes, the IDM submodel about devices results in the diagram illustrated
in Figure 3.
Changes
1. IdentifyingTag is introduced. Its responsibility is to represent a unique identifying tag as in a
RFID carrier.
2. IdentifyingTag has a relationship with RFIDSensor with the same multiplicity as before
between Tag and Sensor
3. Tag and Sensor become superclasses of IdentifyingTag and RFIDSensor respectively. Itshould be noticed that tags are not always identifying tags. Several kinds of tags deliver descripttive information and cannot be accessed by sensors.
4. In the submodel above, Sensor has a relationship with PhysicalEntity, which is in turn related
to VirtualEntity, as from the general model.
5. Two new classes are introduced in the general model: AttributeMetadata and ValueMetadata.
The former contains the metadata about attributes, the latter the ones about empirical data. Bothare related to Attribute. Introducing both classes removes the need for Metadata.
6. Attribute has name, type and value with multiplicity [0..1], Optionality is required to model
the root element of a structure. Attribute has a recursive relationship on itself to model atomic
and compound attributes. Introducing Attribute removes the need for ValueContainer andValue.
H2020 EUJ-02-2016

CPaaS.io

Page 11 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

Figure 3: Submodel of IDM (IoT Domain Model) about devices. The highlighted region
depicts the connection to the IoT Domain Model

The relationship between the SEDAQ ontology and the IoT Domain Model is explained in section 2.5.

H2020 EUJ-02-2016

CPaaS.io

Page 12 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

2.5 Sensor Data Quality Model
The conceptual model for the SEDAQ ontology can be integrated in the IoT Domain Model model, using
as starting point the concepts of Device and Sensor (as subclass of Device).
The class MeasurementType inside SEDAQ is a realisation of AttributeMetadata, MeasurementMetadataa realisation of ValueMetadata.
The conceptual basis for the SEDAQ ontology is illustrated in Figure 4.

Figure 4: Conceptual Model for the SEDAQ ontology

The following sections describe the entities from Figure 4 in more detail.

H2020 EUJ-02-2016

CPaaS.io

Page 13 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

2.5.1 Entity Description
2.5.1.1 Entities Representing Sensors
A Sensor is any kind of physical or virtual device capable of reading data from the environment andoffering a digital representation thereof to a client through a well-defined interface.
The entity Sensor has the following attributes (* means "mandatory"):NameuniqueID*

Type
GUID

shortDescription*

Text

installationDate*

Date

verifiedInstallation

TernaryLogic

installationProtocol

Document

networkLocation*

URL

availabilityLevel*

enum AvailabilityLevel

monitoringClass*enum MonitoringClass

queryable*

LogicalqueryLatency

PhysicalMeasurement

accessAPI*

enum AccessAPITypetechnicalAPIDocumentation

Document

H2020 EUJ-02-2016

CPaaS.io

Description
unique identification at global
level
human-readable information
about the sensor, localized
date where the device wasplaced/mounted and then activated
was the installation verified bytechnical skilled persons, possibly
certified by an appropriate legal
instance?
documentation about the
installation process
URL of the physical sensor
smart enumeration with prognose
information
mechanism used for sensor
monitoringis it possible to obtain data fromthe sensor by sending anappropriate query?
average value for network
responses [ms] (mean +/standard deviation)
which kind of technology is used
to access this device?
human-readable documentation
about the public API offered bythis device

Page 14 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

A Physical Sensor represents a physical device (hardware) located at a specific geographic position(exactly defined by longitude, latitude and elevation in the context of a given cartographic reference
system). Such a device is reachable by remote clients at a well-defined address on the network.
The entity Physical Sensor has the following attributes (* means "mandatory"):NameuniqueID*
vendor [0..1]
model [0..1]
serialNumber [0..1]
GPSCoordinates
officialLocationName

Type
GUID
Text
Text
RawText
GeoCoordinates
Text

country
mobilityLevel
placementType

ISOCountry
enum
enum

placementSecurity

enum

networkConsumption
cacheSize

PhysicalMeasurement
PhysicalMeasurement

Description
unique identification at global level
localized
localized
validation difficult
latitude, longitude, elevation
name according to local authority, in
original language
ISO 3166 alpha2{FIX, MOBILE, AUTONOMOUS}{INDOOR,OUTDOOR}{UNPROTECTED,WEAKLY_PROTECTED,STRONGLY_PROTECTED}
[bps]
[kB]

A Virtual Sensor is a software mechanism able to read sensor data from one or more data sources andto represent their data as aggregation. The data sources themselves can be either sensors (either physicalor virtual sensors) or data repositories such as databases or file systems.
The entity Virtual Sensor has the following attributes (* means "mandatory"):NameuniqueID*architecturalPattern

Type
GUID
enum

Description
unique identification at global level{MEDIATOR,FACADE}

If it acts as a façade, the virtual sensor is only hiding the complexity of the involved data sources, providing
a single, simplified and uniform interface to the client. Data coming from different locations are aggregatedinternally and then delivered through the services of the public interface. In its role as mediator, theVirtual Sensor has additional internal functionality. Such logic is used to process incoming data fromthe backends and transform them into more suitable, standardized forms.

2.5.1.2 Entities Representing Measurements
Each Data Source provides a unique specification of the underlying data repository or sensor. Using theinformation from the data source specification, the physical data source can be reached, and data can beobtained from it. Additionally, if the raw data are processed after extraction and before delivery to theremote client, a machine-readable documentation is provided. Such a document explains the transformations applied to the original data. Additionally, it states if the pre-processing steps can be bypassed, sothat the raw data can be obtained.
H2020 EUJ-02-2016

CPaaS.io

Page 15 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

The entity Data Source has the following attributes (* means "mandatory"):NameuniqueID*urlsourceIsPostProcessed
postProcessingSuppressible
postProcessingDocumentation[0..1]

Type
GUID
URL
TernaryLogic
LogicalDocument

Description
unique identification at global level

A single Measurement Type represents knowledge about the measurement itself (as ontological entity),in contrast with the metadata representing knowledge about empirical data. The latter are represented byan instance of Measurement Metadata. Such an entity represents the metadata about empirical datameasured at a given point in time by a Sensor. The information carried by Measurement Metadata allows
a client to understand how to process raw data delivered by a given sensor, interpreting them in asemantically appropriate way. The empirical data themselves are represented by Empirical Measurement, which is a container of empirical data produced during a given timespan by a sensor. These data arerepresented mathematically as time series and can be interpreted using Measurement Metadata.
The entity Measurement Type has the following attributes (* means "mandatory"):NameuniqueID*
label

Type
GUID
Text

shortDescription
provisioningGranularity
frequency
timestamp
dataProvisioningType

Text
enum
PhysicalUnit
TimeZoneenum

historicalDataAvailable
firstMeasurementAvailable [0..1]
historicalTimeWindow
currentTimeWindow

LogicalTimestamp
TimeUnit
TimeUnit

measurementTimestampAvailable
publicationTimestampAvailable
lastAverageValueAvailable
lastMinValueAvailable
lastMaxValueAvailable
standardDeviationKnown
accuracyLevelreliabilityLevel
completenessLevel

Logical
Logical
Logical
Logical
Logical
Logical
enum
enum
enum

H2020 EUJ-02-2016

CPaaS.io

Description
unique identification at global levelpossibly unique short text tag identifying themeasurement type (localized)
localized{STREAMING, DISCRETE}[Hz]
ISO 8601 with DST (daylight saving time){RAW_DATA,META_DATA,
LINKED_DATA}

Measurements are available on a minutely,
hourly, daily, weekly, … basis

Page 16 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

The entity Measurement Metadata has the following attributes (* means "mandatory"):NameuniqueID*valueType

Type
GUID
DataType

measurementUnit
shortDescription
measurementSpacing

PhysicalUnit
Text
enum

daylightTimeSavingStrategy

enum

dataFormat
notAvailableValueMarked
notAvailableSpecialValueenum
Logical
DataType

timestampFormat

enum

Description
unique identification at global level
IRI of the xsd (or other if useful)value type
dimension (SI, …)
localized{EQUIDISTANT,NOT_EQUIDISTANT}{23_25_HOURS,IGNORE_HOURS,DUPLICATE_HOURS,AVERAGE_HOURS}{JSON, XML, CSV, TSV}The "special value" itself (e.g. 9999
represents NA in the data set)
{ISO8601,…}

The entity Empirical Measurement has the following attributes (* means "mandatory"):NameuniqueID*
sequenceID [0..1]
timestamp [0..1]

Type
GUID
Cardinal
Timestamp

value

DataType

Description
unique identification at global level
natural number (positive integer) > 0
temporal information related to thetime point of the reading operation
raw measurement data

If the client requesting information about measurements is not able to use a SPARQL endpoint or if suchan endpoint is not available, a request for information (RFI) about sensor data or metadata can be posted
using Measurement Info.
The entity Measurement Info has the following attributes (* means "mandatory"):NameuniqueID*labelvalueTypevalueUnit

Type
GUID
Text
DataType
PhysicalUnit

Description
unique identification at global level
localized
type related to such an info item
dimension related to such an info
item

According to deliverable D6.3 "Holistic Data Management: Initial Concepts and Models" (Strohbach et al.,2018, page 12), a semantic description of both RDF and non-RDF based data source should be provided.
To support the latter requirement, Measurement Info is defined. This entity acts as a proxy for themeasurement data (raw empirical data and related metadata) used in queries placed by external agents tothe sensor network. Each single measurement info abstracts the basic elements of a query and represent
them as pairs (a tuple of two elements) of {pair, unit}. By connecting such a tuple with operators froma given set (arithmetical operators {<, >, <=, >=, =} and others) and literals or variables, theH2020 EUJ-02-2016

CPaaS.io

Page 17 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

measurement information can be used in single logical statements, representing the building blocks of aquery. The client will use the information from Measurement Info as atomic query element and build up
a query statement, possibly chaining together other Measurement Info elements using logical operators({and, or, xor, not}) or using them as input parameter for functions ({count, sum, mean, average,…}) in the query statement.

2.5.1.3 Entities Representing Other Devices
According to the conceptual model, two other kinds of physical devices must be considered, because they
are directly and strongly related to sensors.
Mechanisms for clock synchronization are of vital importance in a distributed network, because they ensure
consistence in time measurements across platforms and nodes. These mechanisms contribute to thefulfilment of requirement FREQ.113 (see Table 1). The Clock Synchronization entity represents
information about how and in which quality a clock used in one given device (sensor) is synchronized withrespect to a predefined service for time information (e.g. an atomic clock or the longwave time signal DFC77) used for time alignment. Possible shifts in time synchronization can lead to inaccurate timestamps oreven data loss.
The entity Clock Synchronization has the following attributes:
Name
uniqueID*

Type
GUID

frequency
mechanism
maximumClockDriftstabilityClass

PhysicalMeasurementenum
PhysicalMeasurement
enum

Description
unique identification at
global level[Hz]{NTP, DCF77, …}[s · 10-3]{HIGH, MIDDLE, LOW}

Another critical device is the power supply providing electrical energy to the sensor. Information about
how and in which quality a power supply delivers the requested energy to operate a given device is represented using Power Supply Info. Possible interrupts or smooth discharge can lead to inaccurate time1stamps or even data loss.
The entity Power Supply Info has the following attributes:
Name
uniqueID*supplyType
technology

Type
GUID
enum
enum

isInterruptablestabilityClass

Logicalenum

H2020 EUJ-02-2016

Description
unique identification at global level{INTERNAL, EXTERNAL}{BATTERY, ACCUMULATOR,NETWORK}{HIGH, MIDDLE, LOW}

CPaaS.io

Page 18 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

2.6 The SEDAQ ontology
The ontology has been developed with the open-source ontology editor Protégé2. Figure 5 gives an
overview of the SEDAQ ontology.

Figure 5: A Protégé view of the SEDAQ ontology

The most important entities from Figure 5 are explained in section 2.5. An RDF based Web Ontology
Language (OWL) version of SEDAQ has been generated by the Protégé OWL API. The complete OWL filecan be found at the CPaaS.io GitHub repository3.

2 https://protege.stanford.edu
3

https://github.com/cpaasio/sedaq

H2020 EUJ-02-2016

CPaaS.io

Page 19 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

3 Privacy Support Mechanisms
The privacy support mechanism aims to provide adequate control mechanisms for the processing of
personal data of individuals (formerly called "data subject" in the GDPR). For this organisation or person in
the role of a provider for data which are collected by sensors there are several requirements on access
control and management of the generated data, which are tackled as an extension of the SEDAQ ontology(see section 3.2).

3.1 Requirements Concerning Privacy
In deliverable D3.1 (Carrez, 2016, section 3.1.1.5), privacy requirements for the CPaaS.io platform aredescribed. Specifically, in deliverable D6.3 (Strohbach et al., 2018, section 5.2), the relationship between
CPaaS.io privacy mechanisms and the set of requirements is discussed. Regarding holistic data
management, the below SEDAQ extension contributes to the fulfilment of these requirements, as well as
the privacy mechanisms of the CPaaS.io citizen dashboard which are documented in deliverable D5.6
(Skarmenta & Martinez, 2018)
According to the above-mentioned list of requirements, the data provider must be able to:••••Specify which data are publicly visible (open data)
Define data to be divided with other individuals (shared data)
Know who is using his or her data
Understand about events related to data.

The first three requirements are about access control, the last one is about data analytics. Access control
can be provided as access control lists (ACL), that are bound to the data. Access control is realized indifferent granularity. A whole dataset or only parts of it can be made available to anyone (the public) or toa specified set of data consumers.
Data availability can be regulated through different restrictions:•••time parameterso e.g. disposability during a given timespanlogical statements on data propertieso e.g. data collected from sensors on civil buildings with a maximal height of 50 meters
delivery constraints
o e.g. maximal data size

Providing access control mechanisms requires access management operations such as:•••

Creating a new ACL
Changing an existing ACL
Removing an existing ACL.

The second operation is the most complex one because changes can encompass:••

Metadata: there are different data of interest, additional data are added or removed from the ACL.
Consumers: different consumers are allowed to access the data; additional ones are added (grant
operation) or removed (revoke operation).

H2020 EUJ-02-2016

CPaaS.io

Page 20 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

On the other hand, knowing who is using the data is important because a user profile can influence theway data are presented to the consumer. Additionally, events of social and political relevance (e.g. large
scale pollution as consequence of industrial failure, nuclear accidents, exceptional weather conditions) cangenerate huge demand for sensor data. Detecting and preventing such events can help better organizing
the sensor network, timely delivering the information needed.

3.2 Privacy in the Model Context
To relate access control and analytics to the sensor data quality model (SEDAQ ontology), the following
extensions are proposed:••

The Owner registers the information about the subject controlling the Sensor and therefore
providing data to customers.
The AccessControlList is bound to MeasurementMetadata. The ACL controls the access to themetadata describing the empirical measurements, that is the time series modelled by
EmpiricalMeasurements.

Figure 6 shows a diagram with the SEDAQ extension, with highlighted entities from the core SEDAQ
ontology from section 2.

Figure 6: The SEDAQ ontology with privacy extensions

H2020 EUJ-02-2016

CPaaS.io

Page 21 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

The ACL list contains one or more AccessControlEntry (ACE). Each one refers to a trustee, identified by
a SID (security identifier). The object of an ACE is an instance of MeasurementMetadata. The access rightin the corresponding ACE slot specifies if the trustee is allowed or denied accessing the metadata. As a
special case, the trustee can be audited when trying to access the metadata. If no ACL is available for agiven measurement instance, the data are publicly available and can be obtained anonymously.
The SEDAQ ontology and its extension to data protection proposes an information model with the helpof which desired functionality can be realized in application layers of corresponding architectures. Within
CPaaS.io, a citizen dashboard realizes important privacy mechanisms that are documented in thecorresponding deliverables (Skarmenta & Martinez, 2018).
The described approach obviously fulfils requirements from the General Data Protection Regulation(GDPR) concerning data protection by design and by default. Through data protection based on access
control lists, data can be made available on a definable granular basis.

4 Conclusion
This document on holistic data management proposes refined concepts and models for data quality
assessment on heterogeneous data, superseding its preceding deliverable D6.3 and its predecessors. It
provides a foundation for a data quality ontology and assessment, specifically for the management of
empirical data obtained by sensors. The ontology, that has been inspired by the work of (Debattista et al.,2014), (Debattista et al., 2016) and (Iggena et al., 2016), fits into the CPaaS.io information model andarchitecture. The approach addresses semantic interoperability problems with respect to personal data
managed by different platform instances, with a focus on managing and exchanging data between theEuropean FIWARE-based CPaaS.io instance and the Japanese u2-based instance.
The proposed SEDAQ ontology covers core aspects of data quality in the sensor field. Moreover, it could
be enhanced and extended at property level by additional information. Before doing so, extensive
experimental work should be carried out. The data properties of the classes in the ontology must be
checked on the field and against different sensor types. Additionally, data types and value ranges must be
verified and possibly adapted.
Privacy and data protection aspects as required by the General Data Protection Regulation (GDPR) are also
dealt with. Specifically, in this data model and ontology-based deliverable, core concepts such as sensor
owner, access control lists and entries, and types of access rights are developed. Within CPaaS.io, a citizen
dashboard realizes important privacy mechanisms which is documented in the corresponding deliverable
D5.6.

H2020 EUJ-02-2016

CPaaS.io

Page 22 of 23

Deliverable D6.4

Holistic Data Management: Refined Concepts and Models

References
Bauer, M., Boussard, M., Bui, N., Carrez, F., Jardak (SIEMENS, C., De Loof (ALUBE, J., … Salinas, A. (2013).
Internet of Things – Architecture IoT-A Deliverable D1.5 – Final architectural reference model for theIoT v3.0. Retrieved from https://iotforum.org/wp-content/uploads/2014/09/D1.5-20130715VERYFINAL.pdf
Carrez, F. (2016). Requirement Collection Analysis. Deliverable D3.1 from CPaaS.Io Project. Retrieved fromhttps://cpaas.bfh.ch/wpcontent/uploads/2017/08/CPaaS.io_D3.1_Requirement_Collection_Analysis.pdf
Carrez, F. (2018). CPaaS.io System Architecture. Deliverable D3.7 from CPaaS.Io Project (to Be Published).
Debattista, J., Dekkers, M., Guéret, C., Lee, D., Mihindukulasooriya, N., & Zaveri, A. (2016). Data on the
Web Best Practices: Data Quality Vocabulary. Retrieved November 12, 2018, fromhttps://www.w3.org/TR/vocab-dqv/
Debattista, J., Lange, C., & Auer, S. (2014). daQ, an Ontology for Dataset Quality Information. In LDOW
2014 (Linked Data on the Web). Retrieved from http://ceur-ws.org/Vol-1184/ldow2014_paper_09.pdf
Evans, E. (2003). Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.
Fraefel, M., Gschwend, A., Haller, S., Frecé, J., Shindo, K., & Strohbach, M. (2016). Holistic DataManagement : State of the Art. Deliverable D6.1 from CPaaS.Io Project. Retrieved fromhttps://cpaas.bfh.ch/wp-content/uploads/2017/08/CPaaS.io_D6.1_Holistic-Data-Management_Stateof-the-Art.pdf
Freeman, S., & Pryce, N. (2009). Growing Object-Oriented Software, Guided by Tests. Addison-Wesley.
Iggena, T., Fischer, M., & Kümper, D. (2016). Quality Ontology - Working Draft. Retrieved November 12,
2018, from https://mobcom.ecs.hs-osnabrueck.de/cp_quality/
Palermo, J. (2008). The Onion Architecture. Retrieved November 12, 2018, fromhttps://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
Skarmenta, A., & Martinez, J. A. (2018). Dashboard Integration. Deliverable D5.6 from CPaaS.Io Project (toBe Published).
Strohbach, M., Gschwend, A., Klein, E., Shindo, K., & Frecè, J. (2018). Holistic Data Management: Initial
Concepts and Models. Deliverable D6.3 from CPaaS.Io Project (to Be Published).

H2020 EUJ-02-2016

CPaaS.io

Page 23 of 23