GDPR-inspired IoT Ontology enabling SemanticInteroperability, Federation of Deployments and

Privacy-Preserving ApplicationsRachit Agarwal∗§, Tarek Elsaleh†, Elias Tragos‡

∗Inria-Paris, France, §CSE, IIT Kanpur, India, †University of Surrey, UK, ‡Insight Center for Data Analytics-UCD, IrelandEmail: ∗rachit.agarwal@inria.fr, †t.elsaleh@surrey.ac.uk, ‡elias.tragos@insight-centre.org

Abstract—Testing and experimentation are crucial for promot-ing innovation and building systems that can evolve to meet highlevels of service quality. IoT data that belong to users and fromwhich their personal information can be inferred are frequentlyshared in the background of IoT systems with third parties forexperimentation and building quality services. This data sharingraises privacy concerns especially since in most cases the dataare gathered and shared without the user’s knowledge or explicitconsent or for different purposes than the one for which thedata were initially gathered. With the introduction of GDPR,IoT systems and experimentation platforms that federate datafrom different deployments, testbeds and data providers mustbe privacy-preserving. The wide adoption of IoT applications inscenarios ranging from smart cities to Industry 4.0 has raisedconcerns with respect to the privacy of users’ data collected usingIoT devices. Many experimental smart city applications are alsousing crowdsourcing data. Inspired by the GDPR requirements,we propose an IoT ontology built using available standardsthat enhances privacy, enables semantic interoperability betweenIoT deployments and supports the development of privacy-preserving experimental IoT applications. On top, we proposerecommendations on how to efficiently use the ontology withinIoT testbed and federating platforms. Our ontology is validatedfor different quality assessment criteria using standard validationtools. We focus on “experimentation” without loss of generality,because it covers scenarios from both research and industry, thatare directly linked with innovation.

Index Terms—Semantic Interoperability, Privacy, IoT, BestPractices, Testbeds, Experimentation

I. INTRODUCTION

The role of experimentation platforms for IoT data andservice providers is crucial for building systems that can evolveto meet high levels of service quality and promote innovation.These systems should be highly resilient and include feedbackmechanisms that provide a quality assessment of differentaspects of the data ranging from annotation compliance tothe consistency of frequency. To have an end-to-end testingenvironment that covers the whole data flow from source toconsumer, employing testing or staging instances is essentialnot only for internal testing within the testbed organisation butalso for offering external testing services to third parties.

IoT experimentation assumes that a testbed/data providerprovides the collected data to third parties (i.e., researchers)for running experiments. This requires sharing the data withexternal parties that are not the data owners. Thereby raisingprivacy concerns if external parties mishandle the data. Thelatest European Union (EU) directive for data protection

(GDPR - General Data Protection Regulation [1]) sets strictguidelines on the collection and processing of user data. IoTsystems are required to be compliant with these guidelinesbecause, in most cases, they handle user-generated data.

For example, consider a user participating in a crowd-sourcing based environmental monitoring testbed by havinginstalled an application on his smartphone [2]. A third partyhaving access to the data produced by the smartphone andassociated with the application may be able to interpret privateuser information such as the user’s location at any given time,or his home/work location. Thus, one important aspect of theprovided data is its privacy sensitivity and the context in whichthe IoT devices (such as smartphones) capture it.

For a multi-domain experimentation facility, it is importantto provide a flexible means to configure the level of dataprivacy, depending on the association with real-world entities,and the purpose of data processing. With the introduction ofGDPR the need to have a data model that reflects the conceptsdefined by these laws is essential. This requires modelling theroles of different actors, the consent mechanism, and the dataowner’s permissions on what third parties can consume.

Most of the past activities in IoT experimentation wereonly focused on developing the fundamental technologies tofacilitate the provision of experimentation services on top ofshared testbed(s) and mostly neglected the important aspect ofprivacy. IoT Data marketplace platforms such as Big-IoT [3],Inter-IoT [4] and Wise-IoT [5] do provide interoperability butdo not focus on data privacy. A federation platform such asFIESTA-IoT [6], although is semantically enabled and pro-vides a module to define user authorisation, does not considerdata privacy. However, its semantic power enables IoT testbedsfrom different domains to federate their data easily, test end-to-end services, collect feedback on performance, and provideexperimenters easy to use one-stop data marketplace APIs.

The lack of focus on data privacy from IoT federation andexperimentation platforms motivates us to propose a privacy-enhanced ontology specifically designed for IoT experimenta-tion (that can be easily generalised for generic IoT systems),which includes the main concepts of privacy (as extracted byGDPR and ISO/IEC 29100 [7]) and helps achieve interoper-ability between testbeds by targeting horizontal silos of IoT.Privacy in IoT experimentation projects is usually addressedusing signed agreements with the users, getting their consent

arX

iv:2

012.

1031

4v1

[cs

.DB

] 1

8 D

ec 2

020

to gather their data and use them for experimentation purposes.However, this may cause issues when a user wants to changeor revoke her consent, which requires the communication withthe testbed owners for requesting these changes. This is usuallya timely and manual process, during which the users’ dataare still getting gathered, stored and (re-)used. Our motivationis to provide an ontology that allows users to dynamicallyalter their policies and consent in near “real-time”, so thatany changes can take immediate effect. Also, the users couldcreate very advanced and personalised policies in this respect.Additionally, the testbed owners will be able to provide newapplications, having a process to immediately request theconsent of users. The key contributions of this work are asfollows:• Ontology alignment: We follow the methodology proposed

by Noy et al. [8] and align our ontology to use standard andmost popular ontologies such as SSN1 so that we can eas-ily achieve semantic interoperability between semanticallyenabled IoT testbeds/data-providers.

• Addition of privacy-related concepts: We include essentialconcepts, as per GDPR and ISO guidelines, required forenabling privacy-aware experimentation.

• Ontology usage recommendation: We provide recommen-dations for testbeds/data providers and federation platformson how to efficiently use our proposed ontology so that thestored data can be utilized. We further provide applicationscenarios where our ontology fits best.Note that we do not use the ontologies in totality, rather

use and import only those concepts and properties that areneeded to support our requirements. Such aspects withoutwhich would (a) make the ontology model bulky where mostof the concepts and properties would be useless and potentiallybe replicated, (b) one testbed might use one concept comingfrom one ontology while another testbed might use differentconcept (with same meaning) coming from another ontology,thereby loosing the semantic interoperability.

Additionally, the proposed ontology does not intend tocover all GDPR requirements with respect to the full datacycle (data gathering, sharing, processing, retention, deletion,etc.). Our main focus is on the data gathering and sharingaspects, providing entities that cover the phases of when (ornot) the data of a user should be gathered and to whichother users/applications these data should be shared. This isdescribed in more detail in Section III and Table I, whichshows how our ontology addresses the GDPR requirements.Data retention, processing and deletion are not directly coveredby our ontology, but could be indirectly addressed via theprivacy policies, if the system is properly implemented (i.e.by having a process to delete data according to a user policy).

The rest of the paper is organised as follows. Section IIdetails the related work in the domain of IoT privacy enabledontologies. Section III describes IoT privacy requirements,while Section IV and Section V reports, based on the re-quirements, the overall in-depth description of our proposed

1SSN: http://www.w3.org/ns/ssn/

ontology and our recommendations to data provides, exper-imenters, and platform developers, respectively. Section VIprovide sample workflow, annotations and queries based onthe recommendations. Section VII presents validation of ourontology based on standard ontology validation tools. We thenpresent use cases and application scenarios in Section VIII. Wefinally conclude in Section IX and summarises our results.

II. RELATED WORK

