A Knowledge Driven Policy Framework for Internet of Things

∗

Emre Goynugur

, Geeth de Mel

, Murat Sensoy

, Kartik Talamadupula

and Seraphin Calo

Computer Science, Ozyegin University, Istanbul, Turkey

Daresbury Laboratory, IBM Research , Warrington, U.K.

T. J. Watson Research Center, IBM Research, Yorktown Heights, NY, U.S.A.

Keywords:

Internet of Things, IoT, Semantic Web, OWL-QL, Policy, Conﬂict Resolution.

Abstract:

With the proliferation of technology, connected and interconnected devices (henceforth referred to as IoT) are

fast becoming a viable option to automate the day-to-day interactions of users with their environment—be it

manufacturing or home-care automation. However, with the explosion of IoT deployments we have observed

in recent years, manually managing the interactions between humans-to-devices—and especially devices-to-

devices—is an impractical task, if not an impossible task. This is because devices have their own obligations

and prohibitions in context, and humans are not equip to maintain a bird’s-eye-view of the interaction space.

Motivated by this observation, in this paper, we propose an end-to-end framework that (a) automatically dis-

covers devices, and their associated services and capabilities w.r.t. an ontology; (b) supports representation

of high-level—and expressive—user policies to govern the devices and services in the environment; (c) pro-

vides efﬁcient procedures to reﬁne and reason about policies to automate the management of interactions;

and (d) delegates similar capable devices to fulﬁll the interactions, when conﬂicts occur. We then present our

initial work in instrumenting the framework and discuss its details.

1 INTRODUCTION

According to the vision of Smarter Planet initia-

tive, efﬁcient networks which are made up with

low-cost devices are going to augment and enhance

the day-to-day interactions of humans and organisa-

tions (Palmisano, 2008). With the proliferation of

technology, and the internet connected and intercon-

nected devices—collectively referred to as Internet of

Things (IoT)—this is fast becoming a reality; accord-

ing to Gartner

, by 2020, there will be over 20 billion

interconnected devices, and they will transform the

lives of people and organisations alike by augmenting

their experiences in environments.

In order for the above systems to function effec-

tively, it is mandatory that an IoT-enabled system

supports functionality for devices—especially the ser-

vices support (or exposed) by those devices—to inter-

act with each other in an efﬁcient manner (Jara et al.,

2014; Bak et al., 2015). For example, a weather app

may use a location service coupled with a geo co-

∗

Dr. Sensoy thanks to the Scientiﬁc and Technological

Research Council of Turkey (TUBITAK) for its support un-

der grant 113E238.

http://www.gartner.com/newsroom/id/3165317

located temperature sensor service to provide a lo-

calised view of the environment to a user. In order to

simplify the discussion, in this work, we will abstract

devices to speciﬁc services provided by them—for

example, a television could be abstracted to a thing

that provides display and audio services. However,

this yields to the problem of managing complex ser-

vice interactions. Though human cognition is good at

solving complex tasks, obtaining a bird’s-eye-view of

a network formed by these services is not feasible for

humans. Furthermore, the complexity of the problem

is exacerbated when the numbers of devices increases

as the number of services provided by them increases

too, thus even more services and interactions to gov-

ern. Therefore, any scalable solution to govern in-

teractions in IoT should provide ways to seamlessly

integrate new devices—hence new services—and ex-

pose them to the interactions space.

It is also important to note that when such ser-

vices are used by humans—or other participating

services—their interactions occur under varying con-

straints. This is due to a variety of reasons: (a) ser-

vices have their own obligations and prohibitions in

context; (b) services are owned and managed by dif-

ferent users and organisations, thus multiple con-

Goynugur E., De Mel G., Sensoy M., Talamadupula K. and Calo S.

A Knowledge Driven Policy Framework for Internet of Things.

DOI: 10.5220/0006200402070216

In Proceedings of the 9th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2017), pages 207-216

ISBN: 978-989-758-220-2

207

straints could be placed on a single service; (c) dy-

namism in the environment, and the changes in pref-

erences and goals could abruptly change constraints;

and (d) constraints placed on a service could affect the

functionality of another service.

In traditional systems, policies are typically used

to govern such interactions, but in the IoT arena, we

need expressive policy languages and efﬁcient rea-

soning procedures that can (a) deﬁne high-level poli-

cies and reﬁne them to device- and service- level poli-

cies in context; (b) detect policy violations and con-

ﬂicts automatically; (c) automatically propose reso-

lutions to conﬂicts when discovered; and (d) scale

well in dynamic networks in terms of policy reﬁne-

ment, conﬂict detection and resolution with minimal

human intervention. There is a multitude of pol-

icy frameworks—some with rich policy representa-

tions (Sensoy et al., 2012), and some targeting per-

vasive environments (Kagal et al., 2003). However,

they are either not scalable or expressive enough

with respect to the cost of execution—or reasoning

about constraints—to be effective in IoT environ-

ments. The ﬂexibility and the power of a policy man-

agement framework is to a large degree determined

by the expressiveness and computational efﬁciency

of its policy representation (Uszok et al., 2003). i.e.

OWL-POLAR (Sensoy et al., 2012) uses OWL-DL,

in which worst-case complexity of consistency check-

ing and conjunctive query answering is NEXPTIME-

complete (Baader et al., 2002).

Inspired by these observations, we present a

framework that could be used to build IoT applica-

tions at scale which adhere to a set of governing rules

set by the users and the environments in which they

are deployed. To achieve this goal our framework ﬁrst

provides facilities to devices to advertise their capa-

bilities on the network, and make them discoverable.

Our framework then utilises an effective knowledge-

