+ All Categories
Home > Documents > DELIVERABLE D4.3 Theoretical Framework for Context and...

DELIVERABLE D4.3 Theoretical Framework for Context and...

Date post: 21-Apr-2018
Category:
Upload: hamien
View: 228 times
Download: 1 times
Share this document with a friend
76
DELIVERABLE This project has received financial support from the European Union Horizon 2020 Programme under grant agreement no. 688203. D4.3 Theoretical Framework for Context and Situation Awareness in IoT Project Acronym: bIoTope Project title: Building an IoT Open Innovation Ecosystem for Connected Smart Objects Grant Agreement No. 688203 Website: www.bIoTope-project.org Version: 1.0 Date: 2016-09.27 Responsible Partner: CSIRO Editor: Arkady Zaslavsky Contributing Partners: CSIRO, EPFL, Aalto, Fraunhofer, Uni.Lu, CityzenData Dissemination Level: Public X Confidential – only consortium members and European Commission Services
Transcript

DELIVERABLE

This project has received financial support from the European Union Horizon 2020 Programme under grant agreement no. 688203.

D4.3 Theoretical Framework for Context and

Situation Awareness in IoT

Project Acronym: bIoTope

Project title: Building an IoT Open Innovation Ecosystem for Connected Smart Objects

Grant Agreement No. 688203

Website: www.bIoTope-project.org

Version: 1.0

Date: 2016-09.27

Responsible Partner: CSIRO

Editor: Arkady Zaslavsky

Contributing Partners: CSIRO, EPFL, Aalto, Fraunhofer, Uni.Lu, CityzenData

Dissemination Level: Public X

Confidential – only consortium members and European Commission Services

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 2 2016-09-29

Revision History

Revision Date Author Organization Description

0.1 16/03/2016 Arkady Zaslavsky CSIRO Initial ToC

0.2 6/04/2016 Arkady Zaslavsky CSIRO Section assignments

0.3 18/05/2016 Prodromos Kolyvakis

EPFL 2.2, 2.7, 2.8, 2.9

0.3a 26/05/2016 Sylvain Kubler UL 2.6

0.3b 3/06/2016 Prodromos Kolyvakis

EPFL Section 2.9 revised

0.4 12/08/2016 Christian Mader FHG 2.3, 2.7

0.5 24/08/2016 Arkady Zaslavsky, Alexey Medvedev,

Ali Hassani

CSIRO 2.1, 2.2., 2.3, 2.5, 2.9. 2.11, 2.12

0.6 5/09/2016 Arkady Zaslavsky CSIRO 3.1, 3.2, 3.3. 3.4

0.6a 8/09/2016 Arkady Zaslavsky CSIRO Sections reviewed

0.7a 12/09/2016 Christian Mader FHG 2.8, 2.12

0.7b 12/09/2016 Arkady Zaslavsky CSIRO Sections revised

0.7c 12/09/2016 Prem Jayaraman CSIRO Air quality use case

0.7d 12/09/2016 Manik Madhikermi A! Fault diagnosis use case

0.8a 12/09/2016 Arkady Zaslavsky CSIRO Draft released for review

0.8b 16/09/2016 Yoo Min-Jung EPFL Review feedback provided

0.8c 19/09/2016 Kristian Bäckström ControlThings Review feedback provided

0.8d 24/09/2016 Sylvain Kubler UL Review feedback provided

0.9 26/09/2016 Arkady Zaslavsky CSIRO Feedback and revi-sions consolidated

1.0 28/09/2016 Arkady Zaslavsky CSIRO Final Version

Every effort has been made to ensure that all statements and information contained herein are accurate, however the bIoTope Project Partners accept no liability for any error or omission in the same.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 3 2016-09-29

Table of Contents

1. Introduction ........................................................................................................................ 13

1.1. Scope ...................................................................................................................................... 13

1.2. Audience ................................................................................................................................. 13

1.3. Summary ................................................................................................................................ 13

1.4. Structure ................................................................................................................................. 14

2. State-of-the-Art in Context- and Situation-awareness .......................................................... 15

2.1. Context Defined ...................................................................................................................... 15

2.2. Situation Defined .................................................................................................................... 17

2.2.1. Situation Identification Techniques. .......................................................................................... 18

2.2.2. Learning-based Techniques ....................................................................................................... 20

2.3. Context-aware computing ....................................................................................................... 21

2.4. Context-awareness in the IoT .................................................................................................. 23

2.5. Theoretical Context Models and Representation ...................................................................... 25

2.6. Context quality and utility metrics ........................................................................................... 28

2.7. Context and Semantic Technologies ......................................................................................... 31

2.7.1. Resource Description Framework (RDF) .................................................................................... 31

2.7.2. SPARQL – Linked Open Data ...................................................................................................... 32

2.7.3. OWL and OWL 2 ......................................................................................................................... 32

2.7.4. Reasoning .................................................................................................................................. 33

2.7.5. Combining ontologies and rules ................................................................................................ 34

2.8. Complex events and rule engines. Situation as a complex event ............................................... 35

2.8.1. Rule Engines ............................................................................................................................... 35

2.8.2. Situation as a complex event ..................................................................................................... 37

2.9. Theoretical approaches to describing and modelling situations ................................................ 38

2.10. Context storage, indexing and retrieval ................................................................................ 41

2.10.1. Various approaches to CAP theorem ........................................................................................ 43

2.10.2. Existing context representation and storage technologies ....................................................... 44

2.11. Context- and situation-prediction ........................................................................................ 46

2.11.1. From Task Definition to Evaluation Criteria .............................................................................. 48

2.11.2. Context prediction core. ............................................................................................................ 48

2.11.3. Pre-processing block .................................................................................................................. 50

2.11.4. Memory ..................................................................................................................................... 51

2.11.5. Context Prediction Methods ..................................................................................................... 51

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 4 2016-09-29

2.11.6. Research Challenges of Context Prediction ............................................................................... 52

2.12. Context-provisioning tools, technologies and platforms ........................................................ 53

3. Context Provisioning-as-a-Service in bIoTope ...................................................................... 56

3.1. Context in bIoTope use cases and pilots ................................................................................... 56

3.1.1. Context-as-a-Service Specification for Air Quality Monitoring and Prediction Pilot ................. 56

3.1.2. Case study on context-aware fault diagnosis system for Air Handling Units ............................ 58

3.2. High-level requirements to and expectations of CoaaS in bIoTope ............................................ 63

3.3. CSDL – Context Service Definition Language ............................................................................. 64

3.3.1. A motivating scenario ................................................................................................................ 64

4. Conclusion .......................................................................................................................... 69

5. References .......................................................................................................................... 70

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 5 2016-09-29

List of Tables

Table 1. IQ (Information Quality) Dimensions (Kahn et al. 2002) ..................................................................... 29

Table 2. Context data distribution Dimensions (Bellavista et al. 2012) ............................................................ 30

Table 3. Summary of context representation approaches and their intersections with Smart City platform storage requirements ................................................................................................................................ 45

Table 4. An overview of context prediction approaches ................................................................................... 54

Table 5. List of Sensors and their Descriptions .................................................................................................. 62

Table 6. List of Alarms and Its Description ........................................................................................................ 62

List of Figures

Figure 1. Context processing ............................................................................................................................. 16

Figure 2 Levels of Abstractions in Pervasive Computing, based on (Ye et al. 2012) and (Bettini et al. 2010) .. 17

Figure 3 Definition of the Internet of Things: The Internet of Things allows people and things to be connected anytime, anyplace, with anything and anyone, ideally using any path/network and any service (Vermesan et al. 2009) .............................................................................................................................. 23

Figure 4. Context Space Theory example representation ................................................................................. 26

Figure 5. Living Room Scenario .......................................................................................................................... 27

Figure 6. Smart Fridge Scenario ......................................................................................................................... 27

Figure 7. The typical production system process cycle: (1) scan, (2) match, and (3) execute .......................... 36

Figure 8. a) Counts of model types used in 109 of 114 reviewed context-aware applications. (Boyer & Mili 2011) (b) Counts for 50 recognition applications; classifiers are used most often for applications that do recognition (Perera et al. 2014) (Lim & Dey 2010) .................................................................................... 37

Figure 9. Situations and Perception .................................................................................................................. 38

Figure 10. Visualization of situation subspace in Context Spaces theory (a) and Context-Situation Pyramid (b) ................................................................................................................................................................... 46

Figure 11. Context prediction – general structure ............................................................................................ 48

Figure 12. CoaaS for air quality monitoring and prediction use case ................................................................ 57

Figure 13. From IoT data ingestion to continuous analytics ............................................................................. 57

Figure 14. Sequence diagram for bike riding scenario of the air quality monitoring & prediction use case .... 58

Figure 15. Context-aware Fault diagnosis system ............................................................................................. 59

Figure 16: Sequence diagram of context-aware fault diagnosis system ........................................................... 60

Figure 17: Entity-relation diagram of context-aware fault diagnosis system ................................................... 61

Figure 18. Dependencies between bIoTope workpackages .............................................................................. 63

Figure 19. Big picture of bIoTope ecosystem incorporating core components and O-MI/O-DF wrapped partner platforms ...................................................................................................................................... 64

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 6 2016-09-29

Figure 20. School kid pick-up scenario .............................................................................................................. 65

Figure 21. CoaaS generic framework ................................................................................................................. 66

Figure 22. Entity registration in CoaaS .............................................................................................................. 68

Acronyms and Definitions

Acronym Definition

ABS Anti-lock Braking System

ACID Atomicity, Consistency, Isolation and Durability

ACL Access Control List

AES Advanced Encryption Standard

API Application Programming Interface

ARM Advanced RISC (Reduced Instruction Set Computing) Machine

AWS Amazon Web Services

BDAaaS Big Data Analytics as a Service

BDaaS Big Data as a Service

BDIaaS Big Data Infrastructure as a Service

BDPaaS Big Data Platform as a Service

BDXaaS Big Data Everything as a Service

BIBA Bremer Institute for Production and Logistic

bIoTope Building an IoT Open innovation Ecosystem for connected smart objects

BMW Bayerische Motoren Werke AG

CA Certificate Authority

CAGR Compound Annual Growth Rate

CAP Consistency / Availability / Partition tolerance

CDH Cloudera Distribution including Hadoop

CEP Complex Event Processing

CIRB Centre d'Informatique pour la Région Bruxelloise

CoaaS Context as a Service

CoAP Constrained Application Protocola

CPS Certificate Practice Statement (alternatively Cyber Physical System)

CPU Central Processing Unit

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 7 2016-09-29

CSIRO Commonwealth Scientific and Industrial Research Organisation

CSP Certification Service Provider, a CA (Certificate Authority) in eIDAS context

CST Context Spaces Theory

CSV Comma Separated Values

CT ControlThings

DaaS Data as a Service

DATEX DATa EXchange

DH Diffie-Hellman (key agreement algorithm)

DHT Distributed Hash Table

DIALOG Distributed Information Architectures for coLlaborative loGistics

DNS Domain Name Server

ECC Elliptic curve cryptography

eID Electronic identification

EJDB Embeddable JSON DataBase

eLDS eccenca Linked Data Suite

EMF Eclipse Modelling Framework

Encryption Reversible transformation of data by a cryptographic algorithm to produce cipher text i.e. hide the information content of the data

EPSG European Petroleum Survey Group Geodesy

ETL Extraction, Transform, Loading

GCHQ Government Communications Headquarters (British intelligence and security organisation)

GM General Manager

GML Geography Markup Language

GNU GNU is Not Unix

GnuPG GnuPG stands for GNU Privacy Guard, which is an open and free implementation of the OpenPGP standard, defined by RFC4880

GPL GNU General Public License

GSM Global System for Mobile communications

GSN Global Sensor Networks

GUI Graphical User Interface

HDF Hortonworks Data Flow

HDFS Hadoop Distributed File Systems

HDP Hortonworks Data Platform

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 8 2016-09-29

HMAC Hash-based message authentication code

Host A computing device that mediates access to information or functionality, or provides ser-vices to a network

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

I/O Input/Output

IaaS Information as a Service

IBM International Business Machines Corporation

ICE In Case of Emergency

ICO Internet-Connected Objects

ICT Information and Communication Technologies

ICT30 Internet of Things and Platforms for Connected Smart Objects

Identity A mathematically unique identity bounded to an entity or object using a private key

IoAT Internet of Anything

IoT Internet of Things

IoTBnB IoT service puBlication aNd Billing

ISO International Organization for Standardization

ISP Internet Service Provider

IT Information Technology

JOSE JSON Web Encryption

JS JavaScript

JSON JavaScript Object Notation

JSON-LD JavaScript Object Notation for Linked Data

JVM Java Virtual Machine

JWE JSON Web Encryption

JWT JSON Web Token

KaaS Knowledge as a Service

Key Sequence of symbols that controls the operation of cryptographic transformation (encryp-tion, decryption)

KMF Kevoree Modelling Framework

KML Keyhole Markup Language

LGPL GNU Lesser General Public License

LOD Linked Open Data

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 9 2016-09-29

M2M Machine-to-Machine

MAC Message Authentication Codes

MD5 A widely used has algorithm

MQTT Message Queueing Telemetry Transport

MQV Menezes–Qu–Vanstone is an authenticated protocol for key agreement based on the Diffie–Hellman scheme with stronger notion of security

MyData MyData is a human centric personal information management. The MyData concept lets the individual decide exactly to whom and to what extent his personal data is exposed

NAS Network-Attached Storage

NAT Network Address Translation

Node A computing device which is or can be included in a network

NSA National Security Agency (in United States)

NTRU A public-key cryptosystem

OAuth An open standard authentication protocol

O-DF Open Data Format

OGC Open Geospatial Consortium

O-MI Open Messaging Interface

Open ID An identity layer on top of OpenAuth v2 that verifies the identity of end-user

OpenTSDB Open Time Series DataBase

OWL Web Ontology Language

PaaS Platform as a Service

PDA Personal Digital Assistant

PDF Portable Document Format

Peer A node that can act both as a server for and as a client to other peers. This makes the nodes in a peer-to-peer network more equally ranked from the communication perspective, com-pared to client / server communication.

PGP Pretty Good Privacy, a program that provides cryptographic privacy and authentication for files, emails, etc. PGP implements the OpenPGP standard.

PKC Public Key Cryptography

PKI Public Key Infrastructure on which the Public Key Cryptography is deployed for use.

QES Qualified Electronic Signature

QSCD Qualified Signature Creation Device

QTS Qualified Trust Services, a part of the eIDAS regulation

QTSP Qualified Trust Service Provider, a part of the eIDAS regulation

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 10 2016-09-29

RA Registration Authority

RBAC Role Based Access Control

RC4 Rivest Cipher 4 is a stream cipher

RDBMS Relational Database Management System

RDD Resilient Distributed Dataset

RDF Resource Description Framework

Relation A performed public key exchange between two identities. A relation has also access control definitions for the relation

REST Representational State Transfer

RFID Radio Frequency Identification

RIF Rule Interchange Format

RPM Revolutions Per Minute

RSA A public key crypto system, named after the designers Ron Rivest, Adi Shamir, and Leonard Adleman

SaaS Software as a Service

SHA Secure Hash Algorithm

SIAMU Le Service d'Incendie et d'Aide Médicale Urgente de la Région de Bruxelles-Capitale

SME Small Medium Enterprise

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SPARQL SPARQL Protocol And RDF Query Language

SPIN SPARQL Inferencing Notation

SPoF Single Point of Failure

SQL Structured Query Language

SSL Secure Sockets Layer

SSN Semantic Sensor Networks

STIB Société des Transports Intercommunaux de Bruxelles

STO Situation Theory Ontology

SWRL Semantic Web Rule Language

TCP Transport Control Protocol

TCP/IP Transmission Control Protocol / Internet Protocol (Protocol Stack)

TLS Transport Layer Security

TTP Trusted Third-Party

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 11 2016-09-29

UI User Interface

UL University of Luxembourg

URI Uniform Resource Identifier

USD US Dollar

UTC Coordinated Universal Time

VP Vice President

WGS World Geodetic System

WP3 Work Package 3

WP4 Work Package 4

X.509 An important standard for a public key infrastructure (PKI)

XMI XML Metadata Interchange

XML eXtensible Markup Language

ZIA Zero-Interaction Authentication

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 12 2016-09-29

Executive Summary

This deliverable falls within the scope of WP4 (Context-Aware Service Provisioning for IoT), which addresses challenges of context representation, validation and reasoning about context, as well as context storage and performance.

The primary objective of this deliverable is to provide insight into context- and situation-awareness theory, technologies and frameworks. This state-of-the-art review could serve as a reference study for future design choices during bIoTope development and implementation stages, and even beyond the project itself.

The second objective is (i) to provide an overview of semantics and knowledge representation capabilities that are currently supported / offered by the platforms of the different partners involved in bIoTope, along with (ii) discussions about additional key building blocks that need to be developed to foster the creation of a truly unified IoT ecosystem.

The third objective is to provide a more detailed overview of context-awareness framework that has been developed by the bIoTope CSIRO partners, namely Context Spaces Theory (CST). CST uses a multidimensional space metaphor to represent, reason about, and validate, context. CST has been the subject of various PhD studies and has attracted hundreds of citations and references.

Finally, some preliminary elements about the conceptual theoretical context provisioning framework to be developed and set up in the different bIoTope use cases is presented, although it is still difficult to have a complete overview of what relevant technologies will be required on-site, as the use case and pilot stake-holders have not yet identified all the information sources that need to be integrated into the bIoTope ser-vice marketplace/ecosystem. CSDL as a Context Service Definition Language is conceptually outlined and a “big picture” for the WP4 and the bIoTope project at large are presented and discussed.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 13 2016-09-29

1. Introduction

1.1. Scope

The main purpose of this deliverable is to provide insights into today’s context- and situation-awareness by describing the state of the art, which enables us to understand research gaps and the strategic direction to take to develop, deploy and evaluate the bIoTope Context-as-a-Service framework.

In order to understand the required features of the future bIoTope context- and situation-awareness to be implemented, this document deals with the following research questions:

• What is the role of context in the bIoTope ecosystem?

• What are primary functions of a context provisioning framework to play a key role in building the bIoTope ecosystem ?

• How can context be serviced to other components, tools and platform of bIoTope ecosystem ? The content of this document does not detail the full range of theoretical and technical features of the bIo-Tope context provisioning framework. We need further investigation among WP4 and bIoTope partners for the purpose of developing the complete functional description and solid theoretical basis for context provi-sioning framework upon which all partners agree. Subsequently, our expectation would be that the deliver-able provides basic understanding of the domain issues, which allows us to identify main requirements of context- and situation-awareness for the bIoTope ecosystem.

1.2. Audience

The target audience of the deliverable includes groups within and outside the consortium, in particular:

• Researchers, developers and integrators of the bIoTope consortium: This deliverable illustrates im-portant aspects of the bIoTope context service formulation and delivery and will therefore serve as a valuable input for stakeholders within the bIoTope consortium, notably stakeholders that work on the design of the bIoTope infrastructure and/or its implementation in the scope of the bIoTope open source project.

• Researchers within other IERC and IoT EPI projects: The deliverable illustrates some of the core imple-mentation concepts of bIoTope and will therefore be of interest to researchers in other IERC and IoT EPI projects, notably researchers working on projects that interact closely with bIoTope.

• Researchers working on IoT: The deliverable will be also of interest to broader groups of IoT research-ers, since it provides new insights into IoT open innovation ecosystem (e.g., sensors / cloud computing) integration. As a public document, the deliverable will be accessible to such groups.

• Open source community: In the medium term, bIoTope intends to build an open source community based on the bIoTope IoT platform ecosystem. This deliverable may serve as a guide to some of the in-troductory, yet important topics and functionalities of bIoTope.

1.3. Summary

This deliverable falls within the scope of WP4 (Context-Aware Service Provisioning for IoT), which addresses challenges of context representation, validation and reasoning about context, as well as context storage and performance. Strong links between context and semantics are revealed and emphasised. Complex events are identified as situations inferred from acquired and learned context. Core components are proposed to im-plement and enable Context-as-a-Service functionality.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 14 2016-09-29

1.4. Structure

The deliverable is structured as follows: Section 2 surveys state-of-the-art in context- and situation aware-ness, analyses current trends, technologies and platforms, as well as identifies related tools and technolo-gies. Section 3 provides an overview on how context- and situation-awareness affect selected use cases and proposes core elements of the theoretical framework. Section 4 concludes the deliverable.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 15 2016-09-29

2. State-of-the-Art in Context- and Situation-awareness

The chapter is intended to be “descriptive” in the sense that it contains a state-of-the-art review of theoreti-cal approaches, solutions, tools, platforms and technologies related to context- and situation-awareness, highlighting some key characteristics, pros and cons. This state-of-the-art review identifies challenges and opportunities that will be further pursued within the bIoTope project.

2.1. Context Defined

Context is a key characteristic of any pervasive computing system. According to the widely acknowledged definition given by Dey and Abowd (Dey & Abowd 1999), context is “any information that can be used to characterize situation of an entity”. In plain words, any piece of information that the system has is a part of the system’s context. The aspects of context include, but are not limited to, location, identity, activity, time. In this report the terms “context”, “context data” and “context information” are used interchangeably.

The system is context aware “if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.”(Dey & Abowd 1999). In simple words, the definition means that the system is context aware if it can use the context information to its benefit, to improve its perfor-mance, efficiency, effectiveness and utility. Although recognised as an interdisciplinary area, context aware-ness is often associated with pervasive computing, and more recently with the Internet of Things (IoT). Con-text awareness is a core functionality in IoT, and any pervasive computing system is context aware to some extent.

Figure 1 provides an overview of how the context is processed and how the pervasive computing system actions emerge from context processing efforts. The context processing is viewed from the aspects of algo-rithms and information flows. For simplicity and illustration purposes, the aspects like hardware, physical communications, interaction protocols are intentionally left out from Figure 1.

