integrating semantic networks and object-oriented … · tled integrating semantic networks and...

INTEGRATING SEMANTICNETWORKS AND

OBJECT-ORIENTED MODEL TOREPRESENT AND MANAGE

CONTEXT

June 2012David Sorrentino

Master of Science in Computer Science

INTEGRATING SEMANTIC NETWORKSAND OBJECT-ORIENTED MODEL TOREPRESENT AND MANAGE CONTEXT

David SorrentinoMaster of ScienceComputer ScienceJune 2012School of Computer ScienceReykjavík University

M.Sc. PROJECT REPORTISSN 1670-8539

Integrating Semantic Networks and Object-Orientedmodel to represent and manage context

by

David Sorrentino

Project report submitted to the School of Computer Scienceat Reykjavík University in partial fulfillment of

the requirements for the degree ofMaster of Science in Computer Science

June 2012

Project Report Committee:

Hannes Högni Vilhjálmsson, SupervisorAssociate Professor, Reykjavík University

Emanuela Merelli, SupervisorProfessor, University of Camerino

Marjan SirjaniAssociate Professor, Reykjavík University

CopyrightDavid Sorrentino

June 2012

Date

Hannes Högni Vilhjálmsson, SupervisorAssociate Professor, Reykjavík University

Emanuela Merelli, SupervisorProfessor, University of Camerino

Marjan SirjaniAssociate Professor, Reykjavík University

The undersigned hereby certify that they recommend to the School of Com-puter Science at Reykjavík University for acceptance this project report enti-tled Integrating Semantic Networks and Object-Oriented model to rep-resent and manage context submitted by David Sorrentino in partial ful-fillment of the requirements for the degree of Master of Science in Com-puter Science.

Date

David SorrentinoMaster of Science

The undersigned hereby grants permission to the Reykjavík University Li-brary to reproduce single copies of this project report entitled IntegratingSemantic Networks and Object-Oriented model to represent and man-age context and to lend or sell such copies for private, scholarly or scientificresearch purposes only.

The author reserves all other publication and other rights in association withthe copyright in the project report, and except as herein before provided, nei-ther the project report nor any substantial portion thereof may be printed orotherwise reproduced in any material form whatsoever without the author’sprior written permission.

Integrating Semantic Networks and Object-Oriented model torepresent and manage context

David Sorrentino

June 2012

Abstract

In few years context-aware computing will pervade almost every aspect ofour lives. One of the crucial issues related to this field is to have a properand convenient model to represent and manage the context. Existing rep-resentation models like ontologies constitute a well researched and maturesolution. However, they are not made to represent continuously changingdata; moreover, building and maintaining them might be highly error-prone,time-consuming, and non-scalable processes, and they can become tedioustasks if they are done manually.This thesis proposes a model to represent and manage contextual informationof different types, generated by a variety of heterogeneous sources and withdifferent levels of granularity. The model is derived from the integration ofSemantic Networks with the Object-Oriented software development modeland has been implemented by exploiting the use of scripting languages andtheir properties, such as dynamic typing, meta-programming, and introspec-tion. A context-aware infrastructure (CAFE) based on this model and writ-ten in Python is presented and, by showing an illustrative contextual scenarioimplemented in CAFE, it is demonstrated that the proposed model guaran-tees high readability, flexibility, scalability, general-purpose, and modular-ity.

A mio padre e mia madre, a cui devo tutto..

A mio fratello Marco..

Al mare..

vii

Acknowledgements

This thesis dissertation marks the end of a long and eventful journey which represents themost important phase of my academic career. It is a pleasant task to express my thanks toall those who contributed in many ways to the success of this study and made it possibleand an unforgettable experience for me.

Above all I would like to acknowledge the remarkable sacrifices that my parents Gerardoand Rosalba made to ensure that I had an excellent education. For this and for being aconstant source of love, encouragement and support for me, I am forever in their debt. Itis to them that I dedicate this dissertation. Grazie papà e mamma per avermi regalato unavita meravigliosa. Le soddisfazioni più grandi che ho avuto, sto avendo, ed avrò, sonosolo merito vostro.

My brother and my best friend Marco needs a special mention, since he has been a truesupport always and I have not missed a single opportunity to trouble him and load himwith my difficulties. This dissertation is also dedicated to him. Grazie infinite per essercisempre stato Marco.

I would like to thank my “brothers-in-arms” Andrea, Lillo and Alfredo with which Ispent an extraordinary year of my life in Reykjavik. Let’s keep in touch mates!A huge thank you to all the wonderful people I met during my staying in Reykjavik. Thankyou Arabella, Christian, Michael, Katrin. If this experience has been unforgettableis also because of you. A special thank you to Roxy. Words fail me to express myappreciation for her massive support and generous care. She was always beside me duringthe happy and hard moments to push me and motivate me. Thank you Roxy, a journey iseasier when you travel together.

Huge and warm thanks go to my uncle Luigi, my aunt Ida Rosa, and my cousin Monicafor their continuous support. E’ bello avervi in famiglia. Vi voglio bene.

viii

Thank you, Arianna, for the memorable moments together.Special thanks also to my friends Lorenzo, Luca S., Mirko, Luca O., Daniele, Antonio,Iacopo, Gianluca, and Saverio.

Last but not least, I would like to expand my thanks to my supervisors Hannes andEmanuela, and my committee member Marjan. If this dissertation looks in good shape,it is also because of your precious help and guidance.

David Sorrentino

ix

Contents

List of Figures xi

List of Tables xiii

1 Introduction 11.1 Research statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Overall project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Thesis organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Context-aware computing 52.1 Definition of context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Types of context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Context creation and context composition . . . . . . . . . . . . . . . . . 92.4 Context representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Context awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Context-aware applications . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6.1 Types of context-aware applications classified by features . . . . 132.6.2 Examples of context-aware applications . . . . . . . . . . . . . . 16

2.7 Context reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Semantic networks 193.1 Definition of Semantic Networks . . . . . . . . . . . . . . . . . . . . . . 203.2 Understanding Semantic Networks . . . . . . . . . . . . . . . . . . . . . 203.3 Inferring knowledge with Semantic Networks . . . . . . . . . . . . . . . 243.4 Advantages and disadvantages of Semantic Networks . . . . . . . . . . . 263.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Related works 314.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

x

5 Approach 375.1 Choosing a representation model for the context . . . . . . . . . . . . . . 37

5.1.1 Context as a table . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.2 Context as a relational database . . . . . . . . . . . . . . . . . . 395.1.3 Context as a Semantic Network . . . . . . . . . . . . . . . . . . 41

5.2 Semantic Networks vs Object-Oriented model . . . . . . . . . . . . . . . 455.2.1 Differences analysis . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2 Existing approaches . . . . . . . . . . . . . . . . . . . . . . . . 475.2.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3 Weak spots of the approach . . . . . . . . . . . . . . . . . . . . . . . . . 495.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 CAFE: a context-aware infrastructure 516.1 Context-Spaces, entities and properties . . . . . . . . . . . . . . . . . . . 546.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.1 Environmental layer . . . . . . . . . . . . . . . . . . . . . . . . 596.2.2 Data processing layer . . . . . . . . . . . . . . . . . . . . . . . . 596.2.3 Knowledge layer . . . . . . . . . . . . . . . . . . . . . . . . . . 606.2.4 Reasoning layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3 Resource mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.3.1 Classes mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 616.3.2 Objects mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 626.3.3 Attributes mapping . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.4 Inference and reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7 Results 677.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8 Conclusions 798.1 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Bibliography 83

xi

List of Figures

1.1 Project overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Multidimensional features of types of context . . . . . . . . . . . . . . . 92.2 Classification of context-aware application by features . . . . . . . . . . 14

3.5 Example of Semantic Network . . . . . . . . . . . . . . . . . . . . . . . 233.7 Symmetric relationships in Semantic Networks . . . . . . . . . . . . . . 243.9 Example of knowledge inference in Semantic Networks . . . . . . . . . . 253.11 A more complicated example of inference in Semantic Networks . . . . . 263.12 Example of a link used with different meanings . . . . . . . . . . . . . . 273.13 Removing ambiguity from a link . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Contextual data represented in relational model . . . . . . . . . . . . . . 405.2 Linking additional data to the existing schema . . . . . . . . . . . . . . . 405.3 Normalized schema after adding a new dataset . . . . . . . . . . . . . . . 415.4 Example of a big relational schema . . . . . . . . . . . . . . . . . . . . . 425.5 Subject-predicate-object model . . . . . . . . . . . . . . . . . . . . . . . 425.6 Separate graphs sharing some identifiers . . . . . . . . . . . . . . . . . . 435.7 Merged graph obtained from the union of triples . . . . . . . . . . . . . . 435.8 Contextual data represented as Semantic Networks . . . . . . . . . . . . 445.9 Separate datasets sharing some data . . . . . . . . . . . . . . . . . . . . 445.10 New dataset obtained by merging the existing datasets . . . . . . . . . . . 455.11 Multiple class inheritance in Semantic Networks . . . . . . . . . . . . . 465.12 Multiple class membership in Semantic Networks . . . . . . . . . . . . . 46

6.1 CAFE’s logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 CAFE’s generic schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 UML Sequence Diagram of a simple scenario in CAFE . . . . . . . . . . 536.4 A Context-Space describing a home environment . . . . . . . . . . . . . 556.5 CAFE’s architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

xii

6.6 UML Class Diagram of an illustrative class mapped in CAFE . . . . . . . 616.7 Result of a class mapping in CAFE . . . . . . . . . . . . . . . . . . . . . 616.8 An example of Semantic Network backbone in CAFE . . . . . . . . . . . 63

7.1 UML Class Diagram of the scenario . . . . . . . . . . . . . . . . . . . . 687.2 Creation of a new Context-Space in CAFE . . . . . . . . . . . . . . . . . 697.3 Definition of entities classes in CAFE . . . . . . . . . . . . . . . . . . . 697.4 Definition of entities in CAFE . . . . . . . . . . . . . . . . . . . . . . . 707.5 Example of definition of a local-context in CAFE . . . . . . . . . . . . . 717.6 Example of definition of properties in CAFE . . . . . . . . . . . . . . . . 717.7 Visualisation of a contextual backbone in CAFE . . . . . . . . . . . . . . 727.8 Simulated data from cameras sent to the Sensors Server . . . . . . . . . . 737.9 Graphical representation of the context in CAFE . . . . . . . . . . . . . . 747.10 An example of a SPARQL query performed by means of our query-client 757.11 Saving a context’s snapshot into a binary file . . . . . . . . . . . . . . . . 757.12 Loading a context’s history from a binary file . . . . . . . . . . . . . . . 767.13 Context as OWL ontology . . . . . . . . . . . . . . . . . . . . . . . . . 767.14 Merging two different Context-Spaces . . . . . . . . . . . . . . . . . . . 77

xiii

List of Tables

2.1 Types of context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Types of context representation . . . . . . . . . . . . . . . . . . . . . . . 112.3 Pros and cons of types of context representation . . . . . . . . . . . . . . 12

5.1 Contextual data represented in tabular model . . . . . . . . . . . . . . . . 385.2 Multiple information in tabular model . . . . . . . . . . . . . . . . . . . 38

1

Chapter 1

Introduction

Human beings manage without many problems to exchange ideas among them and reactproperly. This is due to several factors, including the richness of the language they shareand the common sense of understanding how daily situations work. When human beingstalk to other human beings, they are able to use information retrieved from the currentsituation, or context, to increase the bandwidth of the conversation.Unfortunately, this ability to exchange ideas is not applicable when human beings interactwith computers. This happens since computers do not understand our language, do notunderstand how our world works, and they can not retrieve information from the currentsituation; at least they can not do it as easily as the majority of human beings do.In traditional interactive or desktop computing, users use an impoverishment mechanismto provide information to computers, typically by means of a keyboard or a mouse. Theresult is that the information has to be explicitly provided to computers. In practice, theusers translate what they want to perform into specific commands about how accomplishthe task, and therefore they use keyboard and mouse to articulate these details to the com-puter, so that it can execute their commands. This is not similar at all to the interactionof human beings with other human beings. Consequently, computers are not able to fullyexploit the context of a conversation with a human being. By improving the access tothe context for computers, users can increase the richness of the communication withina human-computer interaction and make the production of computational services evenmore useful.We can either improve the language that the human beings use to interact with computers,or increase the quantity of information related to a given situation, or context, which isavailable to the computers.In particular the first approach tries to improve the above-mentioned interaction, allowingthe human being to communicate in a much more natural way. However, this type of

2 Integrating Semantic Networks and O-O model to represent and manage context

communication is explicit, since the computer only knows what the user tells it. In fact,techniques such as speech and gestures recognition do not provide to computers moreinformation than the explicit input.As it is clear from interactions among human beings, information retrieved from the cur-rent situation, such as facial expressions, emotions, past and future events, the presenceof other people in the room, and the relationships with these other people, are crucial inorder to understand what is happening in a given environment and in a given moment.The process consisting in the building of this common sense of understanding betweentwo people is called grounding (Clark & Brennan, 1991). Since both human beings insuch interaction share the information retrieved from the current situation, there is noneed to make it explicit. This need for explicit information does exist in human-computerinteractions, for the computer does not share this implicit information which representsthe context. Therefore, the goal of context-aware computing is to use the context as acue to enrich the impoverished interaction among human beings and computers, makingit easier and more efficient.Indeed, researchers belonging to this field work to make it simpler for users to interactwith computers and environments, allowing the users not to have to think consciouslyabout how to use computers. For this purpose, the approach for developing context-awareapplications is to gather implicit contextual information by using automatic means, mak-ing them easily available to the run-time environment of the computer, and letting theapplication designer free to decide which information is relevant and how to handle it.This is, without any doubt, a better approach, since it can remove the burden of the usersto make all the information explicit and put the decisions about what is relevant in thedesigner’s hands.

1.1 Research statement

One of the crucial issues related to context-aware computing is to have a proper and con-venient model to represent and manage the context. Existing representation models likeontologies constitute a well researched and mature solution. However, they are not madeto represent continuously changing data; moreover, building and maintaining them mightbe highly error-prone, time-consuming, and non-scalable processes, and they can becometedious tasks if they are done manually.In this thesis work we propose a model that is highly-readable, flexible, scalable, general-

purpose, and modular, in order to represent and manage contextual information of differ-ent types, generated by a variety of heterogeneous sources and with different levels of

David Sorrentino 3

granularity.This model is based on the integration of Semantic Networks with the Object-Orientedmodel1, enables reasoning, guarantees an easy handling of the atomic data forming thecontext, and is capable to manage incomplete or not accurate information due to incom-pleteness of data from sensors.

1.2 Overall project

This work was conceived as part of a larger project in Assisted Living2. The main projectidea is a real-time tracking and simulation of a home environment to identify and avertpotentially dangerous situations.

Figure 1.1: Project overview

The general approach is to embed a range of sensors in objects and appliances, in order toallow context awareness. By exploiting the context a state of the real world is describedin an abstract language.Eventually, a simulation, that simulates both the physics of objects and the behaviour ofthe human, runs a number of steps into the future, and watches for possible dangerousstates (as defined by given rules). If the current behaviour of the human seems to be lead-ing towards a disaster (according to the simulation), then the human is alerted throughvoice, sounds or projected visuals.For this purpose, the goal of the user needs to be defined; conjoint use of activity recog-nition and prediction is exploited to achieve this.

1 Object-oriented modelling is a software engineering approach that models a system as a group ofinteracting objects. Each object represents some entity of interest in the system being modelled, and ischaracterised by its class, its state (data elements), and its behaviour. [wikipedia.org]

2 Assisted Living provides supervision or assistance with activities of daily living; coordination of ser-vices by outside health care providers; and monitoring of resident activities to help to ensure their health,safety, and well-being. [wikipedia.org]


1.3 Thesis organization