based approach to represent high-level policies, efﬁ-

cient and scalable mechanisms to reﬁne those policies

to service level policies, automatic mechanisms to de-

tect conﬂicts when enforcing service level policies,

and state-of-the-art mechanisms to automatically re-

solve such conﬂicts. Speciﬁcally, the policy language

is based on OWL-QL (Fikes et al., 2004), which sup-

ports efﬁcient and scalable query re-writing mecha-

nism for reasoning so that conﬂicts could be detected

in polynomial time (i.e., PTime), and space-wise in

many cases LogSpace or even AC

for some speciﬁc

classes of problems, and a planner-based set of tech-

niques to resolve conﬂicts automatically using a poly-

nomial amount of space (i.e., PSpace).

The rest of the paper is structured as follows: In

Section 2 we provide an illustrative scenario, and use

it to ground our discussions throughout the paper. In

Section 3, we provide preliminaries to the proposed

policy language, and in Section 4 we formalise our

policy representation and present the policy manage-

ment framework. In Section 5 we discuss the imple-

mentation of the framework with respect to the illus-

trative scenario. We discuss related work brieﬂy and

sketch the future directions for our research in Sec-

tion 6, and conclude the document in Section 7 by

providing ﬁnal remarks.

2 ILLUSTRATIVE SCENARIO

Let us assume that a smart home is equipped with

an intelligent doorbell amongst its many devices. A

doorbell is typically tasked with notifying the house-

hold inhabitance when new events occur—e.g., when

the doorbell is pressed, it could make a noise or send a

message to a handheld device. Let us also assume that

in association with the smart home hub is an interac-

tive interface in which occupants of the house can en-

force such conditions on the devices in context. Now,

let us assume that the occupants have enforced a col-

lection of such policies on the doorbell and a couple

of such policy examples are notify when the doorbell

is pressed by an audio alarm, and if not responded

in 15 minutes, send a message to the registered mo-

bile phone. We, now assume that the dynamics of the

household have changed and there is a baby in the

house. Now the occupants of the house place an extra

policy on the smart hub to state that no device should

make noise when the baby is sleeping —this is due to

the current sleeping pattern of the baby which is mon-

itored by another sensor. When this policy gets re-

ﬁned and applied to the doorbell, we have a conﬂict—

i.e., the doorbell is obliged to make a noise, but what

happens if the baby is sleeping?

Though simple—yet intuitive—the above sce-

nario advocates for the need to have a policy frame-

work that is agile enough to address the ever changing

policy needs of the users, while providing efﬁcient

reasoning mechanisms quickly ﬁnd conﬂicts and re-

solve them. In order to model such environments,

we need effective domain modelling languages, and

in the next section, we introduce one such language.

3 PRELIMINARIES

In this section, we introduce the language constructs

to ground our policy representation.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

208

3.1 Background: OWL-QL

Typically, languages grounded on expressive seman-

tics focus on providing support for modelling com-

plex relations and descriptions. As descriptions be-

come more complex, the reasoning task becomes

more complex too, thus requiring more computing

power. Therefore, not all languages are suitable for

IoT applications, which must handle very large vol-

umes of instance data, ideally, with low power con-

sumption. As stated in (Motik et al., 2008) OWL 2 QL

(OWL-QL) speciﬁcally targets such applications, in

which query answering is the most important reason-

ing task. In OWL-QL, sound and complete conjunc-

tive query answering can be performed in LogSpace

with respect to the size of the data (i.e., assertions),

and polynomial time algorithms can be used to imple-

ment the ontology consistency and class expression

subsumption reasoning problems (Motik et al., 2008).

This made OWL-QL the perfect semantic language to

base our policy language.

OWL-QL includes most of the main features of

other ontology languages; however, it compromises

some expressiveness to gain performance. Since the

OWL 2 proﬁles are deﬁned as syntactic restrictions

without changing the basic semantic assumptions, in

the OWL 2 QL proﬁle, it was chosen not to include

any construct that interferes with the Unique Name

Assumption (UNA)—i.e., with the absence of the

UNA, it would have had higher reasoning and query

answering complexities. However, this also brings

restrictions to OWL-QL such as no cardinality re-

strictions nor functionality constraints (Artale et al.,

2009). For example, it is not possible to make a state-

ment like a room can only have one temperature.

OWL-QL depends on the Description Logic

DL-Lite

(Artale et al., 2009). The complexity of log-

ical entailment in most of the Description Logics is

EXPTIME (Baader et al., 2002). Calvanese et al. (Cal-

vanese et al., 2007b) proposed DL-Lite

, which can

express most features in UML class diagrams with

a low reasoning overhead—i.e., data complexity of

for ABox reasoning. It is for this reason that

we base our policy framework on DL-Lite

(to be re-

ferred to as DL-Lite in the rest of the paper); below

we provide a brief formalisation of DL-Lite to ground

the subsequent presentation of our model.

3.2 Representation and Semantics

A DL-Lite knowledge base K = (T , A) consists of

a TBox T and an ABox A. Axioms of the follow-

ing forms compose K : (a) class inclusion axioms:

B v C ∈ T where B is a basic class B := A | ∃R | ∃R

−

C is a general class C := B | ¬B | C

u C

, A is a

named class, R is a named property, and R

−

is the

inverse of R; (b) role inclusion axioms: R

v P ∈ T

where P := R

| ¬R

; and (c) individual axioms:

B(a), R(a, b) ∈ A where a and b are named individ-

uals. Description Logics have a well-deﬁned model-

theoretic semantics, which are provided in terms of