Sensors are the devices that directly measure the environment characteristics (like temperature, light, hu-midity). Direct user inputs are provided by such devices as keyboards, touchscreens, and voice recognition solutions. Sensor information and user inputs are often processed in a similar manner. After highly hetero-geneous input data is delivered, the first processing step is the data fusion and low-level validation of sensor information. Sometimes raw sensor data, collected in a single vector of values, are already viewed as low-level context. The distinction between different levels of context depends on the amount of pre-processing performed upon the collected sensor information. Usually raw or minimally pre-processed sensor data is referred to as low-level context, while the generalized and evaluated information is referred to as high-level context (Ye et al. 2012).

The situation awareness in pervasive computing and IoT can be viewed as the highest level of context gener-alisation. Situation awareness aims to formalise and infer real-life situations out of context data. From the perspective of a context aware IoT system, the situation can be identified as “external semantic interpreta-tion of sensor data”, where the interpretation means “situation assigns meaning to sensor data” and exter-nal means “from the perspective of applications, rather than from sensors” (Ye et al. 2012). Therefore, the concept of a situation generalises the context data and elicits the most important information from it. Properly designed situation awareness extracts the most relevant information from the context data and provides it in a clear manner.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 16 2016-09-29

Figure 1. Context processing

Context prediction aims to predict future context information. It can be done on any level of context pro-cessing, starting from low-level context prediction and ending with situation prediction. The adaptation block in Figure 1 defines the response of the pervasive computing system to the provided input, and pro-vides the commands to the actuators. Actuators are the devices that do actions on behalf of IoT applications, services or systems. For example: (i) a relay that turns switch on or off according to the commands of con-text aware system is a simple actuator; (ii) the display that provides the information from context aware system to the user is also an actuator, or (iii) the air-conditioner that adjusts the temperature on request of smart home environment is also an example of actuator. Context prediction describes the tasks of inferring future context information by observing the progression of a context time series (Sigg et al. 2012). In other words, past and present context information is linked to future contexts (Stephan 2008). Predicted knowledge enables pro-activity of applications (e.g., applications could have more time to prepare and pre-sent services) (Anagnostopoulos et al. 2005).

A context model, also referred to as context representation, describes the relevant aspects of the context, i.e. accessible assets from sensors, applications and users, regarding a certain task or application in a formal and general way (Henricksen 2003). There are many different ways to model context. Context modelling techniques can be classified into key-value, mark-up schemes, graphical, object, logic and ontology based modelling (Perera et al. 2014). Each of the approaches differs in complexity, accuracy and applicability of context representation.

Context reasoning, or context inference, means to "deduce new knowledge, based on the available context data" (Bikakis et al. 2008). Context models form the basis for application independent context reasoning and the context reasoning capabilities depend on the used context model technique. Context reasoning can be divided into three steps. During the first phase, pre-processing, the data is cleaned of inaccurate values and

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 17 2016-09-29

missing values are handled. Afterwards data from multiple sensors are combined during the sensor data fusion phase. The last step is context inference in which new high-level context information is inferred from the low-level context data (Perera et al. 2014)(Nurmi & Floréen 2004).

Situations represent a higher level of abstraction than context as depicted in Figure 2. A situation can be defined as an “external semantic interpretation of sensor data” (Ye et al. 2007b) by linking contextual attrib-utes to descriptive names. Meaning needs to be assigned based on the correlations between the relevant collected context to identify a situation. These correlations represented in a logical expression form the logi-cal specification of a situation (Ye et al. 2012). Situations, thus, can be seen as “logically aggregated pieces of context” (Anagnostopoulos et al. 2007).

Figure 2 Levels of Abstractions in Pervasive Computing, based on (Ye et al. 2012) and (Bettini et al. 2010)

Situation aware applications are triggered by the descriptive name of identified occurring situations. Situa-tion awareness is desirable because it provides a simple representation of a complex set of sensor data to applications, hiding the complexity and related issues about noise, inference and uncertainty of sensor data (Ye et al. 2012). This abstraction is useful for effective development of applications that understand and re-act to their environment (Loke 2004).

2.2. Situation Defined

A situation is defined as an external semantic interpretation of sensor data. Interpretation means that situa-tions assign meanings to sensor data. External means that the interpretation is from the perspective of ap-plications, rather than from sensors. Semantic means that the interpretation assigns meaning on sensor data based on structures and relationships within the same type of sensor data and between different types of sensor data (Ye et al. 2012).

A situation can be defined by collecting relevant context attributes, uncovering meaningful correlations be-tween them, and labelling them with a descriptive name. The descriptive name can be called a descriptive definition of a situation, which is about how a human being defines a state of affairs in reality. A logical ex-pression of correlated context predicates is called a logical specification of a situation. With these two, a situation bridges sensor data and applications. Sensor data is abstracted to a certain situation by evaluating its specification, and this situation will trigger applications that correspond to its descriptive name (Ye et al. 2012).

A situation is a subjective concept, whose definition depends on sensors in a current system, which decide available contexts used in a specification; on the environment where the system works, which determines the domain knowledge to be applied (e.g., a spatial map); and on the requirement of applications, which determines what states of affairs are interesting. The same sensor data can be interpreted to different situa-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 18 2016-09-29

tions according to the requirements of applications. For example, based on the location data for a number of users, we can define

• user-centred situations (meeting — the users are gathering in a meeting room), and • location-centred situations (occupied — a room is occupied).

A situation is a particular state that is abstracted from sensor data and is interesting to applications so that certain actions can be taken when this situation is occurring. What distinguishes situations from activity, and situation recognition from activity recognition, is the inclusion in situations of rich temporal and other struc-tural aspects, including time-of-day — a situation may only happen at a particular time of the day; duration — it may only last a certain length of time; frequency — it may only happen a certain time per week, and sequence — different situations may occur in a certain sequence. A situation can be a simple, abstract state of a certain entity (e.g., a room is occupied), or a human action taking place in an environment (e.g., working or cooking). A situation can also be composed of or abstracted from other finer-grained situations; for ex-ample, a ‘seminar’ situation includes the finer situations like ‘presentation’, ‘questioning’, and ‘group discus-sion’. Rich relationships exist between situations, including:

Generalisation: A situation can be regarded as more general than another situation, if the occurrence of the latter implies that of the former; for example, a ‘watching TV’ situation is considered more specific than an ‘entertainment’ situation, because the conditions inherent in the former situation subsume or imply the conditions in the latter situation (Ye et al. 2007b).

Composition: A situation can be decomposed into a set of smaller situations, which is a typical composition relation between situations. For example, a ‘cooking’ situation is composed of a ‘using stove’ situation and a ‘retrieving ingredients’ situation. McCowan et al. propose a two-layered framework of situations: a group situation (e.g., ‘discussion’ or ‘presentation’) is defined as a composition of situations of individual users (e.g., ‘writing’ or ‘speaking’) (McCowan et al. 2005).

Dependence: A situation depends on another situation if the occurrence of the former situation is deter-mined by the occurrence of the latter situation. Dependence can be long- or short-range, as proposed by (Choujaa & Dulay 2009). Sometimes long- range dependence can be more useful in inferring high-level situa-tions. For example, a situation ‘going to work’ may be better in inferring a situation ‘going home from work’ than other short-range dependent situations.

Contradiction: Two situations can be regarded as mutually exclusive from each other if they cannot co-occur at the same time in the same place on the same subject; for example, a user cannot be in a cooking situation and a sleeping situation at the same time.

Temporal Sequence: A situation may occur before, or after another situation, or interleave with another situation; for example, ‘taking pill’ should be performed after ‘having dinner’ (Jakkula et al. 2007)

2.2.1. Situation Identification Techniques.

Situation identification in pervasive computing and IoT, also referred to as situation determination, situation recognition or situation inference, deals with the following three issues:

• The logical representation to define the logical specification of situations, • How it is formed to allow specifications by an expert or machine learning and, • Situation reasoning, i.e. inferring situations from imperfect sensor data (Ye et al. 2012).

This section gives an overview of common and relevant techniques that can be applied to solve the above mentioned issues. The discussion is focused on a high-level view of the techniques, which is sufficient to

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 19 2016-09-29

evaluate their eligibility for situation awareness approaches later on. The discussion is based on the review by Ye et al. (Ye et al. 2012).

Specification-based Techniques. As mentioned previously, situation aware applications rely on external knowledge to interpret the sensor data. In specification-based approaches this expert knowledge is first rep-resented in logic rules. Reasoning engines applied on these rules then infer the situations, based on the sen-sor data (Ye et al. 2012).

Formal Logic. A popular way to represent the knowledge about situations is to use logical predicates. Logic based models provide a strong formalisation to represent the logical specification of situations. The reason-ing is then applied in a rule-based way, whereas rules are statements that define the relation between facts (Padovitz 2006). The underlying concept of approaches representing situations with formal logic is that “knowledge about situations can be modularized or discretized” (Loke 2010). Reasoning capabilities of this approach include the verification of integrity and consistency of the situation specification and systems can be extended to reason about more situations later on (Ye et al. 2012).

Fuzzy Logic. This technique, originally presented in (Zadeh 1975), is used in the field of situation identifica-tion to model imprecise knowledge so that vague information can be expressed. Fuzziness handles uncer-tainty not by using a formal representation with probability but rather by focusing on the natural ambiguity of an event itself (Anagnostopoulos et al. 2007). In fuzzy logic sensor data is linked to linguistic variables by membership functions. For example, a set or range of numerical values can be mapped to a certain term or fuzzy variable. The rule-based reasoning then infers a membership degree between 0 and 1 for each fuzzy set, since the conditions for the sets may overlap (Delir Haghighi et al. 2008).

The eventual result of the reasoning process thus will provide a degree of belief of occurring situations (Ye et al. 2012). It is sometimes argued that this approach would be rather inappropriate for situation awareness because the rule-based reasoning is very dependent on the domain and problem. Also equal beliefs for con-tradictory situations could be calculated on which it would not be possible to react properly for the system.

Ontologies. The term ontology originates from philosophy and is defined as an “explicit specification of a conceptualization” (Gruber 1995). Ontologies are applied in various research domains and are used in perva-sive computing and IoT as a formal representation for sensor data, context as well as situations. For situation identification, ontologies can be seen as a way to capture domain knowledge with a well-structured termi-nology which is readable to humans and machines (Ye et al. 2012)(Chen et al. 2009). Ontological modelling includes the concepts of classes, instances, attributes and relations (Simperl 2009).

Three kinds of ontologies can be differentiated:

• Generic ontologies, also referred to as upper ontologies, describe general concepts, • Domain ontologies specify concepts of a certain domain, • Application ontologies represent application specific knowledge (Ye et al. 2007a).

Ontologies are popular for situation awareness because of the rich semantics and expressiveness. Addition-ally, ontological reasoners can check automatically the consistency and infer new knowledge based on a given ontology (Ye et al. 2012).

Dempster-Shafer Theory. This mathematical theory of evidence, presented in (Glenn 1976), allows to calcu-late the likelihood of events, e.g. a situation, with information from different evidence sources. Mass func-tions specify the distribution of belief across the frame of discernment, the set of possible hypotheses. The combination rule merges evidences from different sources (McKeever et al. 2009). Dempster-Shafer Theory allows for assigning beliefs to sets or intervals, enabling reasoning even if the beliefs are only partially known. This makes the technique very powerful in terms of handling uncertainty and belief distribution. However, it requires expert knowledge to create an evidential network - i.e. which context information can

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 20 2016-09-29

be inferred from which sensor data and which situation can be inferred from which contexts - and domain experts need to define the degree of belief for all evidences (Ye et al. 2012)(Halpern 2003).

2.2.2. Learning-based Techniques

In today’s pervasive computing and IoT environments an enormous amount of sensor data is generated which may contain noise. Handling the noise using a specification-based way is impractical, instead machine learning techniques are used to identify situations based on the sensor data. Learning-based techniques rely on a large set of training data to achieve proper results (Ye et al. 2012).

Bayesian Techniques. Bayesian classification frameworks are based on Bayes’ theorem. Bayes’ theorem is used to update the probability of a hypothesis - i.e. a situation occurring - if a new evidence is given. A prior probability is assigned to both an evidence to support a hypothesis and to the hypothesis itself. With the posterior probability of the supportive evidence conditioned on the hypothesis the theorem updates the probability of the hypothesis (Halpern 2003)(Lewis et al. 1998).

Naïve Bayes assumes that all features characterising evidence are statistically independent. With this prem-ise the posterior probability can be calculated with reduced complexity by multiplying the probability for each feature of the evidence conditioned on the hypothesis (Lewis et al. 1998). This technique relies on a-priori knowledge about the probabilities of the hypothesis, if the probability for a feature of an evidence is missing in the training data the probability will be zero if it occurs later (Ye et al. 2012)(Padovitz 2006).

Bayesian networks are used in case dependencies between features characterising evidence exist. A Bayesi-an network is a directed acyclic graph, whereas nodes represent random variables and edges represent cas-ual influence (Halpern 2003). Each root node is associated with a prior probability. In a qualitative Bayesian network each non-root node is associated with a conditional probability distribution, in a quantitative Bayes-ian network with a conditional probability table, which indicate the influence of each parent of the node. The relationships are usually defined by domain experts. The process of inference and belief update is similar to Naïve Bayes (Ye et al. 2012) (Halpern 2003). Bayesian networks have the same downside as Naïve Bayes in terms of unavailability of prior probability (Ye et al. 2012).

Markov Models. This technique is a generative probabilistic model based on Markov chains. Markov chains are sequences of random variables, describing conditional probabilities for transitions of the state of the system. In Hidden Markov Models (HMM) each state is composed of a hidden and an observable state (Rabiner 1989). A hidden variable at a time t depends only on the previous hidden variable at t-1, whereas an observable variable at a time t depends only on the hidden variable at time t. Based on this the model can be specified with three probability distributions, prior probability for initial states, state transition probability and the probability of a hidden state inferring an observable state (Kasteren et al. 2008). For a HMM obser-vations need to be specified as training data. Problems with default HMM include that the probability of an event declines exponentially over time intervals and that hierarchical relations cannot be modelled. Thus, this approach was mainly applied for activity recognition approaches, whereas situations usually require a more complex specification of structural aspects (Ye et al. 2012).

Neural Networks. In a neural network artificial neurons are linked together according to a specific architec-ture. A neural classifier is based on an input and output layer. The mapping between these two is done by a hidden layer, a composition of activation functions that learn through training data (Ye et al. 2012). The ac-curacy of neural networks depends strongly on the training data set. Neural networks is a technique which is usually applied for activity recognition and if the mapping is composed of a lot of features and linked neu-rons the computations become heavy (Ye et al. 2012)

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 21 2016-09-29

2.3. Context-aware computing

Schilit (Schilit et al. 1994) describes context as a “limited amount of information covering a person’s proxi-mate environment” which is people-centric and characterized by the usage of multiple mobile/stationary devices that are potentially connected and continually changed. Context also invokes the time dimension because people’s location and (social) environment usually changes over time. According to Schilit, context Information encompasses location, nearby people, hosts and devices. They investigate the use of context information using handheld devices that send identification information periodically through a cell-based network so that their location can be tracked. Three kinds of located objects are distinguished:

• devices/people that require physical interaction, • non-physical objects bound to locations (e.g., bank account, menus), • places (e.g., restaurants,…).

However, when proximity is reflected in the user interface, problems can occur due to, e.g., inappropriate update frequency or accuracy and context processing may be limited by external factors such as network bandwidth or device screen size. Schilit also introduced automatic processing of contextual information. Depending on, for instance, a device’s location, the objects with which potential interaction can take place, may change (new objects become available, other objects get unavailable). However, too rapid changes are problematic for users (confusion) or impractical as small mobile devices can run into performance problems. Therefore it is useful to filter the available actions based on the location information: the location deter-mines either the set of commands or can parameterize certain commands, such as routing a word proces-sor’s output to the nearest printer. This way, context processing happens in a transparent way for the user, with e.g., buttons being differently placed and ordered and commands appearing the same but are parame-terized by different contextual information. For triggering these changes of behaviour, Schilit introduced context-triggered actions. They are formalized as “if-then” rules and support use cases like contextual re-minders, i.e., to configure that the next time the user enters the library, the system can remind her to look for a specific book. A similar approach is also suggested by Vlachostergiou (Vlachostergiou et al. 2015), who formalized the notion of context in the smart home and smart city domain and support context awareness by if-then-what rules using OWL and SWRL. Schilit argued that it is crucial for maintaining a good user expe-rience, to balance the display of context information amount as well as maintaining a predictive behaviour of the system.

Abowd (Dey & Abowd 1999) performed a literature survey on what constitutes context-aware applications and what context is. They found that in most systems, contextual information is automatically collected and made available in a runtime environment so that application designers can request the information that are needed or relevant for the application at hand. In the literature, two different views on context exist. Some publications treat context as bound to the user while others see context as bound to a specific device. Fur-thermore, the notion of “context” is often referred to with the synonyms “environment” or “situation”. Abowd stated that importance of the aspects of contextual information can vary according to the current situation. However, when reviewing publications on context-aware systems, they found that some dimen-sions like location, identity, activity and time are more important than others. They extend the definition of context as provided by Schilit with the dimensions activity and time. Also, Abowd found two interpretations of context-awareness: “using context” and “adapting to context”, where they report using context as being most common. As a commonality of some context-aware systems, Abowd mention the definition of “context widgets” that act as a proxy between applications and context information by providing a certain type of context information needed by the application.

On a general level, Dey (Dey 2001) defines three features of context-aware applications

• presentation of information and services, • automatic execution of a service,

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 22 2016-09-29

• tagging of context to information.

Dey proposed the Context Toolkit, a framework that helps application developers to integrate context-aware features. It provides context widgets where developers can subscribe for or poll context information regard-less of how it has been sensed. Multiple such widgets may be, e.g., distributed in a room and provide differ-ent types of information. The Context Toolkit also stores and makes available historical context information as well as aggregates data from different widgets. Dey defined the notion of a situation as a collection of states of different widgets and aggregators that constitutes an additional abstraction layer.

Zimmermann(Zimmermann et al. 2007) introduced a formal structure of context information. They define five categories of context information:

• Individuality: comprises anything that can be observed about an entity, typically its state. It can fur-ther categorize context into natural entity context (e.g., environment like plants, stones), human en-tity context (e.g., preferences of human users), artificial entity context (e.g., results of human actions like buildings, vehicles), group entity context (characteristics that only emerge when if entities are grouped together),

• Activity: covers all tasks this entity may be involved in (currently and in future), • Location and Time: provide the spatio-temporal coordinates of the respective entity, • Relations: information about any possible relation the entity may establish with another entity; fur-

ther distinguish between social relations, functional relations and compositional relations.

Zimmermann also defines an operational extension for covering the use of context: context transitions (e.g., variation of approximation, change of focus, shift of attention) and context sharing (covering how contexts are related to each other).

Chen (Chen & Kotz 2000) provides a survey on context aware systems and on the types of contexts used as well as models of context information and applications that adapt to changing context. They provide various definitions of context as found in literature and distinguish features of context-awareness (e.g., proximate selection or contextual reconfiguration). Chen also distinguishes between active and passive context aware-ness. Using active context awareness means an application can adapt itself to changing contexts, while pas-sive context aware applications present context and context changes to the users (so that they can perform actions) or store context for later use. The review of existing work takes into account this distinction be-tween active and passive context types and targets applications that were actually implemented. Chen dis-cusses applications that sense location using different techniques, e.g., outdoors by GPS, indoors by location tracking using infrared, radio frequency, or ultrasonic signal transmitters or hybrid approaches using wireless LAN or Bluetooth. They describe how “high level context” is used by, e.g., combining multiple sensor’s data (e.g., light and acceleration). The review of existing context models distinguishes between the location mod-el (geometric or symbolic) and data structures (e.g., key-value pairs, object-oriented or logic based). Also discussed are context handling middleware that abstracts from the actual contexts and sensing techniques. Two main middleware architectures have emerged, i.e., centralized (dedicated context servers) vs. distribut-ed. In the latter case, all end devices sense and process context information and contain triggers. Querying is done by multicast or a hierarchical location query service.

Baldauf et al (Baldauf et al. 2007) present common architecture principles of context-aware systems and define a framework to explain common elements. They focus on existing context middleware and frame-works and describe existing architectural styles of context aware systems (e.g., direct sensor access, middle-ware infrastructure, context server, widgets). They discuss the layered model that abstracts physical sensor access, data retrieval, pre-processing, storage and application layers. Baldauf et al. also identify various ways of modelling context: key/value stores, mark-up, graphical, object-oriented, logic based and ontology based. They advocate for standardised formats for expressing context information and communication (i.e. proto-cols).

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 23 2016-09-29

2.4. Context-awareness in the IoT

During the past decade, the IoT has gained significant attention in academia as well as industry. The main reasons behind this interest are the capabilities that the IoT (Association Instituts Carnot 2011)(Atzori et al. 2010) will offer. It promises to create a world where all the objects (also called smart objects (Kortuem et al. 2010)) around us are connected to the Internet and communicate with each other with minimum human intervention (Hauswirth et al. 2009). The ultimate goal is to create ‘a better world for humans’, where ob-jects around us know what we like, what we want, and what we need and act accordingly without explicit instructions (Dohr et al. 2010). The term ‘Internet of Things’ was firstly coined by Kevin Ashton (Ashton 2009) in a presentation in 1998. He has mentioned “The Internet of Things has the potential to change the world, just as the Internet did. Maybe even more so”. Then, the MIT Auto-ID centre presented their IoT vision in 2001 (Brock 2001). Later, IoT was formally introduced by the International Telecommunication Union (ITU) in the ITU Internet report in 2005 (Conti 2006). The IoT encompasses a significant amount of technologies that drive its vision. In the report, “Vision and challenges for realising the Internet of Things”, by CERP-IoT (Sundmaeker et al. 2010), a comprehensive set of technologies was listed (Figure 3). IoT is a very broad vi-sion. The research into the IoT is still maturing. Therefore, there aren’t any standard definitions for IoT. The following definitions were provided by different researchers. Definition by (Tan & Wang 2010): “Things have identities and virtual personalities operating in smart spaces using intelligent interfaces to connect and communicate within social, environment, and user contexts.” Definition by (EPoSS 2008) states: “The seman-tic origin of the expression is composed by two words and concepts: Internet and Thing, where Internet can be defined as the world-wide network of interconnected computer networks, based on a standard commu-nication protocol, the Internet suite (TCP/IP), while Thing is an object not precisely identifiable Therefore, semantically, Internet of Things means a world-wide network of interconnected objects uniquely addressa-ble, based on standard communication protocols.”