Chapter 2 and Chapter 3 provide some useful background information by giving to thereader a quick overview about the main concepts which this thesis work is based on.We chose not to dedicate a chapter to the Object-Oriented model, since we suppose itconstitutes an already well-know subject to everybody. However, detailed informationabout it can be found in (Nierstrasz, 1989).In Chapter 2 we clarify the concept of context, context representation, context awareness,listing also some canonical examples of context-aware applications.In Chapter 3 we define the concept of Semantic Network, providing, in addition, simpleexamples with the purpose to make it clearer to the reader’s eyes. Moreover, we also showthe most important properties characterizing Semantic Networks, and the advantages anddisadvantages related to the use of them.

In Chapter 4 we present the main existing infrastructures aimed at providing tools forbuilding context-aware applications and systems, mostly focusing on the approach theyuse to deal with context representation and the knowledge management.

In Chapter 5 we explore some of the main models suitable for representing context,analysing their strong and weak spots and explaining the reasons why we finally pre-ferred Semantic Networks. Furthermore, we describe in details the problem statementand how our approach addresses it. Finally, we point out the weak spots characterizingour methodology.

In Chapter 6 we introduce CAFE, a contextual infrastructure based on the integration ofSemantic Networks with the Object-Oriented model, describing how we implemented itand listing its main features.

In Chapter 7 we propose an illustrative scenario in order to show how it is possible touse CAFE to represent and manage the context related to that scenario. We also usethis demonstration to underline the results we achieved and point out the limitations ofCAFE.

Finally, in Chapter 8 we summarise our thesis work, highlighting the results of our studyand proposing possible future works related to it.

5

Chapter 2

Context-aware computing

Context-aware computing is a mobile computing paradigm in which applications can dis-cover and take advantage of contextual information, such as user location, time of day,nearby people and devices, and user activity (G. Chen & Kotz, 2000).Naturally, context-aware computing environments are based on the knowledge of the con-text. This is because users have the expectation that they can access whichever informa-tion and service they want, whenever they want, and wherever they are. In order to ensurethat these expectations are satisfied, the need of a context is clear. Indeed, the contextcan be used with the aim of helping to determine which information or services should bemade available to the users (Krumm, 2009).

Since our aim is to propose a model to represent and manage the context, in this chapterwe chose to clarify basic concepts such as context, context representation, context aware-

ness, and context reasoning, providing also some canonical examples of context-awareapplications.

2.1 Definition of context

Merriam-Webster defines the context as “the interrelated conditions in which somethingexists or occurs”.

In 1994 Schilit and Theimer introduced for the first time the term context-aware. At thatjuncture, they referred to the context as location, people’s identity and close objects, andchanges which characterize those objects. In 1997 Brown et al. gave a similar definition,defining the context as location, identity of people around the user, time of the day, sea-son, temperature, etc. In 1998 Ryan et al. described the context as the user’s location,


environment, identity and time. In the same year (1998) Dey defined the context as anemotional state of the user, focus of attention, location and orientation, date and time, andobjects and people in the user’s environment. These definitions describe the context bymeans of examples and they are quite difficult to apply. Indeed, if we wanted to determinewhether a type of information not listed in the above-mentioned definitions is context, itwould not be clear how to use those definitions to do it.Other definitions simply provide synonyms of context, referring, for example, to the con-text as an environment or a situation. Someone claims that the context is the user’s envi-ronment, whereas others look at it as the application’s environment. In 1996 Brown de-fined the context as the user’s environmental elements which are known by the computer.In 1997 Ward et al. considered it as the state of everything surrounding the application,and in 1998 Rodden et al. defined it as the application’s setting. In 1997 Hull et al. tookinto account the entire environment, defining the context as the aspects of a current situ-ation. Right as it happens with the definitions by example, definitions which simply usesynonyms of context are extremely hard to be applied in practice. In 1994 Schilit et al.asserted that the crucial aspects of the contexts are the following ones: where you are,whom you are with, and which resources are surrounding you. Indeed they defined thecontext as the execution of an environment that changes continuously.In fact, in their definition, they include the following environmental elements:

• Computing environment. Available processors, accessible devices for user inputand display, network capability, connectivity, and computational costs.

• User environment. Location, list of close people, and social situations.

• Physical environment. Illumination, noise level, etc.

Dey et al. (1998) defined the context as the physical, emotional, or informational user’sstate. Finally, in the same year (1998), Pascoe described the context as the subset of phys-ical and conceptual states which are interesting for a given entity. In effect, the context isentirely based on the situation judged relevant for an application and on its set of users.It is not possible to list which aspects of all the situations are important, since this wouldchange from situation to situation. For example, in some cases the physical environmentcan be important, whereas in others it can be totally useless.Finally, in 2000, Dey and Abowd defined the context as “... any information that can beused to characterize the situation of an entity. An entity is a person, place, or object thatis considered relevant to the interaction between a user and an application, including theuser and application themselves”.

David Sorrentino 7

In practice the context-aware computing looks at questions such as “who?”, “where?”,“when?”, and “what?” and use these information to determine which situation is occur-ring and why.This type of context includes not only implicit inputs, but also explicit ones. For example,a user’s identity can be explicitly sensed by means of face recognition or can be explicitlydetermined when an user is asked to write his/her name by using a keyboard. From theapplication point of view, both are information related to the user’s identity and allow toperform further activities.In conclusion, there are some types of context which are more important than others.These are location (where), identity (who), time (when), and activity (what). In fact,location, identity, time, and activity are crucial to characterize the situation related to agiven entity. These types of context not only answer to questions like “who?”, “where?”,“when?”, and “what?”, but they also behave as indexes for other contextual informationsources. For example, given the identity of a given person, we may acquire many piecesof related information, such as telephone numbers, addresses, email addresses, a birthdate, lists of friends, relationships with other people belonging to the same environment,etc. With the location of an entity we could determine which objects or people are closeto that entity and which activities are occurring around it (Poslad, 2009).To improve the context categorization, it is also possible to include hierarchical or con-tainment information. An example of this related to the location could be a spot in aroom. That spot may be defined by means of coordinates within the room, the room it-self, the floor of the building which the room is in, the building, the city, etc. (B. Schilit& Theimer, 1994).

2.2 Types of context

Since the concept of context was defined the first time, several ways to classify con-texts have been proposed. Prekop and Burnett (2003) and Gustavsen (2002) referred totwo types of context: one external and one internal, which correspond to physical anduser contexts, respectively. In 2003, Hofer et al. referred to physical and logical contextswhere the logical context is similar to the user context. In 2001, Dey and Abowd proposedrooms and buildings, people, either individuals or groups, and things such as physical ob-jects and components as types of context. In 1995, Schilit et al. classified the context inthree main categories: where you are (location context including resources belonging tothe physical environment which are located close to the user), who you are with (social


context), and what ICT1 resources are nearby. Chen and Kotz (2000) and Henricksen etal. (2002) performed a distinction between dynamic and static context-aware systems.A static context describes aspects of a pervasive system which remain invariant, like thebirth date of a person. A dynamic context refers to a user or an environment context.These contexts may be highly changeable over the space and the time, e.g., temperature,blood pressure, etc. In 2000 Morse et al. modelled the context as six main dimensionsdescribed by means of the questions “what?”, “who?”, “where?”, “how is it accessed?”and “why is it useful?”.Table 2.1 summarizes the characteristics of the types of context classified with respect tothe type of environment: physical, human, and ICT, respectively. The following classifi-cation is based on the one of Morse et al. (2000) (Poslad, 2009).

Context type Characteristic Description

Physical

WhatType of physical environment context-awarenesssuch as awareness of temperature, light intensity, etc.

WhereSpacial awareness or location awareness: where anawareness of context can be exploited.

WhenTemporal awareness: when context-awareness isuseful.

ICT HowICT awareness: awareness of how any context is cre-ated and adapted over an ICT infrastructure.

User Who

User context-awareness: who may benefit from anawareness of someone’s context.User Activity or Task Context: describes a user’s cur-rent situation.Social Context: describes how the actions of some-one may affect others.

Goal Why

User or application goal: why a context is useful,the higher-level application or user purpose the con-text is used for.Context Adaptation: how the current context canperform a transition to the goal context.

Table 2.1: Types of context according to (Poslad, 2009)

Every individual context is, in turn, defined by means of a meta-context, information thatdescribe the context. For example, the context related to the location has also to definewhich type of coordinates and units system are use. The most important invariant contextis the user and his features, such as his identity and perhaps the details related to his con-tacts.

1 Information and Communications Technology (ICT) is often used as an extended synonym for infor-mation technology (IT), but is usually a more general term that stresses the role of unified communications.[wikipedia.org]

David Sorrentino 9

The context often implies a situation influencing another system that is outside the sys-tem, the external conditions of the environment surrounding the system (external context),which is described by Morse et al. (2000). In the same way, the system can be influencedby the conditions of the internal system and the use conditions which a system is aware of(internal context). More generally, we can refer to a context as something related to theuse of the system, i.e., by means of an internal or external interaction.According to (Poslad, 2009), various types of context can have multidimensional charac-teristics and they can be modelled as shown in Figure 2.2.

Figure 2.1: Multidimensional features of types of context according to (Poslad, 2009)

2.3 Context creation and context composition

New contexts can be created at run time by using sensors located in the physical en-vironment, e.g., sensors for the temperature. Often, raw contexts belonging to a lowerabstraction level and coming from sensors need to be processed in contexts belongingto a higher abstraction level which are relevant for users and applications. The data re-trieved by the sensors may need to be scaled or transformed in different range of valuesor domains, e.g., an electrical signal emitted by a temperature sensor can be mapped to


a value on a temperature scale such as Celsius or Fahrenheit. Valued retrieved by meansof sensors may also need to be connected to other entities in order to become useful, e.g.,coordinates in absolute position may be mapped to a positional context such as a givenbuilding or a postcode. Rather than using the location coordinates themselves as a low-level context, it is often more useful to exploit an abstraction of the context, e.g., “thisperson is at this person’s home at this moment”.Some contexts such as location, entity, activities and time, may act as contextual informa-tion sources, which other contexts can be determined from; in that case we can speak ofcontext-reuse. By combining multiple individual contexts it is possible to obtain a moreaccurate comprehension of the current situation, rather than by taking into account everyindividual context. For example, knowing the current geographical position and the time,together with the user’s calendar, allows an application to infer a new user context andunderstand whether the user is at work or waiting for the bus, etc. According to Poslad(2009) the approaches which can be used to determine user contexts are:

• Combining several simple contexts (context composition).

– Combining homogeneous contexts: e.g., from multiple independent sensorsin order to deal with the variation in individual measurements.

– Combining heterogeneous contexts: e.g., determine a composite context com-bining two or more contexts.

– Deriving high-level context from lower-level ones: e.g., get a higher-levelcontext starting from lower-level contexts.

– Deriving a lower-level context from a higher-level one: e.g., an absolute loca-tion coordinate can be determined from a street name or a building name.

• Consulting an user profile, e.g., check an user calendar to know the user’s activityat a certain time.

• Asking users, in order to define directly their preferences.

• Observing users, e.g., use image processing technology to identify faces, finger-prints, etc, and then link these features to the user context.

Context-aware systems may guarantee the possibility to interconnect heterogeneous con-texts. These contexts may be, for example, of the same type, but represented in a differentway and defined by using different meta-contexts.For example, there could be two different types of temperature measurement scales, Cel-sius and Fahrenheit, so the same type of context can be described differently.

David Sorrentino 11

2.4 Context representation

In 2004 Strang and Linnhooff-Popien studied several ways to represent a context and theyidentified six different types of representation. Moreover, they have been discussing andevaluating these six types, according to the following parameters: partial validation, rich-ness and quality of information, incompleteness and ambiguity of context gathered, andlevel of formality and applicability to existing environments. Table 2.2 summarizes thisdistinction, describing the above-mentioned six different types of context representation,according to Strang and Linnhoff-Popien (2004).

Model Type of structureKey value Simple, flat, data structure for modeling contextual information.

Markup schemeHierarchical data structure, e.g., XML, consisting of user definedmarkup tags with attributes that can be arbitrarily nested.

GraphicalGraph data structures and richer data types, e.g., UML (UnifiedModelling Language).

Object-OrientedContext processing is encapsulated, hidden to other components.Access is through specified interfaces only.

Logic basedA logic defines the conditions in which a concluding expression orfact may be derived from a set of other expressions or facts.

Strong ontology A combined expressive conceptual model with a logic.

Table 2.2: Types of context representation according to (Poslad, 2009)

Moreover, Table 2.3 points out the pros and cons of each type of context representation(Poslad, 2009).

2.5 Context awareness

Context-aware computing was described for the first time in 1994 by Schilit and Theimeras a software that “... adapts according to its location of use, the collection of nearbypeople and objects, as well as changes to those objects over time”.This first definition of context-aware applications moved the idea of context awarenessfrom applications which are simply informed about the context to applications whichadapt to it. In fact the term “context-aware” became synonym of “adaptive” (M. Brown,1996), “reactive” (Cooperstock, Tanikoshi, Beirne, Narine, & Buxton, 1995), “respon-sive” (Elrod, Hall, Costanza, Dixon, & Rivieres, 1993), “situated” (Hull, Neaves, &Bedford-Roberts, 1997), “context sensitive” (Rekimoto, Ayatsuka, & Hayashi, 1998) and“environment directed” (Fickas, Kortuem, & Segall, 1997).


Model Pros Cons

Key value

Easy to manage and parse in em-bedded systems.

Uses exact matches, lacks ex-pressive structuring, lacks ef-ficient context retrieval algo-rithms, has weak formalism,handling incompleteness. Mayneed multi-values.

Markup scheme

Distributed model, uses under-lying resource identifier andnamespace model; XML Webservices are becoming perva-sive; handling heterogeneity,handling incompleteness.

Expressive structuring and weakformalism.

GraphicalMore expressive than key value,and hierarchies.

Support for distributed contextmodel, handling incomplete-ness, lack of formalism.

Object-Oriented

Distributed Object-Oriented ismature, some partial validationbut often not very formal. Reusecan be supported through inheri-tance and composition.

Handling incompleteness.

Logic based

Strong formalism, expressivestructuring.

Handling uncertainty, time vary-ing instances, heterogeneity, of-ten difficult to partially validate,simple structuring, handling in-completeness.

Strong ontology

Expressive structuring, handlingheterogeneity, partial validation.

Handling uncertainty, scalabilityin searching large data volumes,use in low resource embeddedenvironments.

Table 2.3: Pros and cons of types of context representation according to (Poslad, 2009)

Previous definitions of context-aware computing fall into two main categories: using con-text and adapting to context. Finally, in 2000 Dey and Abowd defined context awarenessin a more general way with the following statement: “A system is context-aware if it usescontext to provide relevant information and/or services to the user, where relevancy de-pends on the user’s task”.Since the above-mentioned definition is more general, it can include all context-awareapplications, both those that adapt to context and those that simply display the user’s con-text.Therefore, context awareness can be seen as the ability of a system to sense the currentenvironment and autonomously perform appropriate adaptations in regard to its optimal

David Sorrentino 13

operation, general behaviour and user interaction. When a user enters a new context, it isdesirable that the applications on his devices be able to adapt to the new situation, and theenvironment be able to adapt its services to the presence of the new user.

2.6 Context-aware applications

Applications using the context, both in a desktop environment and in a mobile or ubiq-uitous computing one, are called context-aware applications. The growing availabilityof commercial sensing technologies is making it even more possible to sense the con-text in a wide variety of environments. The existence of networked powerful computersmakes it possible to use these technologies and distribute the context in multiple appli-cations. Mobile computing allows users to move through an environment carrying theircomputing power with them. By combining that with wireless communications it is pos-sible to give users the access to information and services not directly available on theirportable devices. Increased mobility creates situations where the user’s context, such ashis/her position, or the people and the objects around him/her, is more dynamic. Withthe introduction of ubiquitous computing users move though an environment and interactwith computer-enhanced objects within the environment. Moreover, this allows users toaccess to information and remote services. Since there is such a wide range of possiblesituations for the users, we need a means to make services adapt properly, in order tobest support human-computer and human-environment interactions. Context-aware ap-plications are becoming even more frequent and they can be found in many areas, such aswearable computing, mobile computing, robotics, adaptive and intelligent user interfaces,augmented reality, adaptive computing, intelligent environments, and context-sensitiveinterfaces. It is not surprising that in the majority of these areas, the user is mobile andhis/her context changes continuously and quickly (Krumm, 2009).