interpretations. An interpretation I is a pair (∆

, ·

where ∆

is a non-empty set of objects and ·

is an

interpretation function, which maps each class C to

a subset C

⊆ ∆

and each property R to a subset

⊆ ∆

× ∆

3.3 QL-based Policy Language

In this work we present our OWL-QL based policy

language so that the policy reasoning framework can

exploit OWL-QL’s efﬁcient and powerful query an-

swering mechanisms (Fikes et al., 2004). We recall

that an OWL-QL ontology consists of a TBox and an

ABox. Concepts, properties, and axioms that describe

relationships between concepts form the TBox of an

ontology. We note that an ABox may be very large

and volatile, while a TBox is small and static; OWL-

QL allows ABox to be stored in a relational database

and is organised based on the schema deﬁned by the

TBox. Each class in TBox is represented as a table,

whose entries are the instances of the class. Similarly,

each object or datatype property in TBox is repre-

sented as a table, whose entries are hsub ject, ob jecti

or hsub ject, datai pairs, respectively.

Table 1: An example TBox for an OWL-QL ontology.

An OWL-QL TBox

Sleeping v State

Awake v State

Awake v ¬Sleeping

Baby v Person

SoundNotiﬁcation v Sound u Notiﬁcation

TextNotiﬁcation v Notiﬁcation

Speaker v Device

Doorbell v Device

∃playSound v Device

PortableDevice v Device

MobilePhone v PortableDevice

∃hasSpeaker v ∃playSound

MediaPlayer v ∃playSound

TV v ∃hasSpeaker u ∃hasDisplay

MakeSound v Action u ∃playSound

Notify v Action

NotifyWithSound v MakeSound u Notify

Baby v Person

SomeoneAtDoor v Event

We borrow syntax and semantics from the

DL-Lite (Calvanese et al., 2007a) family to illustrate

A Knowledge Driven Policy Framework for Internet of Things

209

our TBox. For example, the statement: Computer v

ElectronicDevice means that Computer class is a

subclass of ElectronicDevice; and the statement

ElectronicDevice u ∃playSound represents devices

that can play sound. On the other hand, an ABox is a

collection of extensional knowledge about individual

objects, such as whether an object is an instance of a

concept, or two objects are connected by a role (Cal-

vanese et al., 2007a). In Description Logic, roles are

binary relations between two individual objects—e.g.

livesIn(John, NewYork). In this statement, livesIn

is the role that connects John and NewYork; exam-

ple TBox and ABox of an OWL-QL ontology, which

could be used to illustrate our scenario, are depicted

in Table 1 and 2.

Table 2: Example ABox.

1 Baby(John)

2 Person(Bob)

3 Doorbell(dbell)

4 Flat( f lt)

5 inFlat(Bob, f lt)

6 Sleeping(John)

7 SomeoneAtDoor(e1)

8 producedBy(e1, dbell)

In the next section, we discuss the use of such an

ontology to present policies in an IoT environment.

4 POLICY FRAMEWORK

In this section, we provide an overview of our pol-

icy framework. Speciﬁcally, we provide a formalism

in which we ground our policy representation, and a

framework that brings instances of such policies with

OWL-QL reasoning to detect possible conﬂicts.

4.1 Policy Representation

Adhering to the policy formalism given in (Sensoy

et al., 2012), we represent our policies by a tuple (α,

N, χ : ρ, a : ϕ, e, c) where

1. α is the activation condition of the policy;

2. N is either obligation (O) or prohibition(P);

3. χ is the policy addressee and ρ represents its roles;

4. a : ϕ is the description of the regulated action; a is

the action instance variable and ϕ describes a;

5. e is the expiration condition; and

6. c is the policy’s violation cost.

ρ, α, ϕ, and e are expressed using a conjunction of

concepts and properties from the underlying OWL-

QL ontology—i.e., they are of the form C(x) or

P(x, y), where C is a concept, P is either an object

or datatype property, and x and y are either variables

or individuals from the knowledge base. For example,

using variables b and f , and the conjunction of atoms

Baby(?b)∧Sleeping(?b)∧inFlat(?b, ? f ), describes a

setting where there is a sleeping baby in a ﬂat.

Table 3: An example prohibition policy.

χ : ρ ?d : Device(?d)

N P

α Baby(?b) ∧ Sleeping(?b) ∧ inFlat(?b, ? f ) ∧ inFlat(?d, ? f )

a : ϕ ?a : MakeSound(?a)

e Awake(?b)

c 10.0

Table 3 illustrates a policy that prohibits devices

from making sounds if there is a sleeping baby in the

ﬂat. It is important to note that, though the addressee

of the policy is speciﬁed as a device (i.e., Device(?d)),

concepts such as Speaker(?d),PortableDevice(?d),

MobilePhone(?d) are also included automatically

while evaluating the policy by means of role infer-

encing through query re-writing.

4.2 Framework

Below, we propose our policy management frame-

work that consists of three major components; a

knowledge base, a QL reasoner, and a policy rea-

soner. In this section, we describe the components

and discuss how they interact through the illustrative

scenario highlighted in Section 2. Let us assume that

there is a baby named John sleeps in a ﬂat (i.e., f lt).

John is deﬁned as a baby boy in the KB and he has a

wearable sensor that monitors his activities. The ﬂat

has an intelligent doorbell (i.e., dbell) that can cre-

ate events and alert household when someone is at

the door. At the moment, John is sleeping and Bob

presses the button on the doorbell.

4.2.1 Knowledge Base (KB)

It contains instance data—both assertions and data

coming from the sensors—and schema information

related to the domain. For example, the ABox of

our KB may contain the following set of assertions

after the doorbell button is pressed: (a) type asser-

tions such as Baby(John), Person(Bob), Doorbell(dbell),

Flat( f lt); (b) instance data such as inFlat(Bob, f lt),

Sleeping(John) added by the sleep monitor; and

the doorbell. We use the terms OWL-QL ontology and

knowledge base synonymously in our context.

As the KB gets updated with new information, the

policy reasoner queries the KB to check if a policy is

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

210

activated or expired. Since policies are described us-

ing conjunctive ontology predicates, rewriting policy

conditions to backend database queries is straightfor-

ward. We use the below discussed QL reasoner to per-

form consistency checks in a sandbox before actually

updating KB with new information, since maintain-

ing a consistent state of the world is paramount for

reasoning with our OWL-QL ontology.

4.2.2 QL Reasoner

The QL reasoner is used to interpret role descriptions,

activation conditions, action descriptions, and expi-

ration conditions of a policy over the KB. However,

directly querying the knowledge base may not reveal

the inferred information that may be deduced through

the TBox. For this purpose, query rewriting is used to

expand the policy descriptions. Additionally, the KB

must be in a consistent state with respect to the rules

deﬁned by the underlying ontology, since reasoning

on an inconsistent KB might yield false results. Con-

sistency checking is also performed by means of dis-

junctive queries that consist of conditions that may

cause inconsistency based on the axioms in the TBox.

The consistency and re-written queries can be cached

to be re-used, as long as the TBox is not modiﬁed.

We have adopted OWL-QL package of Quet-

zal (Quetzal-RDF, 2016) for generating type infer-

ence and consistency check queries. Conjunctive

formulae are converted into SPARQL queries, and

are then fed into the reasoner; the re-written output

queries are then converted into SQL. Quetzal uses

Presto (Rosati and Almatelli, 2010) algorithm to do

query reformulation.

4.2.3 Policy Reasoner

The policy reasoner utilises the above QL reasoner to

keep a track of the normative state of the world—i.e.,

a list of active policies in that state of the world. Once

a policy is rewritten through the QL reasoner, the ex-

panded policy set is then used by the policy reasoner

to create or delete active policy instances, or to detect

conﬂicts between policies at design time. The policy

reasoner uses activation and expiration conditions to

determine if a policy is activated for a speciﬁc set of

instances—e.g., in our scenario, the activation condi-

tion for the policy in Table 3 holds for the binding

{?d = dbell, ?b = John, ? f = f lt}, which is returned by

the QL reasoner. Thus, an activated policy instance is

created with the binding—i.e., an active policy dbell

is prohibited to perform MakeSound action until John

is awake is added to the normative state. The pol-

icy reasoner creates an active instance of a policy for

each different binding. Whenever, expiration condi-

tion of an active policy instance holds, it is removed

from the normative state—e.g., the active policy ex-

pires if John wakes up. Furthermore, some policies

can be removed from the normative state when they

are satisﬁed—e.g. active instance of the policy in Ta-

ble 4 could expire after notifying a resident.

4.3 Query Re-writing

There are multiple algorithms to perform query

rewriting. Any of these could be used in our imple-

mentation, however we use Presto (Rosati and Al-

matelli, 2010) algorithm, which is proven to com-

pute the most efﬁcient queries—i.e., it produces non-

recursive datalog programs. The main ideas of the al-

gorithm are eliminating existential join variables, and

deﬁning views corresponding to the expansion of ba-

sic concepts and roles. In other words, Presto tries

to eliminate redundancies and to reduce the number

of unions in conjunctive queries (UCQs) by reformu-

lating them. Eventually, the remaining complexity of

the generated query is handled by the database sys-

tem. We refer the reader to (Rosati and Almatelli,

2010) for a detailed description of the algorithm to

perform query rewriting.

Presto uses UCQs only in generated views, which

would then replace the expanded concept or role

in the original query. For example, if we had a

query to get devices in a room Q(?x) = Device(?x) ∧

inRoom(?x, livingRoom), it could generate the view

V = Device(?x) ∨ Speaker(?x) ∨ Doorbell(?x) for se-

lecting devices. Then, the original query would be

changed to Q(?x) = V (?x)∧inRoom(?x, livingRoom).

Furthermore, to illustrate the elimination of exis-

tential join variables, let us assume we have a

query Q(?x) = Television(?x) ∧ hasSpeaker(?x, ?y) ∧

Speaker(?y). In our example TBox, it is implied that

every television has a display and a speaker and the

query does not require variable ?y. Thus, Presto algo-

rithm re-writes query Q as Q = Television(?x).

4.4 Policy Conﬂict Detection

When multiple policies get applied to a service, con-

ﬂicts could occur. In our work, three conditions have

to be met for two policies to conﬂict:

1. policies should be applied to the same policy ad-

dressee (e.g., same device, service, or individual);

2. one policy must oblige an action, while the other

prohibits the same action; and

3. policies are active at the same time in a consistent

world state.

A Knowledge Driven Policy Framework for Internet of Things

211

Table 4: An example obligation policy.

χ : ρ ?d : Doorbell(?x)

N O

α SomeoneAtDoor(?e) ∧ producedBy(?e, ?x)∧

belongsToFlat(?x, ? f ) ∧ hasResident(? f , ?p) ∧ Adult(?p)

a : ϕ ?a : Noti f yWithSound(?a) ∧ hasTarget(?a, ?p)

c 4.0

Though it is trivial to ﬁgure-out policy conﬂicts

within a speciﬁc state of the world, it is a non-trivial

task to ﬁgure out if two policy may ever get into con-

ﬂict at the design time.

In order to demonstrate the complexity in conﬂict

detection—and to provide a solution—let us consider

an obligation policy associated with our scenario. As

shown by Table 4, the doorbell is obliged to notify the

event with sound. In the remainder of the section, we

denote the policies represented in Table 3 and 4 by

p1 and p2, respectively. We can easily compute the

fact that the modalities of p1 and p2 are in conﬂict,

and the action description of p1 subsumes that of p2.

We use query freezing for both checking of an ac-

tion description subsuming the other; and to detect if

two policies can be active at the same time. Query

freezing is a commonly used technique in database

optimization(Motik, 2006; Ullman, 1997) to reduce

the query containment problem in query answering.

Figure 1: Sandbox of the world model created for the two

policies p1 and p2 by freezing the activation conditions.

(Green: Obligation, Red: Prohibition).

In order to prove that p1 and p2 are in con-

ﬂict, all we need to do is to show a state of the

world in which both p1 and p2 are active for the

same addressee. For this purpose, we ﬁrst create an

empty ABox (a sandbox), and using query freezing

techniques in (Motik, 2006), this sandbox is pop-

ulated with the instances and relationships that ap-

pear in role and activation conditions of the poli-

cies. We ﬁrst freeze role and activation conditions

of p1, and populate the sandbox with the following

set of assertions, which are the minimum require-

ments for p1 to be active: Device(ind1), Baby(ind2),

belongsToFlat(ind1, ind5), inFlat(ind2, ind3).

We now freeze the role and activation conditions

for p2. However, while doing so, we do not use a

fresh individual for the policy addressee in p2 since

for two policies to be in conﬂict, they should have

the same policy addressee. The following assertions

get inserted into the sandbox: {Doorbell(ind1),

SomeoneAtDoor(ind4), producedBy(ind4, ind1),

hasResident(ind5, ind6), Adult(ind6)}.

Since the resulting sandbox is consistent, it is ap-

parent that p1 and p2 can be active at the same time.

Thus, we can conclude that these policies are in con-

ﬂict. We would have to make an additional check if

p1 and p2 had expiration conditions since one of the

policies might expire when the other one becomes ac-

tive. Figure 1 illustrates the ﬁnal state of the sandbox.

5 IMPLEMENTATION

In order to demonstrate the applicability of our frame-

work, we designed and implemented the core of the

proposal and tested it against the illustrated scenario;

below we discuss the details of its architecture and the

implementation.

5.1 Architecture of the Framework

The architecture of the proposed solution is depicted

in Figure 2; it is composed of ﬁve main compo-

nents: HyperCat Server, Device Coordinator, Knowl-

edge Base, Policy Reasoner, and Planner. We imple-

mented all these components along with the sensors

and smart devices in our running example.

Figure 2: System Architecture: Policy-enabled IoT Frame-

work.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

212

5.1.1 HyperCat Server

This is responsible for device registration and storing

data that does not frequently change—e.g., capabili-

ties (services) of devices. It is an open, lightweight

JSON-based hypermedia catalogue for IoT devices,

and stores information in triples. When used with an

ontology, we can exploit this structure to exchange

and store semantic information about devices and as-

sociated services. This method could act as a means

for achieving semantic interoperability between het-

erogeneous IoT devices and services alike.

Devices that want to connect to the system have to

more, sensor devices may also stream collected data

to the server. Our system considers all devices as a

collection of services they provide. As mentioned in

the introduction, a television could be modelled as a

collection of a speaker, a video player, a photo viewer,

a web browser, a notiﬁcation tool and so forth. In

addition, if a device needs to learn about the current

state of the system, it can retrieve the necessary sen-

sor data from the server. However, HyperCat does not

specify an interface for devices to prioritise real time

events like motion sensor or doorbell signals, thus we

extended the protocol to provide an interface for the

incoming events. Below code illustrates an example

JSON request for a speaker, which only offers one

service, to register itself and its capabilities.

item-metadata":[

{"rel":"rdf-syntax-ns#type","val":"Speaker"},

{"rel":"rdf-syntax-ns#about","val":"speaker1"},

{"rel":"canPerformAction","val":"PlaySound"},

{"rel":"inRoom","val":"room1"}],