Figure 3 Definition of the Internet of Things: The Internet of Things allows people and things to be connected anytime, anyplace, with anything and anyone, ideally using any path/network and any service (Vermesan et al. 2009)

The IoT, interconnection and communication between everyday objects, enables many applications in many domains. The application domain can be mainly divided in to three categories based on their focus (Atzori et al. 2010)(Sundmaeker et al. 2010): industry, environment, and society. The magnitude of the applications is quite wide. Supply chain management (Weiss Ferreira & Decker 2010), transportation and logistics (Chen et

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 24 2016-09-29

al. 2010), aerospace, aviation, and automotive are some of the industry focused applications of IoT. Tele-communication, medical technology (Wang et al. 2011), healthcare, smart building, home (Gao et al. 2011) and office, media, entertainment, and ticketing are some of the society focused applications of IoT. Agricul-ture and breeding (Burrell et al. 2004)(Li 2011), recycling, disaster alerting, environmental monitoring are some of the environment focused applications. Asin and Gascon (Asin & Gascon 2012) listed 54 application domains under twelve categories: smart cities, smart environment, smart water, smart metering, security and emergencies, retail, logistics, industrial control, smart agriculture, smart animal farming, domestic and home automation, and eHealth.

Martin et al. (Martín et al. 2010) have identified and comprehensively discussed six design principles related to context-aware management frameworks (middleware) for IoT. Further, Ramparany et al. (Ramparany et al. 2007) and Bernardos et al. (Bernardos et al. 2008) have also identified several design requirements. We summarise the findings below with brief explanations. This list is not intended to be exhaustive. Only the most important design aspects are considered.

• Architecture layers and components: The functionalities need to be divided into layers and compo-nents in a meaningful manner. Each component should perform a very limited amount of the task and should be able to perform independently up to a large extent.

• Scalability and extensibility: The component should be able to added or removed dynamically. For example. New functionalities (i.e. components) should be able to be added without altering the ex-isting components (e.g. Open Services Gateway initiative). The component needs to be developed according to standards across the solutions, which improves scalability and extensibility (e.g. plug-in architectures).

• Application programming interface (API): All the functionalities should be available to be accessed via a comprehensive easy to learn and easy to use APIs. This allows the incorporation of different so-lutions very easily. Further, APIs can be used to bind context management frameworks to applica-tions. Interoperability among different IoT solutions heavily depends on APIs and their usability.

• Debugging mechanisms and tools: Debugging is a critical task in any software development process. In the IoT paradigm, debugging would be difficult due to the exponential number of possible alterna-tive interactions. In order to win the trust of the consumers, the IoT should prove its trustworthi-ness. Integrated debug mechanisms inbuilt into the framework will help to achieve this challenge. For example, the justifications behind the results produced by the reasoners should be available to be evaluated to find possible inaccuracies so further development can be carried out. Some initial work in this area is presented in the Intelligibility Toolkit (Lim & Dey 2010).

• Automatic context life cycle management: Context-aware frameworks should be able to be under-stood by the available context sources (i.e. physical and virtual sensors), their data structure, and au-tomatically built internal data models to facilitate them. Further, raw context needs to be retrieved and transformed into appropriate context representation models correctly with minimum human in-tervention.

• Context model independence: Context needs to be modelled and stored separately from context-aware framework related code and data structures, which allows both parts to be altered inde-pendently.

• Extended, rich, and comprehensive modelling: Context models should be able to extend easily. The IoT will need to deal with enormous amount of devices, and will be required to handle vast amounts of domain specific context. It also needs to support complex relationships, constrains, etc. In an ideal context-aware framework for the IoT, multiple different context representation models should be incorporated together to improve their efficiency and effectiveness.

• Multi-model reasoning: No single reasoning model can accommodate the demands of the IoT. Each reasoning model has its own strengths and weaknesses. An ideal framework should incorporate mul-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 25 2016-09-29

tiple reasoning models together to complement each other’s strengths and mitigate their weakness-es.

• Mobility support: In the IoT, most devices would be mobile, where each one has a different set of hardware and software capabilities. Therefore, context-aware frameworks should be developed in multiple flavours (i.e. versions), which can run on different hardware and software configurations (e.g. more capabilities for server level software and less capabilities for mobile phones).

• Share information (real-time and historic): In the IoT, there is no single point of control. The archi-tecture would be distributed. Therefore, context sharing should happen at different levels: frame-work-to-framework and framework to application. Context model in-dependency has been dis-cussed earlier and is crucial in sharing.

• Resource optimisation: Due to the scale (e.g. 50 billion devices), a small improvement in data struc-tures or processing can make a huge impact in storage and energy consumption. This stays true for any type of resource used in the IoT.

• Monitoring and detect event: Events play a significant role in the IoT, which is complement by moni-toring. Detecting an event triggers an action autonomously in the IoT paradigm. This is how the IoT will help humans carry out their day-to-day work easily and efficiently. Detecting events in real time is a major challenge for context-aware frameworks in the IoT paradigm.

2.5. Theoretical Context Models and Representation

The Context Spaces Theory (CST) was developed by a group of PhD students and researchers led by Prof Arkady Zaslavsky (some are also involved in bIoTope project). CST provides a general context representation and model with a rich theoretical foundation. Context reasoning approaches are limited to the underlying general theory. Models in pervasive computing and later in IoT that have context as a central concept form a foundation that relaxes these limitations, motivating further development of CST. In CST context and situa-tions are modelled in an intuitive way as a multidimensional space. The main concepts are visual-ised/metaphorised as in Figure 4. The basic concepts of CST are presented in (Padovitz 2006),(Padovitz et al. 2004) and (Padovitz et al. 2008).

Context Attributes, which are measurable properties are usually provided by sensors or observations, form the dimensions of the Application Space. Real-life situations are represented as subspaces of the application space, named Situation Spaces. A Context State describes a point that moves through the application space depending on the current values of a corresponding set of context attributes over time. Formally, a situation space is defined as a set of Acceptable Regions for each corresponding context attribute, denoted as 𝑆𝑗 = (𝐴1

𝑗 ,𝐴2𝑗 , … ,𝐴𝑛

𝑗 ). An acceptable region V of a context attribute is a set of elements that satisfy a cer-

tain predicate 𝐴𝑖𝑗 = {𝑉|𝑃(𝑉)}.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 26 2016-09-29

Figure 4. Context Space Theory example representation

The Relevance Function assigns a weight to each context attribute of a situation space, which signifies the relative importance of a particular context attribute to infer a situation. A weight is characterized by 𝑤𝑖 ∈ [0,1] and ∑ 𝑤𝑖𝑛

𝑖=1 = 1 for all weights of one situation space. The Contribution Function assigns a contri-bution degree for each value in an acceptable region for a situation space. In other words, some values of an acceptable region may infer stronger that a situation is occurring than others. The contribution function is denoted as η𝑖𝑆, assigning a contribution level 𝑐 ∈ [0,1] to each value of the acceptable region.

Below two simple examples (Figure 5 and Figure 6) are depicted to demonstrate the concepts. In Figure 5 two attributes of a living room are observed: the number of people present and the noise level. Based on these two context attributes, situations about occurrences in the living room are defined. In Figure 6, situa-tions of a smart fridge are depicted regarding the milk content. Based on the situations based on the amount and the expiry dates recommendations about the fridge content can be modelled. It can be seen that ac-ceptable regions of context attributes are not restricted to numerical values, e.g. the noise level can be clas-sified into levels from “very low” to “very high”.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 27 2016-09-29

CST is not restricted to a single reasoning technique. Instead the Inference Function is based on a placeholder function. The reasoning technique is expected to calculate a Confidence value ∈ [0,1] which is compared to a Confidence Threshold 𝜀𝑖 ∈ [0,1] for a situation space. The inference function is denoted as 𝛾 = (𝜇(𝑥𝑖, 𝑆𝑖, Σ𝑖) ≥ 𝜀𝑖) for a context state 𝑥𝑖, situation space 𝑆𝑖 and a set of functions Σ𝑖 that specify rela-tions between context attributes and situation spaces. A simple possibility to calculate the confidence meas-ure 𝜇 with the concepts discussed takes the weight and contribution function into account, i.e. 𝑐𝑐𝑐𝑐𝑠(𝑥) =∑ 𝑤𝑖 ∗ 𝑐𝑆,𝑖(𝑥𝑖)𝑁𝑖=1 . However, the capabilities of the inference function are much higher. For example, proba-

bility values for sensor uncertainty can be taken into account when calculating the confidence value. Also the well-known Bayesian and Dempster-Shafer reasoning techniques are applied by adopting probability func-tions to the relation between context attributes and situation spaces.

Furthermore, CST defines algebra to specify relationships between situations and to enable logic-based rea-soning. Definitions about relationships of situations include Containment, Overlap and Orthogonal. For ex-ample, the situation “Dinner” contains the situation “Family Dinner” and the situations “Dinner” and “Party” overlap (see Figure 1-2). Situations are orthogonal if they do not overlap.

The situation algebra also allows the composition of situation spaces to form a new, more general situation space. This can be done for different situation spaces representing the same real-life situation but also for situation spaces with a different meaning, enhancing the semantic reasoning capabilities. Additionally com-plex situation statements can be formulated and evaluated. For this, the logical operators AND, OR and NOT are defined.

CST was further extended with context prediction algorithms (Boytsov et al. 2009), proactive adaption (Boytsov & Zaslavsky 2010) and formal verification (Boytsov & Zaslavsky 2011b). Two implementations of CST have been developed, namely ECORA (Padovitz et al. 2008) and ECSTRA (Boytsov & Zaslavsky 2011a). ECORA was developed to provide a general framework for context awareness, capable of handling uncer-tainty and a flexible architecture. The ECSTRA approach was designed to enhance the support of multi-agent based reasoning, the communication of reasoning results and to integrate context prediction as well as pro-active adaptation.

Figure 5. Living Room Scenario

Figure 6. Smart Fridge Scenario

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 28 2016-09-29

Unlike most approaches to situation awareness, CST allows the combination of specification-based tech-niques like formal logic and learning-based techniques like the Bayesian classification to determine situation occurrence. By using geometrical metaphors the theory allows to model context in an insightful way.

2.6. Context quality and utility metrics

In the field of context-aware computing, research on the quality of context is presented below.

Buchholz et al. (Buchholz et al. 2003) suggest five dimensions of context quality: Precision, Probability of Correctness, Trust-worthiness, Resolution, and Up-to-Dateness. They describe the interrelation between Quality of Service, Quality of Device and Quality of Context but do not present a methodology or environ-ment for measuring the proposed quality dimensions. Kim et al. (Kim & Lee 2006) also add the dimensions Accuracy, Completeness, Representation Consistency, and Access Security. In their work, the authors pro-vide formal definitions on how to calculate accuracy and completeness.

Manzoor et al. (Manzoor et al. 2008) provide metrics for the context quality dimensions Up-To-Dateness, Trust-Worthiness, Completeness, and Significance as functions with co-domain [0,1]. However the selection of the dimensions they specify, as well as the interpretation, are driven by their illustrated scenario of a flood warning system. Therefore, e.g., the definition of the dimension Trust-worthiness by the physical dis-tance between sensor and measured object (i.e. a form of correctness) seems to be less generalizable.

Bu et al. (Bu et al. 2006) use three “parameters” for context quality: Delay Time, Context Correctness Proba-bility, and Context Consistency Probability. For measuring context quality, they use an ontology to describe situations (e.g., where a person is located), which enables for reasoning on this context information. The situations and facts expressed in their ontology are also linked to metadata (e.g., last updated, frequency). Bu’s approach supports the detection of inconsistencies based on ontology axioms like, for instance, disjint-ness of classes.

After investigating the identified dimensions of context quality, it has been suggested that the problem of context quality is part of the greater field of data quality. In the latter area, an extensive amount of related work exists, approaching the problem from multiple viewpoints (e.g., technical or process-centred). On the technical level, data quality maintenance and measurement solutions are central components of Relational Database Management Systems (RDBMS) and document storage systems depend on the implementation. In RDBMS consistency with the data model is ensured, e.g., by strict type enforcement and triggers (e.g., delete cascades) to provide data consistency for each transactions. For XML-based document stores, conformance against a specific schema can be checked to ensure all needed data is present for an object. It is common practice to use query languages like SQL or Xquery for finding “suspicious” patterns in existing datasets.

However, most of the context quality dimensions listed above are hard to assess without further knowledge on the circumstances of their collection. This information may also be incomplete and the types and units (what is measured in what unit) are subject to change, especially in large-scale distributed heterogenic sys-tems such as the one developed within the bIoTope project. Therefore, a flexible and extensible model for capturing context information and the aspects of data collection (e.g., network of trust) is desirable. In the field of Semantic Web technologies, open and extensible data models using standardized vocabularies are proposed for integrating data of multiple origin and quality. As already proposed by Bu (though not solely based on RDF or OWL), using ontologies and reasoning to finding inconsistencies in context quality is a feasi-ble approach. Especially the problem domain of ontology and vocabulary quality (covering both A-Box and T-Box data) has been extensively covered. There exist a large number of tools and methodologies (Poveda-Villalón et al. 2012)(Tartir et al. 2005)(Arpinar et al. 2006)(Debattista et al. 2015)(Kontokostas et al. 2014) to assess data quality which can potentially be applied to the area of context quality in the bIoTope project.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 29 2016-09-29

The quality of the context data is a fundamental issue since it can compromise the correctness of adaptation operations. Consequently, the emerging notion of Quality of Context (QoC) – usually defined as the set of parameters that express quality requirements and properties for context data (e.g., precision, freshness, trustworthiness...) – is overwhelming important to control and manage all the possible context inaccuracies (Buchholz et al. 2003)(Bellavista et al. 2012). Delving into finer details, several works studied both context quality parameters and their effects on the context data distribution. In (Manzoor et al. 2009) authors asso-ciate context data with four QoC parameters: i) up-to-dateness to deal with data aging; ii) trustworthiness to rate the belief we have in context correctness; iii) completeness to consider that context data could be par-tial and so incorrect; and iv) significance to express differentiated priorities, while in (Neisse et al. 2008) the author presents considers three QoC parameters: i) up-to-dateness, (ii) precision, (iii) resolution, and exploit a standard ISO vocabulary for measurements to define their own framework. Several authors presented their own QoC framework, also introducing and using the same concepts with different names. However, despite these differences, a common thought can be highlighted: QoC is not requiring perfect context data, such as all data with the highest possible precision and up-to-dateness, but having and maintaining a correct estimation of the data quality. In fact, if the context data distribution is not aware of data quality, possible service reconfigurations could be completely misled by low quality data. To measure data quality based on qualitative and quantitative criteria, several well-known Data Quality (DQ) and/or Information Quality (IQ) frameworks1 have been proposed over the last decades (Krogstie et al. 1995)(Kahn et al. 2002)(Batini et al. 2009). Since those key dimensions are still valid and considered in the literature (Batini et al. 2009), we summarize them in Table 1 and argue that multi-criteria decision-making (MCDM) models/frameworks should be developed in bIoTope so as to be able to both (i) deal with multiple, conflicting and incompatible criteria, and (ii) involves human participation, judgments and preferences when making decisions. Such frameworks shall be developed based upon well-known MCDM techniques such as AHP, TOPSIS, ELECTRE and PROMETHEE (Vaidya & Kumar 2006)(Behzadian et al. 2012)(Mardani et al. 2015).

Table 1. IQ (Information Quality) Dimensions (Kahn et al. 2002)

IQ Category Attribute Definition

Intrinsic Accuracy The extent to which information is correct and reliable

Objectivity The extent to which information is unbiased, unprejudiced, and impartial

Believability The extent to which information is regarded as true and credible

Reputation The extent to which information is highly regarded in terms of its source or content

Accessibility

Access The extent to which information is available, or easily and quickly retrievable

Security The extent to which information is available, or easily and quickly retrievable

Contextual

Relevancy The extent to which information is applicable and helpful for the task at hand

Value-Added The extent to which information is beneficial and provides advantages from its use

Timeliness The extent to which information is sufficiently up-to-date for the task at hand

Completeness The extent to which information is not missing and is of sufficient breadth and depth for the task at hand

Amount of data The extent to which the volume of information is appropriate for the task at hand

Representational Interpretability The extent to which information is in appropriate languages, symbols, and

1 Terms “data” and “information” are often used synonymously, although managers describe information as data that has been processed and enriched in some manner but, unless specified otherwise, we will use “information” interchangeably with “data”.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 30 2016-09-29

units, and the definitions are clear

Ease of understanding The extent to which information is easily comprehended

Concise representation The extent to which information is compactly represented

Consistent representation The extent to which information is presented in the same format

In addition to this notion of QoC, extremely focused on data quality but having a significant – if not the big-gest – impact on QoC, recent research has recognized the approach of introducing the quality of the context data distribution (e.g., data delivery time, reliability...) to ensure the availability of the context data with the right quality, in the right place, and at the right time (Bellavista et al. 2012) (Perera et al. 2014). In other words, if Quality of Service (QoS) permits service consumers and service providers to negotiate their re-quirements at acceptable service levels by considering the network available underneath (Tanenbaum 1996). QoC has to consider the quality of both the exchanged context data and the distribution process to ensure user satisfaction. Consequently, (Bellavista et al. 2012) propose a broader QoC definition, at the same time dealing with both the quality of the context data (e.g., relying IQ dimensions as introduced in Table 1) and of the context data distribution, as summarized in Table 2.

To summarize the above: we believe that the definition and evaluation of QoC should pay a particular atten-tion to data quality-related criteria (cf. Table 1) as well as context data distribution-related criteria (cf. Table 2). In this respect, novel QoC assessment frameworks should be investigated and developed in bIoTope, e.g. based on MCDM techniques, so as to be able to turn quantitative and qualitative criteria and/or human preferences into meaningful QoC levels.

Table 2. Context data distribution Dimensions (Bellavista et al. 2012)

IQ Category Attribute Description

Representation General models Offer a wide design space to enable the specification and the representation of any known application domain

Domain-specific models Data belonging to a specific vertical domain

No model Do not address data representation aspects

Processing Context Data History Possibility of maintaining all relevant past events and retrieving the history of a particular context data

Context Data Aggregation Provide all the fusion and merging operations capable of managing different context data (e.g., Logic-based or Probabilistic reasoning-based)

Context Data Filtering Time-based or Change-based

Context Data Security Include all mechanisms to grant privacy, integrity, and availability of data

Dissemination

Direct access

Flooding-based Operations that reach all the nodes contained in a particular scope (e.g., the entire network, the one-hop neighborhood in an ad-hoc network...), and are typically complete within that scope

Selection-based Selection-based algorithms are typically organized on two phases: (i) they deterministically build dissemination backbones by using context data sub-scriptions; (ii) data dissemination takes place only over the backbones, and is limited by granting that context data reach only interested nodes.

Gossip-based Disseminate data in a probabilistic manner by letting each node resend the data to a randomly-selected set of neighbors. Gossip-based protocols can be classified in two broad categories: context-oblivious and context-aware.

Routing Overlay

Centralized Architecture Take care of organizing the brokers involved in context data dissemination. Centralized architectures are usually adopted in conjunction with fixed wireless infrastructures at the network deployment.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 31 2016-09-29

Decentralized Architec-ture

Flat-distributed or hierarchical distributed

Run-time Adaptation support

Unaware The service level neither reaches nor influences run-time adaptation sup-port strategies

Partially-aware There is more collaboration between the service level (supplying profiles that describe the required kind of service) and the run-time adaptation support strategies (modifying context data distribution facilities to meet those requests)

Totally-aware The run-time adaptation support does not perform anything on its own, and it is the service level that completely drives reconfigurations

2.7. Context and Semantic Technologies

Nowadays computing is pervasive, anywhere and any-time, leading to a profound impact on everyday life. An IDC study (Adshead Antony 2014) predicts that the number of connected objects is approaching 200 bil-lion todays with 7% (14 billion) already connected to and communicating over the internet. Most of these objects automatically record, report and receive data. Although the volume of these IoT data currently rep-resents only 2% of the world’s data, the same study reports that by 2020 it will increase up to 10%.

However, pervasive computing as well as IoT face the challenge of how to model and reason on such mas-sive amounts of data and how to facilitate sharing and interoperability across heterogeneous systems and applications. For example, how can an intelligent traffic control system effectively use pollution data moni-tored in a city, in order to design a pollution-free route? Or how can a smart home energy system meaning-fully use traffic information, in order to predict when a user will arrive home? Consequently, there is a press-ing need for open and standards-based representations that will facilitate integrating information of hetero-geneous types and modalities, as well as communicating and exchanging information between devices and components (Ye et al. 2015)(Ye et al. 2007a).

A suitable solution lies in Semantic Web (SW) technologies (Berners-Lee et al. 2001), which aim to bring to the table the ability to formally capture intended semantics and to support automated reasoning, supporting sharing, integration and management of information from heterogeneous sources. These capabilities satisfy perfectly all those common requirements in pervasive, sensor-driven and adaptive computing environments mentioned above. Via explicitly rendering meaning, the Semantic Web tries to facilitate data exchange be-tween systems and components in an open, extensible manner, maintaining semantic clarity across applica-tions. SW technologies have demonstrated to successfully address several pervasive computing concerns in a number of small-scaled and targeted applications, such as representing complex sensor data, recognising human activities and modelling and querying location data across heterogeneous coordinate systems. Addi-tionally, the use of ontologies elegantly supports the cooperation of data sources within an open system, while ontological reasoning proves useful in manipulating structured conceptual spaces (Bettini et al. 2010)(Ye et al. 2007a).

2.7.1. Resource Description Framework (RDF)