An ontology that targets horizontal silos of IoT must address4W1H (What, When, Where, Who, How) related competencyquestions and aspects [9]. Although most of the IoT ontologiesaddress what, where, and when related competency questions,they fail to address the who aspect. In [9], the authors surveyseveral ontologies that can be instrumental in addressing4W1H aspects. They identify that no ontology is comprehen-sive enough in the IoT domain that can address 4W1H. Popularontologies such as SSN1, IoT-lite2, and oneM2M3 all lackconcepts, especially related to privacy and access control. SSNhas concepts to support different IoT systems, and is used bymany IoT enabled systems, but although has been refactoredit still lacks concepts, such as service, unit of measurement,and location. OneM2M provide an abstract model for IoTdevices. IoT-lite lacks concepts about observations. With manysurveys of IoT ontologies already available [9], [10], werefrain ourselves from going into much detail in this work.Instead, we focus on surveying privacy-related IoT ontologiesthat have come up recently.

Several ontologies [11]–[18] have been proposed that targetaccess control and privacy, in general. Developers can reuseprivacy and access control concepts from these ontologies,however they do not focus on consent towards accessingparticular data, which is a key requirement in GDPR. Fatema etal. [19] proposed a consent ontology targeting the competencyquestion who is allowed or denied activity on the data. In an-other similar work, Pandit et al. [20] proposed provenance andconsent ontology. These ontologies are very early work andrequire much attention to be complete, concise and consistent.

Much recently, IoT-Priv has been proposed [21] extendingIoT-lite ontology to include who aspects and also targetprivacy. As the core of IoT-Priv is IoT-lite ontology, IoT-Privfocuses on resource storage and access policies. It neglects ob-servations taken by the resources. Moreover, there is no notionof a data controller. It also does not follow the conventionsproposed by GDPR. LIoPy [22] and PrOnto [23] both proposeprivacy-related ontologies that have a legal focus. They do notoptimise the ontologies for advanced access control or considerthe dynamic context of an IoT environment.

Many EU projects focus on creating frameworks and ar-chitectures that introduce privacy concepts in the IoT, but tothe best of our knowledge, they do not create ontologies thatinclude privacy features. For example, IoT-A [24] developedan ontology as a basis for their architecture (the IoT-A model),

2IoT-lite: http://purl.oclc.org/NET/UNIS/fiware/iot-lite#, Note, a new versionof IoT-lite has a new namespace

3OneM2M: https://tinyurl.com/tmnn2qy

but this only includes the main concepts of IoT, without anyprivacy features. RERUM [25] improved the ontology of IoT-A introducing privacy features, but in a very abstract way,since their goal was not to develop an IoT ontology.

To best of our knowledge, no ontology enables privacy,interoperability, federation, and experimentation in IoT. Theclosest one being the ontology4 defined in [26] (used inFIESTA-IoT platform). This ontology uses concepts from pre-viously well defined ontologies and defines a taxonomy for thedifferent sensor/actuator devices, phenomena, and measure-ment units adopted across multiple IoT domains. Nonetheless,it misses the privacy-related concepts.

III. PRIVACY REQUIREMENTS

Privacy requirements are usually extracted from the elevenprivacy principles proposed in ISO 29100 [7]. For IoT, therehave been several attempts to adapt the ISO requirements. Herefor our ontology, we adopt the eight privacy requirements asdefined by the EU project RERUM [27], [28], as an adaptationof the ISO principles combined with the requirements ofGDPR. These eight requirements are:

1) Consent and choice: IoT applications should only collectdata when a user has given explicit consent. The applica-tions should also provide the user with a choice to not allowthe collection of her personal information and be able towithdraw her consent at a later stage.

2) Purpose legitimacy and specification: The collection andprocessing of a user’s data should only be allowed whenthe user provides a specific and legitimate purpose for thiscollection/processing. Post-processing of collected data fora different purpose than the one for which the data wascollected should be forbidden.

3) Collection limitation: the data that are collected should beadequate and relevant for the purpose and not excessive,with also a limitation for the number of sources from whichthe data can be collected.

4) Data minimisation: this is closely related to collectionlimitation and requires that only the minimum amount ofnecessary data should be collected and processed.

5) Accuracy and quality: data that are collected must beaccurate and up to date and IoT services should delete orrectify false/incorrect data.

6) Notice and access: users should be given notice when theirdata are collected and they should also be able to accesstheir data and delete them when they wish.

7) Individual participation and transparency: users shouldhave full control over their data, knowing who has accessedthem in the past and who in general has access to them.Users should also have the ability to start/stop the datacollection process at any given time.

8) Accountability: this ensures that whenever there is aprivacy breach, the IoT system should be able to hold theresponsible person accountable for that breach.

4FIESTA-IoT: http://purl.org/iot/ontology/fiesta-iot#

IV. ONTOLOGY AND RELATED DESCRIPTION

Following the methodology in [8], we update the ontologydefined in [26] to include concepts enabling interoperability,federation, and experimentation and comply with the newversion of SSN ontology. We update the ontology in [26] with amotivation to (1) ease migration of testbeds that used ontologyin [26] to our ontology version, (2) ease new semanticallyenabled testbed and those that use other standard ontologies tofederate with other testbeds. The ontology in [26] is modelledusing two subgraphs (i) a sub-graph that contain essentialconcepts towards defining a resource (resource graph), and (ii)a sub-graph that define the observations taken by a resource(observation graph). Similar to [26], we adopt all the resourceand observation-based concepts and properties in the newproposed ontology as well from well-known ontologies such asSSN1, SSN-Systems5, SOSA6, IoT-Lite2, M3-lite7, QU8, Geo9,Geo-sparql10, Schema.org11, and DUL12. Note that, we useowl:equivalentClass to link with popular ontologies such asoneM2M3. This enables a testbed that is already semanticallyenabled to federate with those that would use our ontology.Figure 1 shows the proposed changes in detail. The specificconcepts, we used, are colour encoded. A unique colourdepicts the ontology from which a particular concept is used.Nonetheless, we mark the changes in the concepts with a reddot and the changes in the properties with a red colour. We keptthe core idea of reusing concepts intact and tried to performminimal yet required changes.

In Figure 1, concepts belonging to resource graph aremarked with brown dot while those belonging to the obser-vation graph are marked with a blue dot. A multi-coloureddot depicts that a particular concept belongs to more than onesubgraph. The changes worth highlighting are:• We update M3-lite to reflect the new version of SSN. We

also move object and data properties defined in m3-lite toour ontology and use the this prefix to denote them. Thismakes M3-lite clean. We also rename it to iot-taxonomy-lite13 so to account for new subclass that we created anduse iot-taxonomy prefix to represent it.

• iot-taxonomy:QualityOfObservation: the quality of a sensordetermines the quality of its observations taken over aperiod of time. The quality may be low due to calibrationissues, but once resolved, the quality can be high. The iot-taxonomy:QualityOfObservation identifies the same. To beexplicit, in the current version, we define subclasses of iot-taxonomy:QualityOfObservation as iot-taxonomy:Poor, iot-taxonomy:Fair, and iot-taxonomy:Good. Although there areother ways of representing the quality of observation, i.e.,

5SSN-Systems: http://www.w3.org/ns/ssn/systems6SOSA: http://www.w3.org/ns/sosa/7M3-lite: http://purl.org/iot/vocab/m3-lite#8QU: http://purl.org/NET/ssnx/qu/qu#9Geo: http://www.w3.org/2003/01/geo/wgs84 pos#

10Geo-sparql: http://www.opengis.net/ont/sf#11Schema.org: https://schema.org12DUL: http://www.loa.istc.cnr.it/ontologies/DUL.owl#13iot-taxonomy-lite: http://purl.org/iot/vocab/iot-taxonomy-lite#

Sensor

Observation

System

sosa:resultTime

Result

ObservablePropertysosa:observes

MeasurementTypeDirection

Source

Platform

Deployment

SystemCapability SystemProperty

Unit

xsd:dateTime

xsd:dateTime