2.6.1 Types of context-aware applications classified by features

Classifying context-aware features provides two main benefits. Firstly it specifies thetypes of applications which researchers focus on. Secondly it describes the types of fea-tures which developers should consider when they build context-aware applications.The first attempt to classify context-aware applications according to their features wasmade by Schilit et al. in 1994 and that taxonomy had two orthogonal dimensions: if thetask is to obtain information or execute a command, and if the task is manually or auto-matically executed. Applications which retrieve information for the user in a manual way


going by the available context are classified as proximate selection applications. This isan interaction technique with which a list of objects, or places, is presented to the userand only the items which are relevant for the user’s context are emphasized and madeeasier to choose. Applications which retrieve information for the user in an automaticway based on the available context are classified as automatic contextual reconfiguration.Basically, it is a system-level technique which automatically creates a resource and makesit available according to current context. Applications which execute commands for theuser in a manual way going by the available context are classified as contextual command

applications. They are executable services made available by means of the user’s con-text. The execution of these can always be modified on the basis of the user’s context.Finally, applications which execute commands for the user in an automatic way based onthe available context use context-triggered actions. These are services which are automat-ically executed when the right combination of contexts occurs, and are based on simpleif-then rules (Poslad, 2009).The above-mentioned classification can be summarized in Figure 2.2.

Figure 2.2: Classification of context-aware application by features

More recently, Pascoe (1998) proposed a taxonomy of context-aware features. This tax-onomy presents a considerable overlap with the Schilit’s one, but some important differ-ences as well. In effect Pascoe’s taxonomy has the aim to identify core features of contextawareness, whereas the Schilit’s one identifies classes of context-aware applications. Thefirst feature is contextual sensing and it is the ability to retrieve contextual information and

David Sorrentino 15

present them to the user, trying to augment the user’s sensory system. This looks quitesimilar to proximate selection, but it actually differs from it for the fact that the user doesnot necessarily need to select one of the context items for more information. The secondfeature is contextual adaptation and it is the ability to execute or modify a service in anautomatic way going by the current context. This can be directly mapped on the Schilit’scontext-triggered actions. The third feature is contextual resource discovery, and it allowscontext-aware applications to locate and use resources and services which are relevant tothe user’s context. This can be directly mapped on an automatic contextual reconfigu-ration. The fourth and last feature, contextual augmentation, is the ability to associatedigital data with the user’s context. So, an user has the possibility to visualize the datawhen he is in that associated context. For example, a user can create a virtual note pro-viding details about which food is missing in the fridge and attach the note to the fridge.When another user is close to the fridge, he will see the virtual node left previously.

In 2000 Dey and Abowd combined the ideas from the two above mentioned taxonomiesin a new and innovative taxonomy. This taxonomy, like the Pascoe’s one, is a list of thecontext-aware features that context-aware applications may support, and it is based onthree major categories:

• Presentation of information and services to a user.

• Automatic execution of a service.

• Tagging of context as information for later retrieval.

The presentation can be seen as a combination of Schilit’s proximate selection and con-textual commands, with the addition of Pascoe’s notion of presenting context to the user(context as a form of information). An example of this feature can be a mobile computerthat dynamically updates the list of the closest printers to it. Automatic execution canbe seen as the combination of Schilit’s context-triggered actions and Pascoe’s contextualadaptation. An example of this second feature could be when an user prints a documentout and this is printed from the closest printer to him. Tagging can be mapped on thePascoe’s contextual augmentation. An example of this third feature could be when anapplication keeps track of the names of the documents the user printed out, the time inwhich they were printed out and the printer used. Therefore, these information may beaccessed by the user later on, perhaps to help him to retrieve the printouts he forgot topick up.


2.6.2 Examples of context-aware applications

The Active Badge system

The Active Badge system (Want, Falcao, & Gibbons, 1992) is commonly seen as thefirst context-aware system. The Active Badges were infrared transmitters transmitting aunique identity code. When the user moved trough a building, a database was dynamicallyupdated with information related to the geographical position of each user, the closestphone, and the likelihood of meeting somebody in that location.In this way, when a phone call was received for a given user, the receptionist was ableto forward it to closest phone for that particular user. This applications was focused onthe location-aware computing and today it could belong to the class of the location-basedservices.

Tour guides

If the Active Badge is considered the first context-aware system, the mobile tour guideis definitely considered the most canonical one, since the literature is practically full ofexamples about this system. A mobile tour guide is a hand-held device which a museumvisitor usually receives. It can present information to the user about exhibit locationswhich he/she is interested in, using audio, video/images, or text. Nowadays, the majorityof the tour guides ask the user to explicitly insert the name or the ID of the exhibit loca-tion which he desires more information about. Instead, context-aware mobile tour guidesremove this need of an explicit input. Indeed, they automatically sense which exhibitlocation the visitor is closest to (e.g., using RFID2 tags on every exhibit location and aRFID reader in the tour guide) and automatically present the proper information aboutthat exhibit location (Krumm, 2009).While early systems such as the Active Badge system were focused heavily on location,later systems started taking into account users’ interests, such as the amount of time theyspent at a exhibit location or the amount of time they had to tour in choosing what infor-mation to show, and what exhibit locations to recommend.

2 Radio-frequency identification (RFID) is the use of a wireless non-contact system that uses radio-frequency electromagnetic fields to transfer data from a tag attached to an object, for the purposes of auto-matic identification and tracking.

David Sorrentino 17

Reminders

Another canonical context-aware application is the context-aware reminder system. Context-aware reminders present reminders to individuals, triggered by changes in context. Analarm clock uses a simple contextual trigger, time, to set off an alarm, a simple form ofreminder. Similarly, location-based services can deliver reminders when users are at aparticular location or within some proximity of each other (W. N. Schilit, 1995). Moresophisticated reminder systems use a combination of different forms of context to trig-ger reminders. In being more sophisticated, these applications can remind users moreappropriately, delivering the right reminder in the right situation (Dey & Abowd, 2000)(Ludford, Frankowski, Reily, Wilms, & Terveen, 2006).

Environmental controls

Another canonical context-aware application is a system to control an environment’s heat-ing and lighting, generally for the purposes of being energy-efficient or saving users effort.As many people often leave lights on unnecessarily, or have to manually change heatingor cooling levels to remain comfortable, many systems have been developed that can con-trol these on behalf of users. Some are based on simple rules (Elrod et al., 1993), whileothers use more sophisticated mechanisms to learn how users use a space and sets heatingand lighting accordingly (Mozer, 1998).

2.7 Context reasoning

Context-aware systems need a reasoning mechanism mostly because of some basic char-acteristics of contextual data. These characteristics are imperfection and uncertainty.In 2004, Henricksen and Indulska identified four different types of imperfect contextualinformation:

• Unknown. Because of sensor or connectivity failures, not all the contextual data areavailable all the time.

• Ambiguous. If contextual data come from different sources, the may be ambiguous.

• Imprecise. Imprecision might be really common in sensor-derived data.

• Erroneous. Erroneous contextual information is generally due to human or hard-ware errors.


In these cases reasoning can be used to detect possible errors by predicting missing values,and evaluating the quality and validity of the sensed data (Bikakis, Patkos, Antoniou, &Plexousakism, 2007).

Furthermore, context reasoning might also be used to allow a system to take decisionsbased on the gathered contextual information. By exploiting this mechanism, in fact, asystem can change its behaviour depending on the changes in its context.

Mature and well-researched reasoning techniques are the ontological reasoning and therule-based reasoning.The ontological reasoning approaches are characterized by two main advantages. First,they are well-integrated with the ontology model, which is widely used as representationmodel for the context. Second, they have a relative low computational complexity; there-fore they are made to be used with rapidly changing contexts.Instead, rule-based reasoning approaches use a formal model to reason on the context.For this reason, they are easy to understand and many systems integrate them with theontology model. Anyway, they have to use additional reasoning mechanisms to deal withimperfection and uncertainty.

2.8 Summary

Since our aim is to propose a model to represent and manage the context, in this chap-ter we clarified basic concepts such as context, context awareness, and context reason-ing. In addition we introduced the important role played by the context representation incontext-aware systems. Finally, we provided some canonical examples of context-awareapplications.

In the next chapter we provide a quite detailed overview about Semantic Networks, sincethey constitute the representation model we chose to work on in our approach. 4

19

Chapter 3

Semantic networks

Natural language is extremely powerful. Without any effort it allows us to ask somebodyhow to find the nearest grocery store, to share our knowledge or to express our opinionabout something. As a simple example, think about the following two sentences. Bothare of the form “subject-verb-object”, one of the simplest possible grammatical struc-tures:

1. David owns a dog.

2. Dogs scare Rose.

Each of these sentences represents a piece of information. The words “David” and “Rose”refer to specific people, the word “dogs” refers to a class of mammalian, and the words“owns” and “scare” define the relationship between the person and the animal in question.Since we know from previous experience what the verbs “owns” and “scare” mean, andwe have probably seen a cat before, we are able to understand the two sentences. Andafter reading them, we can say we are equipped with new knowledge of the world. This isa plain example of semantics: symbols can refer to things or concepts, and sequences ofsymbols express a meaning. We can now use the meaning that we derived from the twosentences to answer simple questions such as “Who owns a cat?” or “Who is scared bycats?”.

Merriam-Webster defines semantics as “the language used to achieve a desired effect onan audience.” Semantics is, in fact, the process of communicating enough meaning toresult in an action. A sequence of symbols can be used to communicate meaning, and thiscommunication can then affect behaviour (Segaran, Taylor, & Evans, 2009). For example,when we read a book, we integrate the ideas expressed in the book with all that we alreadyknow.


In conclusion the use of semantics is necessary, if we aim to make it possible to represent,combine, and share knowledge between communities of machines, and to write systemsthat can act on that knowledge.

Since in our approach we use Semantic Networks as knowledge representation for con-text, in this chapter we are going to give a definition of them, providing in addition somesimple examples with the purpose to make them clear to the reader. Finally, we are alsogoing to show the main properties characterizing Semantic Networks, and the advantagesand disadvantages related to them.

3.1 Definition of Semantic Networks

Semantic Networks are graphical knowledge representation schemes consisting of nodes,and links between nodes (Marra & Jonassen, 1996). Computer implementations of se-mantic networks were first developed for artificial intelligence and machine translation,but earlier versions have long been used in philosophy, psychology, and linguistics (J. F. Sowa,1991).

The nodes of the net represent objects or concepts and the links represent relations be-tween nodes. The links are directed and labelled; therefore, a semantic network corre-sponds to a directed graph. From the graphical point of view, the nodes are usually repre-sented by circles or boxes and the links are drawn as arrows or simple connectors betweenthe circles. The structure of the network defines its meaning, depending on which nodesare connected to which other nodes. In practice, by defining a set of binary relations ona set of nodes, the network corresponds to a predicate logic with binary relations. More-over, Semantic Networks are redundancy-free, since they can not have duplications of thesame nodes.

3.2 Understanding Semantic Networks

In order to have a concrete example of what a Semantic Network is, let us look at Figure3.1, which is just composed of two nodes and a link. As can be seen, the node on theleft labelled "person" is linked to the node on the right, labelled “living being”. The linkis labelled “is-a”. Thus, the Semantic Network in questions describes a person as anexample of living being. Indeed, technically speaking, the diagram represents the fact

David Sorrentino 21

that there is a binary relation between a living being, such as a person, and the concept ofperson itself.

Figure 3.1: Example of Semantic Network

In Figure 3.2 another node with the label “cat”, as well as a “is-a” link from this node tothe “living being” node, again representing that a cat is a type of living being.

Figure 3.2: Example of Semantic Network (cont’d)

If a person called “David” and a cat called “Tom” are added, and David owns Tom, thestructure of the network becomes apparent as shown in Figure 3.3. Clearly, a new linklabelled "owns" would need to be added as well, in order to represent that David ownsTom.


At this stage it is important to clarify a point which can create some semantic confusion.It is visible that the nodes belonging to this small network are not all of the same type.


Indeed the nodes labelled “living being”, “person” and “cat” represent the generic ormeta or class concept of a living being, a person and a cat, respectively; in practice,they represent just abstract concepts. Instead, the nodes “David” and “Tom” represent anindividual instance of the nodes “person” and “cat”, respectively; in fact David is a personand Tom is a cat. In conclusion it is crucial to notice that there are two types of context,classes and individuals, although they are represented in the same way.

Now, let us add another class node, labelled “place”, that represents the abstraction ofplaces in a category. Along with that, an instance of a place, labelled “home”, is added.Thus, another “is-a” link and a new link, labelled “is-at”, must be added to the node“home” and the node “David”, respectively. These new additions are shown in Figure3.4. The information now being represented is that David is a person and home is theplace he is at.


As the number of nodes increases, the meaning of the respective links need to be consid-ered. It should be apparent that not all links are alike. Indeed, some links express onlyrelationships between nodes, and are therefore assertions of the nature of the relationshipbetween two different nodes. For example, the link “is-at” in Figure 3.4, which describesthe relationship that the person David is at the place home. The “is-a” links in Figure 3.4,instead, are structural links, in that they provide “type” information about the node. It isclear since this information is about the node itself and not about the relationship it has tobe a different type of node. For instance, the node “home” is an individual instance of theclass node labelled “place”.

In Figure 3.5, more nodes and links are added to the original network. There is nowa “posture” class node with an instance node labelled “sitting”. The link “has-posture”

David Sorrentino 23

conveys the information that the person David has the posture “sitting” in a given mo-ment. We also added a class node labelled “appliance” with an instance node labelled“television”, which in turn is related to the person “David” by means of the link “uses”.Then, we added a class node labelled “room” and a respective instance labelled “livingroom”. Finally, we added a new link labelled “is-in”, that connects the nodes “David” tothe node “living room”, and the node “living room” itself to the node “home”.


The network in Figure 3.5 now provides a representation for information about the nodesbelonging to it. For instance, a person called David is the owner of a cat called Tom, andat the moment he is sitting in the living room, using a television.

Another important characteristic of the node-link representation is the implicit “inverse”of all relationships represented by a link. Indeed, if there is a link going from one nodeto another, this also implies the reverse, and it means that there is a link from the secondnode to the first. in Figure 3.6, for example, there are two nodes labelled “David” and“television” with the link labelled “uses”. The direction of the relationship is that “Daviduses a television”. In practice “David” is a subject and “television” is the object, and“uses” is the verb or action or link between them.

Figure 3.6: Symmetric relationships in Semantic Networks

This “David uses television” relation implies the inverse relationship that “television is-used-by David”, as shown in Figure 3.7.


Figure 3.7: Symmetric relationships in Semantic Networks (cont’d)

3.3 Inferring knowledge with Semantic Networks

With any kind of knowledge representation scheme, it is possible to infer knowledge thatis not directly represented by the scheme. The ability to work with incomplete knowledgesets a knowledge representation apart from a database (Marra & Jonassen, 1996).

Figure 3.8: What can we infer from this extraction from 3.5

To give an example of what can be found out from the Semantic Network in figure 3.5that is not directly represented, let us consider Figure 3.8. It is nothing but the an extrac-tion of Figure 3.5 containing only three nodes and two links. The information explicitlyrepresented is that a person called David is using a television and that he is in the livingroom.

By tracing the path from the node “living room” to the node “David” via the link labelled“is-in” and then from the node “David” to the node “television” via the link labelled“uses”, it is possible to infer that the television is in the living room by inferring a linklabelled “is-in” between the node “television” and the node “living room”, as shown inFigure 3.9. This means that this information does not need to be explicitly represented inthe original network, for it can be easily inferred later.

From a mathematical point of view, composing links occurs by placing them end-to-tail.This composition creates a new link. It is not possible to compose every pair of links,

David Sorrentino 25

Figure 3.9: Example of knowledge inferring in Semantic Networks (cont’d)