The Resource Description Framework (RDF) provides a directed graph formalisation, with nodes represent-ing resources and arcs representing properties. It provides a basic vocabulary for dividing RDF resources into classes and introduces subClass and subProperty for capturing relations between classes and properties at varying levels of abstraction. On the other hand, OWL, as discussed later, provides a richer ontology lan-guage that supports expressing functional, transitive and inverse properties, equivalent properties and clas-ses, and cardinality restrictions on the structure of class members. For sensor-driven systems, the benefits of these technologies emerge directly from their formality. RDF’s use of Uniform Resource Identifiers (URIs) in

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 32 2016-09-29

identifying concepts and properties, combined with OWL’s support for modelling equivalent classes and properties, allows determining whether lexically identical terms share the same meaning, or if two lexically different terms are synonyms or not (Ye et al. 2015). This formality has several advantages:

• there is no single authority responsible for engineering ontologies or producing data, • entities may be described by combining concepts from different ontologies, • combining both ontologies and data from multiple sources is straightforward, • domain-neutrality, • supports the representation of information across disparate application domains, unifying all data

under a single model, and • data across different components in a system and across different systems is seamlessly merged

(Rosi et al. 2011).

This can be contrasted to traditional database schemata, where terms and relations have no prescribed se-mantics, and XML Schema, which is concerned with the hierarchical structure of data elements and not with capturing the underlying relations (Ye et al. 2015).

2.7.2. SPARQL – Linked Open Data

Technologies for managing RDF stores exist in the form of SPARQL3 and SPARQL Update. SPARQL is a query language and a protocol for accessing RDF designed by the W3C RDF Data Access Working Group. But how can you find and manipulate the data you need within RDF graphs? As a query language, SPARQL is "data-oriented" in that it only queries the information held in the models; there is no inference in the query lan-guage itself. SPARQL does not do anything other than take the description of what the application wants, in the form of a query, and returns that information, in the form of a set of bindings or an RDF graph. SPARQL supports queries consisting of triple patterns, conjunctions, negations and disjunctions, while SPARQL Up-date supports the conditional insertion and removal of triples from an RDF store (Ye et al. 2015).

Similarly, to relational databases, there exist various tools supporting RDF-graph level manipulations or providing services to map RDF concepts to programming language type systems. Some representative exam-ples are: Jena (McBride 2002), OWL API (Horridge & Bechhofer 2011) and RDFReactor (V�lkel 2006). A fur-ther RDF benefit is that an environment model can build upon, and interlink with, existing ontology-based domain knowledge through the principles of Linked Data — a set of best practices for exposing, sharing, and connecting pieces of knowledge on the SW (Bizer et al. 2009). The premise of Linked Data is that by using URIs and RDF to link to data sources, a semi structured web of ontologically-represented data emerges that can be navigated and explored. Thus, Linked Open Data provides a structured means for accessing data from existing ‘non-pervasive’ sources and integrating it with existing RDF representations (or via an RDF wrapper for legacy data sources). This has particular potential for bootstrapping systems with the knowledge held by myriad social information sources on the web (Ye et al. 2015)(Stabeler et al. 2009)(Rosi et al. 2011).

2.7.3. OWL and OWL 2

In 2004, the Web Ontology Language (OWL1) became a W3C recommendation, paving the way for a new generation of state of the art tools (ontology editors and reasoners) and the proliferation of ontology-based applications in several domains. Formally founded on Description Logics (DL) (Baader et al. 2003), OWL is endowed with expressive representational constructs that allow capturing complex knowledge. At the same time, OWL avails of well-defined DL reasoning services for affording automated reasoning support. These advantages furnish OWL with a variety of appealing features within the context of pervasive applications. For example, in OWL one can effectively model and reason over taxonomic knowledge. This is a desirable fea-ture in pervasive applications, where there is the need for modelling information at different levels of granu-larity and abstraction that will drive the derivation of further successively detailed contexts. Similarly, OWL supports consistency checking, another useful feature when dealing with imperfect context information

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 33 2016-09-29

coming from multiple sources. OWL’s design is strongly influenced by Description Logics (DL) (Ye et al. 2015)(Baader et al. 2003).

DLs are a family of knowledge representation formalisms characterised by logically grounded semantics and well-defined reasoning. The main building blocks are concepts representing sets of objects (e.g. Person), roles representing relationships between objects (e.g. worksIn), and individuals representing specific objects (e.g. Alice). Starting from atomic concepts, such as Person, arbitrary complex concepts can be described through a rich set of constructors that define the conditions on concept membership. For example, the con-cept ∃ hasFriend. Person describes all those individuals that are friends with at least one person (Ye et al. 2015).

OWL comes in three dialects of increasing expressive power: OWL Lite, OWL DL and OWL Full. The first two languages can be considered as syntactic variants of the SHIF (D) and SHOIN(D) DLs, respectively. The third and most expressive language is designed to provide full compatibility with RDFS. It neither imposes any constraints on the use of OWL constructs, nor lifts the distinction between instances (individuals), properties (roles) and classes (concepts). However, the price for this high degree of expressiveness is the loss of decida-bility that makes the language difficult to implement. As a result, the focus lies on the two decidable dialects, and particularly on OWL DL. Nevertheless, despite the rich primitives provided for expressing concepts, OWL DL has often proven insufficient to address the needs of practical applications (Motik et al. 2009). Further-more, OWL can model only domains where objects are connected in a tree-like manner (Sirin et al. 2007). This constraint can be restrictive for real-world applications, including the pervasive domain that requires modelling more generic relational structures (Ye et al. 2012). Responding to these as well as to other draw-backs concerning the use of OWL in different application contexts, the W3C working group has introduced OWL 2 (Grau et al. 2008). OWL 2 (equivalent to the SROIQ(D) DL) is a revised extension of OWL, now com-monly referred to as OWL 1 (Ye et al. 2015).

OWL 2 extends OWL 1 with qualified cardinality restrictions; hence for example, one can assert that a social activity is an activity that has more than one actors: SocialActivity⊑Activity ⊓ ≥2 hasParticipant.Person. Fur-thermore, it is possible to define properties to be reflexive, irreflexive, transitive, and asymmetric, and to define disjoint pairs of properties, thus providing extended support for capturing mereology relations (i.e. the study of part-whole relations). Three profiles, namely OWL 2 EL, OWL 2QL and OWL 2 RL, trade portions of expressive power for reasoning efficiency, targeting different application scenarios. Another prominent OWL 2 feature is the extended relational expressiveness provided through the introduction of complex property inclusion axioms (property chains). To maintain decidability, a regularity restriction is imposed on such axioms disallowing the definition of properties in a cyclic way. Hence, one can assert the inclusion axi-om locatedIn◦ containedIn ⊑ locatedIn, making it possible to infer that if a person is located, for example, in the EngineeringDepartment of the University, then she is located in the University as well (Ye et al. 2015).

2.7.4. Reasoning

Besides formal semantics, DLs come with a set of powerful reasoning services that are based on efficient, sound and complete reasoning algorithms, with well-understood computational properties (e.g. tableaux-based algorithms (Baader & Sattler 2001)). State of the art implementations include Racer (Haarslev & Möller 2003), Hermit (Motik et al. 2009), Pellet (Sirin et al. 2007) and Fact++ (Tsarkov & Horrocks 2006). DL reasoning services typically include subsumption, satisfiability, consistency, instance checking and realisa-tion. Through subsumption one can determine whether concept A subsumes concept B, i.e. whether de-scription of A is more general than the description of B, deriving the implicit taxonomic relations among con-cepts, for example that Room subsumes OccupiedRoom (Ye et al. 2015).

Satisfiability checking leads to identifying concepts for which it is impossible to have members under any interpretation; a sample unsatisfiable concept, though trivial, is OccupiedRoom ⊓ ¬ OccupiedRoom. Con-sistency checking allows identifying whether the set of assertions comprising the knowledge base is admissi-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 34 2016-09-29

ble with respect to the terminological axioms. For example, ifEmptyRoom and OccupiedRoom are asserted as disjoint concepts, then the presence of both OccupiedRoom(kitchen)and EmptyRoom(kitchen) leads to inconsistency (Ye et al. 2015). Instance checking denotes the task of determining whether a specific individ-ual is an instance of a given concept, whereas realisation returns all concepts from the knowledge base that a given individual is an instance of.

Falling under the Classical Logics paradigm, reasoning in DL (and hence in OWL) adopts the open-world as-sumption. Intuitively, open-world semantics assumes that we do not have complete information about the world, providing an elegant way of modelling incomplete information. This assumption is well-suited for sensor-driven systems, where information may be incomplete due to sensor inaccuracies or imperfect ob-servations. For example, if the only available knowledge regarding the residents of a house is the assertion livesIn(Alice,house), we cannot deduce based on it alone that no one else lives in the house. In contrast, formalisms adhering to the closed-world assumption make the common-sense conjecture that all relevant information is explicitly known, so all unprovable facts should be assumed not to hold. In our example, this would lead to the conclusion that Alice is the sole resident of this house (Ye et al. 2015).

2.7.5. Combining ontologies and rules

To achieve decidability, OWL trades expressiveness for reasoning efficiency. The tree-model property, men-tioned above, is one such example; as a result, it is not possible to describe classes whose instances are re-lated to an anonymous individual through different property paths. To leverage OWL’s limited relational expressiveness and overcome modelling shortcomings that OWL alone would insufficiently address, research has been devoted to the integration of OWL with rules. User-defined rules on top of the ontology allow ex-pressing richer semantic relations that lie beyond OWL’s expressive capabilities and couple ontological and rule knowledge.

A proposal towards this direction is the Semantic Web Rule Language (SWRL) (Horrocks et al. 2004), in which rules are interpreted under the classical first order logic semantics. Via allowing concept and role predicates to occur in the head and body of a rule, SWRL maximises the interaction between OWL and rule compo-nents, but at the same time renders the combination undecidable. To regain decidability, proposals have explored syntactic restrictions on rules (Rosati 2006) (Motik et al. 2005) as well as their expressive intersection (Grosof et al. 2003). The DL-safe rules introduced in (Motik et al. 2005) impose the application of rule semantics only over known individuals. It is worth noting that, in practice, DL reasoners providing support for SWRL actually implement a subset of SWRL based on this notion of DL-safety. Parallel to these efforts, a highly challenging and active SW research area addresses the seamless integration of open and closed world semantics (Ye et al. 2015).

Taking a different perspective, a number of approaches have been investigated combining ontologies and rules based on mappings of a subset of the ontology semantics on rule engines. For instance, (ter Horst 2004) defines a weakened variant of OWL Full, according to which classes can also be instances and are ex-tended to apply to a larger subset of the OWL vocabulary. Inspired by the previous approach and DLP (Grosof et al. 2003), the semantics of the OWL 2 RL profile is realised as a partial axiomatization of OWL 2 semantics in the form of first-order implications, known as OWL 2 RL/RDF rules. Especially for the case of sensor driven systems in the pervasive domain, expressing rich semantic relations is essential. The reason lies in the fact that the derivation of high-level knowledge from low-level sensor data requires relational structures that capture the interrelation of various pieces of information in terms of time, location, actors and resources (Ye et al. 2015).

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 35 2016-09-29

2.8. Complex events and rule engines. Situation as a complex event

Events in our life shape our thinking, beliefs and overall attitude. Based on this fact, the efficient modelling, handling and inference on complex events makes it a very significant challenge in pervasive computing. Some examples of incoming data/events:

• API of your CRM (upon new lead creation) • ODBC to a remote server • File changes in your Cloud Storage Service • Someone filling out a form or a business process • A button is pressed in your home automation scheme • Temperature sensors has a new reading • Motion is detected • A new employee is hired or fired

Before going further, a definition of the concept of events will be given, in order to avoid from the beginning any misconceptions inherited by the semi-formal descriptions.

An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. The word event is also used to mean a pro-gramming entity that represents such an occurrence in a computing system.

It is important to understand that according to the previous definition, an event has two meanings. The first meaning refers to an actual occurrence (the something that has happened) in the real world or in some oth-er system. The second meaning takes us into the realm of computerized event processing, where the word event is used to mean a programming entity that represents this occurrence. It is worth noting that a single event occurrence can be represented by many event entities, and also be aware that a given event entity might capture only some of the facets of a particular event occurrence (Etzion & Niblett 2010).

Furthermore, as this is such an important term, it’s worth commenting on three of the phrases used in the definition. The first of these is “system or domain.” In event processing we are chiefly concerned with real-world events–that is, events that occur in real life, such as an order being placed or a plane landing. But the techniques of event processing can also be applied to things that happen in artificial domains such as train-ing simulators, virtual worlds, and similar virtual environments. Next, the definition includes things that are “contemplated as having happened”. It is possible to have events that do not correspond to actual occur-rences. To explain what we mean, imagine a fraud detection system being used in a financial institution. Such a system monitors financial transactions and generates events when it suspects that a fraud is being conducted. These systems can generate false positives, so further investigation is usually required before you can be sure whether a fraud has actually taken place or not. Finally, the definition contains the phrase “programming entity”, but it should be clear that it is not necessarily meant that we talk about an object as defined in object-oriented programming. In some contexts, events are represented as OO objects, but they can also appear in other forms, such as records in SQL or noSQL databases, structures in a language like C, or messages transmitted between systems. Therefore, it has been chosen to use the more general expression programming entity in the event definition (Etzion & Niblett 2010).

2.8.1. Rule Engines

The term “Rule Engine” is quite ambiguous in that it can be any system that uses rules, in any form that can be applied to data to produce outcomes. A rule engine hosts the rules you have written and takes actions according to these rules. For instance, Drools represents one approach for Business Rules Management, while IFTTT represents yet another. In general, they allow the generation of high-level context information using low-level context. More specifically, Rule-based programming is part of a long tradition in computing

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 36 2016-09-29

called production systems (Boyer & Mili 2011). A production system is typically defined in terms of three components:

1. A set of rules, or ruleset 2. A database 3. An interpreter

The ruleset is an unordered set of rules, consisting of expressions of the type LHS RHS, where LHS and RHS stand for left-hand side and right-hand side, respectively. The database consists of a (typically) unor-dered set of elements, and the interpreter is the processor that applies the rules to the database. The pro-cess goes as follows: the interpreter matches the LHS parts of the rules of the ruleset against the database, and if a match is found for a particular rule, that rule is executed, which will typically modify the database. This process repeats as long as matches can be found, and terminates only when no LHS of a rule matches the current state of the database (Figure 1) (Boyer & Mili 2011). What distinguishes these systems?

• The structure of objects of the database. These can range in complexity from simple symbols (strings) to stateful, history-aware objects.

• The structure of the rules, which can range in complexity from simple rewriting (symbol transfor-mation) rules to having access to the full power of a modern programming language in both the LHS and RHS.

• The functioning of the interpreter, and, more specifically, the algorithm and data structures used by the interpreter to control the evaluation and execution of the rules.

Figure 7. The typical production system process cycle: (1) scan, (2) match, and (3) execute

Figure 7 shows a simple production system where the database consists of a set of strings (symbols) and the rules consist of string transformation (or rewriting) rules. Furthermore, rules engines are the most popular method of reasoning according to Figure 8. Recently, rules have been heavily used when combined with ontological reasoning (Horrocks et al. 2004)(Zhou et al. 2009)(Ke??ler et al. 2009). MiRE (Choi et al. 2008) is a minimal rule engine for context-aware mobile devices. Most of the user preferences are encoded using rules. Rules are also used in event detection (Barbero et al. 2011)(Teymourian et al. 2009). Rules are expected to play a significant role in the IoT, where they are the easiest and simplest way to model human thinking and reasoning in machines. PRIAMOS (Konstantinou et al. 2007) has used semantic rules to

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 37 2016-09-29

annotate sensor data with context information. Application of rule based reasoning is clearly explained in relation to context-aware I/O control in (Perera et al. 2014)(Terada et al. 2004).

Figure 8. a) Counts of model types used in 109 of 114 reviewed context-aware applications. (Boyer & Mili 2011) (b) Counts for 50 recognition applications; classifiers are used most often for applications that do recognition (Perera et al. 2014)

(Lim & Dey 2010)

2.8.2. Situation as a complex event

Some events are background noise and do not require any reaction, but some do require reaction, and those we call situations. More formally:

A situation is an event occurrence that might require a reaction.

One of the main themes in event processing is the detection and reporting of situations so that they can be reacted to. The reaction might be as simple as picking up the phone or changing the weekly shopping list, or it might be more complicated. If we miss a flight connection there may be several alternative reactions de-pending on the time of the day, the airport where we are stranded, the airline policies, and the number of other passengers in the same situation (Etzion & Niblett 2010).

Ma et al. (Ma et al. 2015) propose OntoEvent, a OWL-based event description language. For describing events, a standard set of properties for expressing, e.g., timing constraints or response actions are defined by OntoEvent. Furhtermore, the authors introduce the notion of “event constructors” which are natural-language patterns that describe relations between events, such as conjunction (concurrent or subsequent) or temporal distance. The approach uses WordNet2 for definition of synonyms and to translate human-readable event descriptions into the OntoEvent ontology. We see natural language processing for the defini-tion of events and their relationship among each other’s as a suitable means to address some of the user interaction challenges we are faced within the bIoTope use cases. However, the work of Ma et al. lacks eval-uation of this approach in a practical setting, which could be one of the future research contributions of the bIoTope project.

Segers (Segers et al. 2015) et al. developed the Event and Situation Ontology (ESO) that is used to aid extrac-tion of events from natural language text. ESO allows to model pre and post conditions of events, assign roles to events and allows reasoning for deriving situations from pre and post conditions. The authors de-scribe the utilization of their ESO approach for extracting events from a newsfeed in the automotive area in

2 https://wordnet.princeton.edu/

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 38 2016-09-29

conjunction with NLP methods. However, they do not provide an evaluation setting and how usage of ESO performs in this practical use case. Nevertheless, as already noted above, Ontology-based approaches in combination with methods from NLP will be considered when researching user interaction methods in, e.g., smart home or mobility use cases.

2.9. Theoretical approaches to describing and modelling situations

Sensor data occur in large volumes, in different modalities, and are highly inter-dependent, dynamic and uncertain. On the other hand, situations are in a rich structural and temporal relationship, and they evolve in diffuse boundaries. In addition, the complexity in domain knowledge and applications makes the problem of modelling situations a very challenging task. In representation, logical primitives should be rich enough to capture features in complicated sensor data (e.g., acceleration data), domain knowledge (e.g., a spatial map or social network), and different relationships between situations. Also a pervasive computing system is as-sumed to be highly dynamic in the sense that it might introduce new sensors that yield new types of context, so the logical primitives should be flexibly extensive; that is, new primitives will not cause modifications or produce ambiguous meanings on existing ones (Ye et al. 2012).

However, although the notion of ‘‘situation awareness’’ is becoming an urgent need in the era of the IoT, this term has been used with a number of different meanings, and this inevitably leads to confusion. For this reason, a brief overview of some of the most common interpretations of this concept is provided in order to pave the way for the presentation of main theoretical approaches towards its formal modelling.

Figure 9. Situations and Perception

Figure 9 shows four planes, each referring to a different level of abstraction. The bottom layer shows the World, i.e., the physical (or abstract) world that is the subject of some inquiry. Although this figure suggests that the World is associated with a geographical region, it actually does not have to be so. It is just a symbol-ic depiction of the things that give rise to a situation. These can be either physical or conceptual things, or both. To the right of the World plane, a human head depicts the fact that situation awareness actually takes

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 39 2016-09-29

place in the human’s brain. The human observes some aspects of the World, and the human gets inputs from the computer, as shown in the figure. The next layer is denoted as ‘‘Perception.’’ The dots on this plane represent objects from the World that are observed through sensors and are represented in computer memory. The arrow from the World plane toward the radar icon represents the sensory process, which then feeds the computer, which in turn generates the object representations. The label ‘‘Perception’’ represents the fact that this kind of representation is compatible with the output of the Perception process in Endsley’s model (Endsley 2000). In some discussions of situation awareness, this kind of representation is considered to be the ‘‘situation,’’ i.e., some people consider the situation to be the knowledge of all the objects in a specific area, and possibly their kinematic states (Kokar et al. 2009). This is not how this term is defined in dictionaries. For instance, Webster Dictionary (Anon n.d.) defines ‘‘situation’’ as

the way in which something is placed in relation to its surroundings.

Thus the emphasis in the dictionary definition is on relationships. The relations are viewed from the point of view of a thing, and they capture how other things in the surroundings of that thing are related to it; the thing is the focal object of the situation. The JDL model (Steinberg et al. 1999), which is a model of data fu-sion consisted of the six following levels:

• Level 0: Source Pre-processing/subject Assessment • Level 1: Object Assessment • Level 2: Situation Assessment • Level 3: Impact Assessment (or Threat Refinement) • Level 4: Process Refinement • Level 5: User Refinement (or Cognitive Refinement)

also recognizes the role of relations as the basic feature of situations:

Situation Assessment: estimation and prediction of relations among entities, to include force structure and cross force relations, communications and perceptual influences, physical con-text, etc.

Even if the JDL Model is often criticized for its implication that the levels necessarily happen in order and also for its lack of adequate representation of the potential for a human-in-the-loop, its definition of Situation Assessment gives a very good description of what is a situation; a description that is adopted as the defini-tion of a situation for the next of the section (Blasch et al. 2006). In Figure 9, this kind of notion of situation is represented by the plane labelled as ‘‘Comprehension.’’ The lines that connect some of the points represent the relations. Again, this is just a view that symbolizes relations. Although the figure shows only lines con-necting pairs of points, i.e., only binary relations, in fact relations can relate more than two objects. Moreo-ver, the same set of objects can be related by many different relations. Note, however, that although the JDL model captures the role that relations play in the definition of ‘‘situation,’ ’it misses the essence of ‘‘aware-ness’’ in its formulation. For instance, the term ‘‘aware’’ provided in Webster’s Dictionary (Anon n.d.) is ex-plained as:

awareness implies vigilance in observing or alertness in drawing inferences from what one experiences.

In other words, a subject is aware if the subject is capable not only of observing some objects (experiences) but also of drawing conclusions (inferences) from these observations. The need for inference comes from the fact that not all information comes explicitly through experience. This is particularly true for relations. While it is typical that information about objects (or at least their properties) can be experienced, or ob-served directly, the relational information must be inferred. This aspect of awareness seems to be part (alt-hough not explicitly) of ‘‘comprehension’’ as defined by Endsley (Endsley 2000). The top layer of Figure 9 shows the plane labeled ‘‘Projection.’’ This layer has a direct relationship with Endsley’s model in which pro-jection is defined as the capability of anticipating future events and their implications (Kokar et al. 2009).

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 40 2016-09-29