xsd:int

SpatialThing

DomainOfInterest

ssn:

hasD

eplo

ymen

t

sosa:isHostedBy

sosa

:hos

tsgeo:location

this:hasDomainOfInterest

this:hasMeasurementType

this:hasDirectionthis:hasSource

sosa

:mad

eObs

erva

tion

sosa

:mad

eByS

enso

r

sosa:hasResult

sosa:isObservedBy

ssn-system:hasSystemCapability

ssn-system:hasSystemProperty

dul:h

asD

ataV

alue

dul:hasDataValue

Accuracy

sche

ma:

min

Valu

esc

hem

a:m

axVa

lueQualityOfObservation

ssn-system:qualityOfObservation

xsd:boolean

xsd:string

Fair

ssn:hasSubSystem

iot-lite:hasCoverage

Circle

iot-l

ite:ra

dius

xsd:double

Metadata

iot-l

ite:m

etad

ataV

alue

xsd:string

iot-lite:isMobilexsd:boolean

xsd:double

Service

iot-lite:interfaceDescription

iot-lite:interfaceType

iot-lite:endpointxsd:string

xsd:anyURI

FeatureOfInterest

iot-lite:isAssociatedWith

geo:location

geo:location

iot-lite:exposes

iot-l

ite:e

xpos

edB

y

FeatureOfInterestsosa:hasFeatureOfInterest

xsd:double

geo:lat

iot-l

ite:h

asU

nit

iot-lite:hasUnit

iot-l

ite:h

asU

nit

geo:lon

geo:alt

iot-l

ite:m

etad

ataT

ype

Environment

Sound

Siren

DecibelA

Manual

dul:hasDataValue

sosa:observedProperty

ssn:isPropertyOf

ssn:

hasP

rope

rty

SoundSensor

Cardinality: Some

Cardinality: Exactly 1

Cardinality: Min 1

Cardinality: Max 1

Changed Object Properties

Subclass

Classes

DataPropertyChanged Concepts

iot-l

ite:h

asU

nit

iot-lite:hasMetadata

Point

Coverage

ssn:

hasP

rope

rty

ssn:

isP

rope

rtyO

f

sosa:hasFeatureOfInterest

xsd:boolean iot-lite:online iot-lite:idxsd:string

sosa

iot-taxonomyiot-litegeo

qussn

ssn-system

In Resource Graph

In Observation Graph

Fig. 1: Modified version of Ontology defined in [26]. For clarity we only show concepts related to Sensors. Note that sosa:Featu-reOfInterest is replicated just to clearly show the connections. They should be considered same.

using QUDT14 ontology, but we refrain from using it for thisversion of our ontology and keep it simple annotation-wise.

• We use sosa:Actuator to define an Actuating device. Previ-ously, it was defined using iot-lite:ActuatingDevice. We alsoadd sosa:Actuation and sosa:ActuatableProperty to accountfor the measurement made using sosa:Actuators and thephenomena they act on, respectively.

• sosa:FeatureOfInterest: defines “the thing whose propertyis being estimated”. For example sosa:FeatureOfInterest canbe a room and a building. For now, we add only a few sub-classes of sosa:FeatureOfInterest and make them availableas a part of IoT-Taxonomy. A sosa:FeatureOfInterest is alsoassociated with iot-lite:Service.

• ssn-system:SystemProperty is “the observable character-istic that represents the System’s ability to operate itsprimary purpose”. For ssn-system:SystemProperty we reuseits Accuracy, Frequency, Latency, Precision, Resolution, andResponse time subclasses. We associate these subclasses

14QUDT: http://qudt.org/1.1/schema/qudt#

with three different data properties: (i) dul:hasDataValue- used for those system properties that do not have a rangeof values, (ii) schema:minValue and (iii) schema:maxValue- used for those system properties that do have a range ofvalues. We associate the above-mentioned data propertieswith range xsd:int and xsd:double.We include privacy related concepts in our ontology to

address the requirement of privacy and call this new subgraphas a privacy graph (see Figure 2). For the privacy graph, weagain follow the seven-step methodology [8] where we identifythe scope of the ontology and before adding concepts in thisgraph ask competency questions, such as:• What resources a user has permission to discover?• Who has permission to discover resources and observations?• Who provides the consent for access?• Who owns a particular resource or observation?• What purpose a user has to discover specific types of data?• Who controls the data collection process?

Given such competency questions, we identified the need

to include consent [19] and provenance [20] based concepts.Therefore, we reuse concepts from Consent15 (we use prefixcon) and GDPRtEXT16 (we use prefix gdprtext) ontologies.Nonetheless, these ontologies do not fulfil all the requirementsand are not standardised. Upon exhaustive search, we wereunable to identify ontologies that we could reuse to fulfil all ofour requirements as described in Section III. Thus, we defineseveral object properties to match our requirements. We useprefix priv to denote the properties that we have explicitlycreated. We model the privacy graph using two subgraphs:consentGraph and userPermissionsGraph. The userPermis-sionsGraph stores the user permissions for the discovery ofeither resources or observations along with the permissibleactions and their purpose. On the other hand, the consentGraphcontains information about who has given the permissions tothe users and who is the owner of the resources/observations.This graph also stores who controls the data (usually a testbedowner or a user). These privacy related subgraphs are depictedin Figure 2. The concepts related to consentGraph are markedwith a brown dot while those in the userPermissionGraphare marked with blue dot. Concepts belonging to both graphsare appropriately shown. Next, we describe the concepts andproperties we used in the privacy graph, in detail.

• The privacy graph focuses on the discovery of the re-sources (ssn:System and iot-lite:Service) and the observa-tions (sosa:Observation and sosa:Actuation). Based on thecompetency questions, we define concepts and propertiesrelated to requested permissions, parties that are allowedaccess, and parties that provide consent to certain permis-sions. Our privacy graph does not focus on the storageof the information about how a permission for discoveryis requested, granted, or denied. It also does not storeinformation about the denied parties. We explicitly do thisto keep the graph simple.

• con:AllowedParty is the root of the userPermissionsGraphand identifies users that are allowed to discover resourcesand the observations. con:AllowedParty has permission(priv:hasPermission) to perform a discovery task. Thus,priv:hasPermission has the domain con:AllowedParty andthe range con:Permission. It has an inverse object prop-erty called con:permission given to. The con:AllowedPartycan have no or more than one con:Permissions. Simi-larly, a con:Permission is given to no or more than onecon:AllowedParty.

• con:Permission identifies different permissions in thesystem. Permissions are given for (con:permission giv-en for data) discovering the resources (ssn:system and iot-lite:service) and for phenomenon (sosa:ObservedPropertyand sosa:ActuatableProperty). Some con:Permissions canbe denied or given to discover the above data. Notethat here we specifically link to sosa:ObservedPropertyand sosa:ActuatableProperty to avoid any scalability issuesthat would appear in case we link to sosa:Observation

15Consent: http://purl.org/adaptcentre/openscience/ontologies/consent#16GDPRtEXT: https://w3id.org/GDPRtEXT#

Cardinality: Some

Cardinality: Exactly 1

Cardinality: Min 1

Cardinality: Max 1

Concepts

DataProperty

Permission

Consent

Purpose

Controller

con:permission_given_for_data

con:

cons

ent_

give

n_fo

r

con:permission_given_for_activity

con:activity_has_purpose

con:consent_given_byConsentingParty

priv:controls

Action

DataSubject

AllowedParty

con:permission_given_to

System

iot-lite:Service

ObservableProperty

priv:hasPermission

priv:owns

priv:ownedBy

priv:givesConsent

priv

:ow

nspriv:controls

priv

:con

trols

priv:controls

con:

perm

issi

on_g

iven

_for

_dat

a

priv:owns

dul:hasDataValue

xsd:string

KnowSensorsInTheArea