items":[{"href":"http://speaker.ip/MakeSound",

"i-object-metadata":[

{"rel":"rdf-syntax-ns#type","val":"PlaySound" },

{"rel":"rdf-syntax-ns#about",

"val":"PlaySoundSpeaker1"}]}]}

5.1.2 Device Coordinator

This component acts as a mediator for devices that do

not have enough computational resources to commu-

nicate with the Hypercat server and make decisions.

It has three roles: (1) pull information from sensors;

(2) compute action plans to achieve goals of devices;

and (3) execute plans by sending action commands

to the devices. Frequently updated data like sensor

readings are stored in SenML (Jennings et al., 2016)

ﬁles on the sensor according to HyperCat speciﬁca-

tion. Devices and sensors that are capable of commu-

nicating with HyperCat server push data to the server

https://bitbucket.org/egoynugur/iotserver

directly. However, data from other devices and sen-

sors are polled by the Device Coordinator. It scans

SenML ﬁles and ﬁnds the latest entry. The below

JSON formatted text could be an output ﬁle of a sen-

sor that measures temperature and humidity.

e":[{"n":"TemperatureOut","v":22.5,"u":"celsius","t":26},

{"n":"TemperatureOut","v":295.6,"u":"kelvin","t":26},

{"n":"HumidityOut","v":80,"u":"RH", "t":27}],