only those whose destinations and sources correspond. The destination of the first mustbe the source of the second. By composing links, new relationships between nodes canbe found and described. Such a process is also called chasing links and the terminol-ogy introduced comes from a branch of mathematics called Category Theory1 (Marra &Jonassen, 1996).

Figure 3.10: Simple example of instancing in Semantic Networks

Looking at Figure 3.10 and formalising the whole lot from a logical point of view, we cansay that if x is an individual and y is class, the link “is-a” between them can be interpretedas the following formula:

y(x)

E.g.: cat(Tom).

Instead, if x and y are classes, the link between them can be interpreted as the followingformula:

∀Z x(Z) ⇒ y(Z)

1 Category theory is an area of study in mathematics that examines in an abstract way the propertiesof particular mathematical concepts, by formalising them as collections of objects and arrows, where thesecollections satisfy some basic conditions.


E.g.: ∀Z cat(Z) ⇒ living_being(Z).

Finally, if a class or an individual has some properties, these can be translated to binarypredicates:

∀Z y(Z) ⇒ property(Z, value) class

property(x, value) individual

In conclusion, coming back to our original example, Figure 3.11 shows the results ofmore link chasing. As you can see, additional relationships are derived, e.g., a person hasa posture, may own a cat and may use appliances.

Figure 3.11: A more complicated example of inference in Semantic Networks

3.4 Advantages and disadvantages of Semantic Networks

As we saw thus far, Semantic Networks are characterized by a high representationaland expressive power, which is why they constitute a powerful and adaptable methodof representing knowledge. In particular, Semantic Networks present the following ad-vantages:

• Many different types of entities can be represented in Semantic Networks.

• Semantic Networks provide a graphical view of the problem space and thereforethey are relatively easy to understand.

David Sorrentino 27

• They can be used as a common communication tool between different fields ofknowledge, e.g., between computer science and anthropology.

• They allow an easy way to explore the problem space.

• Semantic Networks provide a way to create clusters of related elements.

• They resonate with the ways in which people process information.

• They are a more natural representation than logic (using meaning axioms).

• They are characterized by a higher cognitive adequacy than logic-based formalisms.

• Semantic Networks allow the use of efficient inference algorithms (graph algo-rithms).

• They have a higher expressiveness than logic (e.g., they allow properties overrid-ing).

Semantic Network also have some limitations, which frequently lead to some epistemo-logical problems. Such limitations can be summarized in three main points.

1. A distinction between classes and individuals does not exist. The system is limitedby the user’s understanding of the meanings of the links in a semantic network. Aspointed out previously, links between nodes are not all alike in function or form.Indeed, we need to differentiate between links that constitute some relationship andlinks that are structural in nature. Figure 3.12 shows an example of the same linkused both to create a relationship between two nodes and to describe a structure. Infact, the link “is-a” behaves in two different ways: between the nodes “Tom” and“cat” it specifies an instance of a cat; instead, between the nodes “cat” and “livingbeing” it specifies a category, a hierarchy.

Figure 3.12: Example of a link used with different meanings

In 1983, Brachman on the subtleties of the "is-a" link revealed even more distinc-tions in the uses of this link.A possible work-around to this problem could be to specify in a more detailedway the name of the links, distinguishing between relational and structural ones, asshown in Figure 3.13. In this case we re-wrote the link between the nodes “Tom”


and “cat” as an “instance-of” link; and the link between the nodes “cat” and “livingbeing” as a “subtype-of” link.

Figure 3.13: Removing ambiguity from a link

2. A distinction between attributes associated to a class and attributes inherited by theindividuals of the class does not exist.So, on the one hand we may correctly say:

• Tigers are an endangered species.

• Cleopatra is a tiger.

• Cleopatra is endangered.

But on the other hand, we may also erroneously say:

• Tigers are numerous.

• Cleopatra is a tiger.

• Cleopatra is numerous.

3. A formal semantic does not exist, so there is not an agreed-upon notion of whata given representational structure means. Indeed, Semantic Networks do tend torely upon the procedures that manipulate them (J. F. Sowa, 1991). A solution tothis problem could be either using conceptual graphs (J. Sowa, 1984), a formal-ism for knowledge representation, or a knowledge representation system such asKL-ONE, which allows to overcome semantic indistinctness in Semantic Networkrepresentation.

3.5 Summary

Since in our approach we use Semantic Networks as knowledge representation for con-text, in this chapter we gave a definition of them, providing in addition some simpleexamples with the purpose to make them clear to the reader. Finally, we showed the main

David Sorrentino 29

properties characterizing Semantic Networks, and the advantages and disadvantages re-lated to them.

In the next chapter we are going to list and analyse the main existing contextual infras-tructures, focusing on the approach they use to deal with the context representation andthe knowledge management.

31

Chapter 4

Related works

Context-aware computing requires an environment for software development and deploy-ment, where large quantities of different devices and sensors need to be integrated, build-ing a programmable and auto-configurable infrastructure. So far several projects havedeveloped prototypes of such environments, but usually with focus only on specific usecases, user tasks or application domains. However, looking at the current tendency in afew years nearly every public and private space will be equipped with sensors and smartappliances that are able to automatically adapt to the preferences and demands of the localusers and provide special context-specific services to them.

In this section we present the main existing infrastructures aimed to provide tools forbuilding context-aware applications and systems, mostly focusing on the approach theyuse to deal with the context representation and the knowledge management.

Gaia

Gaia provides a generic computational environment which integrates physical spaces andtheir ubiquitous computing devices into a programmable computing and communicationsystem(Román et al., 2002). It is rather similar to a traditional operating system, since itmanages the tasks common to all applications built for physical spaces (Ranganathan &Campbell, 2003). Each space is self-contained, but it may interact with other spaces. Byspecifying well-defined interfaces to services, applications may be built in a generic wayso that they are able to run in arbitrary active spaces. Gaia is a mature project, since thefirst prototypes were implemented in 2002 and several applications for active-classroomshave already been developed.


The Gaia Context Infrastructure allows applications to get contextual information. Thecontext is obtained from either sensors or other data sources by means of various com-ponents, called Context Providers. These Context Providers allow applications to querythem for context information.Gaia uses ontologies to represent the context and describe various concepts of an Ubiqui-tous Computing environment, such as kinds of applications, services, devices, users, datasources and other entities. There ontologies are written in DAML+OIL.All the ontologies in Gaia are maintained by an Ontology Server. Entities contact the On-tology Server to get descriptions of other entities in the environment, information aboutcontext or definitions of various terms used in Gaia.

CoBrA

Context Broker Architecture (CoBrA) is an infrastructure that supports agents, servicesand devices that interact in order to explore context information in active spaces (H. Chen,2004) (H. Chen, Finin, & Joshi, 2003). Its main component is an intelligent agent calledcontext broker, which is responsible for providing a common model to represent contextinformation, inferring higher-level context information not directly available from sensors(H. L. Chen, 2004).CoBrA has a context-acquisition model in order to acquire contextual information fromsensors, agents, and the Web. The acquisition phase is made by means of a library includ-ing procedures for collecting information from Smart Tag sensors (location) and environ-ment sensors (temperature, sound, luminosity, etc.).The base ontologies used for representing context information are the CoBrA Ontology1

(COBRA-ONT) and SOUPA2.All the devices, services, and agents in the space of interest share a centralized model ofcontext provided by the system. The knowledge owned by the context broker consists ofRDF statements and is stored in a persistent knowledge base. In order to acquire contex-tual information, all agents have to send query messages to the context broker.

1 COBRA-ONT is a set of ontologies to describe contextual information and to share context knowledge.It defines concepts for representing actions, agents, devices, meetings, time and space.

2 The SOUPA ontology is a standard ontology for supporting pervasive and ubiquitous computing appli-cations. It consists of vocabularies for expressing common concepts that are associated with person, agent,belief-desire-intention, action, policy, time, space and event.

David Sorrentino 33

Semantic Space

Semantic Space is a context infrastructure developed to address three key issues (X. Wang,Dong, Chin, Hettiarachchi, & Zhang, 2004).

1. It aims to provide an explicit representation of the raw context data obtained fromvarious sources in different formats.

2. It provides means for the applications to access in a selective way a subset of contextdata through context queries.

3. It provides reasoning capabilities for inferring higher-level contexts.

Semantic Space uses the CONtext ONtology3 (CONON) for modeling context in perva-sive computing environments (X. H. Wang, Zhang, Gu, & Pung, 2004).Every smart space contains a Context Knowledge Base, which provides a persistent con-text knowledge storage. The context aggregators are responsible for gathering contextdata from various sources such as hardware sensors and software programs, and then as-serting the gathered data into the context knowledge base. The knowledge base is updatedevery time a context event occurs.

CHIL

CHIL (Computers in the Human Interaction Loop) is a middleware infrastructure pro-viding features as context modeling, control of sensors and actuators, directory servicesfor infrastructure elements and services (Soldatos, Dimakis, Stamatis, & Polymenakos,2007). Mechanisms for modelling composite contextual information and describing net-works of situation states are also available.The system is a distributed multi-agent system where the agents are provided with faulttolerance capabilities, since they can migrate among hosts.This infrastructure can use a wide range of sensors for context acquisition, and new sen-sors can be plugged into the framework to provide new information. Software agents areresponsible for obtaining context information from sensors and making them accessiblethrough the Knowledge Base Agent.CHIL uses a modularized ontology, in order to allow different parts to be used in differentcontexts and applications. The core module may provide a merged version of the concept.

3 CONON is an ontology aiming to be an extensible upper-level context ontology providing a set ofbasic concepts that are common to different environments.


In order to globally put together all the modules, the ontology consists of a main OWL4

file, which imports all modules. In this way developers interested only in a smaller set ofmodules can define a main OWL file of their own that imports only the module of interest.The knowledge base server is accessible both locally and remotely through a unique in-terface. The server remote interface is programming language independent, so that thereare not constrains about the programming language to use for building the client compo-nents.

CAMUS

Context-Aware Middleware for URC (Ubiquitous Robotic Companion) System, also knownas CAMUS, is a context-aware infrastructure for the development and execution of anetwork-based intelligent robot system (Kim, Cho, & Oh, 2005).Basically CAMUS gathers context information from different sensors and provides appro-priate context information to different applications. In addition, CAMUS uses context-aware autonomous service agents that are capable to adapt to different situations.A sensor framework has the aim to process raw data from various sources such as phys-ical sensors, applications and user commands and transfer them to the Context Manager

through an Event system. The Context Manager manages context information collectedfrom the Sensor Framework. When a context event occurs in the environment, the Con-text Manager transfers the event to the Event System.The context model in CAMUS is represented as a four-layered space, where each layerhas a different abstraction level:

1. Shared vocabulary layer. It consists of a set of shared vocabulary used in the com-mon ontology layer.

2. Common ontology layer. This layer contains the ontology concepts that are com-monly used in various applications. It provides the high-level knowledge descrip-tion to context-aware applications.

3. Domain ontology layer. This layer the domain specific knowledge to context-awareapplications.

4. Instance layer. It is a space where all the instances of the ontology concepts arerepresented.

4 The Web Ontology Language (OWL) is a family of knowledge representation languages for authoringontologies. [wikipedia.org]

David Sorrentino 35

SAMOA

SAMOA is a framework that supports the creation of semantic context-aware social net-works (Bottazzi, Montanari, & Toninelli, 2007). In details, SAMOA allows mobile usersto create roaming social networks that, following user movements, reflect all nearby en-counters of interest at each instant.In order to support the creation of social networks in ubiquitous environments, SAMOAexploits geographical context information, e.g., users’ location and proximity.In SAMOA contextual data are modelled and represented in terms of semantic metadata.Places and users are the entities in the system, and they are associated with profiles de-scribing their characteristics.SAMOA does not provide a centralized database containing the contextual information.All the contextual data are maintained and analysed separately.

OWL-SF

OWL-SF is a distributed semantic service framework supporting the design of ubiqui-tous context-aware systems considering both the distributed nature of context informationand the heterogeneity of devices that provide services and deliver context (Mrohs et al.,2005). It exploits OWL in order to represent high-level context information in a semanti-cally well-founded form.OWL-SF uses Super Distributed Objects5 (SDOs) to encapsulate context providers suchas sensors, devices, user’s interfaces or services.Each functional entity in OWL-SF has to be described using a dedicated ontology that pro-vides an automatic classification of the object into appropriate service categories.

DRAGO

Distributed Reasoning Architecture for a Galaxy of Ontologies (DRAGO) is a distributedreasoning system, implemented as a peer-to-peer architecture (Serafini & Tamilin, 2005).Every peer may contain a set of different ontologies describing specific domains of inter-est. In each peer there are also semantic mappings defining semantic relations between

5 A Super Distributed Object (SDO) is a logical representation of a hardware device or a softwarecomponent that provides well-known functionality and services. One of the key characteristics in super dis-tribution is to incorporate a massive number of objects, each of which performs its own task autonomouslyor cooperatively with other objects.


entities belonging to two different ontologies. New peers may be added dynamically tothe system, providing new ontologies and semantic mappings.DRAGO is implemented to operate over HTTP and access ontologies and mappings pub-lished on the web.

4.1 Summary

In this chapter we presented the main existing infrastructures aimed to provide tools forbuilding context-aware applications and systems, mostly focusing on the approach theyuse to deal with the context representation and the knowledge management.The majority of these contextual infrastructures use ontologies as model to represent andmanage the context, since they constitute a fundamental knowledge representation struc-ture in modern Artificial Intelligence. Existing representation models like ontologies con-stitute a well researched and mature solution. Anyway, they are not made to representcontinuously changing data; moreover, building and maintaining them is highly error-prone and time-consuming process, and it can become a tedious and non-scalable task ifit is done manually. (Zouaq, Gasevic, & Hatala, 2011).

In the next chapter we introduce a new model to represent and manage context, basedon the integration of Semantic Networks and Object Oriented software development ap-proach.

37

Chapter 5

Approach

In this thesis work we propose a new model that is highly-readable, flexible, scalable,general-purpose, and modular, in order to represent and manage context, where contextis intended as information of different types, generated by a variety of heterogeneoussources and with different levels of granularity. This model is based on the integration ofSemantic Networks with the Object-Oriented software development model, and it com-bines all the advantages of the two approaches. Furthermore, it enables reasoning, guaran-tees an easy handling of the atomic data forming the context, and is capable of managingincomplete or inaccurate information due to incompleteness of data from sensors.

Before choosing to combine Semantic Networks and the Object-Oriented model, we triedmany other representation models for context, some of them very well researched andmature. In this chapter we explore them, analysing their strong and weak spots and ex-plaining the reasons why we finally preferred Semantic Networks. Moreover, we describein details the problem statement and how our approach addresses it. Finally, we point outthe weak spots characterizing our methodology.

5.1 Choosing a representation model for the context

At the beginning of our work we faced a tough question: “which representation modelshould we use to represent contextual data?”. To answer this question we went throughseveral representation models, analysing them and pointing out their strong and weakspots.The first kind of dataset we thought about, in order to represent the context, was thesimplest one, and probably also the most common one: the table.


5.1.1 Context as a table

Tabular data is any data set organized as a table, such as an Excel spreadsheet or an HTMLtable. The major advantage of tabular data is, without any doubt, represented by the easewith which we can read and manipulate it. Let us consider the data shown in Table 5.1describing people at home.

person posture room usesAndrea standing kitchen toaster, oven, knifeRoxy standing hall -Marco sitting living room dvd-player, projector

Table 5.1: Contextual data represented in tabular model

Data kept in a table are generally easy to display, sort, print, and edit. Actually, data ina table can be considered not modelled at all, but the fact that they are placed in rowsand columns gives each piece a particular meaning. Indeed, unlike modelling methods torepresent data, there is no variation in the ways we can look at tabular data. However, it isinteresting to note that a data table or a spreadsheet is characterized by a semantics: in factthe row and column in which the data is explains what the data means to a person readingthe table. The fact that “living room” is in the same row as “Marco” tells us immediatelythat Marco is in the living room. We simply know it, since we understand what peopleand rooms are.This type of dataset has obvious limitations. Let us consider the column “uses”. Wejust included a list of objects (used by somebody) into a single column. This turns outto be fine if we are simply going to read the table, but it causes some issues if we wantto add more information, such as the type of object a person is using (e.g., appliance,kitchenware, etc). In theory it could be possible to add this information in parenthesesafter every object listed, as shown in Table 5.2.