The importance of relations and inference for situation awareness can be easily observed in various scenari-os in which humans can be said to be aware (or not). For instance, consider a scenario of watching a game, like American football or baseball, by someone who has never learned the rules and the strategies of these games. Although the person can clearly see where each player is and where the ball is, the person still has no idea of ‘‘what is going on’’ and thus cannot claim to be ‘‘aware’’ of the situation of the game being watched. The main part of being aware is to be able to answer the question of ‘‘what’s going on?’’ As this example shows, in order to be able to do so, one needs to have data pertinent to the objects of interest, some back-ground knowledge that allows one to interpret the collected object data and finally a capability for drawing inferences (Kokar et al. 2009).

The previous analysis becomes fertile ground for introducing the various theoretical attempts to provide a concrete and robust theory of situations. In fact, situation awareness research can be classified by the sub-ject that performs this process – human or computer. For human situation awareness, the model proposed by Endsley (Endsley 2000) has been more or less accepted by the information fusion community. Moreover, this model has been used in various studies as a justification for structuring the computer-supported situa-tion awareness process. While the human situation awareness model has been grounded in various studies of cognitive science, the computer situation awareness process still lacks a more systematic treatment. Moreover, the difference between human and computer processing is that the human situation awareness process needs to be measured and possibly supported, which is the main focus of Endsley’s research, while the computer process needs to be defined and implemented.

Clearly it is necessary to develop unambiguous specifications, designs and implementations of situation awareness processes. One of the trends in this direction that became prevalent in recent years is that of using ontology-based computing as a paradigm on which to develop computer based situation awareness processes (Christopher J. Matheus et al. 2003)(Boury-Brisset 2003)(Homey et al. 2003)(Sycara et al. 2003)(Blasch & Plano 2003)(Chao et al. 2003)(McGuinness 2003)(Nowak 2003)(Christopher J Matheus et al. 2003)(Mieczyslaw M. Kokar & Wang 2002)(Mieczyslaw M Kokar & Wang 2002). Although all of these efforts are based on ontologies as the main representational structure, they lack commonality in the repertoire of concepts used in the analysis and the synthesis of situation awareness processing. Artificial intelligence (AI) has dealt with a notion of ‘‘context’’, which, according to (Akman & Surav 1996), stands for the same con-cept as ‘‘situation’’. This line of AI research was started by McCarthy, cf. (McCarthy 1987) and is still an active research field. The main idea of the AI approach is to introduce a predicate, isp(c,p), that explicitly states the fact that the proposition p is true in the context c (Kokar et al. 2009).

Sowa in his book (Sowa 2000) provides both a historical overview of the AI treatment of context and an ap-proach to representing contexts (situations) in the formalism of conceptual graphs (Sowa 1984) (Sowa J.F. n.d.). Conceptual graphs are patterned upon existential graphs developed by Charles S. Peirce. Similarly to McCarthy’s approach, Sowa introduces a description predicate, dscr(x,p), which captures the fact that the entity x is described by the proposition p. When the entity is a situation, then the proposition p describes that situation. This predicate is then used to state facts that hold in a given situation. Conceptual graphs are representable in a graphical form that is more human friendly than a computer-readable form called Con-ceptual Graph Interchange Form (CGIF).

As described above, the notions of ‘‘situation’’ and ‘‘situation awareness’’ have been formulated by many authors in various contexts. However, one of the most formal and strict, from the mathematical point of view, theories is the Situation Theory developed by Barwise and Perry (Barwise 1981)(Barwise & Perry 1981)(Barwise 1989), which was subsequently extended by Devlin (SAY 1997). Since the concepts of situa-tion theory encompass most of the concepts discussed by Endsley, and since situation theory is described in a more formal language with computer-processable semantics, it is considered as one of the most promi-nent attempts to model situations (Kokar et al. 2009).

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 41 2016-09-29

Barwise and Perry began with the assumption that ‘‘people use language in limited parts of the world to talk about (i.e., exchange information about) other limited parts of the world. They call those limited parts of the world situations. Events and episodes are situations in time, scenes are visually perceived situations, changes are sequences of situations, and facts are situations enriched (or polluted) by language.’’ Devlin stresses that ‘‘the appearance of the word parts in the above quotation is significant. Situations are parts of the world and the information an agent has about a given situation at any moment will be just a part of all the information that is theoretically available. The emphasis on partiality contrasts situation semantics from what was re-garded by many as its principal competitor as a semantic theory, possible worlds semantics (Barwise 1989) (Kokar et al. 2009).

In situation theory, information about a situation is expressed in terms of infons. Devlin states that ‘‘infons are not things that in themselves are true or false. Rather a particular item of information may be true or false about a situation.’’ Infons may be recursively combined to form compound infons by using conjunction, disjunction and situation-bounded quantification. Devlin does not have a term for infons that are not com-pound. We say that such infons are elementary. To capture the semantics of situations, situation theory provides a relation between situations and infons. This relationship is called the supports relationship which relates a situation with the infons that ‘‘are made factual’’ by the situation. In situation theory, it is the agent who establishes such a link. This link is defined by connections that link entities in the world to formal con-structs of the situation-theoretic framework (Barwise 1989) (Kokar et al. 2009). These connections are not part of the formal theory. Thus they cannot be part of any formal theory such as a situation-awareness on-tology. One refers to situations within a formal theory by using abstract situations, although the qualifier ‘‘abstract’’ is usually dropped in most discussions of situation theory, and we will generally do so as well in the following discussion3.

Moreover, Kokar et al. (Mieczyslaw M Kokar & Wang 2002) proceeded one step further and managed to capture the situation theory of Barwise in terms of an OWL ontology. Based on the fact that since the intent of this ontology is to capture most of situation theory, they called it the Situation Theory Ontology, or STO, for short. This direction allows one to express situations in a commonly supported language with computer processable semantics. At the same time, this gives the opportunity to illustrate the formalization with some simple examples, which show the power of that direction. As far as the needed expressivity is concerned, it should be noted that since situation theory requires that one model ‘‘classes as instances’’, it is necessary to use the highest OWL level, OWL Full. Furthermore, while OWL Full is sufficient for nearly all concepts re-quired by situation theory, there are a few that even OWL Full cannot express. Those concepts can be for-malized using a computer-processable rule language compatible with OWL such as RuleML. The concepts expressed in OWL and the ones expressed using rules together form a formal ontology for situation aware-ness. As it was described extensively in the previous sections, the advantage of an ontology based approach to situation awareness is that once facts about the world are stated in terms of the ontology, other facts can be inferred using an inference engine. This is particularly important for situation awareness since it heavily relies on the knowledge of relations. Because there are so many possible relations, it is impractical to expect that procedures could be written for all potential relations (Kokar et al. 2009).

2.10. Context storage, indexing and retrieval

Over the last decade, the concept of Smart City is being converted into mature and prototype applications and services. The number of systems and applications in such areas as Intelligent Transportation Systems (ITS), smart buildings and homes, city security and smart metering continues to grow by virtue of significant achievements in proliferation of various Internet enabled devices, sensor manufacturing and wireless com-munication services (Petrolo et al. 2014).

3 The interested reader can refer to [67] for further information.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 42 2016-09-29

While some parts of the Smart city infrastructure are already implemented, the problem of providing rele-vant and reliable data to applications has not yet been solved. We refer to relevant metadata and annota-tions that describe the raw data as context. Applications that consume context are referred as context-aware applications. We define both these terms in more detail in the following section. Existing context-aware systems are incompatible in the ways they represent and store context. To develop smarter applica-tions we need to provide methods for acquiring context from context producers without being dependent on their particular properties or domains (Antunes et al. 2014).

Data decentralisation is one of the main features of the Internet that adds complexity to the context incom-patibility problem. Smart city applications need to integrate data from different sources like information systems, users’ histories and sensor data. While being used, these systems and applications generate vast amounts of data, which is transferred, processed and stored by service providers and users’ end-points. This Big Data is constantly changing and the volume of data streams is growing, raising the questions of scalabil-ity, performance, interoperability, data format conversion, data discovery and security.

Mostly, modern Smart City systems work in an isolated fashion, having low level of interoperability that lim-its their functionality (Antunes et al. 2014). This leads to the concept of deploying Smart city scale middle-ware systems that will serve a number of agents (city authorities, enterprises, users, sensors, actuators) and provide them with transparent access to all needed context by communicating with similar middleware sys-tems of other companies or organisations.

The idea of an IoT platform, a middleware system that enables various systems to interchange data for mu-tual benefits, is widely discussed in academic and research community (Maia et al. 2007)(Wagner et al. 2011) and a number of problems/questions are raised. One of these emerging questions is finding ways for struc-turing, modelling, storing, indexing and retrieving context from large datasets that are generated by differ-ent kinds of virtual and physical sensors and used for analytical, predictive and other purposes.

The process of storing and retrieving large datasets is not new and is well studied in both relational and NoSQL paradigms. As we move from internal systems owned by one organization to a system of systems (SoS) (Maia et al. 2007), we see that each system, even in one domain of knowledge, uses different struc-tures for representing information. Integrating exterior services into large systems usually lead to the devel-opment of drivers, protocols, parsers, ETL procedures and tests. Another problem is that the information is often needed in a higher-level contextual form, rather than in a raw form. For example, a smart home sys-tem needs to be notified that the user left work and is driving home, so it is time to switch on the air-conditioning system. At the same time, the smart home system is not receiving GPS data from the user’s smartphone and therefore can reason over this raw information. However, the smart home system may request user movements and location via a service request. Also, raw context can be used for a number of other applications like building a dynamic map of city traffic, timetable management, etc. The solution to both problems is providing Context-as-a-Service (Wagner et al. 2011) (Moore et al. 2014) by delivering the context in an interoperable form and at the level of the abstraction that is needed by different applications.

Development of novel efficient scalable methods for reasoning, aggregating, representing, storing and re-trieving context on middleware side can bring us closer to seamless system interoperability, enabling the possibility for faster creation of more context-aware Smart City applications.

In this section, we identify and discuss requirements of a context storage middleware. These requirements can have sufficient differences with context representation that is optimal in ubiquitous/mobile computing scenarios because of the significant difference in computing power, value and veracity of data streams and durability expectations.

Endpoint applications need to acquire context from various sources. The only way for these applications to get context about the outside world is to communicate with some middleware, as communication with enormous numbers of sensors is not feasible due to many restrictions, such as network bandwidth, energy

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 43 2016-09-29

efficiency, access control and complexity of task. The middleware receives requests for context from clients and tries to fulfil these requests. For this, the middleware platform should either store all the information inside or query some other systems for retrieving the needed data. The first approach is disc space consum-ing, but it can improve performance. For example, modern search engines use indexed information for providing search results. The second approach is time-consuming, as querying other systems and especially mobile sensors and devices can be a time-consuming process due to networks delays and slow response time or inaccessibility of mobile data sources. The IoT middleware may combine both approaches that will result in a better balance of disc space consumption, performance and data relevance.

We have identified the following requirements of a context storage middleware:

• Disk based – although in-memory systems are getting more attention nowadays, the amount and variety of data sources make processing not possible without keeping data persistently on disk.

• Scalability - it is hard to predict the amount of stored information, but in case of a Smart City it would not be possible to provide the storage service by one server node. This means that the pro-posed solution must be horizontally scalable.

• High Availability – the storage should not have a single point of failure (SPoF). • Structural freedom – storage must be able to store structured data without applying restrictions on

its structure. • Interconnected entities – in some cases storage must facilitate the means for storing highly inter-

connected data (e.g. relations of people, organizations, transport, infrastructure etc.) and effectively running queries over such data.

• Veracity – different sources can supply information that can be conflicting or un-certain and there should be a way to store all variants of incoming data with annotations about the identity and trust level of the originator and rank of the suggestion. Context of the querying side must be treated re-spectively during responding to the query.

• Large amounts of sensory data – sensors and other Internet enabled devices generate large number of time series events of similar but not the same structure.

• Ontology support – a number of research projects (Perera et al. 2014) model data using ontological principles as it is a good way for modelling the domain interconnections and facilitating reasoning over data. However, this approach does not seem to be suitable for storing large amounts of raw da-ta and low-level context.

• Fast information retrieval and rich indexing capabilities – performance is the key requirement for context delivery in smart cities applications. This highlights the need for efficient indexing of stored context.

• Fast writes – streams of sensor readings must be written on disk without long queues and expensive rebuilding of indexes.

• Geospatial data – many of Smart City applications are highly dependable of geo-spatial context, so the middleware storage must be able to provide effective indexing possibilities for this type of con-text.

2.10.1. Various approaches to CAP theorem

Traditionally, one of the main principles of database management systems is ACID – Atomicity, Consistency, Isolation and Durability. According to the CAP theorem, we cannot have consistency, availability and parti-tioning tolerance in one system at the same time. As mentioned, the context coming from different sources can already be uncertain and conflicting. That means the middleware solution in some cases can afford lack of transactional support and consistency in favour of high availability and partitioning, as the requirements for horizontal scalability and availability have higher priority. At the same time some parts of middleware system can have strong requirements for consistency and these requirements must be satisfied. After ana-lysing the requirements for the middleware storage system it becomes clear that fulfilling all the require-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 44 2016-09-29

ments with one existing solution is not feasible. The variety of data processing approaches leads us to the idea of hybrid storage architecture.

One of the recent trends in software development is polyglot persistence (Kaur & Rani 2015) (Prasad & Avinash 2014). It means systems no longer try to accomplish all tasks using single data storage, but rather use different technologies to store data where each technology provides certain capabilities. In (Kaur & Rani 2015) a use case of PolygotHIS, a health information system using three different databases is presented. The system uses relational database (PostgreSQL) for storing structured transactional data, document-oriented datastore (MongoDB) for storing schema-less documents and graph datastore (Neo4J) for storing data containing relationships. PolygotHIS implements various software agents to achieve interoperation between involved data stores. In (Prasad & Avinash 2014) polyglot persistence approach is used to Enhance Performance of the Energy Data Management System (EDMS). EDMS uses MySQL, MongoDB and OpenTSDB (Anon n.d.) that runs over HBase.

In the next section we briefly describe the most popular approaches for context modelling and representa-tion with respect to storage considerations. We also mention the most popular open-source software pro-jects in each area.

2.10.2. Existing context representation and storage technologies

An earlier discussion of storage technologies has appeared in the deliverable D4.1 and is extended and dis-cussed in this section for consistency and self-sufficiency.

Key-Value is a popular NoSQL modelling and storage technique that represents any information with a key association and retrieves it by the given key effortlessly and quickly. The key-value modelling is the fastest, easiest and noticeably scalable way of retrieving information from storage. However, standards, schema, verification and relations between entities are not offered. The most important point from our perspective is the absence of means for searching inside values, making it possible to request data only by key.

Document-oriented or Mark-up scheme tagged encoding is another NoSQL technique for representing con-text. It is still very flexible and scalable, but allows organise data in structures, usually using JSON as serializa-tion format. Documents are organized in collections and the most important – there are ways to organize different types of indexes over collections, making fast queries possible. Data de-normalisation is a strong and at the same time weak point of this approach. It is fast to retrieve and write, but the data can easily be-come inconsistent. Furthermore, document-oriented approaches consume more disk space in comparison with the relational approaches due to applying data de-normalisation as a main data modelling technique. Organizing relations between documents is possible, but document storage engines usually do not support joins, as it assumes that this work should be done by higher-level software components. The most widely used document-oriented stores are MongoDB (Mongodb.com 2016) and CouchDB. JSON-LD fits naturally with MongoDB document model. Another example of document-oriented datastore is ElasticSearch (Elastic.co 2016). It is a multi-tenant search engine based on Lucene. The difference between ElasticSearch and other document-oriented datastores is its ability to automatically create mappings and index documents of structure that was not defined in advance. ElasticSearch indexes data using inverted lists and wide-columns based on the type of incoming data. A specialised query JSON-based language called Query DSL is also provided. Another distinguishing feature of Query DSL is the presence of scoring function that enables data search based on unprecise queries with computing the relevance of returned data.

Relational database is another way of context storage. Relational database management systems (RDBMS) technology is the most established technology and have been used as a main approach for data manage-ment for more than 40 years. Allowing an excellent level of stability, functional richness, knowledge base and other benefits, relational model has a serious disadvantage for modelling context – it is the rigid schema that makes it hard to store any information that is not structured in the way that is defined by relational

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 45 2016-09-29

schema. Another problem is the expensiveness of joins between tables. Most well-known open-source rela-tional databases are PostgreSQL and MySQL.

Ontology Based Modelling is a way of organizing context into ontologies using semantic technologies like RDF or OWL. A large number of development tools, reasoners, standards and storage engines (Faye et al. 2016) are available. Ontologies give capabilities for defining entities and expressing relations between them. However, when dealing with Big Data, retrieval of context can be resource consuming and issues with scala-bility may arise. Besides, ontologies are not recommended for representing streams of sensor data. Exam-ples of RDF storage engines are Jena2, Sesame, AllegroGraph, Virtuoso, etc. (Faye et al. 2016). Most popular serialisation formats are Turtle, N-Triples, N-Quads, N3, RDF/XML and JSON-LD.

Graph-based modelling is a natural way for representing entities and interconnections between them. They are ideal for representing unstructured information and information that has ambiguity. Graphs are type-less and, schema-less, and there are no constraints on relations. This structure is ideal for representing social networks and is recommended for read-mostly requirements. Graph databases have a lot in com-mon with RDF storages but use different languages for querying data. Some graph databases can be used as RDF stor-ages with special plugins applied. According to (Paul Andlinger 2015) the popularity of graph databases has increased by 500% within 2014-2015 years period. Most popular graph Databases are Neo4J, Titan and Ori-entDB.

Object Based Modelling. Numerous projects focus on context-awareness common object-oriented pro-gramming languages technique of modelling context as objects (Boytsov & Zaslavsky 2011a)(Padovitz et al. 2008). These projects deliver huge theoretic base and numerous advanced features for context processing without focusing on the persistence problem that makes them hard to use in a large-scale environment. Though numerous attempts were taken to develop object storage, the industry standard is still mapping objects to a relational database schema. This is usually done manually or with a special object/relational framework facilitating automatic process of mapping entities and hiding the persistence level under ORM abstractions (Hibernate.org 2016). The main problem of this approach is called object-relational impedance mismatch (Ireland et al. 2009), which represents a set of difficulties while transferring data from object model with polymorphism, inheritance and encapsulation to the de-normalised table-based database ap-proach.

Our research of context representation approaches is summarized by providing quantitative analysis in Table 3. We use the following designations: Disk based (D); Relations (R); Veracity (C); Geospatial data indexing (GSI); Storage of Sensory Data (SD); Schema-less/Structural data freedom (SL); Horizontal Scalability (HS); Fast Writes (FW); Strong/native support (++); Supported (+); Limited support (+/-); Not supported (-).

According to the analysis of context representation and storage techniques we identify the document-oriented approach as the most suitable for our purposes.

Table 3. Summary of context representation approaches and their intersections with Smart City platform storage requirements

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 46 2016-09-29

One of the above mentioned theoretical foundations for context representation and reasoning about situa-tion awareness is the CST (Padovitz et al. 2004). It uses geometric metaphors for representing context at-tributes and building multidimensional spaces. Special context situations algebra is used for situation detec-tion and prediction.

The visualization of a situation subspace and context-situation pyramid (Padovitz et al. 2006) in CST is pre-sented in Fig. 1. CST proposes steps to a generic framework for context-aware applications and provides a model and concepts for context description and operations over context. As previously stated, this theory is implemented in two frameworks ECORA (Padovitz et al. 2008) and ECSTRA (Boytsov & Zaslavsky 2011a) and has been extended in Fuzzy Situation Inference (FSI) (Delir Haghighi et al. 2008) for situation modelling and reasoning under uncertainty and other advanced reasoning capabilities. These frameworks use the afore-mentioned object-based modelling approach and do not focus on issues such as scalability or persistence. Developing methods for mapping CST approaches to scalable and efficient hybrid storage can help to imple-ment these methods in large-scale Smart City middleware usage scenarios.

Figure 10. Visualization of situation subspace in Context Spaces theory (a) and Context-Situation Pyramid (b)

2.11. Context- and situation-prediction

Context awareness, as it has been discussed previously, is one of the core features of any pervasive compu-ting and/or IoT system. Context prediction is acknowledged as both a challenge and an opportunity. Some works provide comprehensive lists of context prediction use case scenarios. Those use cases include (list partially based on (Nurmi et al. 2005) (Mayrhofer 2004)):

D R V GSI SD SL HS FW

Relational + + - + +/- - - +/-

Ontology + + + - - + - -

Key-Value + - + - +/- ++ ++ ++

Document + +/- + + ++ ++ ++ +

Wide-Column + - + + + + ++ +

Graph + ++ + + - ++ +/- -

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 47 2016-09-29

Reconfiguration. Sometimes configuration-related tasks take a while to complete. This includes installation of updates, loading and unloading libraries, starting new applications, processing the infrastructure changes related to node mobility, searching in large databases. If the system can predict the need for those tasks in advance, it can perform the work beforehand and avoid unnecessary delays.

An application specific example was presented by Mayrhofer (Mayrhofer 2004). When the key appears near upper-class BMW cars, the car predicts that it is going to be started and the on-board navigation system initiates boot-up. Therefore, when the user enters the car, the navigation system is already fully functional. Otherwise, it would have taken extra 30 seconds to complete.

Device power management. Device that are unused and will not be used in near future can be shut down or switched to sleep mode.

There are other scenarios that fall under that category as well. For example (Nurmi et al. 2005), if the user attempts to send a large multimedia message while in an area of bad radio reception, the system can predict that the user is going to enter a better reception area soon and will delay sending the message (and there-fore saving power).