xsd:dateTimedul:hasDataValue

DiscoverSensors

Deployment priv:controls

sosaiot-taxonomyiot-lite

congdprtextssn

Subclass In Consent Graph

In User Permission Graph

Fig. 2: Privacy related concepts included in the ontology.

or sosa:Actuation because different observations would bestored in the triple-store as and when they are made. Usingthe link between sosa:observableProperty and sosa:Sensorusers can query the graph to get sosa:Observations.

• con:Permission is given for a particular time for a par-ticular con:Action which, for example, can be the dis-covery of sensors (iot-taxonomy:DiscoverSensors). Thedul:hasDataValue identifies the time until when the per-mission is granted. We assume that when an entry ismade in the triple-store, permission is granted. The objectproperty con:permission given for activity that has do-main con:Permission and range con:Action helps to identifythe set of activities that are granted to a con:AllowedPartyand for what purpose (con:Purpose). Each con:Actionhas a purpose. con:activity has purpose that has do-main con:Action and the range con:Purpose helps pro-vide such information. A con:Purpose can be either freetext (xsd:string) or from a predefined set (example: iot-taxonomy:KnowSensorsInTheArea).

• The consentGraph contains information about who ispermitted to access the resources and the observations.The root of consentGraph is the con:ConsentingPartywhich identifies the person who has given the consent(con:Consent) and also owns (priv:owns) the resources andthe observations. priv:owns has an inverse property calledpriv:ownedBy. The con:ConsentingParty can priv:ownsmultiple resources and observations while a resource or anobservation is priv:ownedBy by exactly one con:Consenting-Party. con:gives consent links con:ConsentingParty and thecon:Consent where the domain is con:ConsentingParty, therange is con:Consent and the cardinality is 0 or more.

• gdprtext:Controller is the “legal person, public authority,agency or other body which, alone or jointly with others,

TABLE I: Requirements mapped to our ontology

# How the requirement is addressed in the ontology1 Given a specific purpose, there are entities for consent and consenting

party that give/revoke permission to the action (i.e., data collection)requested by some users.

2 The entity purpose is introduced to require that access to data is givenonly for a specific purpose and not in general

3 Compliance to the ontology requires that any action is given per-mission only for a specific purpose and the privacy policy specifieswhich data should be collected and that only these are collected.

4 Similarly, as above, the entity action (for a specific Purpose) controlsthe type and amount of data that are requested for a service accordingto a specific purpose and then grants permission for the minimumamount of data to be collected.

5 Users can know the quality of the data stored and this can be doneusing the accuracy entity which allows accuracy values to be senttogether with the observations.

6 The consent module supports the notification of the users when thereis a new request for collecting their data.

7 Users can be considered as allowedParty to have access to their owndata and know at any given time what data are collected and whohas access to their data. This can be implemented as an additionalIoT Service on top of the IoT System, with users having additional,administrator privileges on their privacy policies.

8 An IoT system should keep record of users that have requested accessto data and can backtrack to identify the origin of a data breach whenit takes place. The AllowedParty entity can help on this aspect.

determines the purpose and means of the processing ofpersonal data.” It is the administrator of the testbed whocontrols the testbed and the related data.

Our ontology addresses all the requirements that are relatedwith data capturing and sharing phases described in Sec-tion III. A mapping is presented in Table I.

V. BEST PRACTICES FOLLOWED AND RECOMMENDATIONSTO TRIPLE-STORE CREATORS AND DATA PROVIDERS

For an ontology to have impact, be re-usable, and interop-erable it is necessary that it follows best practices and the datastored using the ontology follow recommended guidelines.Below we list the steps we followed to build our ontology andour recommendations to testbeds and triple-stores that use it.A. Best practice followed to create the ontology

Our ontology follows the methodology described in [8]. ForIoT systems on the top of the said methodology, the ontologyis engineered to follow recommendations described in [29].Most of the concepts and properties, other than those that wehave defined, are taken from ontologies that already follow thebest practices and are available in LOV17 [30]. Further:• We publish the ontology in several formats, such as

RDF/XML, JSON-LD, Turtle, and Ntriples. Each con-cept and property fulfills a set of metadata that in-cludes rdfs:labels and rdfs:comments. We maintain the on-line accessibility18 and the permanent URL of the ontol-ogy. The ontology web documentation is generated usingWIDOCO [31]. It reflects detailed documentation of theconcepts and the properties, how-to, and related material.

• We aim to standardise the ontology. As a step towardsstandardisation, the ontology is in submission to LOV.

17LOV: https://lov.linkeddata.es/dataset/lov/18FIESTA-Priv: http://purl.org/iot/ontology/fiesta-priv#

ssn:Deployment

soundcity:soundcitysoundcity

ssn:

hasD

eplo

ymen

t

iot-taxonomy:SoundSensor

soundcity:sensor.resource.3230

sosa:isHostedBy

geo:lat = 48.85^^xsd:doublegeo:long = 2.352^^xsd:double

geo:Point

soundcity:location.resource.3230

geo:

loca

tion

iot-taxonomy:Sound

soundcity:qk.resource.3230.Sound

sosa:observes

iot-taxonomy:DecibelA

soundcity:unit.resource.3230.DBAiot-lite:hasUnit

sosa:isObservedBy

this:domainOfInterest

iot-taxonomy:Environment

soundcity:doi.resource.3230.environment

iot-lite:exposes

iot-lite:Service

soundcity:service.resource.3230

iot-lite:interfaceDescription = “XXX”^^xsd:stringiot-lite:endpoint = “YYY”^^xsd:anyURI

iot-lite:interfaceType = “REST”^^xsd:string

iot-lite:exposedBy

ssn-system:SystemCapability

soundcity:sc.resource.3230

ssn-system:hasSystemCapability

ssn-system:hasSystemProperty

iot-taxonomy:Meters

soundcity:unit.accuracy.resource.3230.M

iot-l

ite:h

asU

nit

ssn-system:Accuracy

soundcity:accuracy.resource.3230

dul:hasDataValue = “50”^^xsd:double

sosa:hosts

ssn:Platform

soundcity:platform.resource.3230

iot-lite:isMobile = “1”^^xsd:boolean

(a) Resource Graph Annotation

iot-taxonomy:SoundSensor

soundcity:sensor.resource.3230

sosa

:mad

eByS

enso

r

sosa:Observation

soundcity:observation.resource.3230.UUID

iot-taxonomy:Siren

soundcity:source.observation.resource.3230.UUID.Sirenthis

:has

Sou

rce

geo:lat = 48.85^^xsd:doublegeo:long = 2.352^^xsd:double

geo:Point

soundcity:location.observation.resource.3230.UUID

geo:

loca

tion

iot-taxonomy:Sound

soundcity:qk.observation.resource.3230.UUID.Sound

sosa

:has

Res

ult

sosa

:obs

erve

dPro

perty

sosa:madeObservation

sosa:resultTime = “2016-10-27T010:20:16.570Z”^^xsd:dataTime

sosa:Result

soundcity:result.observation.resource.3230.UUID

dul:hasDataValue = “90”^^xsd:double

iot-taxonomy:DecibleA

soundcity:unit.observation.resource.3230.UUID.DBA

iot-l

ite:h

asU

nit

iot-taxonomy:Manual

soundcity:mtype.observation.resource.3230.UUID.Manual

this

:has

Mea

sure

men

tTyp

e

(b) Observation Graph Annotation

Fig. 3: Sample annotations for resource and observation graph.

• In case any testbed/data provider wants to request updates inour ontology or taxonomy towards integration in the feder-ated triple-store, they can use our GitHub issue tracker19