person posture room usesAndrea standing kitchen toaster (appliance), knife (kitchenware)Roxy standing hall -Marco seat living room DVD-player (appliance), projector (appliance)

Table 5.2: Multiple information in tabular model

However, the spreadsheet software will not understand that we have used an individualfield to store multiple distinct information values, since it will not capture the deepermeaning of the text we entered.Another problem with spreadsheet and tables occurs when we have multiple spreadsheet-s/tables which refer to the same data. For example, if we had another table containing the

David Sorrentino 39

addresses of the people described in Table 5.1, there would be no simple way to look forinformation combining both documents. For sure experts of the field could use macrosand lookup tables to get the desired data, but this way is definitely rigid, limited, andusually not interchangeable among different users.Therefore, we chose to look for a more sophisticated way to model and represent data inorder to satisfy our expectations; in particular we considered to use relational databases,as shown in the next section.

5.1.2 Context as a relational database

Relational databases constitute an alternative form to the simple table/spreadsheet andthey are considered very fast and powerful tools for storing big amount of data, wherethe data model is well defined and the way in which the data will be used is predictable.Basically, a relational database is composed of multiple tables joined in a standardizedway. Therefore, in order to store the information previously represented in Table 5.2,we could define a schema like the one shown in Figure 5.1. This approach allows us torepresent the same data in a more useful and flexible way. Moreover, it appears clear howin this data model the semantics of the data are more explicit. The meanings of the valuesare actually described by the schema: in fact whoever looks at the tables can easily noticethat there are several types of entities modelled and that they have specific relationshipsbetween them. Moreover, although the database does not know what a “person” is, it isable to respond to requests to list all the people with given properties. This is why eachdatum is labelled with what it means, simply using the table and the columns in it.In our approach we aim to represent data that could quickly change (e.g., the posture of aperson), and that is not well understood from the beginning (we do not know how peoplemay want to use it).

As a plain example, let us consider the database in Figure 5.1, and then let us assume thatwe receive a new database, with additional information about people which are not in thefirst schema (see Table 5.3).

person gender countryAndrea male IcelandRoxy female PolandMarco male Italy

Table 5.3: Dataset containing additional information


Figure 5.1: Contextual data represented in relational model

At this stage, in order to update the main database so that it supports the new data, wecould just link the tables with another table, without being forced to change the existingstructure. Figure 5.2 shows the new database structure including an additional table, thataims to link the existing table with the new one.

Figure 5.2: Linking additional data to the existing schema

This approach works, but it introduces a considerable problem: there are two name fieldsin the database, and if we wanted to query it by name, we need to look at both tables. Inthis way, adding and updating data is much more complicated.A smart way to overcome this problem could be to have a middle table containing com-mon data, as shown in Figure 5.3. It allows us to achieve our goal, but we need to trans-form the old data model to the new one, and usually this process (called schema migra-

tion) is really difficult to perform. In addition, all the queries that were written assuminga certain table structure have to be changed as well. Since our approach needs to dealwith data from environments that are constantly using new datasets, performing a schemamigration each time a new type of data is faced is simply not convenient.

David Sorrentino 41

Figure 5.3: Normalized schema after adding a new dataset

In addition, another problem related to relational databases is that schemas can get ex-tremely complicated when dealing with a large amount of data characterized by differenttypes (see Figure 5.4).

In conclusion we did not find it appropriate for our purposes to use relational databases,since we did not judge it flexible enough to handle a wide variety of types of data whichtend to change quite frequently. In addition its level of readability did not look highenough in our opinion.Thus, looking for a more flexible and expressive solution with a high degree of read-ability, we next examined a graphical knowledge representation model: Semantic Net-works.

5.1.3 Context as a Semantic Network

Semantic Networks, about which we provided a quite complete synthesis in Chapter 3,are characterized by a three-column format known as triple. In practice, triples formthe fundamental building blocks of this type of knowledge representation. Each triple iscomposed of a subject, a predicate, and an object. For simplicity, we could think of triplesjust as linguistic statements, where each element corresponds to a piece of grammar usedto express a sentence (see Figure 5.5).

Usually, the subject of a triple corresponds to an entity, that is whatever can have a concep-tual class. In our approach examples of entities may be people, places, concrete objects

1 Source: http://alabra.com .


Figure 5.4: Example of a big relational schema1

Figure 5.5: Subject-predicate-object model

(e.g., appliances, kitchenware) and also things like periods of time and ideas. In the net-work, subjects are represented as nodes.Predicates are a property of the entity to which they are attached. A person’s location orposture are examples of predicates. In the network, predicates correspond to the links.Objects fall into two classes: entities that can be the subject of other triples, and literalvalues such as strings, boolean, or numbers. In the networks objects are represented asnodes.Obviously, multiple triples can be tied together by using the same subjects and objects

David Sorrentino 43

in different triples, building in this way chains of relationships, and forming a directedgraph.

Directed graphs are well-known data structures in computer science and mathematics,thus they constitute a reliable model to represent our data. One of the marvellous prop-erties of using graphs to model information is that if we have two separate graphs witha consistent system of identifiers for subjects and objects, we can merge the two graphswithout effort. This is because nodes and relationships in graphs are first-class entities,and each triple constitutes a piece of meaningful data (Segaran et al., 2009). In addition,if a triple belongs to both graphs, the two triples merge together in a transparent way,because they are identical. Figure 5.6 and Figure 5.7 show the ease with which we canmerge arbitrary datasets thanks to this approach.

Figure 5.6: Separate graphs sharing some identifiers

Figure 5.7: Merged graph obtained from the union of triples


Let us consider again some data contained in Table 5.1 and let us use a graph model torepresent them, looking at people as entities. Figure 5.8 illustrates the high expressivenessand readability of this representation model.

Figure 5.8: Contextual data represented as Semantic Networks

Furthermore, inserting additional information (such as the information contained in Table5.3) appears to be quick and easy, since we do not need to transform our model to dothat. This happens because of the properties of the graphs previously mentioned, andalso because objects in one triple can be subjects in another triple. Figure 5.9 and Figure5.10 show how different datasets can be easily merged without requiring changes in themodel.

Figure 5.9: Separate datasets sharing some data

David Sorrentino 45

Now, for example, by following the chain of assertions, we could determine some basicinformation about a given person. We just have to know where to look.

Figure 5.10: New dataset obtained by merging the existing datasets

In conclusion, after comparing pros and cons of the datasets mentioned above, we decidedto use Semantic Networks as representation model to represent contextual data. In par-ticular the advantages of Semantic Networks mentioned in Section 3.4 make them a goodsolution to integrate heterogeneous data characterized by varying structures from varyingsources, where both schema and data evolve over the time.

5.2 Semantic Networks vs Object-Oriented model

In order to make Semantic Networks simple, modular, modifiable, extensible, maintain-able, and re-usable, we chose to embed them in the Object-Oriented model, integratingnodes and links of Semantic Networks with classes, instances, and attributes of an Object-Oriented programming language. In practice we provide an API to map programmingclasses to classes of a Semantic Network.Since the conceptual model and semantics of Semantic Networks differ substantially fromthe object-oriented paradigm, the gap between these two approaches is considerable, andtraditional techniques to fill such a gap can not be applied directly.


5.2.1 Differences analysis

Classes and instances in Semantic Networks are characterized by an open-world and de-scription logics-based semantics, whereas object-oriented type systems are closed-worldand constraint based (Kalyanpur, Pastor, Battle, & Padget, 2004). This semantic gap leadsto six crucial differences that our approach aims to minimize:

1. Class inheritance. In object-oriented systems, classes can inherit at most one super-class, whereas in Semantic Networks, classes can inherit more than one superclass.For example, in Figure 5.11 the class “engineer” inherits both the class “person”and the class “job”, since an engineer is a person, but engineer is also a job.

Figure 5.11: Multiple class inheritance in Semantic Networks

2. Class membership. In object-oriented languages, one object is member of one andonly one class. Moreover, its membership is fixed (since it cannot change duringthe execution) and is defined during the object instantiation. In Semantic Networks,instead, a resource can belong to more than a class. For example, in Figure 5.12,the individual “Marco” is an instance both of the class “musician” and of the class“student”, since Marco is a musician, but he is also a student. Furthermore, itsmembership is not fixed but defined by its rdf:type and the properties belonging tothe resource.

Figure 5.12: Multiple class membership in Semantic Networks

David Sorrentino 47

3. Class flexibility. Object-oriented languages generally do not allow class definitionsto change at runtime. In contrast, Semantic Networks are designed right to integrateheterogeneous data characterized by varying structures from varying sources, whereboth schema and data evolve over the time.

4. Object compliance. Usually, in object-oriented languages, the structures of the in-stances have to perfectly match with the definitions of the classes. In SemanticNetworks, instead, class definitions are not rigid and do not constrain the structuresof the instances. In plain words, any resource can use any property.

5. Attributes inheritance. In object-oriented programming, objects inherit their at-tributes from their superclasses. In Semantic Networks, since properties do notbelong to classes, they are not inherited, but their domains are propagated into theupwards direction of the class hierarchy.

6. Attributes vs properties. In the object-oriented model, attributes are defined locallyinside a class, they can be used only by the instances of that class, and usually theyhave single-typed values. On the contrary, properties in Semantic Networks areindependent entities that can be used by any resource of any class. Moreover, theycan have different types of values.

5.2.2 Existing approaches

If we talk about relational databases, many object-relational mappings exist, such asHibernate, Java Data Objects, ADO.Net and ActiveRecord (Fowler, 2002). Their ap-proaches consist in mapping tables to classes. Table columns are mapped to class at-tributes, except for foreign keys, which are mapped to object relationships. Furthermore,every tuple in the relational model is mapped to an object and intersection tables2 aremapped to object relationships (e.g., is-a relations).This mapping methodology is not suitable when we deal with Semantic Networks, sincethe mismatches listed in Section 5.2.1 do not occur in relational data. Therefore, existingobject-relational approaches are not able to address the problem.

2 Intersection tables are introduced in the relational model to capture many-to-many relations.[msdn.microsoft.com]


5.2.3 Solution

First of all, we decided to set the bases of our approach on object-oriented scriptinglanguages, such as Python, Perl, and Ruby, where the gap between the object-orientedparadigm and Semantic Networks is smaller than using compiled object-oriented lan-guages.Dynamic and general purpose scripting languages are generally interpreted, use dynamictyping, are characterized by strong meta-programming3 capabilities, and give the possi-bility to exploit introspection at runtime (Ousterhout, 1998). These features allow us tofill the gap discussed in Section 5.2.1 and implement a domain-specific object-orientedlanguage embedding Semantic Networks. In particular, we chose to use Python for itsvery clear syntax and its high code readability.Thus, our approach solves (although in some cases just partially) the above-mentioned sixdifferences as follows:

• Class inheritance. By supporting multiple inheritance, the use of Python as script-ing language automatically solve the issue related to the class hierarchy.

• Class membership. Python, like the other scripting languages, uses dynamic typing.For this reason objects type does not require static specification; in fact, these aredetermined at runtime according to the capabilities of the object. Dynamic typingperfectly adapts to Semantic Networks class membership, which can also changedynamically. Moreover, even though objects in Python can have only one type at atime, we can use meta-programming and easily override that behaviour.

• Class flexibility. As a scripting language, Python is interpreted and is not basedon strict and pre-defined classes. For this reason it constitutes a good solution todeal with flexible environments in which both data and schema can continuouslychange. Furthermore, the introspection provided by Python allows to investigateboth schemas and data at runtime, that is a very interesting property in such a vary-ing domain like the context one.

• Object compliance. Python does not require object to be strictly conformed totheir class structure, allowing them to deviate from it. For example, in Python itis possible to define a different behaviour for every instance of the same class.

• Attributes inheritance. Actually, the lack of the attribute inheritance in SemanticNetworks does not constitute a problem for our object-oriented mapping.

3 Meta-programming is the writing of computer programs that write or manipulate other programs (orthemselves) as their data, or that do part of the work at compile time that would otherwise be done atruntime. [wikipedia.org]

David Sorrentino 49

• Attributes vs properties. Since Python allows the use of meta-programming, weare enabled to add attributes of objects in a dynamic way. Moreover, by meansof Python’s dynamic typing we are allowed to assign to the attributes values ofmultiple types.

In conclusion by exploiting the properties of scripting languages such as dynamic typ-ing, meta-programming, and introspection, our approach constitutes a solution to embedthe Semantic Networks model into the object-oriented one. In this way we are able toexploit the high expressiveness of the Semantic Networks and all the advantages relatedto the Object-Oriented model, such as simplicity, modularity, modifiability, extensibility,maintainability, re-usability.

5.3 Weak spots of the approach

In this section we list six points that, according to us, constitute a weakness of this ap-proach. As is clear, most of them are directly related to the limitations characterizingSemantic Networks (see Section 3.4).The first three weak spots, in particular, are due to the graphical nature of the Seman-tic Networks. For this reason they actually do not affect our model, since, as shown inChapter 6, we treat Semantic Networks as directed graphs, and not as a graphical repre-sentation.

1. Showing all the different inferred information using a network can be difficult.

2. Representing the context with Semantic Networks is less reliable than doing it withother knowledge representation techniques because inferring becomes a process ofsearching across a diagram.

3. When we deal with huge amounts of data, diagrams can become very complex.Therefore, this model may suffer scalability problems.

4. The wide range of possible types of links and the ways they might combine to formindirect links, plus the large number of concepts usually included in a SemanticNetwork, make this approach susceptible to a combinatorial explosion. However itis possible to mitigate this problem by dividing the model in several sub-models,avoiding, in this way, to deal with huge amounts of data.

5. The meaning of nodes and links in Semantic Networks is not clear and only definedprocedurally by the inference algorithms. This weak spot is addressed as futurework in Chapter 8.


6. This model requires knowledge of the problem space. This is actually a limitationrelated to Semantic Networks and ontologies, and in this thesis we do not proposeany mitigation to it.

5.4 Summary

In this chapter we explored the main representation models for context, analysing theirstrong and weak spots and explaining the reasons why we finally preferred SemanticNetworks. Moreover, we described in details the problem statement and how our ap-proach addresses it. Finally, we pointed out the weak spots characterizing our methodol-ogy.

In the next chapter we are going to introduce CAFE, a contextual infrastructure based onthe integration of Semantic Networks with the Object-Oriented model, describing howwe implemented it and listing its main features.

51

Chapter 6

CAFE: a context-awareinfrastructure

On the basis of the approach presented in Chapter 5, we created a direct, quick-to-understand, and easy-to-use solution to build highly-readable, flexible, scalable, general-purpose, and modular context-aware applications.CAFE1 (Context-Awareness Factory for Entities) is a context-aware infrastructure writtenin Python, that exploits the considerable power of the Object-Oriented model, and thestrong expressiveness and the high readability of Semantic Networks.

Figure 6.1: CAFE’s logo

CAFE is thought to work both with real and with virtual environments and aims to providethe entities present in a given environment a clear and precise knowledge of the context

1 Source code available at https://github.com/dapids/Context-Awareness-Factory-with-Entities.


related to that environment, independent of the type of sensors used (adding or removingsensors, for example, does not affect the system).Let us imagine, for example, smart appliances which have the task of automatically man-aging actions and reactions of a house according to the context. Thanks to CAFE, wecan give the appliances independent behaviours, making them capable of auto-managingtheir activities and auto-configuring themselves when necessary, by auto-adapting to thecontext in which they are at a given moment. An independent behaviour guarantees con-tinuous operation of the appliances, since they do not need a human intervention to bemanaged. This could lead to a considerable saving of time, money, and effort.In practice, in order to guarantee an independent behaviour, we simply make the appli-ances aware of what is happening around them (context-awareness), so that they can actand react in an appropriate way.