Early warning of possible problems (predictive maintenance). Context prediction can determine whether the system is about to enter an unwanted state and act accordingly. For example, a pervasive system can predict that it is going to run out of memory or computation power soon and act proactively to counter that problem – for example, find the devices to share the computations, offload the data and drop unnecessary applications. Or, for example, a pervasive system can predict that user is going to enter a traffic jam soon. In that case, the system can find a way around the traffic jam and provide it to the user before the traffic jam area is entered. Different cases of accident prevention also fall under the category of early warning of possi-ble problems.

Planning aid. If a user’s need can be predicted, a pervasive system can meet them proactively. For example, an air conditioner in a smart home can be launched in advance to have a certain air temperature when the user returns from work. Or in a smart office, the door can be opened right before the person enters.

Inferences on other’s future contexts. User can actually be influenced by the future context of another user. For example (Nurmi et al. 2005), a user may have confidential information on the screen. Therefore, when someone passes by, the screen should be hidden. Prediction of other people’s interference can help to hide the image proactively and in a timely fashion.

Early coordination of individuals. This can be viewed as a consequence of the previous point. If the needs of several users in a group can be predicted, the system can act to satisfy the interests of the group as a whole.

Future context can be predicted using a large variety of models. However, implementation of context predic-tion faces challenges that distinguish context prediction from many other kinds of prediction tasks. The chal-lenges include the following (partially based on the papers (Nurmi et al. 2005) (Mayrhofer 2004)):

• Pervasive systems work in real time. • Pervasive systems need to predict human actions. This is one of the main reasons why most of con-

text prediction techniques are grounded in machine learning. Human actions depend on human hab-its and personal features which, in turn, often cannot be guessed beforehand but can be inferred during the run time.

• The systems work in discrete time. All context data are provided by sensors and sensors work in an impulse manner, which provides the measurements in certain points of time.

• The data are highly heterogeneous. Lots of data of different nature and different type are coming from different sources. For example, context data can be numerical and non-numerical; context data can come periodically or when a certain event occurs.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 48 2016-09-29

• Sometimes hardware capabilities are limited. Using lots of small and preferably inexpensive devices is very common in pervasive computing. Many devices have to be relatively autonomous and use wireless interfaces for interactions. Devices of that kind have limited power supply and limited com-putational capacity.

• Connectivity problems are possible, which can cause problems including data loss and sensor una-vailability.

• The learning phase should be kept to a minimum. Often a pervasive computing system needs to start working right away. Ability to incorporate prior assumptions about the system is also highly desired in order to achieve a fast system start.

• Sensors are uncertain. Not taking that into account can lead to reasoning and prediction problems. • There is a need for automated decision making.

So far there are some works that address context prediction challenges, but there still is a definite lack of universal approaches to the problem. In the discussion below, context prediction techniques will be classi-fied according to the formal models and approaches, which inspired them. This is an insightful way that can provide a direction for new techniques research. Sometimes those approaches can overlap and, therefore, some approaches can be associated with several classes.

2.11.1. From Task Definition to Evaluation Criteria

To develop a basis for context prediction methods classification, we need a formal definition of the context prediction task. It will help to identify criteria for classification and evaluation of context prediction ap-proaches. Let S1, S2, be the context data at a certain moment in time. As usual, every portion of context data Si is a vector that contains sensor data and the results of sensor data pre-processing. A context predictor in most general sense can be viewed in following manner:

Pr = G(S1, S2, …,St)

In this formula t is current time and Pr is prediction result, the prediction result can be either just a set of expected future context features, or their distribution, or a future event, or a future state. Context predic-tion operation is represented by operator G. Initial knowledge and assumptions about the system are also included in G. To summarize, context prediction results depend on the context prediction method and possi-bly on context history and current context data. Questions of context history awareness will be addressed later in this section. In more details, the context predictor can be viewed as in Figure 11.

Figure 11. Context prediction – general structure

Several elements of the context prediction are identified in the following section.

2.11.2. Context prediction core.

It implements the exact context prediction method. This can be an ad hoc method defined for an exact case or any kind of well-known approach (like neural network, Markov model, Bayesian network, sequence pre-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 49 2016-09-29

dictor). Actually, the method used as the context prediction core is the main criterion of distinguishing one method of context prediction from another.

To define the context prediction method, we need to define its main principle (e.g., Bayesian network, Mar-kov model, neural network) and its parameters. Those parameters can be, for example, transition probabili-ties for Markov chain, neural network coefficients, or distributions for Bayesian network. The context predic-tor can obtain the parameters as prior knowledge or infer the parameters during run time. Here are the sug-gested evaluation criteria:

Criterion 1. Determine whether prior estimations about a pervasive system can be incorporated into the method. If the method cannot do that, it might result in low effectiveness at the startup. Sometimes prior training can be a workaround for that problem: to pre-train the context predictor, the trainer system needs to generate training data according to prior estimations and present it as pre-training before the system actually starts.

Criterion 2. Determine whether prior estimations about the pervasive system can be incorporated into the method. In pervasive computing systems, the problem of having numerous unknown parameters is quite common. For example, pervasive computing systems often involve user behaviour prediction. User behav-iour depends on user habits; the system usually cannot guess those habits in advance and needs to learn them during the run time. Practically, in pervasive computing there are almost no methods that are incapa-ble of incorporating run time knowledge.

Criterion 3. Determine whether white box/black box. Another criterion, closely correlated with two afore-mentioned ones, is whether the method is a “black box” or “white box.” If the method is a white box, meth-od parameters usually show in a quite insightful manner how the system really works. By looking at system parameters the expert can tell what exactly the system has learnt or, in turn, having some prior estimation, the expert can configure the system parameters accordingly. If the method is a black box, it is capable of prediction, but an expert cannot see the underlying reasons for the current prediction even if that expert knows the complete set of method parameters. Black box methods are generally unlikely to be able to in-corporate prior knowledge about the system.

For example, transition probabilities of the discrete time Markov chain explicitly reveal the chance for the system context to be in a particular state at a particular time; the state, in turn, corresponds to certain con-text features. And, having the transition probability, expert can easily understand what kind of regularity is found (at least in terms like “if context at current time t has features a1, a2, a3, …, that means that it will have features b1, b2, b3, … at time t+t’ with probability p”). So, Markov chain-based methods are white box methods. As for neural networks, even though the expert knows all the weights for every neuron, it is usual-ly impossible to tell what kind of regularities it corresponds to. So, neural network-based methods are black box methods.

Criterion 4. Determine whether estimation of prediction reliability is incorporated into the method. In prac-tice if the method is capable of estimating its own reliability, the predictor usually returns the distribution of predicted value (e.g., Markov models, Bayesian networks), not just the value itself. If reliability estimation is not possible in the method, such method usually returns just predicted value with no probabilistic estima-tions.

Criterion 5. Determine outlier sensitivity. All sensors have some degree of uncertainty. Moreover, the sen-sors can become unavailable or the measurement results can be lost in transfer. In that case, an outlier ap-pears. The outlier can significantly alter the prediction results. In a very general sense we can classify outlier sensitivity in the following groups.

• No sensitivity. Outliers will not affect prediction effectiveness in any way. No examples so far. Theo-retically it is possible if, for example, we have just a prediction formula which does not take any cur-rent data into account.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 50 2016-09-29

Pr = G(S1, S2, …,St) = G(t)

But practically that kind of predictor is very inflexible and, therefore, is not used.

• Moderate sensitivity. Outliers do affect prediction effectiveness, but over time the influence of the outlier fades. For example, the neural network of the Markov predictor learns over time, and if there is an outlier in the training sequence, it will have an effect. However, the amounts of data in the training sequence will be growing and the influence of the outlier will be decreasing.

• High sensitivity. One outlier can significantly influence subsequent results of context predictions; the effect of the outlier will not decrease until the outlier value is completely excluded from the history. For example, the values of sensor measurements over time can be treated as function and interpo-lated. Later that function can be extrapolated to the future and it will be the prediction result. But outlier presence can significantly alter the resulting function and the effect will not be reduced until that point is out of the history range (which will happen practically, at least due to memory limita-tions).

Criterion 6. Determine what types of incoming data is supported by the context predictor. Context can con-tain data of several types: real, integer and non-numerical (e.g., room in smart office or the position of the switch). If some data type of the context is not accepted by the context prediction method, pre-processing needs to be performed.

2.11.3. Pre-processing block

The pre-processing block transfers incoming sensor data to the format that is applicable to the context pre-diction core. In a very general sense it can be represented in the following manner:

S’ = Prep(S)

where S – current received context data, S’ – pre-processed context data for further usage by context predic-tion core. Prep() represents pre-processing operator. Pre-processing operation also can theoretically be de-pendent on historical data, but practically it is not likely.

Criterion 7. Determine pre-processing information loss. The more information lost during pre-processing, the greater the chance to miss significant information, not use it during context prediction and therefore get reduced context prediction capability. So here is one more context prediction method evaluation criterion: whether the information is lost during pre-processing.

• No information loss. For example, context can be left as is (it can be represented as state-space model with later prediction using filter theory or context data can be used directly as an input for the neural network). Or new context attributes can be introduced during pre-processing (e.g., one of the environmental characteristics can be estimated in two different manners to detect sensor failure or use filtering to combine two sources of data). So, processing in this case can require some efforts as well. The criterion for the method to be included in this category is following: for every S’ there should be at most one value of S.

• Information loss present. Denotes all other cases. For example, some values can be aggregated, or context can be completely reduced to a finite number of states of the Markov model or probabilities of Bayesian network nodes, or the context can be decomposed into event flow and timing infor-mation can be lost, and many more examples.

Usually the presence of information loss depends both on the prediction method and on sensor data the system obtains. For example, if there are only a few sensors with a small set of discrete non-numerical data coming from them, the Markov model can be created without information loss – every predictor state (S’) will correspond to every possible combination of sensor values (S). However, even if the system has just one real-valued sensor, creating the Markov model without information loss is impossible – there is an infinite number of possible values of S and it cannot be covered by any finite number of states in S’.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 51 2016-09-29

2.11.4. Memory

The predictor might need to store history or parameters in an applicable manner. Some methods require only current value and do not store history in any manner. Some of the methods are capable of handling all the history and using it to its benefit.

Criterion 8. Determine constant or variable amount of memory needed. For example, a neural network needs only memory to store weight coefficients for neurons. The Markov model needs only a fixed amount of memory to store transition probabilities and some intermediate data to obtain them. However, an expert system-based context predictor that constantly introduces new rules or a sequence predictor-based ap-proach with growing prediction tree requires a variable amount of memory and the memory demand can grow over time.

In summary then, here are the defined criteria for evaluation of context prediction methods:

• Prior knowledge accumulation? Yes / No. • Real-time knowledge accumulation? Yes / No. • “Black box” / “White box”? • Prediction reliability estimation? Yes / No. • Outlier sensitivity? No / Medium / High. • Types of data supported?

o Real? Yes / No. o Integer? Yes / No. o Non-numerical? Yes / No.

• Information loss on preprocessing? Yes / No (usually it depends on certain conditions). • Memory amount needed? Fixed, Variable.

2.11.5. Context Prediction Methods

In practice, the methods used most frequently include:

Sequence prediction approach. This approach to context prediction is based on the sequence prediction task from theoretical computer science and can be applied if the context can be decomposed into some kind of event flow.

Markov chains approach. Context prediction techniques based on Markov chains are quite widespread. Markov chains provide an easily understandable view of the system and can be applied if the context can be decomposed into a finite set of non-overlapping states.

Bayesian network approach. This can be viewed as the generalisation of the Markov models. It provides more flexibility but requires more training data in turn.

Neural networks approach. Neural networks are biologically inspired formal models that imitate the activity of an interconnected set of neurons. Neural networks are quite popular in machine learning. Context predic-tion approaches based on neural networks exist as well.

Branch prediction approach. This approach initially comes from the task of predicting the instruction flow in a microprocessor after the branching command. Some context prediction systems use similar algorithms.

Trajectory prolongation approach. Some context prediction approaches treat the vector of context data as a point in multidimensional space. Then the context predictor approximates or interpolates those points with some function, and that function is extrapolated to predict future values.

Expert systems approach. Based on expert systems and rule-based engines, the expert systems approach appears in some works on context prediction. The goal of the approach is to construct the rules for predic-tion. It provides a very clear view of the system.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 52 2016-09-29

Table 4 presents the comparison of context prediction approaches according to the criteria identified in sec-tion 2. It should be noted that different kinds of predictors can be combined to improve prediction quality, enhance each other’s strength and compensate each other’s weaknesses.

One of the context prediction research challenges is the development of a general approach to context pre-diction. Many context prediction approaches were designed to fit the particular task and most of them were not designed to be generaliseable (although some of them have generalisation capability). The context pre-diction process consists of several steps (Mayrhofer 2004):

• Sensor data acquisition. This step takes data received from multiple sensors and arranges them into the vector of values.

• Feature extraction. This step transforms raw sensor data for further usage. From vector of sensor data, vector of features is formed.

• Classification. Performs searches for recurring patterns in context feature space. Growing neural gas was considered to be the best choice. See (Fritzke 1995) for more details on that algorithm. The re-sult of the classification step is a vector of values that represents degrees of membership of current vector to certain class.

• Labelling. This is the only step that involves direct user interaction. The frequency of involvement depends on a quality of clustering step if classes are often overwritten and replaced that will result in more frequent user involvements.

• Prediction. This step takes the history of class vectors and estimates a future expected class mem-bership vector. For this step the author researched numerous prediction approaches and, according to evaluation results presented in (Mayrhofer 2004), an active LeZi – combined with a duration pre-dictor – slightly outperformed other evaluated algorithms.

2.11.6. Research Challenges of Context Prediction

Context prediction is a relatively new problem for computer science. Now the area of context prediction is just being developed and still there are numerous challenges yet to be addressed. Those challenges include:

• Lack of general approaches to the context prediction problem. Most current solutions predict con-text for particular situations. There have been only a few attempts to define and solve the context prediction task in general.

• Lack of automated decision-making approaches. Most context prediction-related works focused the efforts on prediction itself, but proper acting on prediction results usually was not considered. Most context prediction systems employed an expert system with pre-defined rules to define the actions based on prediction results. With one notable exception of Markov decision processes, almost no systems considered a problem like “learning to act”.

• Mutual dependency between system actions and prediction results is not resolved. This challenge is somewhat related to the previous one. Many context prediction systems considered the tasks of predicting the context and acting on predicted context in sequence: predict and then act on predic-tion results. That approach can handle only simplified use cases when actions do not affect predic-tion results. For example, in a smart home the system can employ any policy for switching the light or opening the door in advance, depending on user movement prediction results. But whatever the system does, it will not affect user intentions to go to a particular room. However, in a general case system, actions do affect prediction results. For example, consider a system which is capable of au-tomatic purchases to some degree and which needs to plan the expenses, or in a more serious use case, consider a pervasive system that is capable of calling the ambulance and that needs to decide whether to do it or not depending on observed user conditions. In those and many more use cases, prediction results clearly will depend on what the system does. However, there are almost no work that considered the problem of mutual dependency between system actions and prediction results.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 53 2016-09-29

So far, the only works that did address that problem were the ones on the Markov decision process-es as discussed above. The task of resolving that dependency is actually a special case of a rein-forcement learning task. In our opinion, although comparing to most reinforcement learning task pervasive computing systems have their own specifics (e.g., relatively obscure cost and reward func-tions, high cost of errors and therefore very limited exploration capabilities), recent advancement in the reinforcement learning area can help to overcome that problem.

If all those context prediction challenges are resolved, it will let pervasive computing systems handle more sophisticated use cases, enhance the applicability and the effectiveness of context prediction techniques and therefore enhance overall usability of pervasive computing systems.

2.12. Context-provisioning tools, technologies and platforms

In this section, we will review existing context query languages (CQL). CQLs can be categorized into five sub-classes: SQL-based, RDF-based, XML-based, API-based and Graph-based CQLs. In (Haghighi et al. 2006), an evaluation of different CQL is presented. They compare different CQLs and demonstrate that SQL-based and RDF-based CQLs are more effective and powerful compared to the other subclasses. Therefore, in the rest of this section, we will mainly focus on the state of the art in SQL-based and RDF-based CQLs.

SQL is the most well-known declarative query language which is designed for accessing data from traditional databases. However, directly utilizing SQL in CoaaS is not possible as context data has its own characteristics that are different from relational database data. Compared to traditional database data, context data has its own special characteristics. According to (Haghighi et al. 2006), context can be:

• Dynamic or static. • Continuous data streams. • Temporal, erroneous, ambiguous, unavailable or incomplete. • Spatial. • Unstructured. • A situation that is derived and reasoned from other context.

SQL-based CQLs extend traditional SQL by adding optional instructions to support querying on context data. Contory (Riva & Di Flora 2006) proposed an SQL-based CQL to provide contextual information for mobile applications. Contory supports both pull-based and push-based queries. However, this language suffers from performance issues when retrieving contextual information from different sources. Furthermore, another shortcoming of this approach is the lack of supporting context processing operations. Another SQL- based query language is presented by Feng (Feng 2010). They designed a query language for the ambient intelli-gent environment, which utilizes contextual data to identify data retrieval conditions in a relational data-base. The main disadvantage of this work is that it is limited to relational databases and is not suitable for context data management in general.

PerLa (Schreiber & Camplani 2012) is another well-known SQL-based context query language, which is de-signed for collecting contextual data from different sources. Per-La can access data from various nodes by masking the heterogeneity at the data level. However, PerLa has poor support for processing context data. Another SQL-based context querying language is Fjords architecture (Madden & Franklin 2002), which is designed for querying streaming sensor data. This framework supports both pull-based and push-based que-ries.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 54 2016-09-29

Table 4. An overview of context prediction approaches

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 55 2016-09-29

The most recent work in the area of SQL-based CQL is presented in (Chen et al. 2014). The author of (Chen et al. 2014) proposed a new SQL-based CQL that supports both pull-based and push-based queries. This work introduces some useful ideas and concepts. Their work supports continuous queries with compound condi-tions for accessing contextual information from various context entities. Furthermore, they claim that their work also supports contextual functions, however, they did not mention how these contextual functions can be represented.

As it is demonstrated in (Haghighi et al. 2006), the other powerful context query language is RDF-based CQLs. To the best of our knowledge, the most sophisticated RDF-based CQL is the MUSIC CQL proposed by Reichle et al.(Reichle et al. 2008). Their work has a decent backing on querying contextual information. Not-withstanding, as their work can only represent context request from a single entity, it cannot express com-plex context queries. Perich et al. (Perich et al. 2004) proposed another query language based on RDF. They break down queries into subqueries and run them independently to mitigate some issues related to mobile environment. However, this work suffers from availability and reliability issues as it highly relies on mobile devices. SOCAM (Gu et al. 2005) is another RDF-based SQL language. This language is capable of providing contextual data about context entities and the relationships among them by using ontology technology. However, the main shortcoming of this work is its restriction on supporting complex queries.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 56 2016-09-29

3. Context Provisioning-as-a-Service in bIoTope

This chapter is directly related to how context provisioning in bIoTope will be conceptualised, implemented and evaluated. The chapter gives examples of context relevant to selected use cases. It also defines the framework for context service requests and how context could be exchanged between bIoTope components.

3.1. Context in bIoTope use cases and pilots

3.1.1. Context-as-a-Service Specification for Air Quality Monitoring and Prediction Pilot

Context-as-a-Service (CoaaS) is responsible for providing a comprehensive method to allow entities in IoT ecosystem to share and query context. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. An entity in an IoT ecosystem can include physical IoT devices to human beings to Internet connect vehicles, mobile smart phones, etc., to name a few. Figure 12 provides an overview of CoaaS for the Air Quality and Predic-tion (AQMP) use case.

An entity can be a context service consumer; consumes a context service and/or a context service provider; provide context to CoaaS. The context service producer component of CoaaS is a proxy for the context pro-vider. It provides the following functions namely: 1) provide an interface for entities that are capable of gen-erating context from data external to the CoaaS platform e.g. exiting CRM systems, web services etc., and 2) provide the service to extract, capture, reason, infer and verify context from data produced by IoT devices that do not have the capability to generate context from data e.g. an internet connected temperature sen-sor. The CoaaS enables global standardization and interworking among different context providers and con-sumers in IoT environments. The CoaaS also stores the relationship between entities.

For example, consider the push bike rider scenario in the AQMP use case. An entity A (e.g. user) wants to know about the level of light (context) at night in a certain bike path (entity). To answer this query, we need to first find those context provider entities (e.g. humans carrying mobile devices and attached sensors, push bikes with attached sensors etc. that are part of AQMP environmental monitoring IoT applications) located in that area that can provide relevant contextual information to process the query. Then, we need to filter the retrieved list based on the requested entity’s context e.g. the current activity of the user, current loca-tion to determine relevance, user preferences e.g. not comfortable to ride alone at night in dark areas etc., to suggest the right paths (arrived by considering context provided by multiple entities; context providers).

We see the CoaaS platform complimenting analytic as a service platform by providing relevant context in-formation about IoT entities (context providers) to enable faster reasoning and processing. Figure 13 pro-vides an overview of our view of CoaaS and analytics platforms.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 57 2016-09-29

Figure 12. CoaaS for air quality monitoring and prediction use case

Figure 13. From IoT data ingestion to continuous analytics

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 58 2016-09-29

Scenario: Push bike rider

The goal of this AQMP use case scenario is to provide push bike riders real-time information about air quality in different pockets of the city and in particular along bikes paths used by the user.

The 4 types of context that is relevant to this scenario are:

• User Context: User’s context can include user preferences such as i) allergies e.g. pollen ii) group/individual biker, iii) frequent/favourite bike paths; iv) common destinations

• Environmental Context: The environmental context focuses on air quality, weather conditions, sea-sonal conditions e.g. spring/autumn

• Location Context: The location context considers the bike path location, the user’s location, points of interest related to user’s context

• Application Context: The application context is specific to the scenario. In case of push bike rider scenario, this could include i) most used bike paths, ii) safety of bike paths, iii) relation of location and air quality and other application specific requirements.

A step-by-step description of context requests and exchanges between entities is presented in the sequence diagram in Figure 14).

Entities: Push bike rider, environmental sensors (physical sensors), mobile smart devices (bike rider), applica-tion/service (provide a safe and allergy free route to push bike rider).