bn":"http://localhost/out.senml","bt":1320078429,"ver":1}

In our implementation, all active policy instances

are stored in the Device Coordinator, which performs

policy reasoning on behalf of the devices; individual

devices do not know if they are prohibited or obliged

to perform certain actions—this is a realistic assump-

tion, especially for a swam of dumb devices. When-

ever an obligation is activated, Device Coordinator

runs the planner and executes the generated plan.

5.1.3 Knowledge Base

KB provides the domain descriptions—based on an

ontology—and the initial state of the system to the

planner, so that it can act, when policy conﬂicts are

detected or an obligation policy gets activated.

5.1.4 QL Reasoner

The QL Reasoner is implemented as described in Sec-

tion 4.2.2. For example, when new information is

received from the HyperCat Server—or the Device

Coordinator—the QL reasoner simulates insertion of

the new piece of information using a sandbox; con-

sistency check query is then executed in the sandbox,

and ﬁnally the new transaction is committed only if

the world state is consistent. In addition to its de-

scribed functions, the QL Reasoner is also used to

rewrite conditions of planning domain actions which

are used by the planner to verify plans to make sure

they do not cause an inconsistent world states. In this

way, we allow the planner to exploit semantic infor-

mation about the domain. Additionally, the QL Rea-

soner checks for consistency at each step of the gen-