Figure 6.2: CAFE’s generic schema

Figure 6.2 constitutes a generic snapshot describing how CAFE works. Data from sen-sors are gathered by means of a server and organized in a queue. A dispatcher reads datafrom this queue and generates an event for each of them. Every entity is subscribed toevents regarding itself and has the task to update information about itself in the Semantic

David Sorrentino 53

Network. For example, when the sensors recognises the presence of a person in a room,the entity corresponding to that person updates the information about its location in theSemantic Network. In this way every entity does its part to keep the knowledge aboutitself up-to-date. Notice that we may also arbitrarily make an entity subscribe to a givenevent and react to it in a given way. For example, we could make the Light Manager Sys-tem subscribe to events regarding the presence of people inside rooms, in order to switcha light off when somebody leaves a room. It is important to underline that every entitymay access the whole knowledge contained in the Semantic Network, or just a part of it.Entities can also perform reasoning on the Semantic Network, in order to infer additionalknowledge. In this way we provide context-awareness to the entities, since they are com-pletely or partially aware of what is happening around them. Since entities are providedwith context-awareness, they can act/react consequently and modify the environment bymeans of actuators2. Finally, CAFE also provides a way to get information from the net-work by means of an external client, but this aspect will be deepened in Section 6.4.Figure 6.3 shows a UML Sequence Diagram describing a simple scenario in CAFE,where a camera notices that a person identified as “Marco” is leaving a room identified as“kitchen”.

Figure 6.3: UML Sequence Diagram of a simple scenario in CAFE

In this case the Sensors Server gets to know that Marco is leaving the kitchen and for-wards the information to the Dispatcher. The Dispatcher, in turn, generates the eventrelated to that information. The entity “Marco” and the entity “LightManager” are sub-scribed to that event, therefore they are aware of it. At this stage, the entity “Marco”updates the information about its location in the Semantic Network (deleting the triple“Marco;is-located-in;kitchen”, or probably simply updating it with a new location). The

2 An actuator is the mechanism by which an agent acts upon an environment. [wikipedia.org]


LightManager, on the other hand, asks the network whether the room Marco has left isnow empty; in that case it provides for switching off the light.

6.1 Context-Spaces, entities and properties

In CAFE the context is considered a space, which takes the name of Context-Space. Thisspace contains all the entities and the properties characterizing the context. Regardingthe concept of entity, following the definition of entity given in Section 2.1, in our ap-proach we consider an entity “whichever person, place, or object that is considered rel-evant to the interaction between a user and an application, including the user and appli-cation themselves”. Regarding the concept of property, in our approach we consider aproperty “whichever relationship among entities that belong to the context”.

The Context-Space, in turn, can be divided in a set of local-contexts, where every local-context describes a part of the global context related to the environment. The Context-Space, therefore, can be seen as a puzzle, and the local-contexts as the pieces composingthat puzzle. Local-contexts can be used to describe the context from different points ofview. For example, we can define a local-context for the part of the context regardingthe geographical locations, another one for that part regarding the actions performed, andanother one for that part regarding the information about the entities. In practice, local-contexts contain all the properties related to the entities that populate a given environment.The benefit of having different local-contexts is clear, since in this way it is possible toaccess even only a small part of the context, making the research and the management ofinformation more accurate and easier.Figure 6.4 shows an example of a Context-Space describing a home environment. TheContext-Space shown contains a series of entities and local-contexts, in turn containing aseries of properties which constitute the relationships among the above-mentioned enti-ties.

Looking from the point of view of the Object-Oriented model, Context-Spaces and local-contexts are represented as simple objects, containing information about entities and prop-erties related to the context, respectively. Entities and properties are, in turn, objects, andmore specifically attributes of a Context-Space.Considering the Semantic Networks point of view, instead, the Context-Space is seen asa graph, where entities and properties correspond to nodes and links, respectively. As wealready remarked in Chapter 3, this type of representation is redundancy-free, thereforeambiguous situations due to some repetitions of information are automatically avoided.

David Sorrentino 55

Moreover, thanks to the graph properties, it is possible to merge two or more graphspractically without any effort, which allows us to bind information coming from differentContext-Spaces in order to have an even wider view of the context.

Figure 6.4: A Context-Space describing a home environment

In this section we show how to accomplish the main tasks in CAFE, in order to managethe context related to a given environment by exploiting the combination of SemanticNetworks and Object-Oriented model.

With CAFE it is possible to create a Context-Space in such a simple and intuitive way.Listing 6.1 shows how to create a Context-Space simply importing the class ContextSpaceand instantiating it.

Listing 6.1: Creation of a Context-Space

import C o n t e x t S p a c ec o n t e x t s p a c e = C o n t e x t S p a c e ( " h t t p : / / c a f e . ns / home−e n v i r o n m e n t # " )

To instantiate a new Context-Space we need to specify a namespace3 as parameter. Names-paces are thought to be unique, and they can be seen as a label attached to the en-vironments. Thanks to namespaces, in fact, resources belonging to different environ-ments can be distinguished with a unique identifier sanctioning the belonging to their

3 In general, a namespace is a container for a set of identifiers (names), and allows the disambiguationof homonym identifiers residing in different namespaces. [wikipedia.org]


own environment. For example, the resources “http://cafe.ns/marco-home#fridge” and“http://cafe.ns/andrea-home#fridge” are different, since one fridge belongs to Marco’senvironment, and the another one to Andrea’s environment.

Creating an entity is also an easy task in CAFE. In fact, Listing 6.2 shows that it is enoughto import the class we want to instantiate, obviously, and call the method “createEntity”from an object of type “ContextSpace”, specifying the name of the entity to create.

Listing 6.2: Creation of an entity

import Pe r s onmarco = c o n t e x t s p a c e . c r e a t e E n t i t y ( Person , " Marco " )

Starting from its creation, every entity and all their properties will be mapped on a Se-mantic Network.

Before creating a property we need to create a local-context to contain it. As shown inListing 6.3, creating a local-context is possible by means of the method “createLocalCon-text”, called from an object of type “ContextSpace”.

Listing 6.3: Creation of a local-context

i n f o = c o n t e x t s p a c e . s e t L o c a l C o n t e x t ( " i n f o r m a t i o n " )

After creating a local-context we are able to attach to it some properties. This operation ispossible by calling the method “defineProperties” from an object of type “LocalContext”,specifying the name of the property, its cardinality, and whether it is a symmetric propertyor not. In detail, since we previously created a local-context containing all the personalinformation about entities, in Listing 6.4 we create some properties related to it.

Listing 6.4: Creation of some properties

i n f o . d e f i n e P r o p e r t i e s ( ( " name " , 1 ) , ( " age " , 1 ) , ( " i s C l o s e T o " , 0 , " s " ) )

A cardinality “0” represents a one-to-infinite property (a person can have only one age),whereas a cardinality “1” represents a one-to-one property (a person can be close to morethat one person). Moreover, by inserting “s” in the definition of the property we can definea symmetric property (the fact that Marco is close to Andrea means that Andrea is closeto Marco).

David Sorrentino 57

Moreover, CAFE provides an easy way to serialize the information contained in a Seman-tic Network to RDF4, RDF/XML5, turtle6, n triples7, n38. They are all knowledge repre-sentation formats that support the inference of additional knowledge by means of reason-ing. Therefore, by calling the method “serialize” from an object of type “ContextSpace”(as shown in Listing 6.5), it is possible to serialize all the information representing thecurrent context to the above-mentioned formats.

Listing 6.5: Serialization of the context

c o n t e x t s p a c e . s e r i a l i z e C o n t e x t ( f o r m a t =" n3 " )

After serializing the context, we may use the method “writeOntology” to store the ontol-ogy either on a local memory or on a FTP server. For instance, Listing 6.6 shows how tostore the ontology produced by CAFE on a FTP9.

Listing 6.6: Write the context as an OWL ontology on a FTP server

c o n t e x t s p a c e . w r i t e O n t o l o g y ( c o n t e x t s p a c e . s e r i a l i z e C o n t e x t ( ) , " f t p " )

In this way we are free to access it from every networked device and reason on it using anexternal OWL reasoner.

In addition CAFE allows us to make our knowledge about a given environment persistent,simply storing the graph containing it into a binary file. This can be made by calling themethod “saveContext” from a Context-Space object (see Listing 6.7).

Listing 6.7: Save the context in a binary file

c o n t e x t s p a c e . s a v e C o n t e x t ( " / home / d a v i d / myContextSpace " )

This feature allows us to take a snapshot of the context related to a given environment ina given moment. In this way we might have a history of the context over the time, thatgives us the possibility to reason on events happened in the past.

4 The Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C)specifications originally designed as a metadata data model. [wikipedia.org]

5 RDF/XML is a syntax, defined by the W3C, to express (i.e. serialize) an RDF graph as an XMLdocument. [wikipedia.org]

6 Turtle (Terse RDF Triple Language) is a serialization format for Resource Description Framework(RDF) graphs. [wikipedia.org]

7 N-Triples is a format for storing and transmitting data. It is a line-based, plain text serialization formatfor RDF (Resource Description Framework) graphs, and a subset of the Turtle (Terse RDF Triple Language)format. [wikipedia.org]

8 Notation3, or N3 as it is more commonly known, is a shorthand non-XML serialization of ResourceDescription Framework models, designed with human-readability in mind: N3 is much more compact andreadable than XML RDF notation. [wikipedia.org]

9 The address and access data of the FTP have to be specified in an external configuration file.


Finally, CAFE provides us the possibility to visualize the context from a graphical pointof view, showing the respective Semantic Network as an image. This functionality canbe really useful if we need to have a highly-readable representation of what is happeningin a given environment. As shown in Listing 6.8, this feature can be used by calling themethod “visualizeContext” from an object of type “ContextSpace”.

Listing 6.8: Visualization of the context

c o n t e x t s p a c e . v i s u a l i z e C o n t e x t ( )

6.2 Architecture

Figure 6.5: CAFE’s architecture

As shown in Figure 6.5, CAFE’s architecture consists of four layers. As is visible, inour approach entities do not manage contextual data in an isolated way and do not havethe task to analyse them. They simply access information already properly structured

David Sorrentino 59

and organized, which represent a knowledge related to a situation of interest. Therefore,entities do not directly access data, but they do it by means of a middle level (knowledgelayer), in which contextual information is organized in a sort of structured sets of atomicdata related among them, that are the Semantic Networks. Exploiting the expressivenessof the Semantic Networks, entities do not need to access raw data from sensors to reachcontext-awareness. Thus, the knowledge organization and the analysis is externalized in aseparate layer, and entities access information pre-digested and in a shape that is simplerto use.

6.2.1 Environmental layer

The environmental layer represents the lowest abstraction level of CAFE’s architecture.At this level data are gathered from different sensors located in the environment. Ourapproach is independent from the number and type of sensors used. Let us think, forexample, about the possibility to track the user’s position inside a room: for this purposewe could use a kinect10, or some cameras, or a pressure sensor on the ground. CAFEis designed so that our choice, whichever it is, does not require any modification to thesystem.Actuators also belong to this layer. By means of them entities can act/react according tocontext, modifying their own environment.

6.2.2 Data processing layer

In the data processing layer, the data gathered from sensors are processed, analysed andused to build a Semantic Network. The Semantic Network is updated every time a newevent occurs. In this way, the network represents a literal snapshot of the context relatedto a given environment in a given moment. The basic idea behind this layer is to contin-uously and autonomously analyse atomic data from sensors, in order to aggregate themand build a series of relationships among them, giving them the exact meaning. This taskis accomplished without a direct human intervention. Moreover, it is general and flexible,since it can be adapted to a wide range of data types.

10 Kinect is a motion sensing input device by Microsoft for the Xbox 360 video game console andWindows PCs. [wikipedia.org]


6.2.3 Knowledge layer

The knowledge layer is composed of a Semantic Network used as repository of infor-mation. Using a Semantic Network allows us to describe the context in a semantic way,disregarding whatever programming language, operating system, or middleware. How-ever, the major benefit related to this model is that it facilitates the formal analysis of theknowledge. Thanks to this approach, in fact, it is possible to exploit reasoning method-ologies which use first-order logic11, temporal logic12, etc. As already pointed out inChapter 3, the knowledge is stored as a set of triples, where every information has theform subject-predicate-object, for example “David is-located-in kitchen”.

6.2.4 Reasoning layer

The reasoning layer constitutes the highest abstraction level of the CAFE’s architecture.This layer offers the possibility to query the Semantic Network in order to get a clearand precise knowledge about the context related to a given environment. By queryingthe Semantic Network, entities simply improve their knowledge about what is happeningaround them in a given moment. The queries to the Semantic Network are performedusing SPARQL, a standard query language characterized by a simple syntax and a highexpressiveness. We are going to speak more in details about the CAFE’s reasoning fea-tures in Section 6.4.

6.3 Resource mapping

CAFE maps Python classes to classes of a Semantic Network, Python objects to indi-viduals of a Semantic Network, and attributes on Python objects to links of a SemanticNetwork. In this section we explain in details how the above-mentioned mappings work.All the mapping features are handled by using RDFlib, a Python package intending toprovide core RDF types and interfaces for working with RDF.

11 First-order logic is a formal system used in mathematics, philosophy, linguistics, and computer scienceand it is also known as first-order predicate calculus, the lower predicate calculus, quantification theory, andpredicate logic (a less precise term). [wikipedia.com]

12 In logic, the term temporal logic is used to describe any system of rules and symbolism for represent-ing, and reasoning about, propositions qualified in terms of time. [wikipedia.org]

David Sorrentino 61

6.3.1 Classes mapping

In CAFE every Python class belonging to a Context-Space corresponds to a node in theSemantic Network representing that same Context-Space.Thanks to the use of meta-programming, the mapping is performed in an automatic way.The only care we must take is to inherit the class “Entity” for each class we want toinsert into the Semantic Network. For example, Listing 6.9 shows how to map the class“Student” represented in the UML class diagram in Figure 6.6.

Listing 6.9: Mapping a class in CAFE

import S t u d e n t

It is evident how intuitive the mapping is; in practice, it is enough to perform a nor-mal Python import of the class we want to insert in the network, and CAFE will do therest.

Figure 6.6: UML Class Diagram of an illustrative class mapped in CAFE

As the result in Figure 6.7 shows, CAFE maps the class “Student” inheriting “Entity”,and also all its superclasses, building a hierarchy by means of “is-a” links.

Figure 6.7: Result of a class mapping in CAFE


6.3.2 Objects mapping

As for the classes, in CAFE every Python object belonging to a Context-Space corre-sponds to a node in the Semantic Network representing that same Context-Space. Asalready pointed out in Section 3.4, in fact, Semantic Networks treat classes and individu-als in the same way, without distinguishing between them.As shown in Listing 6.10, the mapping of objects can be performed by using the method“createEntity”, which takes as parameters the class and the name of the individual tobe mapped. CAFE checks whether an individual with the same name already exists inthe same Context-Space, and whether the class which the individual belongs to inheritsthe class “Entity”. Obviously, if the class which the individual belongs to has not beenmapped yet, CAFE automatically provides for mapping it as previously explained in Sec-tion 6.3.1.

Listing 6.10: Mapping an individual in CAFE

marco = c o n t e x t s p a c e . c r e a t e E n t i t y ( S t u d e n t , " Marco " )

6.3.3 Attributes mapping

In CAFE attributes of Python objects belonging to a Context-Space correspond to links inthe Semantic Network representing that same Context-Space.In Section 6.1 we saw how to define a property, corresponding to a link in the SemanticNetwork. But if we want to use this property, we also need to specify which classes aregoing to use that property, that corresponds to specifying which nodes are going to usethat link. For this purpose, as shown in Listing 6.11, in CAFE we use the normal Pythonsyntax to connect two classes and a property, that correspond to two nodes and a link fromthe Semantic Network point of view.

Listing 6.11: Specifying a link’s domain and range in CAFE

Pe r s on .NAME = s t rPe r s on .AGE = i n tThing . ISLOCATEDIN = Room