Figure 14. Sequence diagram for bike riding scenario of the air quality monitoring & prediction use case

3.1.2. Case study on context-aware fault diagnosis system for Air Handling Units

Maintenance is a complicated task that encompasses various activities including fault detection, fault diagnosis and fault reparation (Figure 15). With advancement of computer aided engineering, maintenance task become even more challenging as modern assets became complex mixes of systems and sub systems with complex interaction. Fault diagnosis became particularly cumbersome as reason of failure on the system are often neither obvious in terms of their source nor unique. In such a senario, context information

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 59 2016-09-29

plays vital role in identification of root cause of failure. Here, in this case study we will present context-aware fault diagnosis system for air handling unit using case based reasoning.

Case-based reasoning(CBR), a well-known artificial intelligence technique of solving new problems based on the solutions of similar past problems. In CBR, We need to define the similarity functuin that is be used to find similar previous case. The similarity score between a new case N and a previous case C is calculated using the Following equation.

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆(𝑁,𝐶) =∑ 𝐹(𝑁𝑖,𝐶𝑖) ∗𝑊𝑖𝑛𝑖=1

∑ 𝑊𝑖𝑛𝑖=1

where Ni is the ith feature value of the new case, Ci is the ith feature value of the old case, n is the number of features, F(Ni, Ci) is the distance function between Ni and Ci, and Wi is the weight of ith feature.

Figure 15. Context-aware Fault diagnosis system

The goal of this case study is to create a context aware fault diagnosis system for maintenance. For this pur-pose, a smart home with air handling unit has been selected as prove of concept. This case study involved three entities which interact with each other as shown in sequence diagram in Figure 16.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 60 2016-09-29

Figure 16: Sequence diagram of context-aware fault diagnosis system

• Smart House : The smart house is equipped with air handling units that are to maintain the air quiality through out the house. In addition, the house is equipped with two temperature sensor, two carbon dioxide and a humidity sensor to montitor temperature, CO2 level and humidity of the house. The temperature sensor and CO2 sensor are installed in two bed rooms whereas humidity sensor is installed in the bathroom. The air handling unit itself is a very complex system with control system which is responsible to maintain the air quality of the house and is capable of detecting abnormal functional behavior and can trigger Alrams based on the several sensors installed within Air handling unit. The List of sensors and Alarms are listed in Table 5 and Table 6.

• Maintenance Personnels: Maintenance personnels are persons who are responsible for maintenance activities of air handling units. Contenxt-aware Fault Diagnosis system is desgined to aid these maintenance personal to diagnosis the faulty condition of air handling unit by making them aware of possible cause and context information related to that particular fault.

• Context-aware Fault Diagnosis System: This is main component of our case study. This system will be capable of diagnosis the faulty condition of air handling unit based on the context data as well as previous context case history. The application is made up of three modules

o Frontend Module: The Frontend module is responsible with interacting with maintenance personnels. This module consist of two sub-modules. Firstly, O-MI enabled context acquisition module which is resposible to identify context parameter on case to case basis and to request context information using O-MI messaging interface. Secondly, notification and feedback module. This module is responsible to notify maintenance personnel with con-text information and possible diagnosis of faulty condition that triggered an alarm. In addi-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 61 2016-09-29

tion, notification and feedback module allows maintenance personnel to provide rating of feedback.

o Logic Module: The Logic module is heart of the context-aware fault diagnosis system. This module get context information such as temperature sensor, fan rotation speed(Internal context),weather condition,humidity(external condition) about alarms from the context acquisition module. In addition, to contextual information this module also get context case history from backend module and use rule and case based reasoning as discussed above to identify possible diagnosis for cause of failure. This module forward contextual information and possible diagnosis of faulty condition to notification and feedback module of frontend module.

o Backend Module: The backend module will be implemented in postgres and is responsible to store relevant cases and data. Figure 17 shows the entity-relationship diagram of the case study and data stored in the repository. Backend module consist of table to store history of previous cases, context informations and recommendation. The feedback of recommendation from maintenance personnels are also stored.

Figure 17: Entity-relation diagram of context-aware fault diagnosis system

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 62 2016-09-29

Table 5. List of Sensors and their Descriptions

Alarm Name Alarm Description

TE5 Min After HRC supply air cold

TE10 Min Supply air cold

TE10 Max Fire risk supply temp high

TE20 max Fire risk room temp high

TE45 Min Water cooler freeze risk

TE30 Min Extract air cold

TE30 Max Fire risk extract temp high

ELH-Problem Electrical coil overheating

Freeze Problem Freeze problem info

E-Stop External emergency stop

Fire Risk External Fire Risk

PDS10 Pressure switch

SF Deviation alarm

EF Deviation alarm

Table 6. List of Alarms and Its Description

Sensor Label Sensor Description HREG_T_OP1 Temperature at operator panel 1 HREG_T_OP2 Temperature at operator panel 2 HREG_EFFECTIVE_TF The current effective TF fan speed HREG_EFFECTIVE_PF he current effective PF fan speed HREG_T_FRS TE01 (fresh air) temperature HREG_T_SPLY_LTO TE05: Fresh (incoming) air temperature after HRC. HREG_T_SPLY TE10 Room supply air temperature HREG_T_WST TE32 Waste air temperature HREG_T_EXT TE30 Room removed air temperature HREG_T_EXT_LTO TE31 removed air before heat recycler HREG_T_WR TE45 heater element return water temperature. HREG_HUM_EXT RH30 measurement, removed air relative humidity

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 63 2016-09-29

3.2. High-level requirements to and expectations of CoaaS in bIoTope

The core research/technical workpackages of the bIoTope project (WP2, WP3, WP4 and WP5) are interlinked and depend on each other’s services. It is an ongoing work on identifying the types of services, a format of a service request, how the core bIoTope components will interoperate. O-MI/O-DF have been adopted as the “glue” between bIoTope ecosystem components, tools and technologies. The dependencies between these workpackages are depicted in Figure 18.

Figure 18. Dependencies between bIoTope workpackages

The “big picture” of the bIoTope ecosystem is illustrated in Figure 19. Platforms P1, P2 and so on represent partner platforms and technologies (eg., Warp10) which are wrapped into O-MI/O-DF compliant wrappers. O-MI/O-DF is the “glue” that binds the ecosystem together. Any new tool or platform can join the bIoTope ecosystem once it has an O-MI/O-DF compliant wrapper that can be developed manually or possibly in a semi-automated way as illustrated by P5 in the figure. The core components will be developed by the bIo-Tope consortium and are represented in the belt that encompasses the component platforms. The ecosys-tem will have multiple entry points and the service requests (SR) are represented by multi-section docu-ments possibly incorporating SPARQL queries, O-MI/O-DF XML, web-services, SSNO (SSN Ontology) refer-ences and resources URIs. SRs can be generated by users using IDE interfaces or via APIs from applications, services and other IoT EPI ecosystems.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 64 2016-09-29

Figure 19. Big picture of bIoTope ecosystem incorporating core components and O-MI/O-DF wrapped partner platforms

3.3. CSDL – Context Service Definition Language

2.1 Context-as-a-Service (CoaaS) vison

CoaaS is responsible for providing a comprehensive method to allow a smart entity, namely context service consumers, to consume a context service provided by another entity that is a context service provider. The entity is a member of the IoT ecosystem and can include physical IoT devices, human beings, internet con-nected vehicles, and mobile smart phones. The CoaaS enables global standardisation and interworking among different context providers and consumers in IoT environments. Context as a Service (CoaaS) forms an important part of the service offerings in the bIoTope project. Figure 12, despite being depicted in rela-tion to air quality use case, is rather generic, illustrates the overview of CoaaS framework and shows its main components. Several challenges need to be addressed, such as modelling and representing context provid-ers, expressing context requests, storing and indexing contextual information, describing context services, semantic service discovery, dynamic selection of context services. In this section we focus on two core com-ponents of the CoaaS framework namely describing context services (CDM) and expressing context requests (Context Query Language (CQL)).

3.3.1. A motivating scenario

Let us consider a motivating scenario that explains the need for a flexible, dynamic, easy to use, and scalable representation and query language for context service in IoT applications. The scenario under consideration is about safety in smart cities, in particular school children safety (related to a Brussels city pilot). As depict-ed in Figure 20, the school safety scenario consists of several entities such as a smart bus, a smart car, mo-bile devices, a school server, and a smart gate. As a first step, it is essential to have a generic context model to acquire and represent the contextual information from IoT entities.

In the example depicted in Figure 20 a user called John wants to pick-up his daughter, Hannah, from her school. On his way to school, due to an unexpected traffic, he realises that he cannot arrive at the school on time. Realizing this, a smart IoT system begins to determine alternatives to achieve the goal “pickup Han-

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 65 2016-09-29

nah”. An option could be to request another trusted parents to pick-up Hannah from school on John’s be-half. In order to represent this context request, several factors should be considered, namely:

• The selected parent(s) for picking up Hannah should be trusted by John; • The selected parent(s) should have a car with an extra seat for Hanna; • The selected parent(s) should be close enough to the school; • The child of the selected parent(s) should finish the school in the same time as Hannah; • The child of the selected parent(s) should be currently at school.

Figure 20. School kid pick-up scenario

Additionally, this process needs to be automated so John’s device can automatically trigger the same query, “pickup Hannah” whenever he is running late. Now consider Alice who is Bob’s mother. She is the parent matching all the above-mentioned criteria to pick up Hannah. She wants to know the fastest and safest loca-tion for picking up Bob and Hannah from school.

Based on this smart city IoT application scenario and the aforementioned considerations, we list the key requirements in designing CDQL as the following:

• To support complex context queries concerning various contexts entities and constraints; • To provide transparency. In another word, it should hide technical details of context providers such

as storage techniques; • To conform to a context model that can be converted into different data models as required. • To support both pull-based and push-based queries; • To support continuous queries; • To support aggregating and reasoning functions to query both low level and infer high-level context.

CoaaS architecture is depicted in Figure 21, which is similar to Figure 12. The components of the CoaaS archi-tecture are described below:

Context consumer: An entity with a context request. Note that a context consumer might be context pro-ducer as well.

Security: All incoming messages (e.g. subscriptions, context requests, context updates) go through the secu-rity module. Security module is responsible for the authentication (by checking the validity of the token).

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 66 2016-09-29

Furthermore, it is also responsible for monitoring all the incoming messages to identify any suspicious pat-terns, for example, to stop distributed denial-of-service (DDoS) attack.

Context Query Engine (CQE): This module has two main responsibilities: parsing the incoming queries, and producing the final query result. Figure 3 illustrates the architecture of CQE.

Figure 21. CoaaS generic framework

Context Service Discovery and Selection:

• Context Service Discovery: This component is responsible for finding those context services that match the requirements of the context request.

• Context Service Selector: Due to the proliferation of smart devices and popularity of other context’s sources, the same contextual information might be offered by several context sources. However, context services can differ in their quality levels (e.g. accuracy) and representations (e.g. position represented in coordinates and as an address) of the offered information, and costs (e.g. battery consumption) for providing the information. Therefore, Context Service Selector is responsible for selecting the best available context service that can satisfy requirements of the context request.

Context Storage and Caching: In CoaaS, different type of contexts (Cached contexts, CSD, Subscription re-pository, entity repository) are needed to be stored and queried. Therefore, it is essential to have a proper storage mechanism to enhance the performance of CoaaS. On top of that, Context Storage is also responsi-ble for caching the received contextual information for further performance improvement. Each context provider should register its Context CSD in the CoaaS. CSD registration module is responsible for this task.

Query coordinator: This component is responsible for handling push-based (event based) and continues queries. Regarding the continuous query, the query coordinator will trigger the registered query on the spec-ified intervals. And in the case of push based queries, the query coordinator will listen to the incoming con-textual information form entities (it can be high-level or low level context) and trigger a query if the incom-ing information matches the conditions of the registered query.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 67 2016-09-29

Authorisation: Each context service might be accessible only for a specific set of users. Therefore, the au-thorisation module is responsible to check if the context consumer has access to the requested context ser-vice or not. Access level of each service is defined in the CSD. Tools from other bIoTope partners could be deployed as well, for example, MIST from ControlThings.

Context Service Invoker: The context service invoker is responsible for invoking the context services from the corresponding context providers to retrieve the required contextual information and pass the retrieved contexts to the CQE.

Context provider: An entity that can provide contextual information. In another word, context provider can be considered as source of context. Note that sources of context are not limited to external sensors and built-in sensors in smart devices such as accelerometers, GPS sensors, and light level sensors. Web APIs (e.g. linked open data) and social networks also provide rich, useful and relevant information to deduce context.

Pull-based queries workflow can be described in the following way:

1. Context consumer issues a query. 2. Query Engine parses the query, and breaks it down into the sub-queries 3. Context Service Discovery and selection:

a. Receives the sub-queries b. Finds the context services (providers) that can answer each sub-query by looking up in the

CSDL repository. c. If more than one service is found for each sub-query, selects the best service, for example,

based on QoS, CoS (Analytics services can be used here). 4. If CoaaS works as a redirector, send the selected services back to the context consumer (finish)

a. Else, send the selected services to the Context Service Invoker. 5. Context Service Invoker send the context queries (requests) to the context provider(s)

a. Note that before passing the context requests to the Context Service Invoker, the context consumer is authenticated.

b. Note that context provider might be the caching server 6. Context provider(s) send the requested contexts back to the context Service Invoker

a. Note contexts can be cached by caching server 7. Send the context to the Context Query Engine 8. Context query engine calculates the final result and sends it to the context consumer

a. Note that reasoning module (or aggregation) might be used to infer high level context

Push based queries workflow can be described in the following way:

Part 1: Subscription

1. Context consumer issues a query. 2. Query Engine parses the query, and breaks it down into the sub-queries 3. Context Service Discovery and selection:

a. Receives the sub-queries b. Finds the context services (providers) that can answer each sub-query by looking up in the

CSDL repository. c. If more than one service is found for each sub-query, selects the best service, for example,

based on QoS, CoS (Analytics services can be used here). 4. Send the selected services to the query scheduler and register them in the subscription repository. 5. If applicable, register the situations of interest in the context providers/consumer to be notified

when the situation is detected.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 68 2016-09-29

Part 2: trigger

1. Detected situations are sent to the query scheduler 2. Query scheduler looks up in the subscription repository

a. Reasoning module might be used 3. Corresponding query will be sent to the query engine 4. Go to 2 in pull-based queries

Figure 22 illustrates entity registration in CoaaS.

Figure 22. Entity registration in CoaaS

Entities (components, connected smart objects) have to register in CoaaS in the following way:

• Entity Registration: When an entity wants to get register to the system for the first time, it needs to send a registration request to the Entity registration component. Then, the entity registration mod-ule will store the provided information in the Context Storage module and also generates a token based on the provided information. This token will be sent back to the requestor entity. Whenever an entity wants to communicate with the CoaaS, this token should be sent as part of the message.

• CSD Registration: Each context provider should register its Context Service Description (CSD) in the CoaaS. CSD registration module is responsible for this task.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 69 2016-09-29

4. Conclusion

This deliverable “D4.3 Theoretical Framework for Context and Situation Awareness in IoT” has addressed the following objectives:

• State-of-the-art survey of existing approaches, tools, technologies and platforms for context- and situation awareness.

• Analysis of challenges in context representation, reasoning about, validation, prediction and provi-sioning on-demand was presented. Developing of the bIoTope core components and the ecosystem itself will have to address those challenges in order to build a successful ecosystem.

• Context, situations, semantics, complex events, knowledge, reasoning are all strongly related to one another and will form the core of the proposed context provisioning platform.

• The conceptual architecture of Context-as-a-Service (CoaaS) was presented and will be used as a ba-sis for subsequent CoaaS development, implementation, validation and evaluation in the course of the bIoTope project.

• Context Spaces Theory will be used as a theoretical framework for context representation, reasoning about, validation and mapping to JSON-LD doucments and incorporate O-MI/O-DF standards.

WP4 team will continue developing beyond the state-of-the-art context provisioning platform a sa core component of the bIoTope ecosystem.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 70 2016-09-29

5. References

Adshead Antony, 2014. Data set to grow 10-fold by 2020 as internet of things takes off.

Akman, V. & Surav, M., 1996. Steps toward Formalizing Context. AI magazine, 17(3), pp.55–72.

Anagnostopoulos, C., Mpougiouris, P. & Hadjiefthymiades, S., 2005. Prediction intelligence in context-aware applications. Proceedings of the 6th international conference on Mobile data management, pp.137–141.

Anagnostopoulos, C.B., Ntarladimas, Y. & Hadjiefthymiades, S., 2007. Situational computing: An innovative architecture with imprecise reasoning. Journal of Systems and Software, 80(12 SPEC. ISS.), pp.1993–2014.

Anon, Merriam-Webster Online.

Anon, OpenTSDB.

Antunes, M., Gomes, D. & Aguiar, R., 2014. Semantic-based publish/subscribe for M2M. Proceedings - 2014 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery, CyberC 2014, (October), pp.256–263.

Arpinar, I.B., Giriloganathan, K. & Aleman-Meza, B., 2006. Ontology Quality by Detection of Conflicts in Metadata. In In Proceedings of the 4th International EON Workshop.

Ashton, K., 2009. That “Internet of Things” Thing. RFiD Journal, p.4986.

Asin, A. & Gascon, D., 2012. 50 sensor applications for a smarter world. Libelium Comunicaciones Distribuidas, Tech. Rep.

Association Instituts Carnot, 2011. Smart Networked Objects & Internet Of Things,

Atzori, L., Iera, A. & Morabito, G., 2010. The Internet of Things: A survey. Computer Networks, 54(15), pp.2787–2805.

Baader, F. et al., 2003. The Description Logic Handbook: Theory, Implementation, and Applications F. Baader et al., eds., Cambridge University Press.

Baader, F. & Sattler, U., 2001. An Overview of Tableau Algorithms for Description Logics. Studia Logica, 69(1), pp.5–40.

Baldauf, M., Dustdar, S. & Rosenberg, F., 2007. A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing, 2(4), p.263.

Barbero, C., Dal Zovo, P. & Gobbi, B., 2011. A flexible context aware reasoning approach for IoT applications. In Proceedings - IEEE International Conference on Mobile Data Management. pp. 266–275.

Barwise, J., 1981. Scenes and Other situations. Journal of Philosophy, 78(7), pp.369–397.

Barwise, J., 1989. The situation in logic, Center for the Study of Language and Information.

Barwise, J. & Perry, J., 1981. Situations and attitudes. The Journal of Philosophy, 78, pp.668–691.

Batini, C. et al., 2009. Methodologies for data quality assessment and improvement. ACM Computing Surveys (CSUR), 41(3), p.16:1–16:52.

Behzadian, M. et al., 2012. A state-of the-art survey of TOPSIS applications. Expert Systems with Applications, 39(17), pp.13051–13069.

Bellavista, P. et al., 2012. A survey of context data distribution for mobile ubiquitous systems. ACM Computing Surveys, 44(4), pp.1–45.

Bernardos, A.M., Tarrio, P. & Casar, J.R., 2008. A data fusion framework for context-aware mobile services. 2008 IEEE International Conference on Multisensor Fusion and Integration for Intelligent Systems, pp.606–613.

Berners-Lee, T., Hendler, J. & Lassila, O., 2001. The Semantic Web. Scientific American, 284, pp.34–43.

Bettini, C. et al., 2010. A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing, 6(2), pp.161–180.

Bikakis, A. et al., 2008. A Survey of Semantics-Based Approaches for Context Reasoning in Ambient Intelligence. In Constructing Ambient Intelligence. pp. 14–23.

Bizer, C., Heath, T. & Berners-Lee, T., 2009. Linked data-the story so far. International journal on Semantic Web and Information Systems, 5(3), pp.1–22.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 71 2016-09-29

Blasch, E. et al., 2006. Issues and challenges of knowledge representation and reasoning methods in situation assessment (Level 2 Fusion). In Defense and Security Symposium. International Society for Optics and Photonics, pp. 623510-623510–14.

Blasch, E.P. & Plano, S., 2003. Ontological issues in higher levels of information fusion: User refinement of the fusion process. In Proceedings of the 6th International Conference on Information Fusion, FUSION 2003. IEEE Computer Society, pp. 634–641.

Boury-Brisset, A.C., 2003. Ontology-based approach for information fusion. Conference on Information Fusion, 1(418), pp.522–529.

Boyer, J. & Mili, H., 2011. Rule Engine Technology. In Agile Business Rule Development. Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 147–175.

Boytsov, A. & Zaslavsky, A., 2011a. ECSTRA – Distributed Context Reasoning Framework for Pervasive Computing Systems. In Springer Berlin Heidelberg, pp. 1–13.

Boytsov, A. & Zaslavsky, A., 2010. Extending Context Spaces Theory by Proactive Adaptation. In Springer Berlin Heidelberg, pp. 1–12.

Boytsov, A. & Zaslavsky, A., 2011b. Formal Verification of the Context Model -Enhanced Context Spaces Theory Approach,

Boytsov, A., Zaslavsky, A. & Synnes, K., 2009. Extending Context Spaces Theory by Predicting Run-Time Context. In Springer Berlin Heidelberg, pp. 8–21.

Brock, D.L., 2001. white paper The Electronic Product Code (EPC) A Naming Scheme for Physical Objectsc. Mit Auto-Id Center, (January 1), pp.1–21.

Bu, Y. et al., 2006. Managing quality of context in pervasive computing. In Proceedings - International Conference on Quality Software. pp. 193–200.

Buchholz, T., Küpper, A. & Schiffers, M., 2003. Quality of Context: What It Is And Why We Need It. In Proceedings of the 10th International Workshop of the HP OpenView University Association(HPOVUA). Hewlet-Packard OpenView University Association.

Burrell, J., Brooke, T. & Beckwith, R., 2004. Vineyard Computing: Sensor Networks in Agricultural Production. IEEE Pervasive Computing, 3(1), pp.38–45.

Chao, A.I. et al., 2003. An extensible, ontology-based, distributed information system architecture. In Proceedings of the 6th International Conference on Information Fusion, FUSION 2003. IEEE Computer Society, pp. 642–649.