erated plans. It simulates each step as if they were ex-

ecuted by applying their effects to the current world

state in a sandbox. As soon as one step causes incon-

sistency, that plan is discarded. Furthermore, the QL

Reasoner modiﬁes the static domain ﬁles by integrat-

ing the query rewrites to the planning process.

https://bitbucket.org/egoynugur/iotql

A Knowledge Driven Policy Framework for Internet of Things

213

5.1.5 Policy Reasoner

Currently, the policy reasoner reads policies from an

XML ﬁle and stores each policy in the memory—

code snippet below shows the XML representation

of the policy in Table 4. Internally, the policy rea-

soner uses the QL reasoner to rewrite policies with

respect to the roles, actions, and conditions. Active

instances of policies are stored in the normative state

and obligations are passed to the Device Coordinator.

Furthermore, Policy Reasoner is used to compute ac-

curate plan costs, as resulting plans may violate exist-

ing policies or new policies may become active during

sub-steps of the plan.

<Policy Name="TestObligation" Addressee="?x"

Modality="owlpolar:’Obligation’">

<AddresseeRole>sspn:’Doorbell’(?x)</AddresseeRole>

<Activation> sspn:’SomeoneAtDoor’(?e),

sspn:’producedBy’(?e, ?x), sspn:’Adult’(?p)

sspn:’belongsToFlat’(?x, ?f), sspn:’hasResident’(?f, ?p)

</Activation>

<Action var="?a"> sspn:’NotifyWithSound’(?a),

sspn:’hasTarget’(?a, ?p) </Action>

Cost>5.0</Cost> </Policy>

5.1.6 Planner

Policy conﬂicts could be avoided by ﬁnding alter-

native ways of achieving obligations and delegating

tasks to other devices. We used an artiﬁcial intelli-

gence (AI) planner in our application to implement

this approach. We used JSHOP2 as our planner as

it was easy to integrate in to our application and its

external calls allow us to simulate interleaved plan-

ning that requires the execution of non-deterministic

actions such as locate and search actions.

After JSHOP2 receives an obligation from De-

vice Coordinator, it starts planning and generates plan

ﬁles. Each atomic action of the resulting plans is ﬁrst

checked by the QL Reasoner. If the action does not

cause an inconsistency, the policy reasoner checks for

possible violations and updates the normative state

and the plan cost. It is important to note that new poli-

cies may become active or expire during the execution

of a plan. If an action in a plan causes an inconsistent

state of the world, that plan is discarded. Device Co-

ordinator picks the plan with the lowest cost; let us

note that the plan cost does include not only the cost

of actions in the plan but also the cost of policy viola-

tions that will be made while executing the plan.

https://bitbucket.org/egoynugur/iotplanner

5.2 Execution of the Demo

We simulated the environment with Java programs

acting as sensors and devices along with an Android

smartphone application behaving as the doorbell. In

addition, the planning domain description has three

actions; locate-people-in-ﬂat, notify-with-visual, and

notify-with-sound. Initial setup includes a locate ser-

vice, two active policies, and two connected devices

(a TV and a speaker) that can perform notify. Finally,

two conﬂicting policies, which are represented in Ta-

ble 3 and 4, exist in the initial setting.

The workﬂow starts with sensors sending requests

to HyperCat Server to connect and to register their ca-

pabilities to the system. Then, we send a new event to

the hub with the doorbell application. Once the hub

receives a new doorbell event, an active instance of

the obligation is created by the Policy Reasoner and

forwarded to the Device Coordinator. Ideally, Device

Coordinator should have a priority queue that sorts

obligations based on how urgent they are. We use

their violations costs to prioritize obligations. How-

ever, deadline ﬁelds and other metrics could be added

and used to compute policies’ priorities.

Next, we use the planner to ﬁnd ways of notifying

people in the house without violating no-sound policy.

Within the current setting the planner generates three

plans, which start by locating the people in the apart-

ment. Two plans notify people with sound by using

the speaker or the television. The last plan displays a

visual message on the television. Before making the

ﬁnal decision, violation cost of the prohibition policy

will be added to the plans making sound. Since the

execution costs of other two plans are considerably

increased, the plan which displays a message will be

selected as the ﬁnal choice due to its lower cost.

It can be seen from this example that interleaved

planning is essential for the IoT domain. The planner

cannot know if people are in the TV room without

actually locating them. Hence, some actions have to

be executed during planning to locate household ﬁrst.

To simulate interleaved planning, we created a service

that returns locations of people in the house and it is

called by using JSHOP2’s external call feature.

6 DISCUSSION

The proposed framework is able to perform efﬁcient