As is visible from the previous example, it is enough to consider the property as an at-tribute of the subject class and assign to it the respective object class. In this way we createa backbone of the Semantic Network, in which all the domains and ranges of the proper-ties are clearly specified. The backbone corresponding to Listing 6.11 is represented inFigure 6.8.

David Sorrentino 63

Figure 6.8: An example of Semantic Network backbone in CAFE

It is important to notice that a backbone, apart from giving to the network a precise struc-ture and avoiding misunderstandings, is also useful to reason on, since it may containmany relevant information.Once the backbone has been defined, CAFE is ready to automatically map on the Seman-tic Network the attributes of the Python objects belonging to the respective Context-Space(also known as entities). To do that, as Listing 6.12 shows, we simply need to assign avalue to the attribute we want to map on the network.

Listing 6.12: Mapping a link in CAFE

marco .AGE = 26

Obviously, looking at backbone, CAFE will make sure that the type of the assigned valuecorresponds to the expected one.The property taken into account in the previous example is a property with cardinality“1”, therefore we can not assign more than one object to it (Marco has only one age). Butlet us consider the property “talks-to” and the triple “Marco;talks-to;Andrea”. What hap-pens if, while Marco is talking to Andrea, Rose approaches Marco and joins the talk? Inthat case our triple should become something similar to “Marco;talks-to;Andrea,Rose”.Well, CAFE automatically manages properties with multiple cardinality, without requir-ing changes in the syntax used to map a single property. In fact, in that case CAFE uses alist to store all their objects. However, thanks to meta-programming, this is hidden to oureyes, since we can go on treating these properties in the same way as we treat propertieswith cardinality “1”. In this respect, Listing 6.13 shows the mapping of a property withmultiple cardinality.

Listing 6.13: Mapping a link with multiple cardinality in CAFE

marco . TALKSTO = a n d r e amarco . TALKSTO = r o s e


It is important to point out that, since the property “talks-to” is also symmetric, CAFEwill manage it creating symmetric links among the nodes related to that property. Thismeans that we just need to know that Marco is talking to Andrea and Rose, and CAFEwill know that, consequently, Rose is talking to Marco and Andrea, and Andrea is talkingto Marco and Rose.But what happens if Rose eventually gets bored and decides to leave the conversation withMarco and Andrea? In that case we would probably need to remove from the network thetriple “Rose;talks-to;Marco,Andrea”. Well, CAFE allows us to do it simply by using thenormal Python syntax for deleting an attribute, as shown in Listing 6.14.

Listing 6.14: Removing a link between two or more nodes in CAFE

d e l r o s e . TALKSTO

Instead, let us imagine that Rose decides to leave only the conversation with Andrea, butshe goes on talking to Marco. In that case, CAFE allows us to remove only the triple“Rose;talks-to;Andrea” simply by specifying the object to remove, as shown in Listing6.15.

Listing 6.15: Removing a link between twos nodes in CAFE

d e l r o s e . TALKSTO[ a n d r e a ]

Last but not least, let us imagine that today is Marco’s birthday and we want to update hisage. In this case we can just assign a new value to Marco’s age, as shown in Listing 6.16,without worrying about deleting the previous age. Indeed, CAFE knows that “age” is aproperty with cardinality “1”, and it will automatically replace the old age with the newone. Obviously, this does not work with properties with multiple cardinality, since CAFEwill just add the new value to the existing list of old values.

Listing 6.16: Updating a link between two nodes in CAFE

marco .AGE = 27

6.4 Inference and reasoning

As shown in Section 6.2.4, CAFE also provides reasoning features, allowing us to querythe network in order to get information about the context stored in it. Queries have to beformulated in SPARQL (Simple Protocol and RDF Query Language), a query language

David Sorrentino 65

that matches patterns in the graph and binds wildcard character13 variables as it findssolutions.

Figure 6.9: Example of a Semantic Network

Considering the Semantic Network shown in Figure 6.9, a plain example of SPARQLquery could be the one in Listing 6.17.

Listing 6.17: Example of a SPARQL query

base < h t t p : / / c a f e . ns / home−e n v i r o n m e n t #>SELECT DISTINCT ? aname ? bname

WHERE {? a : knows ? b .? a : name ? aname .? b : name ? bname .

}

The result of this query (see Listing 6.18) is simply the name of all the people knowingother people:

Listing 6.18: Example of a SPARQL query

Marco knows RoseMarco knows AndreaRose knows MarcoRose knows AndreaAndrea knows MarcoAndrea knows RoseAndrea knows JackJack knows Andrea

13 A wildcard character can be used to substitute for any other character or characters in a string.[wikipedia.org]


Listing 6.17 shows just a plain example, but SPARQL is a power tool and it providesplenty of advanced features to extract information from the network and infer new knowl-edge in it.Entities belonging to a Context-Space can directly query the Semantic Network to getuseful data by using the method “ask”, as shown in Listing 6.19.

Listing 6.19: Example of a query performed by an entity

r e s p o n s e = s e l f . a sk ( que ry )

However, every Context-Space in CAFE is also equipped with a server aiming to serverequests of queries from outside, and an external client, which allows others to contactthe server and ask for information about the context. Therefore, by using the client, anexternal user having the right privileges can query the Semantic Network in order to un-derstand the context.Once we queried the network for information, CAFE also allows us to convert that infor-mation into a new set of triples that can be added to the network. In this way it is alwayspossible to create new knowledge, simply by performing queries.Also the management of the SPARQL networking of queries has been implemented by us-ing the already mentioned RDFlib, which provides useful and powerful API for that.

6.5 Summary

In this chapter we introduced CAFE, a contextual infrastructure based on the integrationof Semantic Networks with the Object-Oriented model, describing how we implementedit and listing its main features.

In the next chapter we are going to propose an illustrative scenario in order to show howit is possible to use CAFE to represent and manage the context related to that scenario.We will also use this demonstration to underline the results we achieved and point out thelimitations of CAFE.

67

Chapter 7

Results

In the previous chapter we introduced and described CAFE, a context-aware infrastruc-ture based on the integration of Semantic Networks with the Object-Oriented model. Inthis chapter, we propose an illustrative scenario in order to show how it is possible touse CAFE to represent and manage the context related to that scenario. Furthermore,we exploit this demonstration to underline the results we achieved and to point out thelimitations of CAFE.

7.1 Scenario

The scenario presented in this chapter is just a plain scenario about a home environment,but it is a good example to easily understand how CAFE works and which benefits we canget from it. The scenario includes a house, some people living in it, and some objects thatyou can typically find in a house.

Our main idea is to build context-aware application able to manage the context related to agiven environment. For this purpose, the first step is to individuate the entities belongingto the environment and classify them in classes. Then, the following step is to individuatethe properties of the entities and the relationships among them, and to represent them asattributes of the above-mentioned classes.Let us consider the following entities and properties for the scenario taken into account:

• Child, Adult, Elderly. We decided to distinguish among children, adults, and el-derly people, since they usually tend to behave differently. However, they share thefollowing properties: ID, name, location, age, gender, posture, temperature in Cel-


sius, blood pressure, people they are talking to, appliances they are using, objectsthey are holding.

• Appliance. All the household machines, using electricity or some other energyinput. They have the following properties: ID, name, location, description, status(e.g., on, off, stand-by, etc).

• Kitchenware. Utensils, dishes, and other tools made to be used in the kitchen.They have the following properties: ID, name, location, description.

• Generic Object. All the objects that are not appliances or kitchenware. They havethe following properties: ID, name, location, description.

• Room. The rooms of the house taken into account. They have the following prop-erties: ID, name, location, temperature in Celsius.

The UML Class Diagram in Figure 7.1 shows how the scenario may be modelled accord-ing to the Object-Oriented model.

Figure 7.1: UML Class Diagram of the scenario

David Sorrentino 69

7.2 Demonstration

Once we individuated classes and properties characterizing the environment which we areworking on, we can create the Context-Space that will represent the context of the homeenvironment taken into account.

Figure 7.2: Creation of a new Context-Space in CAFE

As shown in Figure 7.2, when we create a new Context-Space, CAFE initializes the Se-mantic Network that will be used to represent the context, associating to it a namespace.As already mentioned in Chapter 5, the Context-Space is nothing but a graph, that meansthat we can merge two or more Context-Spaces without any effort. This feature underlinesthe scalability of our approach. In fact, we might choose to divide a given context in moresub-contexts and manage them separately, and finally merge the sub-contexts without anyeffort and consider them again as a single context during the reasoning phase.It is important to underline that the use of Semantic Networks makes CAFE capable ofmanaging incomplete or inaccurate information due to incompleteness of data from sen-sors. This shows that our approach is flexible, since it allows CAFE to adapt to lacks ofinformation.

The next step is to define the classes of the entities populating the environment (see Figure7.3).

Figure 7.3: Definition of entities classes in CAFE

Clearly defining an entity class in CAFE is easy and direct, since this task can be accom-plished using the normal Python syntax to import a class. It is important to notice howCAFE automatically manages the hierarchy of the classes. The class “Person”, for exam-


ple, is not mentioned in the import command, however CAFE initializes it, since an adultis also a person.

Figure 7.4 shows the next step, that is to define the entities present in the environment,which are supposed to belong to the previously defined classes. Notice how every en-tity we create starts to be mapped on the Semantic Network, constituting a piece of ourknowledge.

Figure 7.4: Definition of entities in CAFE

At this stage we could prefer to divide the Context-Space in different local-contexts, as al-ready explained in Section 6.1, and define the properties related to each local-context. Forthis scenario, we chose to have three local-contexts: information, actions, and location.The first one constitutes the part of the context containing information about the entities.The second one constitutes the part of the context containing the actions performed by theentities. Finally, the third one constitutes the part of the context containing locations andmovements of the entities.Figure 7.5 shows how the local-context “actions” and the properties related to it are de-fined.

After defining the properties characterizing the environment taken into account, we needto assign to each of them a subject entity and an object entity. In order to do that, as shownin Figure 7.6, we can simply use the Python syntax to assign a value to a class attribute.

David Sorrentino 71

Figure 7.5: Example of definition of a local-context in CAFE

Figure 7.6: Example of definition of properties in CAFE

Once the contextual backbone discussed in Section 6.3.3 is ready, we might use theCAFE’s feature providing a graphical overview of the context. As already pointed out inthe previous chapter, this feature is accessible by invoking the method “visualizeContext”from a Context-Space object. Notice how the possibility to have a graphical representa-tion of the context gives to the model proposed in our approach a very high readability.Figure 7.7 shows the image that CAFE produces in output to graphically represent thecontextual backbone previously created.

Now that the structure of the context is ready we can start to fill it in with data gatheredfrom the sensors. CAFE needs that all the input data are in the format subject-predicate-object, as the example in Listing 7.1 shows. For this reason we assume that every sensoris provided with an interface aiming to transform raw data to the subject-predicate-objectformat.

Listing 7.1: Example of input data in CAFE

marco t a l k s t o a n d r e a ;

In order to test CAFE, we decided to create a series of simulated sensors, connecting tothe Sensors Server and sending to it data about the environment. These simulated sensorswork in a very simple way. Each of them has a list of possible sensed data. After sleepingfor a random time interval, they randomly pick from the list one of the possible sensed


data and they send it to the Sensors Server. After sending data, they come back sleepingfor another random time interval.

bathroom

Room

is a

Thing

is a

Placeis a

Person

is a

marco

Adult

is a

is a

bottle

Kitchenware

is a

Objectis a

is a

television

Appliance

is a

is a

toaster

is a

GenericObject

is a

livingRoom

is a

broom

is a

kitchen

is a

roseis a

spoon

is a

andrea

is a

dishwasher

is a

bowlis a

Figure 7.7: Visualisation of a contextual backbone in CAFE

In this scenario we consider seven types of sensors: cameras, microphones, RFID read-ers, a blood pressure sensor, a heart rate sensor, a body thermometer, and environmentalthermometers. In addition, we assume that every appliance can communicate with the

David Sorrentino 73

Sensors Server to send data about its status (i.e., on, off, stand-by, etc). By means ofcameras we could have information about people’s posture and location. By using mi-crophones and voice recognition we could know when somebody is speaking and whohe/she is. RFID readers could provide us information about who is holding what. Theblood pressure sensor and the body thermometer could give us information about peo-ple’s health status. Finally, the environmental thermometers could let us know what is thetemperature of every room.The fact that CAFE can handle information of different types, generated by a variety ofheterogeneous sources and with different levels of granularity, shows that our approach isgeneral-purpose, since the system is able to easily change in response to different systemrequirements and types of data. Furthermore, CAFE also demonstrates that our approachis flexible, by guaranteeing an easy handling of the atomic data forming the context, andbeing capable to manage incomplete or inaccurate information due to incompleteness ofdata from sensors.

Figure 7.8 shows an illustrative execution of CAFE, in which simulated data from camerasare sent to the Sensors Server. Naturally the system is going to use those data to update itsknowledge about the environment. In this particular case the system receives data aboutpeople’s locations and posture.

Figure 7.8: Simulated data from cameras sent to the Sensors Server


However, in this demonstration we involve all the types of sensors above-mentioned insending simulated data to the Sensor Server. Therefore, after some time of execution, wemay ask CAFE to print the context to the screen.

television

Appliance

is a

Object

is a

GenericObject

is a

Thing

is a

marco

uses

kitchen

islocatedAdult

is a rose

talksto

andrea

talksto

bowl

holds

spoon

holds

standing posture

Room

is a

Person

is a

uses

is a

posture

bathroom

islocated

bottleholds

talksto

is a

talksto

posture

islocated

toasteruses

Kitchenware

is a

is a

is a

is a

Place

is a

dishwasher

is a

is a

is a

is a

livingRoom

is a

is a

broom

is a

Figure 7.9: Graphical representation of the context in CAFE

As shown in Figure 7.9, the image produced by the system gives us a graphical repre-sentation of the context related to the environment taken into account. It is clear that thereadability of this model decreases proportionally with the increasing of the amount ofdata we deal with.

At this stage all the entities have the possibility to be aware of the context (or a part of it)around them, since they can use simple SPARQL queries to reason on every informationthey are interested in. For example, the LightManager is probably interested in knowingwhether everybody left the house, since it could switch the lights off.However we also might be interested in accessing some information about the contextrelated to a given environment from outside the system. In this respect, CAFE providesto us the possibility to query a Context-Space by using a client expressly implemented for

David Sorrentino 75

this purpose. Obviously the client can be used independently, since it does not impede thenormal execution of CAFE. Figure 7.10 shows an example of a SPARQL query performedby means of the above-mentioned client. In this case, for instance, the query allows us toknow the list of empty rooms, where by empty rooms we mean the rooms that contain nopeople.

Figure 7.10: An example of a SPARQL query performed by means of our query-client

Now let us assume we want to make this knowledge persistent, perhaps in order to shareit among different applications.Well, by using Shelve1 CAFE provides us the possibility to store the context of a givenenvironment into a binary file.

Figure 7.11: Saving a context’s snapshot into a binary file

1 Shelve is a powerful Python module for object persistence. [python.about.com]


In practice CAFE takes a snapshot of the context at a given moment. In this way we mayaccess a shelf containing all the history of the context, that allows us to reason on eventshappened in the past. Figure 7.11 shows how CAFE saves some snapshots of the contextinto a binary file.

Figure 7.12 shows how to load the history of a context. As is visible, every snapshotconstituting the history is identified by a timestamp and is composed by the namespace ofa Context-Space and a graph containing all the contextual information about that Context-Space.

Figure 7.12: Loading a context’s history from a binary file

In addition, CAFE allows us to serialize the context to an OWL ontology and upload iton a FTP server. In this way we are free to access it from every networked device andreason on it using an external OWL reasoner. Furthermore, we may choose to convert itagain into a graph, in order to update its content. Figure 7.13 shows how CAFE serializesa context into an OWL ontology, updates it on a FTP server, and finally gets it from theserver converting it again into a graph.

Figure 7.13: Context as OWL ontology