to propose changes. For completeness, each concept orproperty that the testbed wants to add should consist ofa name (rdfs:label), a clear description (rdfs:comment),and the parent (if any). Further, for properties, addition-ally, the testbeds should define the domain, the range,and the cardinality. To ease the integration process, if theconcept or the property is already defined in some otherontology, the testbed/data provider should also provide therdfs:isDefinedBy or rdfs:seeAlso.

B. Recommendations to federating triple-stores and testbed/data providers

As discussed before, there are four subgraphs in our ontol-ogy. The interactions of the consentGraph with the resourcegraph and the observation graph increase with the number ofresources and observations. This increases communication andstorage overheads. Thus, we provide recommendations that areparticular to our ontology. These recommendations certainlyshould be treated along with the generic recommendations thatexists within the semantic realm. Our recommendations are:

• related to the use of privacy graph.• related to the use of iot-lite:metadata.• related to the order in which data should be inserted.

The following list provides our specific recommendations:

• Using our ontology, currently, one cannot store informationregarding how the permissions are granted or denied. Itfocuses only on which users are granted permissions. Thetriple-store should provide the functionality to update theconsentGraph and the userPermissionGraph with relevantinformation when a new resource or new observation isadded. Further, the functionality should also enable theupdate of the userPermissionGraph when a new permissionis granted. Nonetheless, when permission is denied, therelevant information should be deleted from the graph usingthe triple-store provided functionality. Also, our ontologydoes not store any information about how a user getsregistered or any other information about the user. It onlycontains the URIs of users that are con:AllowedParty oron:ConsentingParty. A triple-store should build their ownuser management functionality.

• The privacy graph should have restricted access. No userexcept the triple-store admin should be allowed to query thisgraph. con:AllowedParty should only have access to thoseresources and observations for which they have permission(i.e., their own data or policies/permissions).

• A testbed should respect the inverse properties and cardinal-ities of the object properties. If the inverse property exists,they should provide triples to support both links. Moreover,if a testbed wants to publish triples related to some featurethat is not supported currently by the ontology, they can

19FIESTA-Priv Github: https://github.com/ragarwa2/fiesta-priv

con:DataSubject

soundcity:consentingParty.Consent.UUID

con:Consent

soundcity:consent.Consent.UUID

priv:consent_given_to

iot-taxonomy:SoundSensor

soundcity:sensor.resource.3230

con:permission_given_for_data

con:consent_given_for

con:consent_given_by

gdprtext:Controller

soundcity:controller.Consent.UUID

priv:owns

priv

:ow

nedB

y

priv

:con

trols

priv:controls

con:Permission

soundcity:permission.Consent.UUID

dul:hasDataValue = “2016-10-27T010:20:16.570Z”^^xsd:dataTime

(a) Consent Graph Annotation

con:AllowedParty

soundcity:allowedParty.Consent.UUID

con:Permission

soundcity:permission.Consent.UUID

priv:hasPermission

con:permission_given_for_activity

iot-taxonomy:DiscoverSensors

soundcity:action.Consent.UUID.DiscoverSensors

iot-taxonomy:KnowSensorsInTheArea

soundcity:purpose.Consent.UUID.KnowSensorsInTheArea

con:activity_has_purpose

con:permission_given_to

dul:hasDataValue = “2016-10-27T010:20:16.570Z”^^xsd:dataTime

(b) UserPermission Graph Annotation

Fig. 4: Sample annotations for privacy graph.

use iot-lite:Metadata. Nonetheless, they should not abusethe iot-lite:Metadata concept.

• IoT resources should first be inserted into the resourcegraph. Then privacy related information should be updated.Then testbeds should publish observations in the observationgraph. Note that if a resource or sosa:ObservablePropertyis not granted any permission, then they are not accessibleto any con:AllowedParty but only the con:ConsentingPartyand the gdprtext:Controller can access them.

VI. WORKFLOW, ANNOTATIONS AND QUERYING

The workflow for annotation and access to resources andobservations would primarily depend on the system designfor the platform, but as a guideline, we propose the followingapproach. At the initial stage the data provider should register

resources that it wants to make available on the platformfor experimentation and populate the resource graph. Postthis process, the data provider creates instances for gdpr-text:Controller and con:ConsentingParty using in the reg-istration module, unless this is set by default by a priordata provider. User access to any resource or observationsbelonging to the data provider and residing in the triple-store of the platform is denied by default, unless a policyis pre-set. The policy would primarily be based on thecon:Purpose and con:Action, due to their significance withGDPR compliance. Assume, con:AllowedParty are users thatare registered. For such a case the data provider creates acon:Permission that will link all the current and any futurecon:AllowedParty with a resource if the policy requirementsare met. This type of process can be viewed as “passive” con-sent. If a policy is not pre-set then a user (con:AllowedParty)request for access to resources or observations is triggeringa mechanism to request an “active” consent usually withina set period before expiration. This would involve the plat-form notifying all the con:ConsentingPartys. Whenever acon:ConsentingParty grants access to their resources or obser-vations, a new con:Consent and con:Permission is instantiatedand the usersPermissionGraph is updated accordingly.

For a better understanding of our recommendations andworkflow, we provide sample annotations that a testbed shouldrefer. Figure 3a and Figure 3b provide sample annotations forthe resource and observation graph. The annotations assumethat a sound sensor associated to an example testbed calledSoundcity (a mobile crowdsensing testbed [32]) is availableand the testbed wants to use our ontology to both store datalocally in its own triple-store and send the data to a federatedtriple-store. In the process the testbed creates an IRI sound-city:sensor.resource.3230 of type iot-taxonomy:soundSensor.The sensor is on a platform soundcity:platform.resource.3230that has location soundcity:location.resource.3230 and is mo-bile (iot-lite:isMobile=1ˆˆxsd:boolean). The sensor is exposedvia a service soundcity:service.resource.3230 and has unitsoundcity:unit.resource.3230 of type iot-taxonomy:DecibelA.The sensor has domain of interest soundcity:doi.resource.32-30.environment. The testbed similarly creates IRIs to otherassociated properties. The testbed annotates an obser-vation produced by this sensor at time 2016-10-27T0-10:20:16.570Zˆˆxsd:dataTime (after setting the required pri-vacy parameters) in a similar way and creates its IRIsoundcity:observation.resource.3230.UUID. Here UUID is theunique identifier. This observation has sosa:Result IRI sound-city:result.observation.resource.3230.UUID which dul:has-DataValue 90ˆˆxsd:double. This observation is recorded to-wards the sound produced by a sound source soundcity:-source.observation.resource:3230.UUID.Siren. Note that, inthese figures, the ontology concepts are shown in lightblue box while the testbed provided IRIs are shown inlight grey box. The figures also show the object proper-ties and the annotations only to the most relevant con-cepts. Note that the starting point in the resource graphsis soundcity:sensor.resource.3230 while for the observa-

Fig. 5: Augmented SPARQL query.

tion graph, depending on the need, it can be eithersoundcity:sensor.resource.3230 or the observation soundc-ity:observation.resource.3230.UUID the sensor made. This isin particular useful while querying.

On the other hand, Figure 4a and Figure 4b, providesample annotation for the consentGraph and userPermis-sionGraph, respectively. These figures as before use samestyling and show annotations to most relevant privacy relatedconcepts. Here, for the same sensor described above, thetestbed provides annotations regarding a consenting party(IRI soundcity:consentingParty.Consent.UUID) who is of typecon:DataSubject that gives consent (soundcity:consent.Con-sent.UUID) for a request of permission (soundcity:permis-sion.Consent.UUID). Depending on the the scenario, thispermission could be asked by the user/experimenter forthe activity of discovering sound sensors (soundcity:activity.-Consent.UUID.DiscoverSensors) for the purpose of knowingthe available sensors in the given area (soundcity:purpo-se.Consent.UUID.KnowSensorsIntheArea) or set by thetestbed itself (passive mode). Note that, as consentGraph isdata provider centric, the starting point or the root of the graphis the con:ConsentingParty, soundcity:consentingParty.Con-sent.UUID. On the other hand, depending on the needs, forthe userPermissionsGraph, the starting point can be either thecon:AllowedParty or the con:Permissions.

