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: ∗[email protected], †[email protected], ‡[email protected]
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.
Top Related