reasoning and detect policy conﬂicts due to the prop-

erties of OWL-QL—i.e., expressiveness of OWL-QL,

and database driven fast consistency checking and

class expression reasoning—when compared to other

languages from OWL family. However, the limita-

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

214

tions of expressivity associated with the OWL-QL

introduces limitations in expressing policies—e.g.,

number restrictions and functionality constraints are

not supported by DL-Lite family of languages. For ex-

ample, we cannot state that a room can only have one

temperature in OWL-QL. However, we can use the

numerical reasoning supported by planner software to

overcome some of this limitation.

Additionally, when conﬂicts are detected, one

could take several approaches to resolve conﬂicts

automatically—e.g., one could use (a) policy viola-

tion costs—i.e., use violation costs to decide which

policy has precedence over the other one. Also, in-

stead of having predeﬁned violation costs, it is pos-

sible to learn violation costs over time from user

behaviour—e.g., if a user prefers hygiene over com-

fort; (b) user feedback through a reinforcement learn-

ing mechanism to resolve conﬂicts; or (c) AI planning

techniques to automatically solve the conﬂicts.

Our current focus is on using AI planning tech-

niques to automatically resolve policy conﬂicts. In an

essence, AI planners could also be used to ﬁnd alter-

native ways of accomplishing a goal—e.g., a conﬂict

could be avoided instead of trying to resolve it. Ad-

ditionally, in situations in which planner cannot avoid

conﬂicts, we could apply other planning-based tech-

niques to come-up with conﬂict resolution strategies.

We have presented a simple planner-based ap-

proach to resolve conﬂicts automatically. However,

we can enhance the conﬂict resolution mechanism by

considering user preferences as a heuristic, and re-

formulating policy conﬂict resolution as a planning

problem. Furthermore, we can consider learning ap-

proaches wherein user preferences are captured as

utility functions and be integrated with the planner

domain. This is important in situation, especially in

IoT enabled environments, where users have different

preferences (e.g. the temperature setting in the room)

and the system wants to come to a consensus among

the users; this is the current focus of the work.

Though our current implementation has all the

necessary backend components and services, intu-

itively authoring policies is a challenging tasks. This

is mainly due to the steep learning curve users must go

through to author policies with respect to ontologies.

System assisted query writing (or generation) is an in-

teresting research problem, but is out of the scope of

this paper. However, we can get inspiration from tech-

niques such as conversational aspects in query gener-

ation with respect to schema information (Hixon and

Passonneau, 2013; Braines et al., 2014), and pragmat-

ically aware query formulation (Viswanathan et al.,

2015), to augment our system to address this issue.

Furthermore, we plan to create an intuitive app which

interfaces with the policy authoring framework sup-

ported by Google Now and Apple Siri APIs to provide

a speech interface for policy authoring.

6.1 Policy Frameworks

There are a number of frameworks to represent and

reason about polices: Ponder2 (Twidle et al., 2009),

KAoS (Uszok et al., 2003), Rei (Kagal et al., 2003),

and OWL-POLAR (Sensoy et al., 2012) to name a

few. Ponder2 is a general-purpose object manage-

ment system that can be used to enforce policies on

entities (Twidle et al., 2009). However, it is not an

ontology-based implementation and makes it difﬁcult

to infer policy conﬂicts. From the Autonomic Com-

puting Systems domains, we ﬁnd goal-driven self

assembly framework such as Unity (Tesauro et al.,

2004), and approaches that uses Self-Managed Cells

in-conjunction with event buses (Keoh et al., 2007).

These are based on Ponder2 policy language, thus

policy reasoning and analysis are made difﬁcult.

KAoS was the ﬁrst policy framework to utilise an

ontology-based approach to model and reason about

policies (Uszok et al., 2003); the policies were de-

ﬁned using the concepts and object properties, thus

it is not possible to use variables in policy descrip-

tions. Therefore, KAoS is not expressive enough to

represent policies we need for the IoT arena as we

cannot represent policies such as a speaker can no-

tify a person if they are in the same room. Rei (Ka-

gal et al., 2003) is another effort towards an ontol-

ogy based policy framework, especially for pervasive

environments since the policy language is based on

DL-Lite (Calvanese et al., 2007a). However, for the

reasoning tasks, Rei uses Prolog—especially to spec-

ify relationships such as role-value-maps—which di-

minishes the open-world properties of OWL speciﬁ-

cation. Furthermore, Rei can only determine conﬂicts

at run time, thus unable to prevent conﬂicts among

high-level policies that we are interested in apply-

ing in the IoT setting. OWL-POLAR is a knowledge

representation and reasoning framework for policies

based on Description Logics (DL) (Sensoy et al.,

2012). Though the effort is commendable, it is not

tractable for IoT arena as DL-based reasoning is not

efﬁcient nor lightweight enough for IoT applications.

7 CONCLUSION

In this paper, we have proposed a lightweight frame-

work to govern interactions in IoT environments. It

allows users to (a) make their devices—and associ-

ated services—be discoverable in the network; (b) de-

A Knowledge Driven Policy Framework for Internet of Things

215

scribe semantically rich policies; and (c) efﬁciently

reﬁne those policies to device- and service- level

policies by means of efﬁcient reasoning procedures

and conﬂict detection mechanisms. In order to ad-

dress the performance issues we have seen with other

ontology-based frameworks, we have restricted our

policy representation language to OWL-QL. This is

because, OWL-QL supports efﬁcient reasoning pro-

cedures whilst providing sufﬁcient amount of expres-

siveness for IoT application. We then presented an

implantation of this framework and showed its appli-

cability through a smart home application. Addition-

ally, we demonstrated how our system detects policy