Once data is available in a triple-store, users/experimenterscan write SPARQL queries depending on their needs us-ing the SPARQL endpoint provided by the triple-store.As the users/experimenters only need to access the re-source and observation graphs, they should only writequeries that target either the resource, the observationgraph or both. Consider an experimenter who has reg-

istered his interest for discovering available sensors (iot-taxonomy:DiscoverSensors) in a given location for knowl-edge purpose (iot-taxonomy:KnowSensorsIntheArea) with theplatform and the platform has stored this information. TheuserPermissionsGraph is only updated after a particular in-terest/request of the user is granted permission. The user thenmakes a query to get data associated to all the sensors availablein a region bounded between -50 degrees and +50 degreeslongitude and between 0 degree and 100 degrees latitude. Thetriple-store then augments the query internally to include theprivacy related concepts depending on the registered interestof the user. On the other hand, the triple-store can also firstexecute the user query and then filter the results based on theprivacy graph (a time-consuming alternative).

Assuming the triple-stores use the first approach, Figure 5shows an augmented SPARQL query for knowing all re-sources a particular user can discover in a particular region.Here, we assume that the platform internally gathers allthe permissions requested by the user and use them in theaugmentation part. In the example, as the user wants to iot-taxonomy:DiscoverSensors, the platform augments the state-ment ?action a iot-taxonomy:DiscoverSensors in the query.

VII. ONTOLOGY VALIDATION

We perform a qualitative evaluation of the ontology, validat-ing its conformance (example: lexical, syntactic and semanticaspects) [33] and quality (example: accuracy, completeness,conciseness, adaptability, clarity, computational efficiency, andconsistency) [34]. We also comment on the reusability andmodularity aspects. This work does not provide any usagespecific evaluation as we do not focus on building a platform.

For structural aspects, we validate our ontology using toolssuch as Ontology Pitfall Scanner20 (OOPS), TripleChecker21

and Vapour22. Among the above tools, OOPS also provides uswith an evaluation of completeness, conciseness, clarity, andconsistency. An OOPS report on the validation of our ontologyis available on the ontology document page. The tool identifiesthat our ontology is concise. For completeness, it reports thatour ontology has unconnected elements. This is true in thecase of iot-lite:Metadata for which domain is deliberatelykept open. It further reports that some properties are missingdomain and range. This again is not relevant as we have usedschema:domainIncludes and schema:rangeIncludes to definedomain and range of the properties. These annotations are notchecked by the tool. The tool also reports that there are inverserelations other than those defined. This again is not true as thetool reported inverse relations are not valid. Thereby makingour ontology consistent. The only clarity issue raised is theuse of different naming conventions in the ontology. We areaware of this situation as the Consent ontology uses a differentconvention. Other than OOPs report, we also make availablethe TripleChecker23 and Vapour24 reports.

20OOPS: http://oops.linkeddata.es21TripleChecker: http://graphite.ecs.soton.ac.uk/checker/22Vapour: http://linkeddata.uriburner.com:8000/vapour23FIESTA-Priv TripleChecker: https://tinyurl.com/qwbnj8724FIESTA-Priv Vapour: https://tinyurl.com/r7f5wbt

To provide complete validation of our ontology, we executethe Hermit reasoner with the hope to identify any entailmentsthat we did not intend. We apply reasoning on the structureof the ontology, the relationships among classes and amongproperties. As there are no instances, we do not reasoninstances. For our ontology, other than direct relations, thereasoner inferred results mainly using rules such as:• (rdfs11) if A is a subClassOf B and B is a subClassOf C

then A is a subClassOf C• if A is a subClassOf B and B is equivalentTo C then A is

a subClassOf C• if A is a subClassOf B and B is inverseOf C then A is a

subClassOf inverseOf C• if A is inverseOf B and B is equivalentTo C then A is

inverseOf CNote that here we only show the rules for classes. Similarresults were obtained for objectProperties as well. Nonethe-less, we notice no issues25. The reasoner also detected thatour ontology is ‘satisfiable’. For validation purpose we alsoexecuted Pallet Reasoner and found similar results.

Our ontology is partially modular. It reuses most of theconcepts from the existing ontologies. We defined the conceptsand properties within the ontology because we were not ableto find related concepts in the existing ontologies.

According to the ontology metrics, our ontology has 3133Axioms, 645 Logical Axioms, 608 Declaration Axioms, 520Classes, 46 Object Properties, 13 Data Properties, 31 Annota-tion Properties, 10 Inverse Object Properties, and 3 Equivalentproperties. Out of the above-mentioned number of classes,object properties, and data properties, we have only created10 object properties. All the other classes, object properties,and data properties have been reused from existing ontologies.

VIII. USE CASES

We demonstrate the scenarios where our ontology can beused to ensure privacy for testbed participants and enabletestbed providers to restrict sharing their data with the users.

A. Selective Privacy for Participants

Testbeds and Living Labs are often closely associated withpeople. Data captured is often multi-variate in the sense thatIoT devices associated with a testbed usually monitor multiplephenomena simultaneously. For example, a testbed may com-prise devices installed in a room that measure temperature,humidity, sound, and light intensity. Some participants mightnot feel comfortable with sharing data about sound that isaround them, even though devices are not recording audiostreams. Additionally, temperature information may also revealuser presence (having the air-conditioning in on state). Thus,the associated testbed must take the user’s acceptance, and ul-timately consent, into serious consideration and restrict accessto these data on the level mandated by the participant. Thiscould be based on user roles, affiliation or locality. In this case,the con:ConsentingParty would not give con:Consent, and

25The results of Hermit reasoner are available at http://smart-ics.ee.surrey.ac.uk/fiesta/ontology/fiesta-priv/HermitResults.owl

in turn the con:Permission to the sosa:ObservablePropertywould be denied. Based on this, the testbed provider who isin priv:control as the gdprtext:Controller, will enforce denialof access to consumers who are not an con:AllowedParty.

In cases where devices are carried by humans or are mobile,such as mobile crowdsourcing, an con:Actions relating todiscovering sensors or observations can be restricted based onspatial and/or temporal rules (restricted to certain locationsand to certain times of the day). For example, consider aliving lab deployed in a workplace where sensory data iscaptured from employee smartphone managed by an employer.The employee might not want his employer to know whathe does or where he goes outside of working hours. Herethe employee (con:ConsentingParty) can restrict the dis-covery of sosa:ObservableProperties (con:Action being iot-taxonomy:GetWorkplaceObservations) captured during workhours only to the employer (con:AllowedParty).

B. Selective Data Sharing for Providers

IoT-enabled platforms have evolved from collecting datafrom homogeneous to heterogeneous sources. This involvesintegrating systems from multiple devices where data fromassociated devices are sent to the testbed where it is stored,analysed, and monitored. In the data-driven world one of themajor needs of the experimenters is the volume of the data soas to perform different analysis such as comparison betweendata of same quantity kind, and to further train their AI com-ponents to achieve better performance. Here, a data exchangepoint can be established by having a central or federatedrepository to pull data from, or more practically a data brokerwhere experimenters can subscribe to data of their interest. Al-though, providers/testbeds might want to restrict exposing theirdata to experimenters based on the purpose (con:Purpose)of data consumption, information governance compliance, orno explicitly declared interest submitted by the experimenter.Also, some providers/testbeds might want to deny access totheir data (or subset of) to other providers who are identifiedas direct competitors. Data providers (con:ConsentingParty)can only allow con:AllowedParty for the data access.