Finally, as already explained in Section 6.1, in CAFE Context-Space are treated as simplegraphs, and that allows us to exploit all the properties related to this kind of data structures.Since the graph model is redundancy-free, ambiguous situations due to some repetitionsof information are automatically avoided. Therefore, merging two or more graphs it ispossible to bind information coming from different Context-Spaces in order to have awider view of the context.

David Sorrentino 77

Figure 7.14 shows how CAFE merges two Context-Spaces representing two different en-vironments. The result is nothing but a third graph containing all the information belong-ing to the merged graphs.

Figure 7.14: Merging two different Context-Spaces

7.3 Summary

In this chapter we proposed an illustrative scenario in order to show how it is possibleto use CAFE to represent and manage the context related to that scenario. We also usedthis demonstration to underline the results we achieved and point out the limitations ofCAFE.

79

Chapter 8

Conclusions

One of the crucial issues related to context-aware computing is to have a proper andconvenient model to represent and manage the context. Existing representation modelslike ontologies constitute a well researched and mature solution. However, they are notmade to represent continuously changing data; moreover, building and maintaining themmight be highly error-prone, time-consuming, and non-scalable processes, and they canbecome tedious tasks if they are done manually.This thesis work aimed to propose a model that is highly-readable, flexible, scalable,general-purpose, and modular, in order to represent and manage contextual information ofdifferent types, generated by a variety of heterogeneous sources and with different levelsof granularity. Furthermore, the proposed model allows reasoning, guarantees an easyhandling of the atomic data forming the context, and is capable to manage incomplete ornot accurate information due to incompleteness of data from sensors.This model is based on the integration of Semantic Networks with the Object-Orientedmodel, therefore it exploits all the advantages of the two approaches.

In this essay, first of all we analysed the most popular and important representation modelssuitable to represent contextual data, pointing out, for each one of them, advantages anddisadvantages.After that, we focused on Semantic Networks, explaining in details their strong and weakspots, and the reasons that led us to choose them.Then, we presented the approach we followed in order to integrate Semantic Networksand the Object-Oriented model, showing that the use of scripting languages and theirproperties, such as dynamic typing, meta-programming, and introspection, guarantees agood integration of the two models.In addition, we showed the implementation of CAFE, a contextual infrastructure written


in Python that exploits the integration of Semantic Networks and the Object-Orientedmodel.Finally, we introduced an illustrative scenario in CAFE, showing how the presented modelworks, and underlining the achieved results and the gaps which can be plugged in thefuture.

In conclusion, in this section we summarise the results of our work, highlighting thereasons why the integration of Semantic Networks with the Object-Oriented constitutesa model characterized by high readability, flexibility, scalability, general-purpose, andmodularity.

• General-purpose. The model proposed does not need to work in a specific domain.Indeed, the high expressiveness of Semantic Networks makes the system able toeasily change in response to different system requirements and types of data.

• High readability. The possibility to have a graphical representation of the context(Semantic Networks are a graphical model) gives to the model proposed in ourapproach a very high readability. However, it is clear that the readability of thismodel decreases proportionally with the increasing of the amount of data we dealwith.

• Flexibility. Thanks to the use of Semantic Networks, the model proposed guar-antees an easy handling of the atomic data forming the context, and is capable ofmanaging incomplete or inaccurate information due to incompleteness of data fromsensors.

• Scalability. The model proposed enjoys a good scalability. For example, we mightchoose to divide a given context in more sub-contexts and manage them separately,and finally, since Semantic Networks can be considered graphs, we can merge thesub-contexts without any effort and consider them again as a single context duringthe reasoning phase.

• Modularity. According to the Object-Oriented approach, every entity forming thecontext constitutes a separate entity, whose internal workings are decoupled fromother parts of the system. In particular, modularity brings with it the followingadvantages concerning the system design and development:

– Simplicity. Thanks to the Object-Oriented model, the complexity of the pro-posed model is reduced and its structure is very clear.

– Modifiability. In the proposed model it is easy to make minor changes inthe data representation. In fact, the integration of the Object-Oriented model

David Sorrentino 81

guarantees that changes of an entity do not affect any other part of the model,since in the Object-Oriented approach the only public interface that the exter-nal world has to a class is through the use of methods.

– Extensibility. The model proposed is extensible, since, thanks to the Object-Oriented model, adding new features or responding to changing operating en-vironments can be solved by introducing a few new objects or modifying someexisting ones.

– Maintainability. The model proposed enjoys a high maintainability, since theObject-Oriented approach allows objects to be maintained separately, makinglocating and fixing problems easier.

– Re-usability. The Object-Oriented model makes the model we proposed re-usable. This means that entities characterizing a given context can be reusedin different contexts.

8.1 Future works

Following the approach described in this essay and analysing CAFE, the context-awareinfrastructure presented in this thesis work, a series of possible future works could betaken up.

First of all, we claim that it would be beneficial to integrate our model with a standardontology language, such as OWL, in order to overcome the limitations that affect regularSemantic Networks. In that way, in fact, the resulting model would be even more completeand therefore more convenient to use in order to represent and manage context.

Second, although our approach allows us to merge different contexts (since they aretreated like graphs), so far CAFE does not provide the possibility to manage the unifica-tion of distributed Context-Spaces. In order to handle this issue, we consider interestingthe idea to use a tuple space1. In fact, by using a tuple space, every Context-Space couldpost its own context as a set of tuples in the space, and reasoners could retrieve the datawhich they are interested in directly from that space, with the purpose of reasoning onthem.

Furthermore, since CAFE needs data in subject-predicate-object format, it assumes thatevery sensor is provided with an interface aiming to transform raw data to the above-

1 A tuple space is an implementation of the associative memory paradigm for parallel/distributed com-puting. [wikipedia.org]


mentioned format. For this reason, we chose to overcome this issue by working withsimulated sensors. Thus, a future work would be to make CAFE work with real sensors,by designing and implementing simple interfaces capable to take raw data from sensorsas input and give a subject-predicate-object representation of them as output.

Finally, in this essay we claimed that the Object-Oriented approach which CAFE isbased on makes it a direct, quick-to-understand, and easy-to-use contextual infrastruc-ture. However, an interesting future work could be to use HCI usability techniques, suchas think-aloud protocol2, heuristic evaluation3, and cognitive walkthrough4, in order toperform a qualitative evaluation that effectively demonstrates the claimed ease-of-use andsimplicity-of-understanding.

2 Think-aloud protocol (or TAP) is a method used to gather data in usability testing in product designand development. [wikipedia.org]

3 A heuristic evaluation is a discount usability inspection method for computer software that helps toidentify usability problems in the user interface (UI) design. [wikipedia.com]

4 The cognitive walkthrough method is a usability inspection method used to identify usability issuesin a piece of software or web site, focusing on how easy it is for new users to accomplish tasks with thesystem. [wikipedia.org]

83

Bibliography

Bikakis, A., Patkos, T., Antoniou, G., & Plexousakism, D. (2007). A survey of semantics-based approaches for context reasoning in ambient intelligence. In .

Bottazzi, D., Montanari, R., & Toninelli, A. (2007, sep). Context-aware middleware foranytime, anywhere social networks. IEEE Intelligent Systems, 22(5), 23–32.

Brachman, R. (1983, October). What is-a is and isn’t: An analysis of taxonomic links insemantic networks. Computer, 16(10), 30-36.

Brown, M. (1996). Supporting user mobility. In In proceedings of ifip world conference

on mobile communications (pp. 69–77). Chapman and Hall.Brown, P. J., Bovey, J. D., & Chen, X. (1997, October). Context-aware applications: from

the laboratory to the marketplace. IEEE Personal Communications, 4(5), 58-64.Chen, G., & Kotz, D. (2000). A survey of context-aware mobile computing research

(Tech. Rep.). Hanover, NH, USA.Chen, H. (2004). An intelligent broker architecture for pervasive context-aware systems.

Unpublished doctoral dissertation, University of Maryland, Baltimore County.Chen, H., Finin, T., & Joshi, A. (2003). An ontology for context-aware pervasive comput-

ing environments. Special Issue on Ontologies for Distributed Systems, Knowledge

Engineering Review, 18, 197–207.Chen, H. L. (2004). An intelligent broker architecture for pervasive context-aware sys-

tems. University of Maryland, Baltimore County.Clark, H. H., & Brennan, S. E. (1991). Grounding in communication. perspectives on

socially shared cognition. In L. B. Resnick, J. M. Levine, & S. D. Teasley (Eds.),Perspectives on socially shared cognition (pp. 127–149). American PsychologicalAssociation.

Cooperstock, J. R., Tanikoshi, K., Beirne, G., Narine, T., & Buxton, W. (1995). Evolutionof a reactive environment. In I. R. Katz, R. L. Mack, L. Marks, M. B. Rosson, &J. Nielsen (Eds.), Chi (p. 170-177). ACM/Addison-Wesley.

Dargie, W. (2009). Context-aware computing and self-managing systems (1st ed.). Chap-man & Hall/CRC.


Dey, A. K., Abowd, G., Pinkerton, M., & Wood, A. (1998). Cyberdesk: A frameworkfor providing self-integrating context-aware services. In Knowledge-based systems

(pp. 47–54). ACM Press.Dey, A. K., & Abowd, G. D. (1999). Towards a better understanding of context and

context-awareness. In In huc ’99: Proceedings of the 1st international symposium

on handheld and ubiquitous computing (pp. 304–307). Springer-Verlag.Dey, A. K., & Abowd, G. D. (2000). Cybreminder: A context-aware system for support-

ing reminders. In (pp. 172–186). Springer-Verlag.Elrod, S., Hall, G., Costanza, R., Dixon, M., & Rivieres, J. des. (1993). Responsive office

environments. Commun. ACM, 36(7), 84-85.Fickas, S., Kortuem, G., & Segall, Z. (1997). Software organization for dynamic and

adaptable wearable systems. In In proceedings first international symposium on

wearable computers (iswc’97) (pp. 13–14).Fowler, M. (2002). Patterns of enterprise application architecture. Addison-Wesley

Longman, Amsterdam.Henricksen, K., & Indulska, J. (2004). Modelling and using imperfect context informa-

tion. In Proceedings of the second ieee annual conference on pervasive computing

and communications workshops (pp. 33–). Washington, DC, USA: IEEE ComputerSociety.

Hull, R., Neaves, P., & Bedford-Roberts, J. (1997). Towards situated computing. InProceedings of the 1st ieee international symposium on wearable computers (pp.146–). Washington, DC, USA: IEEE Computer Society.

Kalyanpur, A., Pastor, D. J., Battle, S., & Padget, J. A. (2004, June). Automatic mappingof owl ontologies into java. In F. Maurer & G. Ruhe (Eds.), Proceedings of the 16th

int’l conference on software engineering & knowledge engineering (seke’2004) (pp.98–103). Banff, Alberta, Canada.

Kim, H., Cho, Y.-J., & Oh, S.-R. (2005). Camus: a middleware supporting context-aware

services for network-based robots.

Krumm, J. (2009). Ubiquitous computing fundamentals (1st ed.). Chapman & Hall/CRC.Ludford, P. J., Frankowski, D., Reily, K., Wilms, K., & Terveen, L. (2006). Because i

carry my cell phone anyway: functional location-based reminder applications. InChi 06 proceedings of the sigchi conference on human factors in computing systems

(Vol. 8, pp. 889–898). ACM Press.Marra, R. M., & Jonassen, D. H. (1996). Transfer effects of semantic networks on expert

systems: mindtools at work. In Proceedings of the 1996 international conference on

learning sciences (pp. 219–226). International Society of the Learning Sciences.

David Sorrentino 85

Morse, D. R., Armstrong, S., & Dey, A. K. (2000). The what, who, where, when, and

how of context awareness.

Mozer, M. C. (1998). The neural network house: An environment hat adapts to itsinhabitants. Proc AAAI Spring Symp Intelligent Environments, 110–114.

Mrohs, B., Luther, M., Vaidya, R., Wagner, M., Steglich, S., Kellerer, W., et al. (2005).Owl-sf: A distributed semantic service framework. Proc. of the Workshop on Con-

text Awareness for Proactive Systems (CAPS 05), Helsinki.Nierstrasz, O. (1989). A survey of object-oriented concepts. In Object-oriented concepts,

databases and applications (pp. 3–21). ACM Press and Addison Wesley.Oren, E., Delbru, R., Gerke, S., Haller, A., & Decker, S. (2007). Activerdf: object-

oriented semantic web programming. In C. L. Williamson, M. E. Zurko, P. F. Patel-Schneider, & P. J. Shenoy (Eds.), (p. 817-824). ACM.

Ousterhout, J. K. (1998, March). Scripting: Higher-level programming for the 21stcentury. Computer, 31(3), 23–30.

Pascoe, M. J. (1998). Adding generic contextual capabilities to wearable computers. InProceedings of the 2nd ieee international symposium on wearable computers (pp.92–). Washington, DC, USA: IEEE Computer Society.

Poslad, S. (2009). Ubiquitous computing: Smart devices, environments and interactions

(1st ed.). Wiley Publishing.Ranganathan, A., & Campbell, R. H. (2003). A middleware for context-aware agents in

ubiquitous computing environments. In Proceedings of the acm/ifip/usenix 2003

international conference on middleware (pp. 143–161). New York, NY, USA:Springer-Verlag New York, Inc.

Rekimoto, J., Ayatsuka, Y., & Hayashi, K. (1998). Augment-able reality: Situated com-munication through physical and digital spaces. In In proceedings of the 2 nd inter-

national symposium on wearable computers (pp. 68–75).Rodden, T., Chervest, K., Davies, N., & Dix, A. (1998). Exploiting context in hci design

for mobile systems. In in workshop on human computer interaction with mobile

devices.

Román, M., Hess, C., Cerqueira, R., Ranganathan, A., Campbell, R. H., & Nahrstedt, K.(2002, October). A middleware infrastructure for active spaces. IEEE Pervasive

Computing, 1(4), 74–83.Ryan, N. S., Pascoe, J., & Morse, D. R. (1998, October). Enhanced reality fieldwork: the

context-aware archaeological assistant. In V. Gaffney, M. van Leusen, & S. Exxon(Eds.), Computer applications in archaeology 1997. Oxford: Tempus Reparatum.

Schilit, B., & Theimer, M. (1994). Disseminating active map information to mobile hosts.IEEE Network, 8(5), 22–32.


Schilit, W. N. (1995). A system architecture for context-aware mobile computing.

Segaran, T., Taylor, J., & Evans, C. (2009). Programming the semantic web. Cambridge,MA: O’Reilly.

Serafini, L., & Tamilin, A. (2005). Drago: Distributed reasoning architecture for thesemantic web. In In eswc (pp. 361–376). Springer.

Soldatos, J., Dimakis, N., Stamatis, K., & Polymenakos, L. (2007, February). A bread-board architecture for pervasive context-aware services in smart spaces: middle-ware components and prototype applications. Personal Ubiquitous Comput., 11(3),193–212.

Sowa, J. (1984). Conceptual structures: Information processing in mind and machine.Addison-Wesley.

Sowa, J. F. (1991). Principles of semantic networks. In . Morgan Kaufmann.Wang, X., Dong, J. S., Chin, C.-Y., Hettiarachchi, S., & Zhang, D. (2004). Semantic

space: An infrastructure for smart spaces. IEEE Pervasive Computing, 3(3), 32-39.

Wang, X. H., Zhang, D. Q., Gu, T., & Pung, H. K. (2004). Ontology based contextmodeling and reasoning using owl. Pervasive Computing and Communications

Workshops, IEEE International Conference on, 0, 18.Want, R., Falcao, V., & Gibbons, J. (1992). The active badge location system. ACM

Transactions on Information Systems, 10, 91–102.Ward, A., & Jones, A. (1997). A new location technique for the active office.

Zouaq, A., Gasevic, D., & Hatala, M. (2011). Unresolved issues in ontology learning -position paper. In . Vancouver, BC, Canada.

School of Computer ScienceReykjavík UniversityMenntavegi 1101 Reykjavík, IcelandTel. +354 599 6200Fax +354 599 6201www.reykjavikuniversity.isISSN 1670-8539

integrating semantic networks and object-oriented … · tled integrating semantic networks and...

Documents