Chen, G. & Kotz, D., 2000. A Survey of Context-Aware Mobile Computing Research,

Chen, L. et al., 2009. Semantic smart homes: Towards knowledge rich assisted living environments. Studies in Computational Intelligence, 189, pp.279–296.

Chen, P. et al., 2014. A SQL-based Context Query Language for Context-aware Systems. , (c), pp.96–102.

Chen, Y., Guo, J. & Hu, X., 2010. The research of Internet of things’ supporting technologies which face the logistics industry. In Proceedings - 2010 International Conference on Computational Intelligence and Security, CIS 2010. pp. 659–663.

Choi, C. et al., 2008. MiRE: A minimal rule engine for context-aware mobile devices. In 3rd International Conference on Digital Information Management, ICDIM 2008. pp. 172–177.

Choujaa, D. & Dulay, N., 2009. Activity inference through sequence alignment. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 19–36.

Conti, J.P., 2006. ITU Internet Reports 2005: The Internet of Things,

Debattista, J., Lange, C. & Auer, S., 2015. Luzzu - A framework for linked data quality assessment. In ISWC 2015 Posters and Demonstrations Track. CEUR Workshop Proceedings. CEUR-WS.

Delir Haghighi, P. et al., 2008. Reasoning about context in uncertain pervasive computing environments. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 112–125.

Dey, A.K., 2001. Understanding and Using Context. Personal and Ubiquitous Computing, 5(1), pp.4–7.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 72 2016-09-29

Dey, A.K. & Abowd, G.D., 1999. Towards a Better Understanding of Context and Context-Awareness. Computing Systems, 40(3), pp.304–307.

Dohr, A. et al., 2010. The Internet of Things for Ambient Assisted Living. 2010 Seventh International Conference on Information Technology: New Generations, pp.804–809.

Elastic.co, 2016. Elasticsearch.

Endsley, M.R., 2000. Theoretical Underpinnings of Situation Awareness: A Critical Review. In M. R. Endsley & D. J. Garland, eds. Situation Awareness Analysis and Measurement. Lawrence Erlbaum Associates, Inc., p. 408.

EPoSS, 2008. Internet of Things in 2020 A ROADMAP FOR THE FUTURE. European Technology Platform on Smart Systems Integration, pp.1–27.

Etzion, O. & Niblett, P., 2010. Event Processing in Action,

Faye, D.C., Cure, O. & Blin, G., 2016. A survey of RDF storage approaches.

Feng, L., 2010. Supporting context-aware database querying in an Ambient Intelligent environment. 2010 3rd IEEE International Conference on Ubi-Media Computing, U-Media 2010, pp.161–166.

Fritzke, B., 1995. A Growing Neural Gas Network Learns Topologies. Advances in Neural Information Processing Systems 7, 7(1), pp.625–632.

Gao, C., Ling, Z. & Yuan, Y., 2011. The research and implement of smart home system based on Internet of Things. In 2011 International Conference on Electronics, Communications and Control, ICECC 2011 - Proceedings. pp. 2944–2947.

Glenn, S., 1976. A Mathematical Theory of Evidence., Princeton University Press.

Grau, B.C. et al., 2008. OWL 2: The next step for OWL. Web Semantics, 6(4), pp.309–322.

Grosof, B.N. et al., 2003. Description Logic Programs : Combining Logic Programs with Description Logic. WWW ’03 Proceedings of the 12th international conference on World Wide Web, pp.48–57.

Gruber, T.R., 1995. Toward principles for the design of ontologies used for knowledge sharing. International Journal of Human-Computer Studies, 43(5–6), pp.907–928.

Gu, T., Pung, H.K. & Zhang, D.Q., 2005. A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, 28(1), pp.1–18.

Haarslev, V. & Möller, R., 2003. Racer: A Core Inference Engine for the Semantic Web. Proceedings of the 2nd International Workshop on Evaluation of Ontologybased Tools, 87, pp.27–36.

Haghighi, P.D., Zaslavsky, A. & Krishnaswamy, S., 2006. An Evaluation of Query Languages for Context-Aware Computing. In the 1st International Workshop on Flexible Database and Information Systems Technology (FlexDBIST-06), Held in conjunction with DEXA-06 International Conference on Database and Expert Systems Applications. pp. 455–462.

Halpern, J.Y., 2003. Reasoning About Uncertainty,

Hauswirth, M. et al., 2009. Rapid Prototyping of Semantic Mash-Ups through Semantic Web Pipes. Proceedings of the 18th International Conference on World Wide Web, Madrid, pp.581–590.

Henricksen, K., 2003. A framework for context-aware pervasive computing applications. The School of Information Technology and Electrical Engineering, The University of Queensland, pp.13–20.

Hibernate.org, 2016. Hybernate.

Homey, T., Jungert, E. & Folkesson, M., 2003. An ontology controlled data fusion process for a query language. In Proceedings of the 6th International Conference on Information Fusion, FUSION 2003. IEEE Computer Society, pp. 530–537.

Horridge, M. & Bechhofer, S., 2011. The OWL API: A Java API for OWL ontologies. Semantic Web, 2(1), pp.11–21.

Horrocks, I. et al., 2004. SWRL : A Semantic Web Rule Language Combining OWL and RuleML. W3C Member submission 21, (May 2004), pp.1–20.

ter Horst, H.J., 2004. Extending the RDFS Entailment Lemma. In The Semantic Web – ISWC 2004. pp. 77–91.

Ireland, C. et al., 2009. A classification of object-relational impedance mismatch. Proceedings - 2009 1st International

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 73 2016-09-29

Conference on Advances in Databases, Knowledge, and Data Applications, DBKDA 2009, pp.36–43.

Jakkula, V.R., Crandall, A.S. & Cook, D.J., 2007. Knowledge discovery in entity based smart environment resident data using temporal relation based data mining. In Proceedings - IEEE International Conference on Data Mining, ICDM. pp. 625–630.

Kahn, B.K., Strong, D.M. & Wang, R.Y., 2002. Information Quality Benchmarks: Product and Service Performance. COMMUNICATIONS OF THE ACM, 45(4), pp.184–192.

Kasteren, T. Van et al., 2008. Accurate Activity Recognition in a Home Setting. In UbiComp ’08 Proceedings of the 10th international conference on Ubiquitous computing. pp. 1–9.

Kaur, K. & Rani, R., 2015. A Smart Polyglot Solution for Big Data in Healthcare. IT Professional, 17(6), pp.48–55.

Keßler, C., Raubal, M. & Wosniok, C., 2009. Semantic rules for context-aware geographical information retrieval. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 77–92.

Kim, Y. & Lee, K., 2006. A Quality Measurement Method of Context Information in Ubiquitous Environments. In 2006 International Conference on Hybrid Information Technology. pp. 576–581.

Kokar, M.M., Matheus, C.J. & Baclawski, K., 2009. Ontology-based situation awareness. Information Fusion, 10(1), pp.83–98.

Kokar, M.M. & Wang, J., 2002. An Example of Using Ontologies and Symbolic Information in Automatic Target Recognition. In In Sensor Fusion: Architectures, Algorithms, and Applications VI. pp. 40–50.

Kokar, M.M. & Wang, J., 2002. Using ontologies for recognition: An example. In Proceedings of the 5th International Conference on Information Fusion, FUSION 2002. IEEE Computer Society, pp. 1324–1330.

Konstantinou, N. et al., 2007. Priamos: a middleware architecture for real-time semantic annotation of context features. In 3rd IET International Conference on Intelligent Environments (IE 07). IEE, pp. 96–103.

Kontokostas, D. et al., 2014. Databugger: A Test-driven Framework for Debugging the Web of Data. Proceedings of the Companion Publication of the 23rd International Conference on World Wide Web Companion, (Section 2), pp.115–118.

Kortuem, G. et al., 2010. Smart objects as building blocks for the Internet of things. Internet Computing, IEEE, 14(1), pp.44–51.

Krogstie, J., Lindland, O.I. & Sindre, G., 1995. Defining quality aspects for conceptual models. ISCO, 1995, pp.216–231.

Lewis, D.D., N’{e}dellec, C. & Rouveirol, C., 1998. Naive (Bayes) at Forty: The Independence Assumption in Information Retrieval. Machine Learning: ECML-98, pp.4--15.

Li, L., 2011. Application of the internet of thing in green agricultural products supply chain management. In Proceedings - 4th International Conference on Intelligent Computation Technology and Automation, ICICTA 2011. pp. 1022–1025.

Lim, B. & Dey, A., 2010. Toolkit to support intelligibility in context-aware applications. Proceedings of the 12th ACM international conference …, pp.13–22.

Loke, S.W., 2010. Incremental awareness and compositionality: A design philosophy for context-aware pervasive systems. Pervasive and Mobile Computing, 6(2), pp.239–253.

Loke, S.W., 2004. Representing and reasoning with situations for context-aware pervasive computing: a logic programming perspective. The Knowledge Engineering Review, 19(3), pp.213–233.

Ma, M. et al., 2015. OntoEvent: An Ontology-Based Event Description Language for Semantic Complex Event Processing. In Springer International Publishing, pp. 448–451. Available at: http://link.springer.com/10.1007/978-3-319-21042-1_38 [Accessed August 23, 2016].

Madden, S. & Franklin, M.J., 2002. Fjording the stream: an architecture for queries over streaming\nsensor data. Proceedings 18th International Conference on Data Engineering, pp.1–25.

Maia, P. et al., 2007. On the Development of Systems-of-Systems based on the Internet of Things. In Proceedings of the 2014 European Conference on Software Architecture Workshops - ECSAW ’14. New York, New York, USA: ACM Press, pp. 1–8.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 74 2016-09-29

Manzoor, A., Truong, H.L. & Dustdar, S., 2008. On the evaluation of quality of context. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 140–153.

Manzoor, A., Truong, H.L. & Dustdar, S., 2009. Using quality of context to resolve conflicts in context-aware systems. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 144–155.

Mardani, A., Jusoh, A. & Zavadskas, E.K., 2015. Fuzzy multiple criteria decision-making techniques and applications - Two decades review from 1994 to 2014. Expert Systems with Applications, 42(8), pp.4126–4148.

Martín, D., Lamsfus, C. & Alzua, A., 2010. Automatic context data life cycle management framework. In ICPCA10 - 5th International Conference on Pervasive Computing and Applications. pp. 330–335.

Matheus, C.J., Baclawski, K.P. & Kokar, M.M., 2003. Derivation of ontological relations using formal methods in a situation awareness scenario. Proc. SPIE, 5099(April), pp.298–309.

Matheus, C.J., Kokar, M.M. & Baclawski, K., 2003. A core ontology for situation awareness. In Proceedings of the 6th International Conference on Information Fusion, FUSION 2003. IEEE Computer Society, pp. 545–552.

Mayrhofer, R., 2004. An Architecture for Context Prediction. Johannes Kepler University of Linz, Austria.

McBride, B., 2002. Jena: A semantic web toolkit. IEEE Internet Computing, 6(6), pp.55–58.

McCarthy, J., 1987. Generality in Artificial Intelligence. Commun. ACM, 30(12), pp.1030–1035.

McCowan, I. et al., 2005. Automatic analysis of multimodal group actions in meetings. IEEE Transactions on Pattern Analysis and Machine Intelligence, 27(3), pp.305–317.

McGuinness, D.L., 2003. Ontologies for information fusion. In Proceedings of the 6th International Conference on Information Fusion, FUSION 2003. IEEE Computer Society, pp. 650–657.

McKeever, S. et al., 2009. Using dempster-shafer theory of evidence for situation inference. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 149–162.

Mongodb.com, 2016. MongoDB. 2016.

Moore, P., Xhafa, F. & Barolli, L., 2014. Context-as-a-Service: A Service Model for Cloud-Based Systems. In 2014 Eighth International Conference on Complex, Intelligent and Software Intensive Systems. IEEE, pp. 379–385.

Motik, B., Sattler, U. & Studer, R., 2005. Query answering for OWL-DL with rules. Web Semantics, 3(1), pp.41–60.

Motik, B., Shearer, R. & Horrocks, I., 2009. Hypertableau reasoning for description logics. Journal of Artificial Intelligence Research, 36, pp.165–228.

Neisse, R., Wegdam, M. & Van Sinderen, M., 2008. Trustworthiness and quality of context information. In Proceedings of the 9th International Conference for Young Computer Scientists, ICYCS 2008. pp. 1925–1931.

Nowak, C., 2003. On ontologies for high-level information fusion. In Sixth International Conference of Information Fusion, 2003. Proceedings of the. IEEE, pp. 657–664.

Nurmi, P. & Floréen, P., 2004. Reasoning in Context-Aware Systems. Position Paper. Department of Computer Science, University of Helsinki, (1), pp.1–6.

Nurmi, P., Martin, M. & Flanagan, J. a, 2005. Enabling proactiviness through Context Prediction. Workshop on Context Awareness for Proactive Systems, 2005 (CAPS 2005), pp.159–168.

Padovitz, A. et al., 2006. A unifying model for representing and reasoning about context under uncertainty. IN PROCEEDINGS OF THE 11TH INTERNATIONAL CONFERENCE ON INFORMATION PROCESSING AND MANAGEMENT OF UNCERTAINTY IN KNOWLEDGE-BASED SYSTEMS (IPMU.

Padovitz, A., 2006. Context Management and Reasoning about Situations in Pervasive Computing. Monash University.

Padovitz, A., Loke, S.W. & Zaslavsky, A., 2008. The ECORA framework: A hybrid architecture for context-oriented pervasive computing. Pervasive and Mobile Computing, 4(2), pp.182–215.

Padovitz, A., Loke, S.W. & Zaslavsky, A., 2004. Towards a theory of context spaces. In Proceedings - Second IEEE Annual Conference on Pervasive Computing and Communications, Workshops, PerCom. pp. 38–42.

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 75 2016-09-29

Paul Andlinger, 2015. Graph DBMS increased their popularity by 500% within the last 2 years. 3 March 2015.

Perera, C. et al., 2014. Context aware computing for the internet of things: A survey. IEEE Communications Surveys and Tutorials, 16(1), pp.414–454.

Perich, F. et al., 2004. On data management in pervasive computing environments. IEEE Transactions on Knowledge and Data Engineering, 16(5), pp.621–634.

Petrolo, R., Loscrí, V. & Mitton, N., 2014. Towards a smart city based on cloud of things. In Proceedings of the 2014 ACM international workshop on Wireless and mobile technologies for smart cities - WiMobCity ’14. New York, New York, USA: ACM Press, pp. 61–66.

Poveda-Villalón, M., Suárez-Figueroa, M.C. & Gómez-Pérez, A., 2012. Validating ontologies with OOPS! In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). pp. 267–281.

Prasad, S. & Avinash, S.B., 2014. Application of polyglot persistence to enhance performance of the energy data management systems. In 2014 International Conference on Advances in Electronics Computers and Communications. IEEE, pp. 1–6.

Rabiner, L.R., 1989. A tutorial on hidden Markov models and selected applications in speech recognition. Proceedings of the IEEE, 77(2), pp.257–286.

Ramparany, F. et al., 2007. An open context information management infrastructure the IST-amigo project. Intelligent Environments, 2007. IE 07. 3rd IET International Conference on, pp.398–403.

Reichle, R. et al., 2008. A Context Query Language for Pervasive Computing Environments. 2008 Sixth Annual IEEE International Conference on Pervasive Computing and Communications (PerCom), pp.434–440.

Riva, O. & Di Flora, C., 2006. Contory: A smart phone middleware supporting multiple context provisioning strategies. In Proceedings - International Conference on Distributed Computing Systems.

Rosati, R., 2006. DL+log: Tight Integration of Description Logics and Disjunctive Datalog. In The Tenth International Conference on Principles of Knowledge Representation and Reasoning KR2006. AAAI Press, pp. 68–78.

Rosi, A. et al., 2011. Social sensors and pervasive services: Approaches and perspectives. In 2011 IEEE International Conference on Pervasive Computing and Communications Workshops, PERCOM Workshops 2011. pp. 525–530.

SAY, B., 1997. Keith Devlin, Logic and Information. Cambridge, UK: Cambridge University Press, 1991. ISBN 0-521-49971-2, £19.95 (paperback). 0-521-41031-4 (hardback). Natural Language Engineering, 3(4), p.S135132499700140X.

Schilit, B., Adams, N. & Want, R., 1994. Context-Aware Computing Applications. Proceedings of the 1994 First Workshop on Mobile Computing Systems and Applications, pp.85–90.

Schreiber, F. & Camplani, R., 2012. Perla: A language and middleware architecture for data management and integration in pervasive information systems. Software …, 38(2), pp.478–496.

Segers, R. et al., 2015. ESO: A Frame Based Ontology for Events and Implied Situations. In In Proceedings of Maplex2015. Naushad.

Sigg, S. et al., 2012. Investigation of context prediction accuracy for different context abstraction levels. IEEE Transactions on Mobile Computing, 11(6), pp.1047–1059.

Simperl, E., 2009. Reusing ontologies on the Semantic Web: A feasibility study. Data & Knowledge Engineering, 68(10), pp.905–925.

Sirin, E. et al., 2007. Pellet: A practical OWL-DL reasoner. Web Semantics, 5(2), pp.51–53.

Sowa, J.F., 1984. Conceptual structures : information processing in mind and machine, Addison-Wesley.

Sowa, J.F., 2000. Knowledge representation : logical, philosophical, and computational foundations, Brooks/Cole.

Sowa J.F., Conceptual Graphs. Proposal for an ISO Standard. Reference number of working document: ISO/JTC1/SC 32/WG2 N 000, 2001.

Stabeler, M. et al., 2009. Basadaeir: harvesting user profiles to bootstrap pervasive applications. The Seventh International Conference on Pervasive Computing - Late Breaking Results, (4).

Steinberg, A.N., Bowman, C.L. & White, F.E., 1999. Revisions to the JDL data fusion model. Proceedings of SPIE, 3719(1),

D4.3 Theoretical Framework for Context and Situation Awareness in IoT

© 688203 bIoTope Project Partners 76 2016-09-29

pp.430–441.

Stephan, S., 2008. Development of a Novel Context Prediction Algorithm and Analysis of Context Prediction Schemes. kassel university press GmbH.

Sundmaeker, H., Guillemin, P. & Friess, P., 2010. Vision and challenges for realising the Internet of Things,

Sycara, K., Paolucci, M. & Lewis, M., 2003. Information discovery and fusion: semantics on the battlefield. In Sixth International Conference of Information Fusion, 2003. Proceedings of the. IEEE, pp. 538–544.

Tan, L. & Wang, N., 2010. Future internet: The Internet of Things. In 2010 3rd International Conference on Advanced Computer Theory and Engineering(ICACTE). pp. 376–380.

Tanenbaum, A.S., 1996. Computer Networks,

Tartir, S. et al., 2005. OntoQA: Metric-Based Ontology Quality Analysis. IEEE Workshop on Knowledge Acquisition from Distributed, Autonomous, Semantically Heterogeneous Data and Knowledge Sources, pp.45–53.

Terada, T. et al., 2004. Ubiquitous Chip: A Rule-Based I/O Control Device for Ubiquitous Computing. In A. Ferscha & F. Mattern, eds. Pervasive Computing SE - 18. Lecture Notes in Computer Science. Springer Berlin Heidelberg, pp. 238–253.

Teymourian, K. et al., 2009. Towards semantic event-driven systems. In 3rd International Conference on New Technologies, Mobility and Security, NTMS 2009.

Tsarkov, D. & Horrocks, I., 2006. FaCT++ Description Logic Reasoner: System Description. In Proceedings of the Third International Joint Conference (IJCAR). pp. 292–297.

Vaidya, O.S. & Kumar, S., 2006. Analytic hierarchy process: An overview of applications. European Journal of Operational Research, 169(1), pp.1–29.

Vermesan, O. et al., 2009. Internet of Things Strategic Research Roadmap. Cluster of European Research Projects on the Internet of Things, Cerp-Iot, pp.9–52.

Vlachostergiou, A. et al., 2015. Smart home context awareness based on Smart and Innovative Cities. In Proceedings of the 16th International Conference on Engineering Applications of Neural Networks (INNS) - EANN ’15. New York, New York, USA: ACM Press, pp. 1–10.

Völkel, M., 2006. RDFReactor -- From Ontologies to Programatic Data Access. In In Proc. of the Jena User Conference.

Wagner, M., Reichle, R. & Geihs, K., 2011. Context as a service - Requirements, design and middleware support. In 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops). IEEE, pp. 220–225.

Wang, Y.-W., Yu, H.-L. & Li, Y., 2011. Internet of things technology applied in medical information. Consumer Electronics, Communications and Networks (CECNet), 2011 International Conference on, pp.430–433.

Weiss Ferreira, L. & Decker, C., 2010. A survey on organic smart labels for the Internet-of-Things. In 2010 Seventh International Conference on Networked Sensing Systems (INSS). IEEE, pp. 161–164.

Ye, J. et al., 2007a. Ontology-based models in pervasive computing systems. The Knowledge Engineering Review, 22(4), pp.315–347.

Ye, J. et al., 2015. Semantic web technologies in pervasive computing: A survey and research roadmap. Pervasive and Mobile Computing, 23, pp.1–25.

Ye, J. et al., 2007b. Using situation lattices to model and reason about context. Modeling and Reasoning in Context (MRC) with Special Session on the Role of Contextualization in Human Tasks (CHUT) which is held in conjunction with CONTEXT, pp.1–12.

Ye, J., Dobson, S. & McKeever, S., 2012. Situation identification techniques in pervasive computing: A review. Pervasive and Mobile Computing, 8(1), pp.36–66.

Zadeh, L.A., 1975. Fuzzy logic and approximate reasoning. Synthese, 30(3–4), pp.407–428.

Zhou, X. et al., 2009. SPBCA: Semantic pattern-based context-aware middleware. In Proceedings of the International Conference on Parallel and Distributed Systems - ICPADS. pp. 891–895.

Zimmermann, A. et al., 2007. An Operational Definition of Context. CONTEXT’07 Proceedings of the 6th international and interdisciplinary conference on Modeling and using context, pp.558–571.


Recommended