From the consumer perspective, users with different roleswould have access to the data. For example, in the contextof healthcare trial systems, these users could be clinical mon-itoring staff (or first point of contact), general practitioners,society support members, technicians or researchers. End userssuch as patients or carers participating in a trial can restrictwhich roles are allowed access to their data.

C. Applicability in IoT Platforms and Existing IoT Ontologies

Besides testbeds/data providers that have the motivationto federate their data or provide semantic powers to it, ourontology finds applicability on IoT platforms that supportfederation, semantic interoperability, and experimentation, aswell as on different existing well known IoT ontologies.

The ontology defined in [26] has been successfully inte-grated with IoT Cloud Platforms such as FIESTA-IoT [6]and has been used to federate at least 11 testbeds [32]that support more than 23 experiments. These testbeds and

experiments have different application domains (such as smartcities, crowdsensing, smart agriculture, smart building, smartenergy, and smart sea) and were selected based on theirusefulness, complementarity, sustainability, and competence.With such a success and data being released to third partiesfor experimentation purposes, privacy aspects (not addressedin [26]) must be integrated within the FIESTA-IoT Platformso to comply with GDPR. Thus, integrating our ontology withthe FIESTA-IoT Platform will provide an edge to FIESTA-IoT.The same applies to other IoT Platforms such as Wise-IoT [5]and ACTIVAGE [35] that adopt ontology defined in [26].Such adoption would not only help experimenters that includeindustries, researchers, and students but also teachers who canuse federated data in their courses.

Several IoT ontologies that lack privacy concepts can adoptthe privacy graph as a whole or the object properties definedtherein to make themselves privacy enabled. As an example,well know ontologies those missing privacy concepts suchas SSN1, IoT-lite2, OneM2M3 and SAREF26 including itsextensions can leverage from our defined privacy graph.

IX. DISCUSSION AND CONCLUSION

In the future IoT-connected world, with a continuous in-crease in the number of IoT devices, the lives of people willbecome more and more heavily dependent on IoT. In such ahyper-connected world with devices continuously monitoringand assisting the every day lives of people, keeping their livesprivate is not a very easy task. To do so, IoT systems shouldbe fully compliant with legal requirements and built underthe concept of privacy by default [1]. The IoT experimen-tation world can not be distinguished from the real world,since the data that are gathered by testbeds (that support theexperiments) are real-world data belonging to or describingreal people. In both cases (real-world implementation andexperimentation) a well-defined ontology providing the re-quired privacy-enhancing features to protect the users’ datais mandatory. This ontology should describe the entities ofan IoT system and their interconnections, embedding also themost important concepts of privacy to ensure that any IoTsystem is privacy-enhanced.

Having this in mind, in this work we enhance existing well-defined ontologies (such as that defined in [26]) adding thenecessary components to address the main data capturing andsharing requirements of GDPR mapped to the specifics ofan IoT system. It has to be noted here that the proposedontology does not claim to address all the GDPR requirements,especially not the ones related to data processing, retentionor deletion, but rather focuses on the privacy requirementsfor data gathering and sharing. The ontology addresses theGDPR requirements described in Section III, by adding a newsubgraph as the privacy graph, which includes key concepts asconsent, permission, data subject, purpose and linking theseconcepts with IoT services and data controllers. The main goalof this graph is to ensure that any request for data will have to

26SAREF: http://saref.linkeddata.es

sosa

iot-lite

iot-taxonomy

ssn

ssn-systemsgeo

qu

xml schema

ssn-

syst

ems

dul, schema

sosa

ssn-systems

ssn

ssn, sosa sosa

iot-l

ite

iot-l

ite

iot-lite

this

, ssn

-sys

tem

s

iot-lite

iot-l

itedul

iot-l

ite

geo

sosa

, dul,

iot-l

ite

iot-lite

sosa

geo

iot-lite

con

con, priv

priv

con

con

dul

gdprtext

conpr

iv

priv

priv

Privacy related

Subclass in

Fig. 6: Different Ontologies used. Circles represent differentontologies used. Connections between different ontologies aremade using object properties coming from stated ontologies.Privacy-related concepts are shown in red. The direction of thedotted line represents from which ontology the “subclasses”for a particular concept is taken from.

get the permission of the data subject (if the data are sensitive).In order to do so, the requester has to provide a well-defineddescription of the purpose, ensuring that the user will have thefull control and full view over who has access to his data.

It is expected that such an ontology will be highly adoptedby IoT experimentation projects, as well as IoT services thatfirst aim to protect the user privacy. Since this is a high-levelview of a privacy-enhanced IoT ontology, in the future, wewould like to focus on extending our ontology to include,for example, concepts related to conditions or context inwhich a particular observation is captured. A context couldbe where the observations are made such as indoor/outdoor,overground/underground, etc. [36]. This could be useful fordata analytics, outlier detection and Complex Event Processing(CEP) tasks that require knowledge about external conditions.

We would like to add even more privacy concepts toaddress more fine-grained scenarios than might not be fullycaptured by this version, i.e., specifying in detail how userscan themselves change/add new policies/rules, how the systemwill ensure that user data will not be kept indefinitely (GDPRrequires to set a time period for keeping the data) , and howto account for data breaches. Further, we are also workingtowards standardising our ontology.

ACKNOWLEDGEMENT

All the authors have contributed equally. Authors wouldlike to thank the members of FIESTA-IoT consortium andthe anonymous reviewers for their valuable comments. Thiswork has been sponsored by the EU Horizon 2020 programmethrough ACTIVAGE (contract no. 732679) and IoTCrawler(contract no. 779852) projects and by the Science FoundationIreland under the grant number SFI/12/RC/2289 P2.

REFERENCES

[1] Council of the European Union and European Parliament, “Regulation(EU) 2016/679 of the European Parliament and of the Council of 27April 2016 on the protection of natural persons with regard to theprocessing of personal data and on the free movement of such data,and repealing Directive 95/46/EC (GDPR),” 2016.

[2] V. Issarny, V. Mallet, K. Nguyen, P. Raverdy, F. Rebhi, and R. Ventura,“Do’s and Don’ts in Mobile Phone Sensing Middleware: Learning from aLarge-Scale Experiment,” in 17th International Middleware Conference,pp. 17:1–17:13, December 2016.

[3] M. Marjani, F. Nasaruddin, A. Gani, A. Karim, I. Hashem, A. Siddiqa,and I. Yaqoob, “Big IoT Data Analytics: Architecture, Opportunities,and Open Research Challenges,” IEEE Access, vol. 5, pp. 5247–5261,2017.

[4] M. Ganzha, M. Paprzycki, W. Pawłowski, P. Szmeja, andK. Wasielewska, “Semantic Interoperability in the Internet of Things:An overview from the INTER-IoT perspective,” Journal of Networkand Computer Applications, vol. 81, pp. 111–124, 2017.

[5] E. Kovacs, M. Bauer, J. Kim, J. Yun, F. Le Gall, and M. Zhao,“Standards-based worldwide Semantic Interoperability for IoT,” IEEECommunications Magazine, vol. 54, no. 12, pp. 40–46, 2016.

[6] J. Lanza, L. Sanchez, J. Santana, R. Agarwal, N. Kefalakis, P. Grace,T. Elsaleh, M. Zhao, E. Tragos, H. Nguyen, F. Cirillo, R. Steinke, andJ. Soldatos, “Experimentation as a service over semantically interopera-ble internet of things testbeds,” IEEE Access, vol. 6, pp. 51607–51625,September 2018.

[7] ISO/IEC JTC 1/SC 27, “ISO/IEC 29100:2011 Information technology-Security techniques -Privacy framework,” 2011.

[8] N. Noy and D. McGuinness, “Ontology Development 101: A Guide toCreating Your First Ontology,” tech. rep., Knowledge Systems Labora-tory, Stanford, 2001.

