Faculteit Ingenieurswetenschappen Vakgroep...

Universiteit Gent

Faculteit Ingenieurswetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Matching van user generated content op basis van contextuele informatie

door

Bram Vandenholen

Promotoren:

Prof. dr. ir. B. DHOEDT

Prof. dr. ir. F. DE TURCK

Scriptiebegeleiders:

Ir. M. STROBBE (Universiteit Gent, INTEC)

Ir. Lic. O. VAN LAERE (Universiteit Gent, INTEC)

Ir. J. CRIEL (Alcatel-Lucent)

Dr. L. CLAEYS (Alcatel-Lucent)

Scriptie ingediend tot het behalen van de academische graad van Master in de

Ingenieurswetenschappen: Computerwetenschappen

Afstudeerrichting: Informatie- en Communicatietechnologie

Academiejaar 2006-2007

ii

Voorwoord

Bij mijn zoektocht naar een boeiende thesis kwam ik langs bij de informatie stand van

Alcatel-Lucent (toen nog gewoon Alcatel). Toen bleek dat zij reeds de thesis die ik in

gedachten had, hadden geïmplementeerd (videotelefonie via een digitaal televisie

platform) ben ik samen met hen op zoek gegaan naar even interessant onderwerp. Zo

zijn we tot context en matching gekomen. Ik wil hiervoor mijn promotoren Prof. Dr. Ir.

Bart Dhoedt, Prof. Dr. ir. Filip De Turck en de mensen van Alcatel-Lucent bedanken om

mij de mogelijkheid te geven om deze thesis na te streven.

Gedurende het voorbije jaar werd ik bijgestaan door verschillende begeleiders, met

name ir. Johan Criel, dr. Laurence Claeys, ir. Matthias Strobbe en ir. Lic. Olivier Van

Laere. Hen wil ik dan ook ten zeerste bedanken voor hun inzet die ze keer op keer

hebben getoond en hun wijze raad die ik steeds van hen kon verwachten.

Daarnaast wil ik ook de mensen van de afdeling ReNA bij Alcatel-Lucent bedanken voor

de aangename sfeer die ze mogelijk maakten tijdens de tijd die ik daar heb mogen

spenderen.

Als laatste zou ik al mijn familie, vrienden en kennissen die mij steeds zijn blijven

steunen en in mij geloven danken voor de energie die ze het afgelopen jaar in mij

hebben gestoken.

De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en

delen van de scriptie te kopiëren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met

betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van

resultaten uit deze scriptie.

20/07/2007 Bram Vandenholen

iii

Overzicht

Matching van user generated content op basis van contextuele informatie

door Bram Vandenholen

Scriptie ingediend tot het behalen van de academische graad van Master in de

Ingenieurswetenschappen: Computerwetenschappen

Afstudeerrichting: Informatie- en Communicatietechnologie

Academiejaar 2006-2007

Promotoren:

Prof. dr. ir. B. DHOEDT en Prof. dr. ir. F. DE TURCK

Scriptiebegeleiders:

Ir. M. STROBBE en ir. Lic. O. VAN LAERE(Universiteit Gent, INTEC)

Ir. J. CRIEL en dr. L. CLAEYS (Alcatel-Lucent)

Universiteit Gent

Faculteit Ingenieurswetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. dr. ir. P. LAGASSE

Samenvatting

Wanneer content uit zijn context gerukt wordt verliest het al zijn betekenis. Content moet daarom steeds binnen zijn context beschouwd worden. Met de komst van de Web 2.0 revolutie wordt content meer en meer door de gebruiker zelf gegenereerd, vanuit zijn context . Wanneer hij dan zelf op zoek gaat naar content gebeurt dit ook van uit een bepaalde context. Om zo goed mogelijke resultaten te produceren moeten we die in- en outputcontexten kunnen vergelijken ,i.e. context matching.

In dit werk stellen we een matching algoritme voor dat dit mogelijk maakt. Met behulp van een use case over restaurantbezoeken zullen we de werking van het algoritme illustreren. We maken gebruik van ontologieën om onze context voor te stellen en we zullen gebruik maken van het modulaire Context Aware Service Platform (CASP) [1] om de use case te implementeren.

Trefwoorden

Context, ontologie, user generated content, context matching.

iv

Abstract

Matching of user generated content based on contextual information

Bram Vandenholen

Supervisors: Prof. Dr. ir. B. DHOEDT and Prof. Dr. ir. F. DE TURCK

Abstract –When content is taken out of its context it will lose all its meaning. Content should therefore always be considered within its context. We introduce the concept of context matching and an associated algorithm to use that context to find better search results. Using ontologies to model context, we make use of the CASP framework [3], introduced by INTEC, to implement a use case involving restaurants. Some testing was done to get an idea of the performance of the algorithm. Keywords – User generated content, ontology, context, context matching.

I. INTRODUCTION

With the Web 2.0 revolution content is more and more being generated by the users themselves. This content needs to be considered within its context. Without context content might lose all its meaning.

Figure 1: Adding content and its context to a knowledge base

When the user queries for content he is also doing this from within a certain context, most likely from a different one than before. The way these contexts will be compared and more suitable content will be found is what we call context matching.

Figure 2: Sending a request, and its context, and receiving matched

content

II. CONCEPTS

A. Context

Context is a very powerful concept and is therefore not easy to define. We follow the definition given by Dey [1]:

“Context is any information that can be used to characterize the situation of an entity. An entity is a person,

place, or object that is considered relevant to the interaction between a user and an application, including

the user and application themselves.”

From this we can determine that there is more to context than location [2], which is the conception of context by the general public. We need to consider the who’s, where’s, when’s and what’s of entities to include all the facets of context.

B. Ontology

An ontology is a domain specific semantic description of concepts and their relations. They are used to model data and have their origins in Artificial Intelligence (AI). Context models are written in OWL [5], an extension of RDF (Resource Description Format) proposed by the W3C, used among other things for the Semantic Web [6]. We will use ontologies to model our context.

III. CONTEXT MATCHING

A. Matching

As stated in the introduction context matching will look for similarities between input- and output contexts to maximize the compatibility of the content to the users request. Similar to what is known as impedance matching in electronics where the output impedance is adjusted to the input impedance to maximize the power transfer.

B. Applicability

Content wise there is a wide spectrum out there and when we look at some of the Web 2.0 services, like YouTube, Flickr, etc, one thing we see in common is the fact that they allow ratings about the content. The ratings themselves are also content generated by the user. Those ratings do not have to be limited to virtual content of course. Real life

v

subjects like restaurants, airlines, super markets, etc. can also be rated.

It’s around those ratings that we have constructed our algorithm but it can be applied to all sorts of content.

C. Algorithm

The algorithm that we introduce consists of 4 steps (Figure 3): elimination, matching, grouping and arranging. In the first step try to eliminate some of the content based on elimination criteria, e.g. when the user looks for a gift store, stores that are not open at that time should not be taken into account.

Elmination Matching Arranging Grouping

Elimination criteria

Figure 3: The 4 steps of the algorithm

In the second step the actual matching takes place. We will adjust the rating considering the context that the rating was added to the knowledge base and the context of the request. R is a vector of n ratings, one for every context item that can be rated. Ki are the context factors of the input context en Ko of the output one, they are situated between 0 and 1 and determine the importance of the context item. Formula (1) will decrease the ratings based on the difference between the context factors.

∑ −−=n

jiom jRjKjK