conﬂicts and uses an AI planner to ﬁnd alternative

means to achieve the goals so that policy violations

are avoided. Lastly, we discussed the shortcomings

of our work and described the lines of future research

to address those shortcomings.

REFERENCES

Artale, A., Calvanese, D., Kontchakov, R., and Za-

kharyaschev, M. (2009). The dl-lite family and re-

lations. J. Artif. Int. Res., 36(1):1–69.

Baader, F., McGuiness, D. L., Nardi, D., and Patel-

Schneider, P., editors (2002). Description Logic

Handbook: Theory, implementation and applications.

Cambridge University Press.

Bak, P., Melamed, R., Moshkovich, D., Nardi, Y., Ship,

H., and Yaeli, A. (2015). Location and context-based

microservices for mobile and internet of things work-

loads. In 2015 IEEE International Conference on Mo-

bile Services, pages 1–8. IEEE.

Braines, D., Preece, A., de Mel, G., and Pham, T. (2014).

Enabling coist users: D2d at the network edge. In In-

formation Fusion (FUSION), 2014 17th International

Conference on, pages 1–8. IEEE.

Calvanese, D., De Giacomo, G., Lembo, D., Lenzerini,

M., and Rosati, R. (2007a). Tractable reasoning

and efﬁcient query answering in description logics:

The dl-lite family. Journal of Automated reasoning,

39(3):385–429.

Calvanese, D., Giacomo, G., Lembo, D., Lenzerini, M.,

and Rosati, R. (2007b). Tractable reasoning and ef-

ﬁcient query answering in description logics: The dl-

lite family. J. Autom. Reason., 39(3):385–429.

Fikes, R., Hayes, P., and Horrocks, I. (2004). Owl-ql?a lan-

guage for deductive query answering on the semantic

web. Web semantics: Science, services and agents on

the World Wide Web, 2(1):19–29.

Hixon, B. and Passonneau, R. J. (2013). Open dialogue

management for relational databases. In HLT-NAACL,

pages 1082–1091.

Jara, A. J., Lopez, P., Fernandez, D., Castillo, J. F., Zamora,

M. A., and Skarmeta, A. F. (2014). Mobile digcovery:

discovering and interacting with the world through the

internet of things. Personal and ubiquitous computing,

18(2):323–338.

Jennings, C., Shelby, Z., and Arkko, J. (2016). Me-

dia types for sensor markup language (senml).

https://tools.ietf.org/html/draft-jennings-senml-10.

Accessed: 2016-10-02.

Kagal, L., Finin, T., and Joshi, A. (2003). A Policy Lan-

guage for A Pervasive Computing Environment. In

IEEE 4th International Workshop on Policies for Dis-

tributed Systems and Networks.

Keoh, S. L., Dulay, N., Lupu, E., Twidle, K., Schaeffer-

Filho, A. E., Sloman, M., Heeps, S., Strowes, S., and

Sventek, J. (2007). Self-managed cell: A middle-

ware for managing body-sensor networks. In Proceed-

ings of the 2007 Fourth Annual International Confer-

ence on Mobile and Ubiquitous Systems: Network-

ing&Services (MobiQuitous), MOBIQUITOUS ’07,

pages 1–5, Washington, DC, USA. IEEE Computer

Society.

Motik, B. (2006). Reasoning in description logics using

resolution and deductive databases. PhD thesis, Karl-

sruhe Institute of Technology.

Motik, B., Grau, B. C., Horrocks, I., Wu, Z., Fokoue, A.,

and Lutz, C. (2008). Owl 2 web ontology language:

Proﬁles. World Wide Web Consortium, Working Draft

WD-owl2-proﬁles-20081202.

Palmisano, S. J. (2008). A smarter planet: the next leader-

ship agenda. IBM. November, 6.

Quetzal-RDF (2016). Quetzal. https://github.com/Quetzal-

RDF/quetzal. Accessed: 2016-10-02.

Rosati, R. and Almatelli, A. (2010). Improving query an-

swering over dl-lite ontologies.

Sensoy, M., Norman, T., Vasconcelos, W., and Sycara, K.

(2012). Owl-polar: A framework for semantic policy

representation and reasoning. Web Semantics: Sci-

ence, Services and Agents on the World Wide Web,

12(0).

Tesauro, G., Chess, D. M., Walsh, W. E., Das, R., Se-

gal, A., Whalley, I., Kephart, J. O., and White, S. R.

(2004). A multi-agent systems approach to autonomic

computing. In Proceedings of the Third International

Joint Conference on Autonomous Agents and Multi-

agent Systems - Volume 1, AAMAS ’04, pages 464–

471, Washington, DC, USA. IEEE Computer Society.

Twidle, K. P., Dulay, N., Lupu, E., and Sloman, M. (2009).

Ponder2: A policy system for autonomous pervasive

environments. In Calinescu, R., Liberal, F., Mar

ın,

M., Herrero, L. P., Turro, C., and Popescu, M., editors,

ICAS, pages 330–335. IEEE Computer Society.

Ullman, J. D. (1997). Information integration using logical

views. page pages. Springer-Verlag.

Uszok, A., Bradshaw, J. M., Jeffers, R., Suri, N., Hayes,

P., Breedy, M. R., Bunch, L., Johnson, M., Kulka-

rni, S., and Lott, J. (2003). Kaos policy and domain

services: Toward a description-logic approach to pol-

icy representation, deconﬂiction, and enforcement. In

Proceedings of Policy, Como, Italy. AAAI.

Viswanathan, A., de Mel, G., and Hendler, J. A. (2015).

Pragmatics and discourse in knowledge graphs.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

216