[9] G. Bajaj, R. Agarwal, P. Singh, N. Georgantas, and V. Issarny, “4W1H inIoT Semantics,” IEEE Access, vol. 6, pp. 65488–65506, October 2018.

[10] G. Bajaj, R. Agarwal, P. Singh, N. Georgantas, and V. Issarny, “A studyof existing Ontologies in the IoT-domain,” 2017.

[11] M. Abomhara and G. Køien, “Security and privacy in the Internet ofThings: Current status and open issues,” in International Conference onPrivacy and Security in Mobile Systems, pp. 1–8, IEEE, May 2014.

[12] O. Sacco and J. Breslin, “PPO & PPM 2.0: Extending the privacypreference framework to provide finer-grained access control for theweb of data,” in 8th International Conference on Semantic Systems,pp. 80–87, ACM, September 2012.

[13] L. Costabello, S. Villata, and F. Gandon, “Context-Aware Access Controlfor RDF Graph Stores,” Frontiers in Artificial Intelligence and Applica-tions, vol. 242, pp. 282–287, 2012.

[14] C. Choi, J. Choi, and P. Kim, “Ontology-based access control modelfor security policy reasoning in cloud computing,” The Journal ofSupercomputing, vol. 67, no. 3, pp. 711–722, 2014.

[15] M. Imran-Daud, D. Sanchez, and A. Viejo, “Ontology-based accesscontrol management: Two use cases,” in 8th International Conference onAgents and Artificial Intelligence, pp. 244–249, Science and TechnologyPublications, February 2016.

[16] S. Kirrane, A. Mileo, and S. Decker, “Access control and the resourcedescription framework: A survey,” Semantic Web, vol. 8, no. 2, pp. 311–352, 2017.

[17] S. Steyskal and A. Polleres, “Defining expressive access policies forlinked data using the ODRL ontology 2.0,” in 10th InternationalConference on Semantic Systems, pp. 20–23, ACM, September 2014.

[18] S. Mouliswaran, C. Kumar, and C. Chandrasekar, “Inter-domain rolebased access control using ontology,” in International Conference onAdvances in Computing, Communications and Informatics, pp. 2027–2032, IEEE, 2015.

[19] K. Fatema, E. Hadziselimovic, H. Pandit, C. Debruyne, D. Lewis, andD. O’Sullivan, “Compliance through Informed Consent: Semantic BasedConsent Permission and Data Management Model,” in PrivOn@ISWC,CEUR-WS, October 2017.

[20] H. Pandit and D. Lewis, “Modelling Provenance for GDPR Complianceusing Linked Open Data Vocabularies,” in PrivOn@ISWC, CEUR-WS,October 2017.

[21] M. Arruda and R. Bulcao Neto, “Toward a Lightweight Ontology forPrivacy Protection in IoT,” in 34th Symposium on Applied Computing,SAC’19, pp. 880–888, ACM, 2019.

Actuator

Actuation

System

sosa:resultTime

Result

ActuatablePropertyssn:forProperty

Unit

xsd:dateTime

SpatialThing

DomainOfInterest

this:hasDomainOfInterest

sosa:hasResult QualityOfObservation

ssn-system:qualityOfObservation

geo:locationgeo:location

FeatureOfInterestsosa:hasFeatureOfInterest

iot-lite:hasUnit

sosa:actsOnProperty

ssn:isPropertyOf

ssn:

hasP

rope

rty

Heating

Cardinality: Some

Cardinality: Exactly 1 Cardinality: Min 1

Cardinality: Max 1

Subclass

Concepts

DataProperty

iot-lite:idxsd:string

sosa:madeActuation sosa:madeByActuator

sosa

iot-taxonomy

iot-litegeo

qussn

ssn-system

Added Object Properties

Fig. 7: Actuation related ontology graph.

[22] F. Loukil, C. Ghedira-Guegan, K. Boukadi, and A. Benharkat, “LIoPY: alegal compliant ontology to preserve privacy for the Internet of Things,”in 42nd Annual Computer Software and Applications Conference, vol. 2,pp. 701–706, IEEE, 2018.

[23] M. Palmirani, M. Martoni, A. Rossi, C. Bartolini, and L. Robaldo,“Pronto: Privacy ontology for legal reasoning,” in Electronic Governmentand the Information Systems Perspective (A. Ko and E. Francesconi,eds.), pp. 139–152, Springer, 2018.

[24] A. Bassi, M. Bauer, M. Fiedler, and R. V. Kranenburg, Enabling thingsto talk. Springer Berlin Heidelberg, 2013.

[25] G. Moldovan, E. Tragos, A. Fragkiadakis, H. Pohls, and D. Calvo, “Aniot middleware for enhanced security and privacy: the rerum approach,”in 8th IFIP International Conference on New Technologies, Mobility andSecurity, pp. 1–5, IEEE, 2016.

[26] R. Agarwal, D. Fernandez, T. Elsaleh, A. Gyrard, J. Lanza, L. Sanchez,N. Georgantas, and V. Issarny, “Unified IoT Ontology to Enable Inter-operability and Federation of Testbeds,” in 3rd World Forum on Internetof Things, pp. 70–75, IEEE, December 2016.

[27] J. Cuellar (eds.), “Deliverable D2.2: System Requirements and Smar-tObjects Model,” tech. rep., EU-FP7-Smartcities-RERUM consortium,2014.

[28] R. Pohls, H. Staudemeyer (eds.), “Deliverable D3.2: Privacy enhanc-ing techniques in the Smart City applications,” tech. rep., EU-FP7-Smartcities-RERUM consortium, 2015.

[29] A. Gyrard, M. Serrano, and G. Atemezing, “Semantic web method-ologies, best practices and ontology engineering applied to Internet ofThings,” in 2nd World Forum on Internet of Things, pp. 412–417, IEEE,December 2015.

[30] P. Vandenbussche, G. Atemezing, M. Poveda-Villalon, and B. Vatant,“Linked open vocabularies (lov): a gateway to reusable semantic vocab-ularies on the web,” Semantic Web, vol. 8, no. 3, pp. 437–452, 2017.

[31] D. Garijo, “WIDOCO: A wizard for documenting ontologies,” in Inter-national Semantic Web Conference, pp. 94–102, Springer, 2017.

[32] L. Sanchez, J. Lanza, J. Santana, R. Agarwal, P. Raverdy, T. Elsaleh,et al., “Federation of internet of things testbeds for the realization of asemantically-enabled multi-domain data marketplace,” Sensors, vol. 18,pp. 1–32, October 2018.

[33] S. Datta, C. Bonnet, H. Baqa, M. Zhao, and F. Le-Gall, “Approachfor Semantic Interoperability Testing in Internet of Things,” in GlobalInternet of Things Summit, pp. 1–6, IEEE, June 2018.

[34] J. Raad and C. Cruz, “A survey on ontology evaluation methods,” in7th International Joint Conference on Knowledge Discovery, KnowledgeEngineering and Knowledge Management, pp. 179–186, Science andTechnology Publications, 2015.

[35] C. Karaberi, G. Dafoulas, A. Ballis, and O. Raptis, “ACTIVAGEproject: European Multi Centric Large Scale Pilot on Smart LivingEnvironments. Case Study of the GLOCAL evaluation framework inCentral Greece,” Dialogues in Clinical Neuroscience & Mental Health,vol. 1, pp. 138–143, Nov. 2018.

[36] R. Agarwal, S. Chopra, V. Christophides, N. Georgantas, and V. Issarny,“Detecting Mobile Crowdsensing Context in the Wild,” in 20th IEEEInternational Conference on Mobile Data Management, pp. 170–175,IEEE, June 2019.

APPENDIX

Figure 6 shows how we connect different ontologies. Fromthe actuation point of view, the most relevant concepts andthe objectProperties linking them in our ontology are shownin Figure 7. Note that for the concepts such as sosa:Results,its connections are same as in Figure 1.