nR ][)][][1(

1 (1)

In the grouping step the adjusted ratings will be grouped by their associated item. Depending on who gave the rating, other possible factors Kr can be added to influence the grouped rating Rn. <K> is the sum of all the Kr.

∑= mrn RKK

R1 (2)

The fourth and final step will arrange the best N ratings, where N is the number of requested results, from best to worst. Next to arranging them to their rating they can also be arranged to other criteria (like distance, price, etc.).

IV. USE CASE: RESTAURANT LOOKUP AND REVIEW

The use case we have implemented allows users to look for a restaurant that would be most suited for their intentions.

The context model that we use for our use case is depicted in Figure 4. It consists of an Upper Level Ontology (ULO) and a Domain Specific Ontology (DSO).

Figure 4: Context model

We distinguished 4 different types: just for food (no special reason), intimate (romantic diner), business (company lunch, possibly with clients) and in group (family or group of friends, possibly for special occasion). After their meal they get the opportunity to review the restaurant and this on food, setting and atmosphere (context items).

The context factors we used can be found in Table 1.

Setting Food Atmosphere

1 Just for food 0.2 0.8 0.4

2 Business 0.7 0.7 0.6

3 Intimate 0.7 0.6 0.9

4 In group 0.5 0.8 0.6

Table 1: Context factors

If for example the ratings 4, 3 and 5 were given in a business context for respectively setting, food and atmosphere we would get the results from Table 2 using formula (1). Depending on the compatibility of the contexts the rating is adjusted with a maximum when both contexts are the same.

Context 1 2 3 4

Rn 2.9 4 3.4 3.63

Table 2: Matched ratings

The Context Aware Service Platform (CASP) [3] we use is a modular framework based on OSGi to deploy and manage context aware applications. It uses the Jena2 library [7] for the knowledge base and the reasoner and supports OWL (Web Ontology Language). The reasoner allows for checking the consistency of the knowledge base and deducing new information.

ULO

DSO

vi

V. TESTING

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

25 50 75 100 125 150 175 200 225 250

# ratings

seco

nd

en

Figure 5: Performance of the matching step

During tests we varied the number of ratings that the matching step had to process and found that algorithm is linear in the number of ratings. With every increase of the number of ratings by 25 there was on average a 1.8 second increase in the execution time of the matching step as can be seen in Figure 5. For 200 ratings about 14 seconds are needed which leeds us to conclude that our implementation of the algorithm is not optimal for real-time systems.

VI. CONCLUSIONS

We have used ontologies to represent context and introduced a new context matching algorithm that allows for better search results in user generated content.

Form our implementation of the algorithm we had to conclude that it was not ideally suited for real time systems. Perhaps through parallelization and more efficient use of datastructures this could be overcome.

Context has proven to be a very powerful concept and together with ontologies it forms a promising duo.

ACKNOWLEDGEMENTS

Several people have been instrumental in allowing my thesis to be completed. Many thanks to ir. Johan Criel, Dr. Laurence Claeys, ir. Matthias Strobbe and ir. Olivier Van Laere for assisting me during the duration of my thesis.

REFERENCES

[1] K. Dey: Providing Architectural Support for Building Context-Aware Applications. Ph.D. thesis, Georgia Institute of Technology (2000)

[2] A. Schmidt, M. Beigl, H. W. Gellersen: There is more to Context than Location, University of Karlsruhe (2000)

[3] M. Strobbe, J. Hollez, G. De Jans, O. Van Laere, J. Nelis, F. De Turck, B. Dhoedt, P. Demeester, N. Janssens, T. Pollet: Design of CASP: an Open Enabling Platform for Context Aware Office and City Services. In Proceedings of MUCS 2007, the 4th International Workshop on Managing Ubiquitous Commuications and Services, Munchen (May 2007)

[4] J. Criel: Context Awareness, Gent (2005) [5] WWW: OWL. http://www.w3.org/2004/OWL/ [6] WWW: Semantic Web. http://www.w3.org/2001/sw/ [7] WWW: Jena. http://jena.sourceforge.net/

vii

Inhoudstafel

Hoofdstuk 1: Inleiding en probleemstelling .......................................................................... 1 Hoofdstuk 2: Concepten en literatuurstudie ......................................................................... 4 2.1 Context en Context Awareness ............................................................................... 4 2.1.1 Context ............................................................................................................. 4 2.1.2 Context awareness............................................................................................. 7

2.2 Ontologieën .......................................................................................................... 8 2.3 RFID en het Internet of Things............................................................................... 9 2.3.1 RFID ................................................................................................................. 9 2.3.2 Het Internet Of Things ..................................................................................... 10

2.4 Community Driven Services.................................................................................. 12 2.5 Literatuurstudie ................................................................................................... 14 2.5.1 Context Frameworks ........................................................................................ 14 2.5.2 CASP............................................................................................................... 16 2.5.3 Matching ......................................................................................................... 17 2.5.4 Upper Level Ontologieën .................................................................................. 19

Hoofdstuk 3: Architectuur en Algoritme ............................................................................. 20 3.1 Requirements...................................................................................................... 20 3.1.1 Humane requirements...................................................................................... 20 3.1.2 Technologische requirements ........................................................................... 21

3.2 Matching............................................................................................................. 24 3.2.1 Toepasbaarheid ............................................................................................... 24 3.2.2 Algoritme ........................................................................................................ 25

Hoofdstuk 4: Proof of Concept .......................................................................................... 29 4.1 Overwogen Use Cases ......................................................................................... 29 4.2 Gekozen Use case: Restaurant lookup and review ................................................. 30 4.2.1 Detaillering...................................................................................................... 30 4.2.2 Problemen en caveats ...................................................................................... 33

4.3 Domein Specifiek Context Model........................................................................... 35 4.4 Algoritme ............................................................................................................ 36 4.4.1 Eliminatie ........................................................................................................ 36 4.4.2 Matching ......................................................................................................... 36 4.4.3 Groepering ...................................................................................................... 39 4.4.4 Ordening ......................................................................................................... 40

4.5 Architectuur ........................................................................................................ 40 4.6 Persistentie ......................................................................................................... 42 4.7 Technologie ........................................................................................................ 43 4.7.1 OSGi ............................................................................................................... 43 4.7.2 Jena2.............................................................................................................. 44 4.7.3 SPARQL........................................................................................................... 44 4.7.4 GUI’s............................................................................................................... 45

Hoofdstuk 5: Evaluatie en prestatie van het algoritme ........................................................ 48 5.1 Testopstelling...................................................................................................... 48 5.2 Testmethode....................................................................................................... 48 5.3 Resultaten........................................................................................................... 48

Hoofdstuk 6: Conclusies ................................................................................................... 50 Hoofdstuk 7: Future Work ................................................................................................ 51 7.1 Context............................................................................................................... 51 7.2 Algoritme ............................................................................................................ 51 7.3 Andere................................................................................................................ 52

Appendix A: Programma’s en tools ................................................................................... 53 Appendix B: Evolutie van de ontologie.............................................................................. 55

viii

Afkortingen en symbolen

AI Artificial Intelligence

AJAX Asynchronous JavaScript and XML

CASP Context Aware Service Platform

CDS Community Driven Services

DL Description Logic

EDGE Enhanced Data Rates for GSM Evolution

EV-DO Evolution-Data Optimized

GPRS General Packet Radio Service

HSDPA High Speed Data Packet Access

HTML HyperText Markup Language

JVM Java Virtual Machine

KB Knowledge Base

NFC Near Field Communication

OSGi Open Source Gateway initiative

OWL Web Ontology Language

PDA Portable Digital Assistant

RDF Resource Description Format

RDFs Resource Description Format schema

RFID Radio-Frequency Identification

SOA Service Oriented Architecture

ULO Upper Level Ontology

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

W3C World Wide Web Consortium

WiFi Wireless Fidelity

WiMAX Worldwide Interoperability for Microwave Access

XML eXtensible Markup Language

Bram Vandenholen Scriptie 2006-2007

Matching van user generated content op basis van contextuele informatie 1

Hoofdstuk 1: Inleiding en probleemstelling

Context is een begrip dat iedereen wel al eens in de mond heeft genomen en het

belang van context is zeker niet te onderschatten. Wanneer iets uit zijn context gerukt

wordt en geponeerd wordt op zich of in een andere context verliest het al zijn

betekenis.

Sinds de jaren ’90 wordt er reeds onderzoek gedaan naar het belang van context en

hoe dit kan gebruikt worden in de technologie. Met de komst van het Semantische

Web [3], [4], [5] heeft de modellering van contextinformatie een nieuwe impuls

gekregen op het vlak van het contextmodel. De standaardisatie van RDF (Resource

Description Format) en OWL (Web Ontology Language) door het W3C [6] om

datamodellen (ontologieën) voor te stellen, zodat ze kunnen geïnterpreteerd worden

door machines, heeft een positieve invloed gehad op de manier we context, meer nog

de wereld, gaan modelleren.

In dit werk zal de nadruk gelegd worden op content en hoe deze zich relateert tot zijn

context waarin hij zich bevindt (Figuur 1). Heel veel content wordt vergaard “in se”

maar moet nadien geclassificeerd worden om later bij opzoekingen meer gepaste

resultaten te bekomen.

CONTEXT

CONTENT

Figuur 1: Content moet steeds binnen zijn context worden gezien



Alle content wordt echter altijd in een bepaalde context aan het systeem toegeleverd

(Figuur 2). Deze gerelateerde context kan gebruikt worden om zoekresultaten te

optimaliseren, met name ze aan te passen aan de context van de vrager. Hiervoor

hebben we een mechanisme nodig dat het mogelijk maakt om contexten te vergelijken

en zo meer gepaste content weer te geven. Dit wordt context matching genoemd. Dit

laat toe om content te gaan beschouwen binnen een andere context dan degene

waarbinnen hij is ingevoerd.

CONTEXT

KB

UPDATE VIA

DEDUCTION

Figuur 2: Content invoeren tezamen met zijn context

Wanneer een gebruiker content wil opvragen (een request) bevindt hij zich in een

bepaalde context die niet noodzakelijk dezelfde is als de context waarin de content

ingevoerd werd (Figuur 3). Meer nog de kans dat dit effectief zo is, is relatief klein.



CONTEXT

KB

��MATCHING &

REASONING

REQ

Figuur 3: Een request binnen zijn context

Het is de bedoeling om aan de hand van de context waarin de gebruiker zich bevindt

een zo goed mogelijke match te vinden, dus het vinden van content die ingegeven is in

een analoge context of content aanpassen aan de context van waaruit er bevraagd

wordt.

Matching laat toe van contexten met elkaar te vergelijken op een objectieve manier. Er

zal een transformatie van de context, waarin de content is ingegeven, gebeuren naar

de context waarin de content bevraagd wordt. Het matching algoritme dat we zullen

voorstellen in dit werk zal bestaan uit 4 stappen: eliminatie, de eigenlijke matching,

groepering en ordening.

In de volgende hoofdstukken zullen we eerst toelichting geven bij een aantal

concepten die aan bod komen in het verdere verloop van dit werk. Terminologie en

technologieën waar onder meer aandacht aan zal besteed worden zijn context, context

awareness, ontologieën en OSGi. Daarna zal de architectuur uitgediept worden alsook

de beschrijving van het ontwikkelde algoritme. In een daaropvolgende sectie zal een

use case aan bod komen rond het restaurant gebeuren als proof of concept van onze

architectuur en algoritme. We zullen eindigen met een aantal conclusies en ook even

aanhalen wat er in de toekomst nog kan gedaan worden rond de problematiek en

mogelijke toepassingen van dit werk.



Hoofdstuk 2: Concepten en literatuurstudie

In dit tweede hoofdstuk behandelen we een aantal concepten en begrippen die aan

bod komen in het verdere verloop van dit werk en die een beter inzicht zullen geven in

wat we willen bereiken met deze thesis. Context, een van de sleutelwoorden uit dit

werk, wordt uitvoerig besproken en ook het daar aan gerelateerde context awareness.

Daarnaast wordt uitgebreid aandacht besteed aan het begrip ontologie dat gebruikt

wordt om context voor te stellen.

De toepasbaarheid van de service die we zullen voostellen wordt ondermeer toegelicht

in de paragrafen over het Internet Of Things en Community Driven Services (CDS).

In de laatste sectie van dit hoofdstuk worden de belangrijkste onderwerpen van de

literatuurstudie toegelicht.

2.1 Context en Context Awareness

2.1.1 Context

Het begrip context in het kader van computerwetenschappen werd vroeger beperkt tot

wat men noemt uitgebreide metadata. Het gaat hier om geassocieerde naam-waarde

paren zoals (“locatie”, “België”) of (“datum”, “19-04-2006”).

De Free On-Line Dictionary of Computing [7] omschrijft context als volgt:

“That which surrounds, and gives meaning to something else”

Wij zullen in dit werk de definitie volgen die door Dey werd vooropgesteld in 2000 in

zijn Ph.D. thesis[8]:

“Context is any information that can be used to characterize the situation of an

entity. An entity is a person, place, or object that is considered relevant to the

interaction between a user and an application, including the user and

application themselves.”



Wanneer mensen echter aan context denken, hebben ze het meestal over locatie

gebonden context. Context is echter veel meer dan locatie alleen [9]. Een meer

accurate voorstelling van context bestaat uit de 4 W’s zoals voorop gesteld door Dey:

Wie, Wat, Waar en Wanneer.

“Context-aware applications look at the who’s, where’s, when’s and what’s of

entities that occur and use this information to determine why a situation is

occurring.”

De ‘Wie’ slaat op de persoon. De context zal zich situeren rond een persoon maar een

persoon kan ook deel uit maken van de context of de context bepalen. Wanneer 2 of

meer personen zich bvb in de zelfde ruimte of omgeving bevinden kan men er van

uitgaan dat er wellicht een relatie bestaat tussen hen (collega’s, familie).

De ‘Wat’ is het materiële. Hiertoe behoren de o.a. mobiele apparaten, GSM, laptop etc.

In het kader van het Internet Of Things (een wereld waar ieder object uniek

geïdentificeerd is in de virtuele wereld en met elkaar kan communiceren, hierover meer

in 2.3) kunnen we hier alles onder brengen dat getagged (uniek gemarkeerd) is en

waar we informatie van of over kunnen verkrijgen.

De “Waar“ is de locatie die iedereen wel kent. Locatie is vrij belangrijk en kan op vele

manieren verworven worden, via RFID, GPS, WiFi, GSM, etc. De locatie is ook niet

alleen de locatie van een persoon maar ook van het “Wat”.

De “Wanneer” is alles wat met tijd te maken heeft. In onze haastige maatschappij is

tijd enorm waardevol en heeft tijd invloed op alles wat we doen: eten, werken,

ontspanning enz. Tijdsafhankelijkheid in services is één van de meest voor de hand

liggende en logische context eigenschappen die we ons kunnen voorstellen. Nemen we

bijvoorbeeld een situatie waar men op zoek is naar een restaurant rond de middag,

dan is het niet nuttig van restaurants voor te stellen die niet open zijn over de middag.

Er zijn verschillende vormen van context:

• Statische context: Eigenschappen die omschrijvend zijn en die niet veranderen

nadat ze zijn geïnitialiseerd. Statische context is informatie die door de



gebruiker zelf in het systeem wordt gebracht, zoals wat zijn naam is, of de

naam van een restaurant. Echter niets is 100% statisch, men zou bvb kunnen

veronderstellen dat het thuisadres van een gebruiker een statisch gegeven is

maar wat als die persoon dan zou verhuizen? Statisch is dus meer een relatief

permanente staat die slechts heel zelden zal veranderen.

• Dynamische context: Eigenschappen die mogelijks zullen veranderen in de loop

van de tijd. Veel contextuele informatie is dynamisch en zal contant geüpdatet

worden, denken we maar aan de locatie. We zijn (bijna) constant in beweging

en onze locatie zal dan ook steeds moeten mee evolueren.

• Afgeleide context: Niet alle eigenschappen of informatie worden rechtstreeks

aan een entiteit toegekend. Het is mogelijk dat men informatie kan afleiden uit

de verworven context bvb via predicaten logica. Hier zit ook de kracht van

context. Niet alles is “gegeven” maar men kan er meer informatie uit halen dan

dat er is ingestoken.

Het definiëren en implementeren van context is niet voor de hand liggend en wordt

goed gevat door de volgende uitspraak [10]:

“The concept of context is difficult only

in that it is only limited by one’s imagination.”

Context is een enorm open begrip en wordt door eenieder anders geïnterpreteerd. Het

opstellen van een datamodel die de context zal voorstellen heeft dus ook te lijden

onder deze problematiek. Men kan heel algemeen blijven in zijn opvatting van context

en enkel de grote bouwblokken gaan definiëren of men kan elk detail en elke

eigenschap nauwkeurig gaan beschrijven. Het probleem is dat men door te veel

detaillering het grote beeld uit het oog verliest en men geen overzicht behoudt. Aan de

andere kant van het spectrum bestaat de mogelijkheid om te algemeen te blijven en

men aan functionaliteit moet gaan inboeten. Zoals zovaak het geval is moet men ook

hier een gezond evenwicht vinden om functionaliteit te garanderen zonder daarbij de

algemeenheid te schaden.



Context is overal en altijd. Het begrip ubiquitous of pervasive computing wordt vaak

geassocieerd met context. Pervasive computing gaat zich specifiek toeleggen op de

wereld van mobile computing, applicaties en services die geïntegreerd zijn in het

dagelijkse leven.

2.1.2 Context awareness

Context awareness, ook context gevoeligheid of context sensitiviteit genoemd, gaat

gebruik maken van de aanwezige context om automatisch aangepaste content te

leveren en/of acties te ondernemen.

Context awareness is overal terug te vinden. Op het internet komen we er dagelijks

mee in contact telkens we iets opzoeken met een zoekmachine zoals Google of Yahoo!.

Zoekmachines proberen een zo goed mogelijke resultaat weer te geven, echter onze

zoekterm kan in veel gevallen op verschillende manieren worden geïnterpreteerd. Het

kan zijn dat de zoekterm eenvoudigweg verkeerd gespeld is en daar kan makkelijk een

mouw aan gepast worden. Echter in het geval van homoniemen is er niet direct een

kant en klare oplossing en kan context een oplossing bieden. Ook locatie wordt

gebruikt door zoekmachines om aangepaste resultaten weer te geven. Wanneer men

zich in België bevindt en zoekt op het woord “hotel” zal men andere resultaten krijgen

dan wanneer men dit zelfde zoekwoord ingeeft op een computer die zich in de

Verenigde Staten bevindt.

Ook in applicaties komen we meer en meer in contact met context awareness. Een

voorbeeld hiervan kunnen we terugvinden in de nieuwste versie van Microsoft Office

(2007). De “ribbon” [11], dit is de taakbalk die de bewerkingsmogelijkheden weergeeft

bovenaan het toepassingsvenster, zal andere mogelijkheden weergeven afhankelijk

van de context (voor een tabel, foto, ...).

Buiten de applicatie omgeving komt contextgevoeligheid uiteraard evenzeer aan bod.

Zo kan men zich voorstellen dat een contextgevoelig reclamebord andere informatie zal

tonen wanneer het de aanwezigheid van een kind opmerkt dan in het geval van een

bejaard koppel. Momenteel wordt context informatie nog vaak gevraagd aan de

gebruiker. Hier is echter verandering in aan het komen met de komst van RFID (Radio



Frequency Identification), sensoren en andere informatieverstrekkers. Contextuele

informatie zal kunnen worden ontrokken aan de omgeving van de gebruiker zonder dat

deze zich daar bewust van is.

Context Awareness houdt ook in dat de aanpassingen en voordelen die de gebruiker

zal ondervinden transparant moeten gebeuren. De gebruiker moet zo min mogelijk zelf

aanpassingen gaan activeren, deze moeten afgeleid worden uit de context.

2.2 Ontologieën

De term ontologie is oorspronkelijk afkomstig uit de filosofie en refereert naar

existentie, naar iets dat bestaat. Van Dale definieert ontologie als volgt:

“Leer van de algemene eigenschappen van de dingen”.

In het kader van computerwetenschappen wordt de term ontologie gebruikt als een

domeinspecifieke semantische omschrijving van concepten en relaties [12]. Men kan

dit vergelijken met een taxonomie of een vocabularium maar een ontologie gaat verder

dan dat. Waar het bij een taxonomie vooral gaat over het indelen in groepen en een

vocabularium vooral definities en woordgebruik zal behandelen biedt een ontologie ook

de mogelijkheid om relaties en beperkingen (restricties) toe te wijzen en wordt

overerving ondersteund.

Ontologieën worden onder meer gebruikt om knowledge bases voor te stellen. Het

gebruik van de term ontologie in de computerwetenschappen werd geïntroduceerd in

de tak van de AI (artificiële intelligentie) waar het werd gebruikt om knowledge sharing

mogelijk te maken tussen verschillende AI softwarecomponenten.

De reden waarom we gebruik zullen maken van een ontologie om context voor te

stellen is veelvuldig. Eerst zijn er de inherente eigenschappen en structuur van

ontologieën: Ze bestaan uit klassen en instanties of individuals, deze lenen zich heel

goed om entiteiten voor te stellen en bovendien is er ondersteuning voor overerving

die het structureren van de entiteiten vergemakkelijkt en ook uitbreidbaarheid en

schaalbaarheid met zich meebrengt. Al deze klassen kunnen geassocieerd worden met

verschillende attributen of eigenschappen (properties) die verdere detaillering van de



klassen toelaat. Naast de attributen kunnen er ook relaties gedefinieerd worden tussen

klassen zodat afhankelijkheden kunnen opgelegd worden. De consistentie van de

relaties en eigenschappen kan automatisch worden nagegaan op basis van het

gedefinieerde schema. Daarnaast is het mogelijk om nog regels te definiëren die via

reasoning bijkomende informatie zullen afleiden uit de reeds aanwezige instanties en

eigenschappen (rule based reasoning).

Een van de belangrijkste talen om ontologieën voor te stellen is OWL (Web Ontology

Language) [6]. Voor meer informatie over de achtergrond en syntax van OWL

(RDF/XML – Resource Description Format/eXtended Markup Language) verwijzen we

graag naar [6], [13] en [14].

2.3 RFID en het Internet of Things

Het Internet of Things is het concept dat in de toekomst alle objecten uniek

geïdentificeerd zullen zijn en communicatie mogelijk zal zijn met en tussen deze

objecten, niet alleen mens-object interactie maar ook object-object interactie en dit

overal en altijd [15]. De kennis van aanwezigheid van objecten kan voor context aware

applicaties een enorme bron van informatie zijn. Om de objecten uniek te identificeren

(taggen) zal gebruik gemaakt worden van RFID (Radio Frequency Identification).

Vooraleer het Internet Of Things verder uit te diepen, zullen we eerst wat meer uitleg

geven bij het begrip RFID aangezien deze technologie nu pas mainstream begint te

worden.

2.3.1 RFID

RFID is een draadloze technologie om informatie op te slaan en te lezen van RFID tags

die bevestigd zijn op objecten. Het is een eenvoudige en kosteffectieve manier om

objecten uniek te identificeren.

Er zijn twee grote groepen van RFID tags: actieve en passieve. De passieve tags

bevatten statische informatie die opgeslaan is in niet-volatiel geheugen en hebben

geen nood aan een eigen energiebron, de energie wordt gehaald uit de

elektromagnetische straling die wordt gebruikt om de tag te lezen. De actieve tags



hebben daarentegen wel een energiebron en bevatten dynamische informatie die

wordt vergaard door middel van sensoren. Beide kunnen ze tussen de 64 bit en 2 kbit

aan informatie opslaan. Voor meer informatie over het ontstaan van RFID verwijzen we

naar [16].

De RFID tags moeten de brug vormen tussen de reële en virtuele wereld. Hiermee

bedoelen we dat ieder object uniek gekend kan zijn binnen de virtuele wereld door de

link die bestaat met de reële wereld dmv die tag. Dit is waar deze technologie zijn

toepassing zal vinden binnen het Internet Of Things.

RFID tags zullen ons onder meer contextuele informatie kunnen verschaffen over de

omgeving (locatie, weer) alsook bvb het identificeren van de gebruiker aan de hand

van zijn e-passport of GSM (NFC, Near Field Communication [17], [18]).

2.3.2 Het Internet Of Things

Het Internet of Things zal zich niet beperken tot enkel het taggen van objecten om zo

een virtuele mapping te creëren tussen virtuele en rëele objecten, communicatie is

essentieel om een echt “net” van objecten te realiseren. De object-object

communicatie moet de automatisering van acties toe laten om zo een betere ervaring

te creëren voor de gebruiker.

Figuur 4 geeft ons een voorbeeld van wat er allemaal mogelijk zou zijn en illustreert

hoe de virtuele wereld kan gelinkt worden aan de fysieke wereld. In de virtuele wereld

gaat men op zoek naar een object uit de reële wereld en die virtuele wereld vertelt je

waar in de reële wereld je dat object kan terug vinden.

Het ‘overal en altijd’ aspect is wat we kennen onder ubiquitous of pervasive computing.

Mobiele toestellen worden steeds krachtiger en bieden momenteel al de mogelijkheid

om rijke multimedia te ervaren en te genereren.



Figuur 4: Een voorbeeld van The Internet of Things

De integratie van technologie vindt overal plaats, in onze huiskamer, in de winkel [19],

op het werk [15], onderweg en op nog vele andere plaatsen [20]. Denken we maar

aan het automatisch afrekenen van je winkelkarretje als je een winkel buitengaat

doordat een scanner al je boodschappen draadloos kan herkennen. Of de GPS

toestellen die ons door de files proberen te helpen en wie van ons heeft nu geen GSM

meer? Ook de mogelijkheden van de GSM of smartphone beperken zich niet meer tot

enkel communicatie maar neigen meer en meer naar mobiele computers.

Ondanks de integratie van al die technologie is het belangrijk om bewust te blijven dat

de mens nog steeds aan de kern ligt van alle activiteiten en dat de technologie er is

om de levenservaring van de mens aangenamer en gemakkelijker te maken.



2.4 Community Driven Services

Vroeger werd content geleverd door een beperkt aantal personen of instanties die

nuttige informatie hadden die ze wilden beschikbaar stellen via het Internet voor het

brede publiek. Enkel zij die iets van HTML of andere markup talen afwisten hadden de

mogelijkheid om hun informatie op het web te zetten.

Nu is de contentmarkt volledig opengegooid en wordt de mogelijkheid gegeven aan de

gebruiker zelf om content te leveren. Op het internet is dit met de komst van Web 2.0

een gevestigde waarde geworden. Ontwerpers leveren een framework dat gebruikers

toelaat om op een eenvoudige manier content te leveren die dan weer op een

intuïtieve en nuttige wijze gedeeld wordt met de rest van de community.

De gedachte hierachter kunnen we staven aan de hand van een analogie die we

maken met de wet van Metcalfe [21]:

“Hoe meer mensen gebruik maken van iets,

hoe waardevoller het wordt”

Door de collaboratie van een groot aantal mensen kan men content meer betrouwbaar,

accurater en waardevoller maken. De matching die we willen invoeren is een manier

om bij te dragen tot het accurater maken van de content door de extra informatie die

aanwezig is in context in rekening te brengen.

Een aantal voorbeelden van Web 2.0 sites die het community driven model volgen zijn

de vele blogs en wikis, Digg, Flickr, YouTube, MySpace en vele anderen. De

voorgenoemde sites zijn allemaal voorbeelden van publieke sites, echter ook in de

bedrijfswereld vinden we deze mentaliteit van Community Driven Services (CDS) terug

[22].

Een voorbeeld van CDS vinden we terug in het model van het Europese Citizen Media

Project [23] dat als volgt wordt omschreven:



“Build an audio visual applications and system

that can handle massive amounts of user-

generated input, compile this user-generated

input to create a novel networked application for

nomadic and home users on different terminals”

Dit komt er dus op neer dat de gebruiker de mogelijkheid wordt gegeven om mee te

werken aan een netwerkapplicatie die gebaseerd is op content die ze zelf hebben

gecreëerd.

Figuur 5: CDS model volgens Citizen Media

Figuur 5 toont ons een overzicht van hoe CDS de gebruikers betrekken bij het

genereren van content die daarna weer door (andere) gebruikers geconsumeerd kan

worden. Het Internet levert ons het communicatiekanaal langswaar we de content

kunnen aanleveren aan de gebruiker, zoals dit vroeger al het geval was, en ook de

content van de gebruiker kunnen vergaren. En aangezien het internet nu beschikbaar

is via vele mobiele kanalen, denken we maar aan GPRS, EDGE, HSDPA, EV-DO, WiFi,



WiMAX, geeft dit de gebruiker ook veel meer vrijheid om overal en altijd bij te dragen

tot deze services. De aanwezigheid van deze technologieën en de steeds groeiende

penetratie van mobiele communicatie toestellen (PDA, Smartphone, BlackBerry,

iPhone) brengt ons steeds dichter bij het model van pervasive computing.

2.5 Literatuurstudie

2.5.1 Context Frameworks

Er zijn reeds verschillende frameworks en architecturen ontwikkeld die gebruik maken

van ontologie -gebaseerde context modellen. Hieronder vindt men een lijst terug van

een aantal bestaande context modellen samen met een korte beschrijving. Daarnaast

zijn er uiteraard ook nog andere architecturen beschikbaar.

• CoBrA: Context Broker Architecture [24]

De CoBra architectuur is een broker-gebaseerde architectuur ter ondersteuning van

pervasive context aware systemen in slimme ruimtes (intelligente vergaderzalen,

huizen). Centraal in deze architectuur staat de context-broker die contextuele

informatie ontvangt van allerhande apparaten, agents en services. Hij zal via

reasoning al die informatie integreren in een coherent contextmodel van al de

apparaten, ruimtes, mensen en andere entiteiten die in het model aanwezig zijn.

• SOCAM: Service-Oriented Context-Aware Middleware [25]

De architectuur en de technologie die door het CASP (Context Aware Service

Platform, zie 2.5.2) framework wordt gebruikt is deels gebaseerd op deze SOCAM

architectuur. Het ontologiemodel van SOCAM (Figuur 6) en het gelaagde model

werd echter niet overgenomen.

De architectuur is service georiënteerd en is in staat dynamisch context te

ontdekken, te verwerken en te interpreteren. In dit laatste ligt ook de kracht van

de SOCAM architectuur, doordat via redeneren impliciete context kan afgeleid

worden uit expliciete contextuele gegevens. Dit vinden we ook terug in het CASP



framework. SOCAM is, net als CASP, geïmplementeerd met behulp van het OSGi

platform.

Figuur 6: Context model van de SOCAM architectuur

• COSS: Context-aware, Ontology based, Semantic Service Discovery [26]

Deze architectuur is gebaseerd op het Web Architectures for Services Platforms

(WASP) [28] en is erop gericht om de ontdekking van services te verbeteren. Ook

deze architectuur is geïmplemeteerd met behulp van het OSGi platform.

• MoCA (CC/PP): Mobile Collaboration Architecture (Composite Capabilities/

Preference Profiles) [25], [29] en [30]

Deze architectuur richt zich vooral op toepassingen voor mobiele toestellen en hun

technische mogelijkheden. De content wordt aangepast aan de aanwezige

mogelijkheden van het doelplatform en de omgeving. Zo zal een video op een

terminal met een breedbandverbinding in een hogere bitrate worden gestreamd

dan indien deze wordt bekeken op een mobiel toestel met een beperkt scherm en

een tragere dataverbinding zoals UMTS1.

1 3e generatie gsm systeem(3G) gestandaardiseerd door ETSI onder 3GPP. Voor meer info zie [27]



2.5.2 CASP

Het Context Aware Service Platform (CASP) werd ontwikkeld door een team binnen de

vakgroep INTEC. CASP is gebaseerd op het framework dat werd voorgesteld door

Johan Criel in zijn thesis “Context Awareness” [13]. In Figuur 7 is de algemene

architectuur weergegeven van het framework zoals voorgesteld in [1].

Figuur 7: Algemene overzicht van de CASP architectuur

Het CASP framework laat toe om op een dynamische wijze services te beheren voor

context aware applicaties. Hiervoor maken ze gebruik van abstractie (interfaces) en

aggregatie van contextuele informatie. Het platform is volledig modulair en laat zo toe

om modules toe te voegen en te verwijderen zonder het framework te moeten

herstarten.

Het framework is geïmplementeerd met behulp van de Knopflerfish (zie Appendix A)

implementatie van het OSGi platform. Meer informatie betreffende OSGi wordt

verstrekt in sectie 4.7.1.



2.5.3 Matching

De term matching vinden we terug in verschillende vakgebieden. Zo kennen we

matching uit de grafentheorie, elektrotechniek en ook het zoeken in strings. De context

matching die we zullen voorstellen kan aan elk van de 3 vakgebieden gerelateerd

worden.

Op het vlak van de grafentheorie kunnen we de link leggen met hoe we de context

zullen voorstellen, namelijk met een ontologie. Een ontologie kan intern worden

voorgesteld als een graaf. Een graaf bestaat uit knopen, i.e. de entiteiten, klassen of

instanties, die met elkaar verbonden zijn door hun onderlinge relaties (takken), zij het

overerving bij subklassen of eigenschappen (properties). Context matching op het vlak

van ontologie matching, zijnde overeenkomsten zoeken tussen ontologieën en het

mappen van ontologische schema’s (zie het voorbeeld in Figuur 8: Voorbeeld van

ontologie matching), is reeds uitvoerig bestudeerd. Voor meer informatie hierover

verwijzen we graag naar [31], [32], [33].

Figuur 8: Voorbeeld van ontologie matching

Het matchen van strings, waarmee bedoeld wordt het zoeken naar een bepaalde string

binnen een grotere string of tekst, is een andere vorm van matching. Een eenvoudige

manier om string matching te implementeren is door gebruik te maken van

zongenaamde reguliere expressies (regexp) [34]. Zo kan de volgende regxep gebruikt

worden om naar emailadressen te zoeken in een text.



Figuur 9: Voorbeeld van een reguliere expressie

String matching zal door ons niet geïmplementeerd worden op dit moment maar is

interessant in het kader van context matching (string matching op zich is reeds

uitgebreid onderzocht en geïmplementeerd). Zoals later zal aangehaald worden bij de

beschrijving van het algoritme zal er op basis van criteria van de gebruiker gezocht

worden naar bepaalde eigenschappen van entiteiten die overeenkomen op basis van

strings. Wij laten echter niet toe dat de gebruiker zelf strings ingeeft maar hij wordt

beperkt door de waarden van eigenschappen die reeds aanwezig zijn in de knowledge

base. Indien we de gebruiker zouden toegelaten willekeurige strings in te geven als

criteria kunnen we te maken hebben o.a. spellingsfouten en synoniemen die door

eenvoudige stringvergelijking niet zouden gevonden worden. Met behulp van string

matching zou hier een mouw aan kunnen gepast worden (zeker in combinatie met

WordNet [35]). Meer informatie is te vinden in [36], [37] en [38].

INPUT

CONTEXT CONTENT

OUTPUT

CONTEXT CONTENT

Figuur 10: Context matching

De matching die wij zullen voorstellen is nog het best te vergelijken met impedantie

matching uit de elektrotechniek. Bij impedantie matching gaat men proberen van de

input impedantie van een bron gelijk te maken aan de output impedantie van de

belasting om zo een maximale energieoverdracht te realiseren. Analoog gaan wij de

content zo goed mogelijk aan te passen van de ene context naar een andere. De input

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b



context is die context waarin de content in het systeem gebracht werd en de output

context is de context waarin de gebruiker zijn request gedaan werd. In Figuur 10:

Context matching wordt dit symbolisch weergegeven.

2.5.4 Upper Level Ontologieën

Er zijn reeds verschillende pogingen ondernomen om een algemene ontologie op te

stellen die kan gebruikt worden als basismodel. Zo creëert men een gelaagde structuur

die kan hergebruikt worden. De domeinspecifieke ontologieën zullen dan overerven

van de zogenaamde Upper Level Ontologie (ULO). Een voorbeeld van een algemene

ontologie is SOUPA [39] (Standard Ontology for Ubiquitous and Pervasive

Applications). Deze werd ontwikkeld ter ondersteuning van de CoBRA [24] architectuur

en MoGATU [40].

Wij zullen ook dit gelaagd model volgen en we zullen onze ULO baseren op de ULO die

voorgesteld werd voor de SOCAM architectuur (zie 2.5.1, Figuur 6).



Hoofdstuk 3: Architectuur en Algoritme

3.1 Requirements

Bij het ontwerp van de architectuur en het datamodel, en meer bepaald van de

ontologie, zijn er verscheidene requirements waar we rekening moeten mee houden.

In de volgende secties worden zowel de humane als de technische requirements

besproken.

3.1.1 Humane requirements

De toepassing die we voor ogen hebben is gericht naar het verbeteren en

vergemakkelijken van sociale handelingen van de mens. Echter door de eerder

technologische visie van ICT ontwikkelaars, durven we het sociale aspect soms uit het

oog te verliezen. Dit komt doordat we er van uit gaan dat technologie de basis is van

de innovatie die we willen bereiken. De innovatie, die bereikt wil worden door nieuwe

technologie in te voeren, komt echter pas volledig tot zijn recht wanneer er

veranderingen optreden in het dagelijkse leven [41]. Met die gedachte in het

achterhoofd, dat een service slechts innovatief kan zijn wanneer ze kan en wil gebruikt

worden in een sociale omgeving, hebben we dan ook onze applicatie ontwikkeld.

Een groot deel van het sociale aspect, dat we een service willen ontwikkelen die door

iedereen in het dagelijkse leven kan gebruikt worden, waar we het hier over hebben

vinden we ook terug in het begrip context zoals vooropgesteld in 2.1.1. Iedere entiteit,

zij het een woord, een beeld, een object of een symbool, krijgt pas zijn betekenis

wanneer het binnen een context wordt geplaatst. Een algemene of generieke betekenis

is meestal niet aanwezig voor een entiteit op zich. Het is dan ook van belang dat de

specifieke, contextafhankelijke betekenis van een entiteit kan gevat worden in een

(computer)applicatie. Dit is echter verre van evident en niet altijd mogelijk. Bij het

opstellen van het datamodel dat we gebruiken voor het voorstellen van context hebben

we er voor gezorgd dat deze zo goed mogelijk de contextafhankelijke betekenis kan

vatten.



3.1.2 Technologische requirements

• Service georiënteerd

Net zoals de architectuur van het CASP framework (Figuur 7), waarop we ons baseren,

maken we gebruik van een SOA (Service Oriented Architecture) waarbij we services

gaan ontwikkelen die met elkaar kunnen communiceren en data uitwisselen. Deze

services moeten welomschreven zijn en een duidelijke interface hebben opdat zij

gebruikt zouden kunnen worden door anderen (services).

• Platformonafhankelijk

Door gebruik te maken van het OSGi platform dat, aangezien het geschreven is in

Java, platformonafhankelijk is kan het over worden op geïnstalleerd. Het kan

ontwikkeld worden, en eventueel ook getest zoals in ons geval, op een Windows

platform om het nadien bvb te deployen op een linux systeem, wat dikwijls gebeurt in

het geval van webservices. Het OSGi platform heeft een webserver bundle die het

mogelijk maakt om een service aan te bieden via het web.

Daarnast hebben we ons context model geïmplementeerd in OWL wat ook platform-

onafhankelijkheid in de hand werkt doordat het gestandaardiseerd is door het W3C.

• Ondersteuning van reasoning

De content en context die we bijhouden kan vrij complex zijn qua structuur en hun

onderlinge relaties. Het is dan ook te begrijpen dat de consistentie van al deze data te

allen tijde moet gegarandeerd worden. De reasoner zal de consistentie van data bij

iedere verandering nagaan en mogelijke onjuistheden aan het licht brengen.

Daarnaast zal er ook via reasoning informatie worden afgeleid van de reeds aanwezige

informatie in de knowledge base, i.e. inductieve informatie. Zo kan er bvb worden

afgeleid dat indien de PDA zich in een bepaald gebouw bevindt, de eigenaar van de

PDA zich wellicht ook in dat gebouw zal bevinden.



• Uitbreidbaarheid en schaalbaarheid

De toepassing is gericht naar grote gebruikersgroepen, communities, en is gebaseerd

op het principe van “Power in Numbers”: Hoe groter de community, hoe meer en hoe

accurater informatie zal zijn. We moeten er voor zorgen dat het mogelijk is voor de

community om te groeien en uit te breiden. De modulaire opbouw van onze

architectuur laat toe om, indien nodig, abstractie te maken van bepaalde modules om

ze zo te verdelen over meerdere processen of hardware (load balancing).

Niet enkel het aantal gebruikers kan uitbreiden maar ook nieuwe contextuele

informatie moet kunnen worden toegevoegd. Door gebruik te maken van generieke

interfaces is het mogelijk, zelfs on-the-fly, om context providers toe te voegen die

nieuwe informatie kunnen leveren.

Daarnaast moet de toepassing ook gebruikt kunnen worden voor verschillende

domeinen (niet alleen restaurants zoals we voorstellen in 4.2). Dit wordt in de hand

gewerkt door gebruik te maken van een ULO zodat er een gemeenschappelijk model is

waar men kan op verder werken en niet steeds van nul moet herbeginnen.

• Semantic Web

Het semantische web, waarbij men een visie heeft van een Internet van data,

informatie en kennis die niet alleen door mensen maar ook door machines/software

kan begrepen en geïnterpreteerd worden, is aan een opmars bezig in het begin van

deze 21e eeuw. Om er voor te zorgen dat de data die we genereren universeel is,

maken we gebruik van OWL om onze data te beschrijven en op te slaan om zo

maximale interoperabiliteit te garanderen met andere services die gerelateerde data

kunnen leveren.

• Matching

De context matching die we gaan invoeren heeft nood aan informatie die goed

gestructureerd is zodat op een eenvoudige manier kan worden vergeleken om de

matching te bepalen. Het is belangrijk hier mee rekening te houden bij het opstellen



van ons context model. Door gebruik te maken van OWL en zijn inherente structuur

kunnen we voldoen aan deze vereiste.

• Soft realtime

De toepassing die we voor ogen hebben moet kunnen gebruikt worden in het

dagelijkse leven. Om de bruikbaarheid te garanderen moeten we er voor zorgen dat de

gebruiker van een interactieve ervaring kan genieten. Om een responsieve applicatie te

creëren moeten we ons systeem soft-realtime maken.



3.2 Matching

3.2.1 Toepasbaarheid

Aangezien zowel content als context zeer uitgebreide begrippen zijn en het vrijwel

onmogelijk is om alles te gaan modelleren, zullen we onze toepasbaarheid beperken

tot meer specifieke content en ook een eerder beperkt context-model gebruiken.

Als we kijken naar de Web Services en sites die ontstaan zijn in de mentaliteit van de

Web 2.0 revolutie zoals YouTube, Flickr, Digg, StumbleUpon en andere, kunnen we

stellen dat ze allemaal een aantal dingen gemeenschappelijk hebben.

Zoals we in dit werk reeds hebben vooropgesteld zijn het CDS die hun content bij de

gebruiker halen en aan de community terug bezorgen op een manier die aangepast is

aan een specifieke gebruiker. De CDS geven de mogelijkheid aan de gebruiker om hun

content te delen met anderen (content sharing). Allen bieden ze de mogelijkheid om

ratings toe te kennen aan content. Nu zijn deze ratings of opinies uiteraard ook

content en user-generate.

Een probleem of bemerking die we hier kunnen bij maken is het volgende: indien we

ons willen baseren op opinies van anderen om ons meer gepaste content te bezorgen,

zal onze mening, smaak of voorkeur wel compatibel zijn met die van anderen uit de

community? Kunnen we iedereen over dezelfde kam scheren en iedere opinie dezelfde

waarde geven? Normaal gezien zullen we meer waarde hechten aan de opinie van een

collega, familielid of van een gerespecteerd criticus. Hier dient rekening mee worden

gehouden te worden bij het opstellen van het algoritme.

De opinies waarover we het reeds hadden moeten zich uiteraard niet beperken tot

virtuele content. Ze kunnen ook gaan over instanties uit de reële wereld en deze zijn

minstens even interessant en misschien zelfs interessanter voor de gebruiker. Denken

we hier onder meer aan hotels, winkels, restaurants, cafés, vliegtuigmaatschappijen,

pretparken, etc. Al deze ondernemingen bieden een service aan aan de gebruiker die

door veel verschillende maatschappijen of bedrijven wordt geleverd en waar de

gebruiker een keuze moet maken bij dewelke hij gebruik zal makken van die service.



De ratings zullen steeds in een bepaalde context gegeven worden. Wie ze geven, waar

ze gegeven worden, wanneer ze worden ingevoerd, in welke omstandigheden, wie er

zich in het gezelschap bevindt, wat het doel is (zakenreis of vakantie, romantisch diner

of familie-uitstap). Al deze factoren zullen bijdragen tot het gewicht en de waarde van

de rating in de context van diegene die het systeem bevraagt naar een bepaalde

service.

We kunnen stellen dat de rating die we willen terug krijgen van de service, die de

mening van de gehele community voorstelt (community opinion), meer is dan louter de

som van de individuele ratings die in het systeem werden ingegeven. Hoe wij de

community opinion zullen interpreteren wordt verder uitgelegd in de 2e stap (matching)

van het algoritme dat we gaan voorstellen.

3.2.2 Algoritme

Het algoritme dat we voorop stellen bestaat uit 4 grote stappen: de eliminatie, de

matching, de groepering en als laatste de ordening. Deze vier stappen, weergegeven

in Figuur 11, worden nu één voor één beschreven.

Figuur 11: Visuele voorstelling van het algoritme

• Eliminatie

De eliminatie stap zorgt er voor dat we geen nodeloze berekeningen doen in de

volgende stap. De gebruiker en het systeem zullen een aantal voorwaarden of criteria

voorop stellen waaraan de content die gezocht wordt moet voldoen. Van de gebruiker

kunnen we criteria verwachten die gerelateerd aan zijn persoonlijke voorkeur. De

gebruiker zal deze zelf meegeven met zijn request.

Elminatie Ordening Groupering

Eliminatie criteria

Matching



Het systeem heeft uiteraard ook een hoop contextuele informatie ter zijner beschikking

zoals de huidige locatie van de gebruiker, de tijd, de geschiedenis van de activiteiten

van de gebruiker, etc. Uit deze informatie kunnen ook eliminatiecriteria afgeleid

worden. Indien bvb blijkt uit de geschiedenis van de gebruiker dat hij niet

geïnteresseerd is in een bepaald genre van muziek kan men alle resultaten gerelateerd

aan dat genre reeds elimineren. Met behulp van de locatie kunnen ook bepaalde

resultaten geëlimineerd worden. Zo moet een winkel niet moeten in rekening gebracht

worden indien deze toch niet op wandelafstand ligt of indien deze niet bereikbaar is

met de wagen.

De eliminatie zal gerealiseerd worden door waarden van eigenschappen van entiteiten

te vergelijken met de vooropgestelde criteria. Voor sommige van de criteria zullen een

aantal berekeningen nodig zijn om te bepalen of de rating al dan niet moet

geëlimineerd worden, denken we bvb aan afstand.

• Matching

Na de eliminatie stap komt de belangrijkste stap, het matchen. We zullen de content,

onze ratings, aanpassen aan de context van waaruit de vraag van de gebruiker is

gesteld. De ratings zullen een conversie ondergaan naar een gematchte rating (Rm) op

de volgende manier:

Met iedere context zal een aantal factoren geassocieerd worden die betrekking hebben

tot één van de onderwerpen die een rating kan ontvangen. De factoren hebben een

waarde tussen 0 en 1 en geven aan in hoeverre de eigenschap waar de factor mee

geassocieerd is, belangrijk is in deze context. Zo is de service die men verwacht in een

hotel belangrijker voor een zakenman dan voor een familie op vakantie. Echter de

gezelligheid of atmosfeer zal dan weer een belangrijkere rol spelen voor het gezin dan

voor de zakenman.

De context in dewelke de rating (R) is ingevoerd in het systeem heeft deze factoren,

zoals beschreven in de vorige paragraaf (Ki: input), alsook de context van waaruit de

vraag is gesteld (Ko: output). Ki en Ko zijn vectoren met elk zoveel factoren als er



onderwerpen zijn die een rating kunnen ontvangen. De verschillende ratings, voor elk

contextonderwerp, vormen samen de vector R.

In het geval dat de input context verschilt van de output context zal de rating R

aangepast worden volgens de volgende formule

∑ −−=n

jiom jRjKjK

nR ][)][][1(

1 (1)

waarbij n het aantal onderwerpen is waarvoor een mogelijke rating aanwezig is. De

factor 1/n is aanwezig om de gematchte rating te normeren naar een waarde tussen 1

en 5.

Indien deze 2 contexten dezelfde zijn zal Ki gelijk zijn aan Ko en zal Rm het gemiddelde

zijn van de verschillende ratings uit R.

• Groepering

Na de matching is alle content, i.e. de ratings, aangepast aan de context van waaruit

de request is gebeurd. Voor iedere item waarnaar de gebruiker op zoek is zullen er ook

verscheidene ratings aanwezig van andere gebruikers. Al deze ratings moet

gegroepeerd worden per item (Figuur 12).

Figuur 12: Groepering van de ratings

Rn

Rn

Rn Rm



Indien we ook rekening houden met de relaties tussen de gebruiker die de aanvraag

invoert en de gebruiker die de rating heeft ingegeven, voeren we nog een bijkomende

factor in, Kr. Zo kan de rating die ingegeven werd door een familielid hoger in waarde

worden geacht dan de rating van een collega.

∑= mrn RKK

R1

(2)

waarbij <K> een normeringsfactor is gelijk aan de som van alle Kr,, wat dus neerkomt

op het gewogen gemiddelde van de ratings met gewichten Kr. Indien we geen

rekening houden met de onderlinge relaties van de gebruikers zijn alle factoren Kr

gelijk aan 1 en is Rn het normale gemiddelde.

• Ordening

De gebruiker krijgt de mogelijkheid om aan te geven volgens welke criteria de content

moet geordend worden. Hiermee kan hij aangeven waaraan hij het meeste belang

hecht. In de eerste plaats zal er geordend worden naar de factor die in de vorige stap

berekend werd. Daarnaast is echter ook mogelijk om bvb de beste 10 resultaten te

gaan ordenen volgens andere criteria zoals afstand, prijs, kwaliteit, etc.



Hoofdstuk 4: Proof of Concept

In dit hoofstuk zullen we een use case voorstellen die het algoritme zal gebruiken dat

we in het vorige hoofdstuk hebben voorgesteld. Er zal ook worden ingegaan op een

aantal valkuilen waar we rekening mee hebben gehouden. Daarnaast stellen we het

contextmodel voor dat we hebben gebruikt voor onze use case als ook verschillende

technologieën die gebruikt zijn voor de realisatie van de use case.

4.1 Overwogen Use Cases

Voor de implementatie van een test case hebben we verschillende mogelijkheden

overwogen. Naast de use case die is uitgewerkt in de volgende sectie hebben we de

volgende use cases bekeken.

• Travel info

Deze use case gaat over het aanbieden van reisinformatie aan de gebruiker terwijl

hij onderweg is alsook het voorzien van elektronische vervoersbewijzen. Een

mogelijk scenario gaat als volgt: een toerist vertrek terug huiswaarts en wil dit met

de trein doen. Hij geeft dit in via een terminal in zijn hotel en koopt de nodige

tickets voor tram en trein. Hij krijgt deze op zijn gsm samen met zijn reistijden. Hij

neemt de tram en komt aan in het station waar hij via SMS op de hoogte wordt

gesteld dat zijn trein een paar minuten vertraging heeft en zal vertrekken van op

perron 2. Eens op de trein moet hij overstappen in een ander station. Hij zal

hiervoor een sms krijgen enkele minuten voor hij aankomt in dat station.

• Ubiquitous tagging

Deze service laat toe om overal virtuele tags achter te laten met informatie. Voor

een toerist kan dit interessant zijn om bijkomende informatie te krijgen terwijl hij

door de stad wandelt. Ook is het mogelijk om bvb een boodschap (video, foto,

text, spraak) achter te laten voor een vriend of een kennis wanneer deze niet thuis

is of indien men te laat is voor een afspraak.



4.2 Gekozen Use case: Restaurant lookup and review

We hebben uiteindelijk gekozen om de use case rond restaurantbezoeken te

gebruiken. De “travel info” use case en de “ubiquitous tagging” waren te veel gericht

naar locatie (en tijd) alleen en zoals we weten is context meer dan alleen locatie.

Daarenboven leent de restaurant use case zich gemakkelijker om naar andere

toepassingsgebieden geporteerd te worden (winkels, sporthallen, dancings, etc.).

4.2.1 Detaillering

De use case gaat over een service waar mensen een restaurant kunnen opzoeken dat

voor hen het meest geschikt is en dit uiteraard gebaseerd op hun context op dat

moment. Ze hebben na hun maaltijd de mogelijkheid het restaurant te beoordelen, wat

later dan weer kan gebruikt worden om betere zoekresultaten te leveren voor zichzelf

en voor mensen uit hun kennissenkring.

client

restaurant managersensor

look for restaurant

add rating

modify information

add restaurant

Figuur 13: Restaurant Use Case Diagram

Stellen we ons de volgende scenario’s voor:

• Look for restaurant

Een verantwoordelijke voor aankoop bij een bedrijf is op zoek naar een geschikt

restaurant om samen met een aantal leveranciers te gaan eten over de middag. Hij



weet dat één van de leveranciers vegetarisch is en mogelijks zouden ze nog iets

moeten raadplegen op het Internet en ze hebben bijgevolg een internetconnectie

nodig ( bvb via WiFi). Qua keuken had hij gedacht aan iets typisch Belgisch

aangezien geen van de leveranciers uit België komen.

Hij geeft deze gegevens in op zijn PDA. Eventueel kan er uit zijn agenda afgeleid

worden dat het om een zakenlunch gaat of anders kan de gebruiker dit ook zelf

ingeven. De gebruiker krijgt 5 restaurants terug die aan zijn vraag voldoen,

geordend volgens hun rating (community opinion). Hij ziet echter dat de eerste 2

restaurants meer dan een half uur ver zijn en filtert verder zodat enkel restaurants

getoond worden die minder dan een half uur rijden zijn. Hij bekijkt de menu’s van

de mogelijke restaurants en het aantal plaatsen dat er nog beschikbaar is (dit

aantal wordt automatisch aangepast vanuit het restaurant) en beslist om bij het 2e

restaurant te gaan en reserveert onmiddellijk voor zichzelf en de leveranciers.

• Add rating

Op het einde van de maaltijd krijgt een familie de rekening. Ze zien op de rekening

dat ze bij hun volgend bezoek 5% korting zullen krijgen indien ze hun mening

willen delen over dit restaurant. Ze gaan met de rekening naar een touchscreen in

de buurt van de uitgang en scannen de barcode die op de rekening staat. Op basis

van deze barcode wordt alle informatie over hun maaltijd weergegeven op het

touchscreen. Uit de maaltijden die er werden gegeten (o.a. 2 kindermaaltijden) en

de tijd (over de middag op zaterdag) heeft het systeem afgeleid dat het om een

familie gaat die louter op restaurant is gegaan om te eten en bvb niet om een

verjaardag te vieren (geen van de leden van de familie heeft een verjaardag rond

deze tijd, wat het systeem heeft afgeleid uit het profiel van de familie dat ze reeds

zelf hebben ingegeven, via het modify information scenario). Ze geven in dat ze

het eten vrij lekker vonden (4/5), het kader vonden ze wel toepasselijk (3/5), ze

hadden ook geen speciale behoeften en de sfeer was iets minder (2/5). Ze vonden

dat de muziek wat te luid stond.



• Modify information

Ieder van de 3 actoren (client, restaurant manager, sensor) kan informatie

aanpassen in de knowledge base. De informatie die aangepast wordt kan

contextueel van aard zijn maar ook statische informatie kan eventueel aangepast

worden.

De client kan zijn persoonlijk profiel aanpassen zo kan hij bvb zijn adres aanpassen

indien hij verhuist of zijn werkgever aanpassen indien hij van werk verandert. De

meeste aanpassingen die die gebruiker zal doen zijn van statische aard.

De uitbater van een restaurant kan zowel statische informatie over het restaurant

zoals het adres, de naam, etc. aanpassen maar hij kan ook contextuele informatie

aanpassen zoals het aantal plaatsen dat nog vrij is als dit niet al automatisch

gebeurt door het facturatie systeem. De dagmenu’s, indien aangeboden, moeten

ook door de uitbater kunnen aangepast worden. Dit kan gezien worden als

statische informatie die echter gedurende het verloop van de dag kan wijzigen als

een bepaald menu niet meer aangeboden wordt.

De sensors zullen contextuele informatie in het systeem pompen. Het soort

informatie dat door de sensors kan geleverd worden is zeer uitgebreid.

Temperatuur, neerslag, locatie, identificatie zijn maar enkele voorbeelden. De

informatie kan continu worden aangepast in de knowledge base of men kan ook bij

een request de meest recente informatie van de sensor opvragen.

• Add restaurant

De restaurantuitbater heeft uiteraard ook de mogelijkheid om zijn restaurant in te

voeren in het systeem. Hierbij zal hij alle informatie over zijn restaurant ingeven.

Van het adres van het restaurant tot de verschillende soorten wijn die hij serveert,

etc.



4.2.2 Problemen en caveats

• Authenticiteit van de transacties

Eén van de punten waar men zich vragen zou kunnen bij stellen voor de beschreven

use case is veiligheid en authenticiteit. Men kan zich wel voorstellen dat een

restauranthouder zijn eigen zaak zou kunnen ophemelen door een groot aantal goede

reviews aan zichzelf te geven. Een oplossing hiervoor is werken met een trusted third

party zoals Verisign [42] of een analoge dienst die de authenticiteit van de transacties

kan waarborgen.

• Privacy

Het Big Brother fenomeen kan hier ook een struikelblok vormen. Er wordt

tegenwoordig al zoveel informatie bijgehouden over gebruikers zonder dat ze het goed

beseffen. Nemen we bijvoorbeeld de klantenkaart bij de supermarkt. Het enige dat de

gemiddelde klant ziet is dat door een klantenkaart hij punten kan sparen met dewelke

hij dan weer voordeel kan doen bij zijn volgende aankoop of een analoge actie.

Weinigen staan er bij stil dat met deze kaarten de supermarkten het koopgedrag van

hun klanten exact kunnen in kaart brengen en op basis daarvan niet alleen klantgericht

reclame kunnen sturen maar ook bijvoorbeeld hun winkelinrichting gaan aanpassen.

Voor een optimale ervaring bij de restaurant use case is het uiteraard nodig dat ook

heel wat informatie over de klanten wordt bijgehouden om zo een betere matching te

garanderen (meningen van familieleden, vrienden of collega’s kunnen bijvoorbeeld

meer invloed hebben dan de mening van een willekeurige persoon). Men kan zich wel

inbeelden dat niet iedereen daar mee opgezet zal zijn om al die gegevens te delen,

maar voor niets gaat enkel de zon op natuurlijk.

• Usability

De service die we voorstellen is bedoeld voor een breed publiek. Van zakenmensen die

een geschikt restaurant zoeken om een contract te bespreken tot een stel dat eens

romantisch wil gaan dineren. Naast het brede publiek zal de service op verschillende

apparaten geraadpleegd worden. En wanneer de gebruiker een zoekopdracht ingeeft



wil hij binnen een aanvaardbare tijd een aantal suggesties zien. Deze voorwaarden

suggereren dat qua usability men ermee rekening moet houden dat de interface

eenvoudig is, overal te raadplegen en het systeem moet reageren op een soft-realtime

manier.

• Meerwaarde voor de gebruiker

Hoe kunnen mensen overtuigd worden om deze service te gebruiken? Het principe van

“voor wat, hoort wat” is hier zeker van toepassing. Het moet aan de gebruiker duidelijk

gemaakt worden dat door informatie te verstrekken aan het systeem hij betere

resultaten zal terugkrijgen .

Voor de restauranthouder komt dit neer dat hij iedere dag zijn menu moet aanpassen

indien hij een dagmenu aanbiedt. Wat krijgt hij hiervoor in de plaats? Reclame en de

mogelijkheid om klanten te lokken die hij anders niet zou bereiken. Alles hangt ook af

van de mening van de gebruikers (maar daar gaat het hier nu eenmaal om). De

restauranthouder wordt onder meer door de gebruikers beoordeeld op de maaltijden

die hij serveert, de service van zijn personeel en de sfeer en inrichting van zijn

restaurant. Hij moet er voor zorgen dat de klanten vinden dat ze waar voor hun geld

krijgen en op die manier hem, het restaurant en het eten een goede evaluatie

toekennen.

De gebruiker die op zoek is naar een restaurant gaat ook zijn deel van het werk

moeten doen namelijk na iedere maaltijd zijn mening invoeren in het systeem. Wat

krijgt deze er voor terug? Indien hij zoals iedereen zijn mening geeft kan hij profiteren

van de opinie van een hele community en kan hij zo andere en betere restaurants

leren kennen. Ook is het mogelijk om de klant aan te sporen om zijn mening te geven

met één of andere beloning bvb de mogelijkheid om een restaurantbon te winnen dmv

een wekelijkse loterij.



4.3 Domein Specifiek Context Model

Voor de restaurant use case hebben we een ontologie model opgesteld dat een aantal

basisentiteiten bevat zoals plaats (location), persoon (person), etc. en ook

verschillende domein specifieke entiteiten voor de restaurant use case zoals restaurant

en maaltijd (mealevent).

Person

Location

Context Entity

Activity

MealEvent

Restaurant

hasLocation hasLocation

involvedIn

tookPlaceAt

hasParticipant

hasLocation

concerns Rating

Setting

Food

Atmosphere

Profile

has

VisitType hasType

JustForFood

Bussiness

Intimate

Group

Figuur 14: Context model voor de restaurant use case

De ontologie die wordt vooropgesteld is geëvolueerd gedurende het verloop van deze

scriptie. In Appendix B zijn een aantal versies van de ontologie te vinden die opgesteld

zijn maar uiteindelijk niet gebruikt zijn in het finale ontwerp omdat ze zich niet leenden

tot een realistische implementatie. Het modelleren van context, zoals eerder

aangehaald, is niet eenvoudig en men kan gemakkelijk het algemene beeld uit het oog



verliezen. Men eindigt dan wel met een juiste voorstelling maar die is niet toepasbaar

in software.

De uiteindelijke ontologie die we gebruikt hebben is terug te vinden in Figuur 14:

Context model voor de restaurant use case. We zijn hiervoor teruggevallen op de ULO

die ook werd gebruikt in het SOCAM framework. Zoals reeds vermeld bij de technische

requirements hebben we er voor gekozen om gebruik te maken van een ULO om de

uitbreidbaarheid en de herbruikbaarheid van ons model toe te laten.

4.4 Algoritme

In deze sectie zullen we toelichting geven bij de implementatie van het algoritme voor

onze use case. De verschillende stappen zoals voorgesteld in 3.2.2 worden besproken.

4.4.1 Eliminatie

De eerste stap is de eliminatie stap. In deze stap zal het aantal restaurants die in

aanmerking komen verminderd worden door het elimineren van restaurants die niet

voldoen aan bepaalde criteria die tijdens de vraag zijn vooropgesteld. Hieronder vallen

bijvoorbeeld specifieke eisen zoals de aanwezigheid van vegetarische maaltijden of

toegankelijkheid met een rolstoel.

Hier zal er ook geselecteerd worden op criteria die te maken hebben met de

voedselvoorkeuren van de gebruiker, i.e. de keuken van het restaurant (Frans,

Italiaans, ...)

Initieel zullen we deze stap beperken tot de soort keuken en een aantal specifieke

criteria zoals vegetarisch, aanwezigheid van internet, etc., maar men kan uiteraard

duizend en één voorwaarden vinden waaraan een restaurant zou moeten voldoen. Dit

hangt allemaal af van de verwachtingen van de gebruiker.

4.4.2 Matching

De volgende stap is de belangrijkste en wordt daarom dan ook in meer detail

uitgewerkt zonder daarmee de algemeenheid van ons opzet in gedrang te brengen.



We gaan uit van de veronderstelling dat we restaurantbezoekers kunnen

onderverdelen in een aantal discrete categorieën, meer bepaald de volgende 4:

• Zuiver functioneel:

Hiermee willen we de groep van mensen aanduiden die wanneer ze eens geen zin

of geen tijd hebben om zelf te koken op restaurant gaan. Het hoofddoel van deze

categorie is eten. Ze hechten minder belang aan de setting of omkadering2 van het

restaurant of de sfeer en zijn vooral geïnteresseerd in het eten en dan meestal in

de prijs/kwaliteit verhouding.

• Voor zaken:

Deze categorie heeft betrekking tot de mensen die de maaltijd zien als een ideaal

moment om zaken te bespreken. Meestal zal dit gaan over twee of meer partijen,

klant en verkoper bvb, en wordt de lunch beschouwd als een geste van de

verkoper of bedrijf om in een goed daglicht te staan bij de tegenpartij. Het kader

van het restaurant zal dus een prominente rol spelen terwijl de prijs van de lunch

van minder belang zal zijn. Uiteraard is het de bedoeling dat er tijdens deze lunch

heel wat besproken wordt en is het noodzakelijk dat er een aangename sfeer is om

te spreken, niet te veel rumoer en geen te luide muziek.

• Intiem:

De doelgroep van deze categorie zijn koppels die gezellig met z’n twee iets gaan

eten op restaurant met de specifieke bedoeling om wat bij te praten of om iets te

vieren. De sfeer is hier een doorslaggevende factor. Het moet een aangename

setting zijn met liefst aangepaste muziek, gezellige belichting, etc. Nu zal de

omkadering ook wel bijdragen tot de ervaring maar toch in mindere mate. Ook hier

is prijs zeker geen kritiek argument.

2 De term setting of omkadering slaat meer op de fysiche omgeving (gebouw, ligging, architectuur) daar de sfeer of atmosfeer eerder een gevoelswaarde aanduid die wordt beïnvloed door muziek, temperatuur, omgevingsgeluid, licht en dergelijke meer.



• In groep:

De laatste categorie die we willen introduceren zijn de mensen die in groep gaan

eten om bijvoorbeeld iets te vieren of nog eens gezellig samen te zijn. Het gaat

hier vooral om families en vrienden die met z’n allen op restaurant gaan. De sfeer

is zeker niet onbelangrijk maar zal vooral gedragen worden door de groep zelf. Als

groep gaat men ook wel op zoek naar een restaurant dat lekker eten aanbiedt aan

een voordelige prijs, al mag dit bij een speciale gelegenheid al iets meer kosten.

Met deze 4 categorieën associëren we factoren voor alle criteria waarover de

gebruikers hun mening kunnen geven. Voor de eenvoud gaan we het aantal criteria

beperken tot 3, maar het is zeker mogelijk om hier later nog andere criteria aan toe te

voegen.

In onderstaande tabel (Tabel 1) zijn deze factoren weergeven, we houden deze

statisch maar men kan zich makkelijk indenken dat met voor iedere persoon een

dergelijke tabel zal bijhouden die dan zal evolueren met het gedrag en opinies van de

gebruiker.

Omkadering (Kk) Prijs/Kwaliteit (Kp) Sfeer (Ks)

1 Zuiver functioneel 0,2 0,8 0,4

2 Voor zaken 0,7 0,7 0,6

3 Intiem 0,7 0,6 0,9

4 In groep 0,5 0,8 0,6

Tabel 1: Conversie factoren voor het matching algoritme

Wanneer men nu de contextafhankelijke rating wil gaan berekenen gebaseerd op deze

factoren gaan we uiteraard moeten normaliseren om een juiste weergave te krijgen.

Een voorbeeld:

De volgende opinie voor een restaurant was gegeven na een zakenlunch (2):

Rk = 4, Rp = 3 en Rs = 5



Een vraag wordt gesteld vanuit een groep context (4). We bekomen de context

afhankelijke rating voor dit restaurant op volgende manier:

R = (1- |Kk(4) - Kk(2)|) x Rk + (1- |Kp(4) - Kp(2)|) x Rp + (1- |Ks(4) - Ks(2)|) x Rs

R = 0,8 x 4 + 0,9 x 3 + 1 x 5

R = 10,9

Na normalisatie wordt dit (er zijn 3 ratings)

Rn = 10,9/3

Rn = 3,63

Analoog bekomen we voor een vraag vanuit een zuiver functionele context (1) een Rn

= 2,9 en vanuit een intieme context (3) is Rn = 3,4. Voor een vraag vanuit een

zekelijke context (2) bekomen we het gemiddelde van de 3 ratings nl 4.

Context 1 2 3 4

Rn 2,9 4 3,4 3,63

Tabel 2: Aangepaste ratings voor de verschillende contexten

De genormeerde rating die we zonet hebben uitgerekend Rn kan als volgt worden

geïnterpreteerd: wanneer de input context en de output context volledig overeen

stemmen dan worden de verschillende ratings ten volle aangerekend. Wanneer dit niet

het geval is wordt de rating aangepast zodat hij reflecteert in welke mate de twee

contexten verschillen. Een rating kan dus nooit verhoogd worden, enkel verlaagd en is

maximaal wanneer beide contexten gelijk zijn, wat inderdaad zo blijkt te zijn uit Tabel

2.

Nu hebben we voor iedere opinie die nog in onze selectie zit een rating die aangepast

is aan de verwachtingen van de gebruiker.

4.4.3 Groepering

In deze voorlaatste stap groeperen we de verkregen opinies per restaurant en nemen

het gemiddelde van de ratings die we in de vorige stap hebben berekend.



4.4.4 Ordening

Op basis van deze gemiddelde ratings kunnen we de restaurants gaan sorteren en de

N beste resultaten weergeven aan de gebruiker. Het aantal (N) kan door de gebruiker

zelf gespecificeerd worden.

4.5 Architectuur

In Figuur 15 vinden we een overzicht terug van de verschillende blokken en bundles uit onze

architectuur. Deze representatie bestaat niet op zich maar is een onderdeel van de CASP

architectuur zoals voorgesteld in Figuur 7.

Figuur 15: Overzicht van de bouwblokken van de architectuur

De context providers staan in voor het leveren van context aan de context interpreter

voor de knowledge base. De context interpreter zal op basis van het context model

verifiëren of de informatie voldoet aan de vooropgestelde ontologie.

Voor meer uitgebreide informatie over de grote bouwblokken verwijzen we graag naar

het artikel over het CASP framework zelf [1].

DB

KBManager

Lookup

Matcher

Protégé

Context Interpreter

Knowledge Base

Reasoner

Context Model

Context Providers

RestoReview

DataProvider



• DataProvider

De DataProvider, een contextprovider, wordt o.a. gebruikt voor het test doeleinden.

Deze laat toe om een willekeurig aantal personen, restaurants of ratings toe te voegen

aan de knowledge base. Daarnaast is het ook mogelijk om andere informatie aan te

passen of toe te voegen zoals het aantal beschikbare plaatsen in een restaurant.

• RestoReview

De RestoReview is een bundle die toe laat om ratings toe te voegen aan de knowledge

base. Meer uitleg wordt gegeven in de GUI’s sectie 4.7.4.

• Matcher

De matchter bundle bevat de logica om de matching te gaan uitvoeren, het eigenlijke

algoritme. Deze biedt de service aan om op basis van verschillende criteria en de

context op zoek te gaan naar de best matchende restaurants.

• Lookup

De Lookup bundle zal gebruik maken van de service van de matcher bundle om op

zoek te gaan naar de restaurants. Meer uitleg wordt gegeven in de GUI’s sectie 4.7.4.

• KBManager

De KBManager staat in voor het laden, opslaan en wissen van snapshots,

momentopnamen van de knowledge base. Hij gebruikt hiervoor de service van de

context interpreter die de data uit de knowledge base levert. De KBManager maakt

gebruik van een DBConnector die via de MySQLDriver connectie maakt met de

database. Meer uitleg wordt gegeven in de GUI’s sectie 4.7.4.

• Protégé (Appendix A)

Via de Protégé plugin, protege2jena, is het mogelijk om snapshots, gecreëerd met

Protégé zelf, te exporteren naar de database en nadien te gebruiken in het framework.

Protégé kan naast het wegschrijven van snapshots, er ook inlezen om bvb na te gaan



of de inhoud van de knowledge base wel overeenkomt met hetgeen men denkt dat er

in zit. Dit is ook mogelijk met de interpretedkbvisualizer, een tool uit het CASP

framework, om de knowledge base te bekijken, echter enkel in textvorm, waar Protégé

naast een betere visualisatie ook de mogelijkheid biedt om aanpassingen te maken.

4.6 Persistentie

In tegenstelling tot wat er in [1] werd beslist in verband met de opslag van de

knowledge base hebben wij er voor gekozen om niet te werken met de open source

object database engine db4o [43]. Wij zullen gebruik maken van een standaard

relationele database engine, meer bepaald MySQL (zie Appendix A).

Er zijn verschillende redenen waarom we gebruik maken van een relationele database:

• Eerst en vooral zullen we de persistentie enkel gebruiken om de knowledge

base bij te houden buiten de werking van het framework. Er zal dus niet

rechtstreeks op de database gewerkt worden. De knowledge base wordt

bijgehouden in het geheugen door het framework en zal enkel naar de

database moeten geschreven worden wanneer het framework afgesloten wordt

of wanneer de gebruiker dit specifiek wenst. Analoog voor het inladen van de

knowlegde base bij het opstarten.

• Dit alles wordt mogelijk gemaakt door de persistentie storage die ingebouwd is

in Jena [44], die toelaat om onafhankelijk van de relationele database engine

die gebruikt wordt, zij het MySQL, Oracle, PostgresSQL of een andere engine,

een model, zowel schema als instanties, weg te schrijven. Het enige dat Jena

nodig heeft is een gepaste driver. Wij hebben gebruik gemaakt van de mysql-

connector-java-3.1.14 driver. Een van de grote voordelen van de persistent

storage van Jena is dat ze ondersteuning biedt om meerdere modellen of

instanties van een knowledge base naast elkaar in de database te bewaren. Het

is dus mogelijk om verschillende snapshots van de knowledge base in de

database op te slaan alsook te switchen naar een ander snapshot, zonder het

framework te moeten stoppen.



• Aangezien Protégé (het programma dat we zullen gebruiken om het datamodel

op te stellen, zie Appendix A) op Java gebaseerd is en plugins ondersteunt, is

het ook mogelijk om de modellen en instanties die men met Protégé heeft

opgesteld, te exporteren naar een relationele database. Naast het exporteren

van modellen is het ook mogelijk om ze met de plugin te importeren. Een

model dat door het framework is opgeslaan kan hierdoor gemakkelijk worden

bekeken en aangepast. Wij hebben daarvoor gebruik gemaakt van de plugin

Protege2Jena (zie Appendix A).

Deze persistentie is geïmplementeerd in de KBManager. Meer uitleg over de werking

van deze bundle wordt uitgelegd in paragraaf 4.5.

4.7 Technologie

4.7.1 OSGi

We baseren ons op CASP (2.5.2) dat gebruik maakt van OSGi [45], Open Services

Gateway initiative. OSGi is een platformonafhankelijk service platform dat toelaat om

software componenten (bundles) “on the fly” te beheren, wat toelaat om componenten

toe te voegen, te starten en te stoppen at runtime, zonder dat het volledige framework

moet herstart worden. De platformonafhankelijkheid is te danken aan het feit dat het

platform Java gebaseerd is en dus overal kan worden op geïnstalleerd waar een JVM

aanwezig is.

Er zijn een aantal standaard componenten en interfaces aanwezig die kunnen instaan

voor logging, security, XML en dergelijke meer. Een van die componenten is een

webserver, die toelaat dat een service beschikbaar kan worden gesteld naar een brede

waaier van eindgebruikers en doelplatformen toe. In combinatie mat AJAX kan er een

dynamische applicatie geleverd worden op allerhande (mobiele) toestellen wat toelaat

om een echte ubiquitous service te leveren.



4.7.2 Jena2

Jena2 (zie Appendix A) is een open source Java framework voor het creëren van

semantische web applicaties. Het is een programmeer

omgeving voor OWL en SPARQL (4.7.3) die ook een regel

gebaseerde reasoner bevat. Wij zullen gebruik maken van

de OWL API om modellen aan te spreken alsook gebruik

maken de ingebouwde reasoner en de SPARQL query engine.

4.7.3 SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) [46] is een protocol en een

query taal voor het semantische web, met name om RDF documenten te bevragen. Op

het moment van schrijven is SPARQL standaardisatie aan het ondergaan van W3C en

het zal normaal de status van W3C recommendation krijgen.

Een SPARQL query bestaat uit een aantal standaard elementen, net als een SQL

(Structured Query Language) [47] query.

Figuur 16: Voorbeeld van een SPARQL query

Alle variabelen worden aangeduid door een voorafgaand ?. PREFIX statements

definiëren de gebruikte namespaces in de query. De SELECT clause zal aangeven

welke van de variabelen er zullen worden teruggegeven. Indien de wildcard ‘*’ gebruikt

wordt worden alle variabelen in de query weergegeven. De WHERE clause gedraagt

zich analoog aan de WHERE clause van SQL queries met dat verschil dat ze bestaat uit

triple patronen die aangeven waaraan de variabelen moeten voldoen. Het is mogelijk

binnen de WHERE clause een OPTIONAL veld te definiëren die één of meerdere

PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title ?author WHERE { ?x rdf:type dc:book ; dc:title ?title . OPTIONAL { ?x dc:author ?author } . FILTER regex(?title, "web", "i" ) }



voorwaarde(n) kan definiëren die niet moeten vervuld worden maar als ze aanwezig

zijn wel opgehaald worden. Naast het OPTIONAL is er ook nog het FILTER veld die

voorwaarden kan opleggen op de variabelen. Dit kan door middel van reguliere

expressies maar ook via boolese uitdrukkingen.

In het voorbeeld (Figuur 16) zien we dat we een node (knoop) zoeken van het type

book die een title moet hebben en eventueel een author en de title moet de string web

bevatten. De title en de author zullen we terug krijgen.

4.7.4 GUI’s

De KBManagerGUI (Figuur 17) laat toe om snapshots van de knowledge base te gaan

beheren. Met een snapshot bedoelen we een momentopname van hoe de knowledge

base er uitziet, zowel het model als de instanties. Het is mogelijk om een snapshot die

men vroeger heeft opgeslaan weer in te laden, dit laat ook toe om in Protégé een

model op te stellen en reeds instanties toe te voegen om deze dan in het systeem te

laden. Uiteraard is het ook mogelijk om de huidige knowledge base weg te schrijven

naar de database en deze later weer in te laden.

Figuur 17: De KBManagerGUI

Ook het verwijderen van snapshots is mogelijk om bvb een beter overzicht te krijgen of

om opslagcapaciteit uit te sparen. De refresh knop laat toe om de lijst van aanwezige

snapshots in de database te vernieuwen, aangezien het mogelijk is met externe

programma’s snapshots naar de database te schrijven.



Figuur 18: De ReviewGUI

De ReviewGUI (Figuur 18) wordt gebruikt om ratings van gebruikers in te geven. Men

kan een gebruiker, die in de knowledge zit, kiezen uit een lijst alsook een restaurant.

De gebruiker kan 3 verschillende ratings ingeven. De omkadering (Setting) gaat over

hoe het restaurant overeenstemt met het doel van zijn restaurantbezoek. Een tweede

rating is de kwaliteit van het eten (Food Quality) en als laatste kan hij aangeven wat

hij vond van de sfeer (Atmosphere). Het context element dat we zullen gebruiken

wordt hier voorgesteld door het “Type Of Visit” veld. De 4 mogelijkheden zijn zoals

aangegeven in 4.4.2: zakelijk (business), intiem (intimate), groep (In Group) en zuiver

functioneel (Just For Food).

De LookupGUI (Figuur 19) is de interface die we hebben gebruikt om de opzoeking uit

te voeren. Men kan uiteraard kiezen wie er de opzoeking uitvoert en analoog aan de

review hebben we hier het contextuele veld “Type Of Visit” dat ook weer 4

mogelijkheden kan aannemen. Zowel de keuken (Kitchen) als de options zijn criteria

die zullen gebruikt worden in de eliminatie stap van ons matching algoritme. Ook kan

aangegeven worden hoeveel resultaten er moeten worden weergegeven.



Figuur 19: De LookupGUI

In het resultaten veld zullen de geordende restaurants komen die het best voldeden

aan de voorwaarden en de context van de gebruiker. Het getal na de naam van het

restaurant is de gematchedte rating die ons algoritme heeft berekend.



Hoofdstuk 5: Evaluatie en prestatie van het

algoritme

5.1 Testopstelling

De machine die we gebruikt hebben om de test uit te voeren is een HP Compaq

nc6400 met de volgende specificaties: Intel Core Duo T2300 (1.66 GHz) en 2 GB RAM.

Het framework draaide onder Windows XP Pro met Java VM 1.5.0 en de Knopflerfish

2.0.0 implementatie van OSGi.

5.2 Testmethode

Om de prestatie van het algoritme, meer specifiek de matching, te testen hebben we

gebruik gemaakt van de DataProvider bundle. Bij het constant houden van het aantal

personen en restaurants in het systeem hebben we het aantal ratings laten varieren

van 25 tot 250 in stappen van 25 (het aantal personen heeft bij ons geen invloed

aangezien we nog geen rekening houden met de onderlinge relaties of persoonlijke

voorkeuren). Bij iedere populatie van de knowledge base, gevuld met x aantal

willekeurige ratings, hebben we een opzoeking gedaan naar de 5 beste restaurants en

de tijden genoteerd van de duur van de matching stap uit het algoritme.

De eliminatie stap hebben we buiten beschouwing gehouden, geen beperkende criteria

opgelegd, omdat deze het aantal restaurants waarvan de ratings in de matching stap

worden onderzocht zou beperken.

5.3 Resultaten

In Figuur 20 zien we een grafiek van de tijden die iedere matching stap heeft geduurd.

We kunnen duidelijk zien dat er een lineaire evolutie is. Bij iedere stap zijn er 25

ratings toegevoegd aan de knowledge base en kwam er gemiddeld 1,8 seconde bij de

uitvoeringstijd van de matching stap. Hieruit kunnen we besluiten dat de ons algoritme

lineair is in het aantal ratings, van de orde O(N). Het aantal ratings is onder meer



afhankelijk van het aantal restaurants dat er over blijven na de eliminatie stap, ieder

restaurant brengt het aantal ratings met zich mee die tot zichzelf betrekking hebben.

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

25 50 75 100 125 150 175 200 225 250

# ratings

seco

nd

en

Figuur 20: Invloed van aantal ratings op de performantie

In een realistische situatie zullen er al gauw 10 tot 20 restaurants zijn die aan de

eliminatie criteria voldoen. Indien deze elk 20 ratings met zich mee brengen

gemiddeld, wat zeker niet overdreven is, hebben we tussen de 200 en de 400 ratings.

Voor 200 ratings zitten we reeds aan 14 seconden uitvoeringstijd enkel voor de

matching stap. Als gebruiker wil je echter niet 14 seconden of meer wachten op een

resultaat, eerder 1 a 2 seconden maximum. Onze implementatie van het algoritme is

dus niet echt geschikt voor soft real-time systemen.

Mogelijke aanpassingen die zouden kunnen leiden tot betere resultaten zijn onder

meer optimalisatie van gebruikte datastructuren en parallellisatie invoeren voor

berekeningen waar mogelijk.



Hoofdstuk 6: Conclusies

In deze thesis werd onderzocht hoe de contextafhankelijkheid van user generated

content in rekening kan worden gebracht om zo betere zoekresultaten te bekomen.

Gebruik makend van een ontologie-model (in OWL) dat we hebben opgesteld om de

context te modelleren hebben we content samen met zijn context kunnen vatten.

Context is een zeer krachtig concept gebleken en vormt samen met ontologieën een

veelbelovend duo.

Wij hebben een matching algoritme omtwikkeld, bestaande uit 4 stappen (eliminatie,

de matching zelf, groepering en ordening), dat mogelijk maakt om content te bekijken

van uit een andere context dan in dewelke hij in het systeem is geïntroduceerd om een

objectieve vergelijking te kunnen maken van de content.

Om ons algoritme, toegepast op ratings, te illustreren hebben we een use case rond

restaurants geïmplementeerd, gebruik makend van het CASP framework. Het OSGi

platform, waarvan CASP gebruik maakt, leent zich uitstekend voor het beheren en

deployen van modulaire services. Bij het testen van de performantie, meer bepaald de

bepalende matching stap van ons algoritme, bleek onze implementatie toch niet

optimaal voor soft real-time systemen maar er is zeker nog ruimte voor verdere

optimalisatie.



Hoofdstuk 7: Future Work

7.1 Context

Context is een enorm uitgebreid begrip en er kan nog met heel wat meer informatie

rekening gehouden worden om tot nog betere resultaten te komen. Wij hebben ons

beperkt tot een aantal essentiële entiteiten om het model makkelijk manipuleerbaar te

houden.

Een mogelijke verdere detaillering van het context model is het toevoegen van

specifieke menu’s en dranken. De meerwaarde hiervan zal vooral terug te vinden zijn

in de eliminatiestap.

Wij hebben ons beperkt tot 3 contextfactoren die de ratings beïnvloeden. Dit kan

uiteraard nog uitgebreid worden met andere factoren zoals service, wachttijden, etc.

7.2 Algoritme

Een verdere optimalisatie en uitbreiding van het algoritme biedt ook nog veel

mogelijkheden. Zo kan men rekening houden met de compositie van de groep van

mensen die op zoek zijn naar een restaurant. Men zal dan de achtergrond van de

gehele groep in acht nemen om een match te vinden.

De factoren die wij hebben voorgesteld in 4.4.2 zijn statisch en voor iedere gebruiker

in het systeem dezelfde. Niet iedereen zal dezelfde waarde hechten aan de

verschillende factoren. Men zou deze factoren variabel kunnen maken voor iedere

gebruiker en eventueel zelfs dynamisch maken zodat ze zichzelf aanpassen aan de

gedragingen van de gebruiker.

Eén van de dingen waar we nog geen rekening mee hebben gehouden is het feit dat

indien geen rating aanwezig is voor een bepaald restaurant men onmogelijk dit

restaurant kan terugkrijgen als resultaat. Ook kan men de gematchte rating laten

afhangen van het aantal ratings die aanwezig zijn. Indien er veel mensen naar een



restaurant gaan en hun mening ingeven kan dit een teken zijn dat het restaurant wel

populair is en eventueel aan te raden is.

7.3 Andere

Wij hebben de gebruiker beperkt qua zoektermen tot hetgeen reeds aanwezig is in de

knowledge base om zo mogelijke verwarring tegen te gaan. Een oplossing hiervoor zou

kunnen zijn om een intelligente spellingscorrector te gebruiken, bvb op basis van

reguliere expressies, in combinatie met het gebruik van WordNet [35] dat

mogelijkheden biedt om lexicale relaties en analyses te doen van woorden alsook uitleg

van gerechten(weliswaar in het Engels).

Bvb ratatouille: a vegetable stew, usually made with tomatoes, eggplant, zucchini,

peppers, onion, and seasonings.

Om de service toegankelijk te maken op allerhande (mobiele) platformen kan men

deze aanbieden als een webservice. Het OSGi platform ondersteunt een http server die

met een AJAX frontend een krachtig platform kan vormen om deze webservice aan de

gebruiker te leveren.



Appendix A Programma’s en tools

In deze appendix zijn de gebruikte programma’s kort toegelicht die tijdens dit werk

gebruikt werden. Voor meer gedetailleerde informatie verwijzen we naar de bijhorende

websites.

• Knopflerfish 2.0.0 (http://www.knopflerfish.org/)

Open source OSGi implementatie volgens OSGi R4.

Service platform.

• Eclipse 3.2 (http://www.eclipse.org/)

Open source ontwikkel platform voor Java. Uitbreidbaar via plugins.

Ontwikkeling van de use case implementatie.

• Jena 2.5.1 (http://jena.sourceforge.net/)

Java framework voor het maken van semantische webapplicaties.

Context model, SPARQL, reasoning.

• Jigloo SWT/Swing GUI Builder 3.9.5

(http://www.cloudgarden.com/jigloo/)

Plugin voor Eclipse voor het maken van GUI’s.

GUI’s voor de use case implementatie.

• Protege 3.2 (http://protege.stanford.edu/)

Open source ontologie editor en knowledge base framework

Opstellen en aanpassen van de ontologie, zowel het schema als instanties.

• Protege2Jena plugin (http://semweb.krasu.ru/protege2jena/)

Protégé plugin voor export en import van en naar Jena persistent storage.

Importeren en exporteren van het de ontologie van en naar de MySQL

database.



• MySQL Community Server 5.0

(http://dev.mysql.com/downloads/mysql/5.0.html)

Open source relationele databank management system.

Persistente opslag van de knowledge base.

• MySQL GUI Tools (http://dev.mysql.com/downloads/gui-tools/5.0.html)

MySQL Administrator 1.2 en MySQL Query Browser 1.2

GUI’s voor het management van de MySQL database.

• Visio 2000 (http://office.microsoft.com/en-us/visio/default.aspx)

Visueel modelleer programma voor het opstellen van techtnische diagrammen.

Modelleren van use case diagram, context modellen en klassediagram.



Appendix B Evolutie van de ontologie

Gedurende het verloop van dit werk heeft de ontologie verschillende iteraties

ondergaan.

Bij de eerste iteraties hebben we ons deels gebaseerd op de ULO die wordt

voorgesteld in de SOCAM architectuur, analoog aan het CASP framework. Echter de

gelaagde structuur werd uit het oog verloren en er werd te veel gekeken naar de

details en het exact modelleren van de realiteit. Het gevold hiervan was dat het model

te groot werd en te gedetailleerd zonder een duidelijke structuur (Figuur 21), alles was

wel aanwezig maar het model was niet werkbaar.

User

Profile

hasProfile

Restaurant

Menu

Device

Location

Course

AddressRating

Time

Interval

Weather

Beverage

Waiter

subClassOf

isGivenBy

isGivenTohasMenu

hasDevice

hasLocation

hasAddress

hasEndTimehasStartTime

hasOpeningHours

hasWeather

hasCourse

hasBeverage

isNearby

hasLocation

isOwnedBy

hasAddress

subClassOf

isOfferedBy

RatingType

hasType

Meal hasParticipant

takesPlaceIn

consistsOf

isServedBy

hasDuration

worksAt

Figuur 21: Ontologie model na het eerste aantal iteraties



Er werd dan besloten van terug te gaan naar een meer zuivere structuur die dichter

aansloot bij de ULO van de SOCAM architectuur (Figuur 22) maar door de nog steeds

overdetaillering was het model nog steeds onoverzichtelijk en niet werkbaar.

User

Device

LocationTime

Weather

ContextEntity

Rateable

Activity

MealEvent

WaiterRestaurant

Course Menu

Beverage

hasLocation

hasLocationratedBy

involvedIn

hasStartTime

tookPlaceAt

hasEndTime

concerns

servedBy

Address

hasAddress

has

has

has

RatingSubject

hasLocation

owns

hasWeather

Figuur 22: Context model in een later stadium

Uiteindelijk hebben we het geheel geminimaliseerd tot het model dat we effectief

hebben gebruikt, zie Figuur 14.



Bibliografie

[1] M. Strobbe, J. Hollez, G. De Jans, O. Van Laere, J. Nelis, F. De Turck, B. Dhoedt, P. Demeester, N. Janssens, T. Pollet: Design of CASP: an Open Enabling Platform for Context Aware Office and City Services. In Proceedings of MUCS 2007, the 4th International Workshop on Managing Ubiquitous Commuications and Services, Munchen (25 Mei 2007)

[2] M. Strobbe, G. De Jans, J. Hollez, N. Goeminne, B. Dhoedt, F. De Turck, P. Demeester, T. Pollet, N. Janssens: Design of an Open Context-Aware Platform enabling Desk Sharing Office Services. In Proceedings of PSC 2006, Las Vegas (Juni 2006)

[3] WWW: What is the Semantic Web? http://www.altova.com/semantic_web.html

[4] WWW: Semantic Web. http://www.w3.org/2001/sw/

[5] E. Bontas: Context Representation and Usage for the Semantic Web: A State of the Art, ftp://ftp.inf.fu-berlin.de/pub/reports/tr-b-04-30.pdf . (December 2004)

[6] WWW: OWL. http://www.w3.org/2004/OWL/

[7] WWW: Free On-Line Dictionary Of Computing. http://foldoc.org/

[8] A. K. Dey: Providing Architectural Support for Building Context-Aware Applications. Ph.D. thesis, Georgia Institute of Technology (2000)

[9] A. Schmidt, M. Beigl, H. W. Gellersen: There is more to Context than Location, University of Karlsruhe (2000)

[10] WWW: http://forsalebylocals.wordpress.com/2007/03/13/linking-real-estate-content-with-user-context-basic-concepts-of-data-and-metadata/

[11] WWW: http://office.microsoft.com/en-us/products/HA101679411033.aspx#2

[12] WWW: What Is An Ontology. http://www-ksl.stanford.edu/kst/what-is-an-ontology.html

[13] J. Criel: Context Awareness, Gent (2005)

[14] S. Powers: Practical RDF. 1st edition, O’Reilly, Sebastopol, CA. (2003)

[15] D. Arregui, C. Fernstrom, F. Pacull, G. Rondeau, J. Willamowski, E. Crochon, F. Favre-Reguillon: Paper-based Communicating Objects in the Future Office (2003)

[16] J. Landt, B. Catlin: Shrouds of Time, The history of RFID. AIM Inc. (Oktober 2001)

[17] WWW: NFC. http://europe.nokia.com/A4153291

[18] WWW: NFC Forum. http://www.nfc-forum.org/

[19] The Internet of Things(Executive summary), ITU, Genève (November 2005)

[20] RFID and the Internet of Things. DIGITAL ID WORLD (November/December 2003), 66-69



[21] WWW: Metcalfe’s Law. http://en.wikipedia.org/wiki/Metcalfe's_law

[22] WWW: Cisco's John Chambers preaches Web 2.0 gospel. http://www.webware.com/8301-1_109-9722419-2.html?tag=blog

[23] WWW: Citizen Media Project. www.ist-citizenmedia.org

[24] H. Chen, T. Finin, A. Joshi: An ontology for context-aware pervasive computing environments. Special Issue on Ontologies for Distributed Systems, Knowledge Engineering Review, 18(3) (2004), 197-207

[25] T. Gu, H. K. Pung, D. Q. Zhang: Toward an OSGi-Based Infrastructure for Context-Aware Applications. IEEE – pervasive computing (Oktober/December 2004)

[26] T. Broens: Context-aware, Ontology based, Semantic Service Discovery (Juli 2004)

[27] WWW: UMTS. http://www.umts-forum.org/

[28] WWW: WASP project. http://wasp.freeband.nl/

[29] H. K. Rubinsztejn, M. Endler, V. Sacramento, K. Gonçalves, en F.N. Nascimento: Support for context-aware collaboration. First International Workshop on Mobility Aware Technologies and Applications (MATA 2004), 5(10) (2004), 34-47

[30] G. Klyne, F. Reynolds, C. Woodrow, H. Ohto, J. Hjelm, M. H. Butler, L. Tran: Composite capability/preference profiles (cc/pp): Structure and vocabularies 1.0. http://www.w3.org/TR/2004/REC-CCPP-structvocab-2040115/ (2004)

[31] P. Shvaiko, J. Euzenat: Tutorial on Schema and Ontology Matching, ESWC’05, http://dit.unitn.it/~accord/Presentations/ESWC'05-MatchingHandOuts.pdf. (2005)

[32] A. Doan, J. Madhavan, P. Domingos, A. Halevy: Ontology Matching: A Machine Learning Approach. http://www.cs.washington.edu/homes/pedrod/papers/hois.pdf. (2003)

[33] N. Noy: Ontology Mapping and Alignment. http://dit.unitn.it/~accord/RelatedWork/Matching/Noy-MappingAlignment-SSSW-05.pdf.(2005

[34] WWW: Regular Expressions. http://www.regular-expressions.info/

[35] WWW: WordtNet. http://wordnet.princeton.edu/

[36] WWW: Exact String Matching Algorithms. http://www-igm.univ-mlv.fr/~lecroq/string/index.html

[37] WWW: String Metrics. http://www.dcs.shef.ac.uk/~sam/stringmetrics.html

[38] WWW: Pattern Matching Pointers. http://www.cs.ucr.edu/%7Estelo/pattern.html

[39] H. Chen, F. Perich, T. Finin, A. Joshi: SOUPA: Standard Ontology for Ubiquitous and Pervasive Applications. (2004)

[40] F. Perich, A. Joshi, Y. Yesha, T. Finin. Neighborhood- Consistent Transaction Management for Pervasive Computing Environments. 14th International



Conference on Database and Expert Systems Applications (DEXA 2003), Praag. (september 2003)

[41] L. Claeys: Informatie- en Communicatie Technologieën in de dagelijkse leefwereld. Een interpretatieve benadering van gelijke kansen in de netwerkmaatschappij. Doctoraal proefschrift, Universiteit Gent, Gent. (2007)

[42] WWW: Verisign. http://www.verisign.com/

[43] WWW: DB4O. http://www.db4o.com/

[44] WWW: Jena. http://jena.sourceforge.net/

[45] WWW: OSGi. http://www.osgi.org/

[46] WWW: SPARQL. http://www.w3.org/TR/rdf-sparql-query/

[47] WWW: SQL. http://www.w3c.org/SQL/

[48] J. Berri, R. Benlamri, Y. Atif: Ontology-based Framework for Context-aware Mobile Learning (2006)

Faculteit Ingenieurswetenschappen Vakgroep...

Documents

Transcript of Faculteit Ingenieurswetenschappen Vakgroep...