Gepersonaliseerde en contextafhankelijke profielen op Android …€¦ · Gepersonaliseerde en...

Pieter Van Lysebetten, Sam Govaert

Android mobiele toestellenGepersonaliseerde en contextafhankelijke profielen op

Academiejaar 2010-2011Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleiders: Philip Leroux, Klaas RoobroeckPromotor: prof. dr. ir. Filip De Turck

Voorwoord

Het schrijven van onze masterproef was een uitdagende en leerzame opdracht.

Allereerst zouden we onze thesisbegeleiders Philip Leroux en Klaas Roobroeck willen bedanken

voor hun uitstekende begeleiding. Wij bedanken eveneens onze promotor Filip De Turck.

Verder wensen wij graag onze vrienden en familie te bedanken voor hun zinvolle tips en com-

mentaren.

Tot slot bedanken wij ook elkaar voor de vlotte samenwerking.

Sam Govaert, Pieter Van Lysebetten, mei 2011

Toelating tot bruikleen

“De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen

van de masterproef te kopieren voor persoonlijk gebruik.

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

trekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten

uit deze masterproef.”

Sam Govaert, Pieter Van Lysebetten, mei 2011

Gepersonaliseerde en contextafhankelijke

profielen op

Android mobiele toestellendoor

Sam GOVAERT

Pieter VAN LYSEBETTEN

Masterproef ingediend tot het behalen van de academische graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Academiejaar 2010–2011

Promotor: prof. dr. ir. F. DE TURCK

Scriptiebegeleiders: P. LEROUX, K. ROOBROECK

Faculteit Ingenieurswetenschappen en Architectuur

Universiteit Gent

Vakgroep Informatietechnologie

Voorzitter: prof. dr. ir. D. DE ZUTTER

Samenvatting

De laatste jaren is er een grote opmars gekomen in het downloaden en installeren van nieuwe ap-

plicaties op smartphones. Bovenop de basisapplicaties voor werk en entertainment die zich reeds

op het toestel bevinden, brengt de opkomst van Web 2.0 en online sociale netwerken een hele

reeks applicaties (apps genoemd) mee die gebruikers wensen te installeren op hun smartphone.

Vele van die applicaties worden vooral gebruikt in een specifieke context. Deze masterproef biedt

een framework aan voor gepersonaliseerde en contextafhankelijke profielen op Android mobiele

toestellen. Er wordt een oplossing voorgesteld voor het automatisch ontdekken en toepassen

van profielen voor verschillende contextuele omgevingen (bvb thuis, werk, vervoer). Op basis

van het huidige profiel en de huidige context zal deze oplossing automatisch overschakelen van

telefooninstellingen (zoals de belmodus) tussen de desbetreffende profielen. Daarbovenop wordt

er een beperkte set van applicaties en contacten aanbevolen die in de huidige context het meest

kans maken om te worden geopend of gebeld door de gebruiker.

Trefwoorden

personalisatie, context-awareness, Android profielen, aanbeveling

1

Personalized and Context-Aware Profiles onAndroid Mobile Phones

Sam Govaert and Pieter Van LysebettenSupervisor: prof. dr. ir. Filip De Turck

Abstract—Over the past years, the continuous purchasing anddownloading of new applications on smartphones (called apps)have become increasingly popular. In addition to traditionalapplications for work and entertainment, the rise of Web 2.0and online social networks provides a lot of new applications thatusers want to use. As a result, several applications are installed ontheir smartphones and as users want to download more and moreapps, this number of applications will only increase. Moreover,many of the applications are especially used in a specific context.This master thesis presents a framework for personalized andcontext-aware profiles on Android mobile phones. Our solutionis to automatically detect and apply personalized profiles fordifferent contextual environments (e.g. home, working, driving).Based on the current profile and the current context, the solutionautomatically switches phone settings (e.g. ringing mode) andrecommends a limited set of applications and contacts which aremost likely to be used or called in this context.

Index Terms—personalization, context-awareness, Androidprofiles, recommendation

I. INTRODUCTION

OVER the past years, users of smartphones often like todownload and install more and more applications. More

than often, a user operation (e.g. opening an application orcalling a friend) is not independent of the context in whichthe operation is performed. For example, an employee of acompany is more likely to use work-related applications (e.g.QuickOffice, Email, Agenda) during the work hours and home-applications (e.g. Facebook, Youtube, Music) in the eveningsor during the weekends. Moreover, certain patterns or routinescould be discovered such as setting the alarm clock beforegoing to bed, checking the agenda when waking up, etc.The same conclusions can be drawn for calling or contactingpeople. Our goal was to create a framework for automatic userprofiles and context-aware recommendation. At any time whena user wishes to use his mobile phone, he will be classifiedinto one of the discovered profiles and a particular set ofcontacts and applications will be recommended dependent onthis profile and the current context. In addition, certain phonesettings such as the ringing mode are automatically set whenswitching between these profiles.

This main goal can be split up into two use cases. Thefirst case is to discover structures and profiles in a historyof unstructured context data traced on the phone. The secondcase is to discover contextual patterns in the structured datain order to classify new context parameters into an existingprofile and a set of applications which are most likely to beused.

II. TECHNOLOGIES

Several techniques within data mining or artificial intelli-gence can be used for this purpose. We haven chosen two maintechniques: clustering for the first use case and association ruleanalysis for the second use case.

A. Clustering

The goal of clustering is to find structures in a set of data,thereby requiring no a priori knowledge about the membershipof samples into classes. Clustering problems are often solvedwith neural networks. Two important neural network modelsfor this purpose are competitive networks and ART networks.Still, the first model lacks the ability to discover by itself thenumber of clusters to create and the second model was notappropriate for our goal.

A more appropriate method for our use case was theExpectation-Maximization Algorithm. This algorithm is as-suming that all clusters in the data can be described byGaussian distributions as a first approximation. Based on thisassumption and the given data, EM tries to discover the mostrealistic shapes of these distributions by finding maximumlikelihood estimates of the parameters. Figure 1 shows how theEM algorithm is capable of finding different topology clusterswithin a set of mixed data samples.

Fig. 1. Expectation-Maximization algorithm

B. Association Rule Analysis

The goal of association rule analysis is to find correlationsbetween different attributes in a large dataset or database. Thediscovered knowledge is represented by means of associationrules. For example, the rule {butter, bread} => {milk} foundin the marketing database of a shop tells us that when acustomer buys butter and bread, he’s likely to buy milk too.

2

III. ARCHITECTURE

We present a ClientServer-based architecture that coversboth use cases that we discussed. The Android client ap-plication consists of two parts: a service and a widget. Theservice is used for tracking and storing context information(e.g. time, longitude, latitude, speed), opened applications andcalled friends and for communicating with the server. Thewidget is used to visualize the profiles and recommendations.

Evaluation showed that the clustering techniques were toointensive to be executed on mobile phones. Therefore, we useda seperate server for all data mining techniques to minimizethe workload on the resource-limited smartphone.

The server architecture is composed of two main parts: aclustering engine and a classifier.

A. Clustering Engine

This component finds clusters in the unstructured traceddata of the Android client. The data is clustered on severalattribute configurations. For example, the samples are clusteredon longitude and latitude for finding a user’s location clusters.Similar clustering is done to find time clusters, speed clusters,etc. We found that combining more attributes together providesmore accurate and realistic cluster results. Figure 2 shows thecombination of the two-dimensional location attribute with theone-dimensional speed attribute to create a three-dimensionalspace for clustering. Consequently, clustering can be done forall attributes together to find realistic clusters forming theuser’s profiles.

latitude(decimal)

longitude (decimal)

51.03419 51.05122

4.21400

4.21742

instance no

speed (km/h)

0.025

70

longitude (decim

al)

speed (km/h)

latitude (decimal)

Fig. 2. Combining attributes

B. Classifier

The found profiles and all other discovered clusters arenow used to find patterns in the use of applications. Threealgorithms are used for this matter:

1) Association Rules: : all found clusters are fed to the as-sociation rule algorithm to find correlations within contextualparameters (e.g. time, location) and used applications.

2) Profile Window: : the profile clusters are used to findprofile-dependent patterns.

3) Recent Window: : a statistic algorithm is used foranalyzing the most recent used applications.

Finally, a classification function (e.g. max function orweighted sum) is used to find application probabilities thatindicate which applications are more likely to be used.

IV. EVALUATION

Our framework was evaluated on quality and performance.For the evaluation of the application recommendation we havemade a modelling tool to create realistic test data of a user.This tool makes it possible to model different contextualenvironments and application patterns. The model is thentranslated into testdata which can be fed into our architecture.Moreover, we have created an own metric to compare therecommendations of the framework with simulated test data.Figure 3 shows the comparison of different configurations ofour architecture together with a Simple Recommender whichrecommends applications only based on the total number ofusages. The figure shows the true positives of used applicationsthat were successfully recommended when we use a recom-mendation set of 6 applications. On the x-axis we find therecommendation index (called bin), on the y-axis we find thenumber of applications per bin.

Fig. 3. Comparison of configurations with a Simple Recommender

We can conclude that we get much better results than thesimple recommender. The association rule algorithm and themax classification deliver the best results.

V. CONCLUSION

We propose a solution to discover structure and patternsin the contextual information of Android mobile phone us-ages. For this purpose, a clustering technique (Expectation-Mazimization) and an association rule algorithm were foundto be appropriate. Based on these techniques, a framework forautomatic user profiles and recommendation was created.

REFERENCES

[1] Toby Segaran, Programming Collective Intelligence, O’Reilly Media,2007.

[2] Guy De Tre, Concepts of Databases, Pearson Education Benelux, 2007.[3] Gail A. Carpenter and Stephen Grossberg, Adaptive Resonance Theory,

Department of Cognitive and Neural Systems, Boston University, 2002.[4] Frank Dellaert, The Expectation Maximization Algorithm, College of

Computing, Georgia Institute of Technology, 2002.

INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Structuur van deze masterproef . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Literatuurstudie 3

2.1 Artificiele intelligentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Machine learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Supervised versus unsupervised learning . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Technieken en frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.2 Beslissingsbomen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5.3 Support Vector Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.4 Neurale netwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.5 Regelgebaseerde systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.6 Verwantschapsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Stability Plasticity Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Android 20

3.1 Android Software Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 REST vs SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

INHOUDSOPGAVE ii

3.7 Compilatieproblemen met libraries op Android . . . . . . . . . . . . . . . . . . . 24

4 Evaluatie van technieken 25

4.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Competitieve netwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.2 Adaptive Resonance Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.3 Expectation-Maximization algoritme . . . . . . . . . . . . . . . . . . . . . 28

4.2.4 Het EM-algoritme voor profielherkenning . . . . . . . . . . . . . . . . . . 31

4.3 Verwantschapsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Genereren van clusters en profielen 38

5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Voorbeeldcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Eerste-niveau clustering: attributen . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1 Locatie, snelheid, weekdag . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.2 Tijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3.3 Attributen combineren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Tweede-niveau clustering: applicaties . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Ontdekken van patronen en structuur 47

6.1 Grafenalgoritme voor profielafhankelijke patronen . . . . . . . . . . . . . . . . . . 48

6.1.1 Opstellen van de graaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.2 Berekenen van de theoretische probabiliteiten . . . . . . . . . . . . . . . . 50

6.2 Associatieregels voor intra-cluster correlatie . . . . . . . . . . . . . . . . . . . . . 52

6.2.1 Intra-attribuut correlatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.2 Intra-applicatie correlatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3 Statistisch algoritme voor kortetermijngeheugen . . . . . . . . . . . . . . . . . . . 54

6.4 Classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Raamwerk 57

7.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.3 Fix, Profiel en Classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.4 Diensten van de server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

INHOUDSOPGAVE iii

7.4.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.4.2 Classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.5 Server architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.5.1 ClusterEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.2 AssociationRuleEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.3 Andere engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.5.4 ProfileManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.5.5 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.5.6 Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.5.7 Klassendiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.6 Client architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.6.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.6.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.6.3 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.6.4 Recommender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.6.5 Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.6.6 Klassendiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8 Evaluatie 75

8.1 Testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.1 Modelling Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.2 Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.2.1 Bestaande metrieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.2 Eigen metriek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.3 Evaluatie van de applicatierecommandatie . . . . . . . . . . . . . . . . . . . . . . 81

8.3.1 Profielvenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.3.2 Associatieregels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.3.3 Kortetermijngeheugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.3.4 Totale classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.4 Performantie van de serverdiensten . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.4.1 Opbouwen van profielen en associatieregels . . . . . . . . . . . . . . . . . 86

8.4.2 Classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.5 Performantie van de Android client . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.5.1 Vertragingen op GUI-niveau . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.5.2 Batterijverbruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

INHOUDSOPGAVE iv

8.6 Netwerkbelasting tussen client en server . . . . . . . . . . . . . . . . . . . . . . . 88

8.6.1 Aanvraag tot clusteren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.6.2 Aanvraag tot classificeren . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

9 Verdere uitbreidingen 94

9.1 Dynamisch evalueren van profielen . . . . . . . . . . . . . . . . . . . . . . . . . . 94

9.2 Optimalisatie van de recommendatie . . . . . . . . . . . . . . . . . . . . . . . . . 94

10 Conclusie 95

A Configuratiegegevens 96

A.1 Gebruikte bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.2 Gebruikte webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.3 Android versie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.4 LocalHost op emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

A.5 Instellen IP-adres op client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

B Inhoud van de CD-ROM 98

INHOUDSOPGAVE v

Lijst van afkortingen

AI Artificiele intelligentie

API Application Programming Interface

ART Adaptive Resonance Theory

EM Expectation-Maximization

GUI Graphical User Interface

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment

IP Information Parameter

JSON JavaScript Object Notation

JVM Java Virtual Machine

NIP Normalized Information Parameter

POC Proof of Concept

REST Representational State Transfer

RGB Red-Green-Blue

SOAP Simple Object Access Protocol

SVM Support Vector Machine

URL Uniform Resource Locator

WSDL Web Services Description Language

WTA Winner-Take-All

XML Extensible Markup Language

INLEIDING 1

Hoofdstuk 1

Inleiding

1.1 Situering

Vandaag de dag zijn smartphones (bvb. Android Smartphones, iPhone, BlackBerry) niet meer

weg te denken uit onze samenleving. De snelgroeiende technologie enerzijds en de opkomst van

Web 2.0 en sociale netwerken anderzijds zorgen er bovendien voor dat deze smartphones nog

weinig beperkingen opleggen in het vrij downloaden en installeren van nieuwe applicaties (apps

genoemd). De moderne functies en sensoren in een smartphone brengen allerhande nieuwe ap-

plicaties mee. GPS, Google Earth, applicaties om foto’s of muziek te herkennen, het zijn maar

enkele voorbeelden. Vele gebruikers zijn ook aangesloten bij sociale netwerken zoals Facebook of

Twitter. Elk van deze netwerksites biedt hun eigen apps aan voor smartphones. Vaak zijn ge-

bruikers zelfs aangesloten bij meerdere sociale netwerken tegelijk. Het Android OS is bovendien

open-source waardoor iedereen eigen applicaties kan schrijven voor Android en deze aanbieden

aan andere gebruikers. Zo worden er voor de kleinste events reeds apps ontwikkeld en aangebo-

den.

1.2 Probleemstelling

Gebruikers hebben meestal dan ook een tal van applicaties op hun mobiel toestel staan. Vaak

zijn gebruikersoperaties (zoals het openen van een applicatie of het bellen van een vriend) dan

ook niet onafhankelijk van de context waarin ze worden uitgevoerd. Een werknemer in een

bedrijf zal bijvoorbeeld eerder werkgerelateerde applicaties (bvb. QuickOffice, Email, Agenda)

openen tijdens de werkuren en vrijetijdsapplicaties (bvb. Facebook, Youtube, Music) ’s avonds

en tijdens het weekend. Bovendien kunnen er vaak patronen of routines ontdekt worden in het

applicatiegebruik. Bekende voorbeelden zijn het zetten van de alarmklok voor het slapengaan,

1.3 Doelstelling 2

het nakijken van de agenda bij het opstaan, opzetten van muziek in de trein, enzoverder. Dezelfde

conclusies kunnen worden getrokken voor het contacteren van mensen.

1.3 Doelstelling

De doelstelling van deze masterproef is om een framework aan te bieden voor gepersonaliseerde

en contextafhankelijke profielen op Android mobiele toestellen. Dit framework zal enerzijds

automatisch profielen proberen te ontdekken voor verschillende contextuele omgevingen (bvb.

thuis, werk, vervoer). Hiervoor zullen verschillende technieken geevalueerd worden op de ca-

pabiliteit om zelfstandig en adaptief stabiele profielen te kunnen genereren. Vervolgens zal er

gezocht worden naar patronen in het gebruik van applicaties. Hiervoor zullen alweer een aantal

algoritmes geevalueerd worden. Tot slot wordt gezocht naar een gebruiksvriendelijke manier om

op het Android toestel automatisch over te schakelen tussen verschillende profielen en op een

intuıtieve wijze applicaties en contacten aan te bevelen die het meest kans maken om geopend

te worden in de huidige context.

1.4 Structuur van deze masterproef

In deze masterproef zal eerst onderzoek gedaan worden naar verschillende technieken en algo-

ritmes enerzijds en naar het Android platform anderzijds. Vervolgens zullen in Hoofdstuk 4

enkele van de meest bruikbare technieken geevalueerd worden. De twee belangrijkste use cases

om onze doelstelling te bereiken zullen nadien in detail besproken worden in Hoofdstuk 5 en 6.

Dit vormt de basis voor ons raamwerk dat wordt besproken in Hoofdstuk 7. In Hoofdstuk 8 zal

ons raamwerk geevalueerd worden. Tot slot worden enkele mogelijke uitbreidingen besproken in

Hoofdstuk 9 en sluiten we af met een conclusie in Hoofdstuk 10.

LITERATUURSTUDIE 3

Hoofdstuk 2

Literatuurstudie

2.1 Artificiele intelligentie

Artificiele intelligentie is de wetenschap die streeft naar het creeren van kunstmatige intelligentie

in machines. We kunnen een onderscheid maken tussen sterke AI en zwakke AI. Sterke AI

heeft als doel om menselijke intelligentie te benaderen of zelfs te overtreffen. De artificiele

intelligentie waarin wij geınteresseerd zijn is echter de zwakke AI. Deze heeft niet als doel om

menselijke intelligentie na te bootsen, maar tracht eerder gedragingen te vormen die enige vorm

van intelligentie bezitten[1].

Artificiele intelligentie draait dus niet alleen rond het simuleren van menselijke intelligentie.

Het grootste deel van onderzoek in AI gaat over het bestuderen van problemen die de wereld

aanlegt, en niet zozeer het bestuderen van mensen of dieren. AI-onderzoekers zijn vrij om

methodes te gebruiken die niet worden gebruikt door de mens, of die veel meer berekeningen

vereisen dan waartoe de mens in staat is.

Het probleem van simuleren van artificiele intelligentie bestaat uit verschillende deelproble-

men. Een aantal van deze deelproblemen zoals machine learning en knowledge representation

zullen we later uitgebreid bespreken. Hiernaast zullen we ook een aantal tools bespreken die

kunnen dienen om deze problemen op te lossen. Denk maar aan neurale netwerken en classifiers

waaronder beslissingsbomen en support vector machine.

2.2 Machine learning

Machine learning[2] is een deel van artificiele intelligentie dat zich bezighoudt met algoritmen

die in staat zijn om te leren. Concreet betekent dit dat een algoritme als input een verzameling

data krijgt en informatie afleidt uit de eigenschappen van deze data. Deze informatie stelt het

2.3 Data Mining 4

algoritme in staat om voorspellingen te maken over toekomstige data. Dit is mogelijk door het

feit dat alle niet-gerandomiseerde data patronen bevatten. Om deze patronen te generaliseren

kan de machine een model aanmaken.

Om uit te leggen hoe een model kan aangemaakt worden, kijken we naar volgend voorbeeld.

We beschouwen een e-mail filter. Stel dat de gebruiker veel spam krijgt met de woorden “online

pharmacy”. Een menselijke lezer kan rap concluderen dat elke mail met “online pharmacy”

spam zal zijn en verwijderd zal moeten worden. Dit noemen we generalisatie. Een machine-

learning algoritme zal dezelfde generalisatie kunnen maken nadat de gebruiker verschillende van

deze berichten als spam heeft gemarkeerd.

Er zijn verschillende soorten van machine-learning algoritmen, allen met verschillende voor-

en nadelen. Sommige meer geschikt voor bepaalde problemen dan anderen. Sommige zoals

beslissingsbomen zijn transparant en men is in staat om het denkproces van het algoritme

volledig te begrijpen. Andere algoritmen, zoals neurale netwerken zijn black box. Hiervan is het

denkproces veel moeilijker te achterhalen.

2.3 Data Mining

Onder datamining[3][4][5] verstaan we het opsporen van informatie uit grote datacollecties. Deze

informatie ligt dieper verborgen dan de data die we kunnen vinden via gewone zoekopdrachten.

Datamining technologie levert ons twee mogelijkheden. Langs de ene kan het het automatisch

voorspellen van trends en gedrag, en langs de andere kant automatisch zoeken naar voorheen

ongekende patronen. Datamining wordt vooral gebruikt bij bedrijven om een concurrentie-

voordeel te behalen op verschillende manieren. Bijvoorbeeld om te achterhalen welke producten

vaak samen worden gekocht, bepalen van de populatie die het meest vatbaar is voor bepaalde

promoties,...

Het datamining-proces werkt in verschillende fases. De meest belangrijke fase is een techniek

dat modellering wordt genoemd. Modellering is het opbouwen van een model in een situatie

waar we de antwoorden weten, en het toepassen op een situatie die we nog niet kennen. We

kunnen dit vergelijken met het zoeken naar een gezonken schip: eerst gaan we onderzoeken

waar en wanneer de meeste schepen zijn gezonken, wat de meest gebruikte vaarroutes waren.

Deze informatie gieten we in een model, en dit model gebruiken we dan om te zoeken naar

een gezonken schip. Het gebruiken van zo’n model is iets dat we al veel langer doen, nog voor

het bestaan van computer- of dataminingtechnologie. In onze masterproef zal de gebruiker zelf

een model opbouwen door bepaalde acties uit te voeren op zijn smartphone. We houden dan

bepaalde informatie zoals tijd en plaats bij. Dit model zullen we dan gebruiken om bepaalde

2.4 Supervised versus unsupervised learning 5

acties te voorspellen in een ongekende situatie (namelijk de toekomst). Andere fases in het

datamining-proces zijn het begrijpen van de business, begrijpen van de data (verzamelen van

data en metadata over de data en deze zo goed mogelijk beschrijven, hier kruipt het meeste werk

in), voorbereiden van de data, evaluatie (welke resultaten zijn belangrijk?) en presentatie van

de resultaten. In onze masterproef zullen we gebruik maken van patroonherkenning in plaats en

tijd. Datamining technologie laat ons toe om dit te verwezenlijken. Hiervoor kunnen we enkele

dataminingtechnieken gebruiken die uiteenvallen in drie belangrijke categorieen, namelijk:

• Predictief modelleren Deze technieken hebben als doel om nieuwe data af te leiden

uit bestaande data. Hier hebben we twee fases: een trainingsfase en een toepassingsfase.

In de traningsfase zullen we een model opbouwen en in de toepassingsfase gebruiken we

het opgebouwd model om nieuwe data te voorspellen. Twee belangrijke subcategorieen

zijn hierbij classificatietechnieken en regressietechnieken. Bij classificatietechnieken zal er

tijdens de trainingsfase gebruik gemaakt worden van bijvoorbeeld een beslissingsboom. Bij

regressie zal tijdens de trainingsfase een of meerdere regressieregels worden opgebouwd.

In sommige gevallen is het mogelijk om een regressiefunctie te construeren.

• Datasegmentering en clustering Technieken voor datasegmentering en clustering hebben

als doel de data op te delen in disjuncte segmenten. Alle data die voldoende sterk op elkaar

lijkt, zullen we in hetzelfde segment plaatsen.

• Verwantschapanalyse Hierbij is het de bedoeling om correlaties te vinden tussen ver-

schillende data om zo nieuwe inzichten te verwerven. Deze vorm van kennis wordt dikwijls

gemodelleerd door gebruik te maken van associatieregels. Een associatieregel heeft de

vorm X ⇒ Y en kan geınterpreteerd worden als volgt: als X zich voordoet, impliceert

dit dat ook Y zich voordoet. Een mogelijke toepassing in het licht van onze masterproef

is inzicht te verwerven in het gebruik van applicaties op de smartphone (als de gebruiker

applicatie X veel gebruikt, zal hij wellicht applicatie Y ook willen gebruiken).

2.4 Supervised versus unsupervised learning

Binnen het domein van Artificiele Intelligentie en Machine Learning kunnen we twee klassen

van problemen onderscheiden: supervised en unsupervised learning[7]. Supervised learning algo-

ritmes gebruiken trainingswaarden (voorbeelden van koppels van invoerwaarden en correspon-

derende uitvoerwaarden) om op die manier te leren hoe het voorspellingen moet maken. Er is

hier een onderscheid tussen een leerproces en een operationeel proces. In het leerproces wordt

een verzameling van invoerwaarden en corresponderende uitvoerwaarden geanalyseerd. In het

2.5 Technieken en frameworks 6

operationeel proces wordt enkel invoerdata gegeven en maakt het algoritme een voorspelling op

basis van wat hij geleerd heeft in de trainingsfase. Afhankelijk van het algoritme in kwestie

kunnen deze twee fases los van elkaar uitgevoerd worden of kunnen ze simultaan gebeuren. In

het laatste geval kan bepaalde invoerdata leiden tot een voorspelling, maar kan het daarenboven

ook dienen als trainingsdata voor een toekomstige voorspelling.

Bij unsupervised learning algorithms is er slechts een proces, nl. meteen het operationeel

proces. Er zijn geen voorbeelden van correcte antwoorden. Het algoritme moet een structuur

proberen vinden in een dataset waarbij niets van deze data wijst op een correct antwoord.

2.5 Technieken en frameworks

2.5.1 Clustering

Clustering[5][6] is een subcategorie van technieken voor datasegmentatie. Het is een methode

voor het ontdekken en visualiseren van elementen die een nauwe relatie hebben met elkaar. Een

belangrijk aspect hierbij is om te bepalen in welke mate twee elementen gelijkmatig zijn. Hier-

voor kunnen we een afstandsmaat gebruiken. Een veelgebruikte afstandsmaat is de Euclidische

afstand. Hoe kleiner de afstand tussen twee elementen, hoe meer ze gelijken op elkaar. De

Euclidische afstand tussen twee elementen met n attributen wordt gegeven door de volgende

formule:

d(p, q) =√

(p1 − q1)2 + (p2 − q2)2 + ...+ (pn − qn)2

Waarbij pi de attribuutwaarde van attribuut i van het eerste element voorstelt, en qi de attribu-

utwaarde van attribuut i van het tweede element[7].

K-means-algoritme

Een basisalgoritme voor clustering is het k-means-algoritme[8]. Het partitioneert n element in

k clusters, waarbij elk element wordt toegewezen aan de dichtsbijzijnde cluster. Het algoritme

bestaat uit volgende vier stappen:

• Stap 1: kies willekeurig k records die zullen dienen als kern van de verschillende clusters.

• Stap 2: Wijs ieder element toe aan een clusterkern met de kleinst Euclidische afstand.

• Stap 3: Herbereken voor elke cluster een nieuw centrum. Deze kern hoeft niet noodzakelijk

samen te vallen met een record.


Figuur 2.1: Het resultaat van clustering op een aantal elementen. In deze figuur worden deelementen opgedeeld in vier clusters.

• Stap 4: Herhaal de twee laatste stappen tot de gevonden oplossing stabiel is. Een oplossing

is stabiel indien in stap twee geen elementen meer veranderd zijn van cluster. Men kan

hier ook een andere definitie van stabiel gebruiken.

Dit algoritme heeft als voordeel dat het performant is, waardoor we het kunnen gebruiken

bij grote datasets. Een eerste nadeel is het feit dat het algoritme vereist dat het aantal clusters

op voorhand wordt meegegeven. Dit is echter praktisch gezien niet altijd mogelijk. Een tweede

nadeel is dat het algoritme ook nooit hetzelfde resultaat geeft aangezien we in de eerste stap

willekeurig k kernen hebben genomen. Verschillende verbeteringen voor het k-means-algoritme

bestaan in de literatuur. Een voorbeeld hiervan is het k-means++-algoritme die de startende

kernen beter tracht te kiezen. Een ander voorbeeld is k-medoids-algoritme. Deze biedt een

oplossing aan het feit dat het concept van gemiddelde niet altijd definieerbaar is.

Hierarchisch clusteren

Een belangrijk type van clustering is hierarchisch clusteren. Hierbij wordt een hierarchie uitge-

bouwd door steeds de twee meest gelijksoortige groepen samen te voegen. In het begin bestaat

elke groep uit exact n element. In elke opeenvolgende iteratie wordt de afstand tussen elk paar

berekend. Het paar met de kortste afstand wordt samengevoegd. Het algoritme stopt wanneer

er nog maar een groep overschiet. In Figuur 2.2 zijn elementen die dichter bij elkaar liggen ook

meer gelijksoortig. In de eerste stap worden elementen D en C samengevoegd omdat zij op de

kortste afstand van elkaar liggen. In de volgende stap wordt deze nieuwe groep samengevoegd

met element E. Vervolgens worden elementen A en B samengevoegd omdat zij op dat moment


het dichtst bij elkaar staan. De laatste stap voegt de overschietende groepen samen tot n groep.

A B

CD

E

A B

CD

E

A B

CD

E

A B

CD

E

A B

CD

E

Figuur 2.2: Voorbeeld van hierarchisch clusteren.

Frameworks

Voor clustering zijn verscheidene Java frameworks te vinden. De meest gekende zijn Weka[5],

OpenRDS en Shoal.

2.5.2 Beslissingsbomen

Een beslissingsboom[4][5] is een voorstelling of model van een aantal kennisregels. Het is een

manier om een algoritme in beeld te brengen. Ze kunnen dienen om een besluit te maken op

basis van verschillende eigenschappen van bepaalde data.

Het doel van beslissingsbomen is het voorspellen van een bepaalde variabele op basis van


verschillende inputvariabelen. Een voorbeeld van een beslissingsboom ziet men in Figuur 2.3.

Elke knoop correspondeert met een van de inputvariabelen (een relevant recordveld). Elk blad

representeert de waarde van de outputvariabele gegeven de waarde van de inputvariabelen die

bekomen worden door het pad van de root naar het blad te volgen. Elke tak stelt een of

meerdere toegelaten waarde (een verzameling) voor van het recordveld dat wordt voorgesteld

door de ouderknoop.

vooruitzichten

vochtigheid winderig spelen

spelen niet spelen

niet spelen spelen

zonnig bewolking regen

ja nee<= 60 > 60

Figuur 2.3: Voorbeeld van een beslissingsboom voor het al dan niet spelen van een voetbalmatchbij bepaalde weersomstandigheden

Een boom ”leert” door het splitsen van de bronverzameling in deelverzamelingen gebaseerd

op het testen van de attribuutwaarden. Dit proces wordt op een recursieve manier herhaald op

elke afgeleide deelverzameling. De recursie stopt wanneer de deelverzameling in een bepaalde

knoop overal dezelfde waarde heeft voor de outputvariabele, of wanneer splitsen niet langer een

meerwaarde levert aan de voorspellingen.

Voordelen

• Beslissingsbomen zijn gemakkelijk te begrijpen en te interpreteren.

• Een beslissingsboom is een beknopte voorstelling van een aantal kennisregels.

• Beslissingsbomen kunnen zowel numerieke als categorische data verwerken.

• Algoritmes om beslissingsbomen te construeren presteren goed met grote hoeveelheden

data en zijn robuust.


Nadelen

• Het output attribuut moet categorisch zijn en is gelimiteerd tot een attribuut.

• Het construeren van een optimale beslissingsboom is NP-compleet. Hierdoor zijn de meeste

praktische algoritmes heuristisch. Dit soort algoritmes kunnen niet garanderen om een

globaal optimale beslissingsboom te berekenen.

Frameworks

Voor beslissingsbomen kan gebruik gemaakt worden van hetzelfde Java framework als voor

clustering, nl. Weka[5].

2.5.3 Support Vector Machines

Support vector machines (SVM)[9][10] zijn een verzameling van supervised learning methodes

voor regressie-analyse en classificatie van data. Een support vector machine zal classificatie

uitvoeren door het construeren van een N-dimensionale hyperplane die de data opdeelt in twee

categorieen. Gegeven een trainingsset waarbij elk element is opgedeeld in een van de twee cate-

gorieen, zal een SVM-trainingsalgoritme een model bouwen dat elk nieuw element kan toewijzen

aan de juiste categorie. Een SVM model is een representatie waarbij de elementen punten in een

ruimte zijn. In deze ruimte zoeken we een hyperplane die zo ver mogelijk ligt van beide klassen.

Dit noemen we de maximum-margin hyperplane. In 2-dimensionale ruimten zijn de hyperplanes

gewone lijnen. Laten we een voorbeeld veronderstellen waar er twee predictor variabelen zijn.

We plotten de waarden van de ene predictor op de x-as, en de andere op de y-as waarbij we de

ene categorie voorstellen als niet-opgevulde bollen en de andere categorie als opgevulde bollen.

In Figuur 2.4 zien we twee mogelijke plaatsingen van de opdelende lijn. De vraag is nu welke

lijn de beste opdeling maakt. SVM zal de lijn kiezen die ervoor zorgt dat de parallelle lijnen

die de elementen van de verschillende categorieen aanraken zo ver mogelijk van elkaar staan.

Met andere woorden de lijn die de marge (afstand tussen de parallelle lijnen) maximaliseert.

De elementen die de marge afgrenzen noemen we de support vectors. Een algoritme die deze

support vectors zoekt, en deze gebruikt om de maximum-margin hyperplane te vinden, is de

support-vector machine. Een nieuw element wordt dan toegewezen aan een categorie door te

kijken aan welke kant van de lijn (of hyperplane) het element zich bevindt.

Support vector machines werken goed met hoog-dimensionale datasets. Ze worden veel ge-

bruikt in wetenschappelijke problemen die data-intensief zijn en andere problemen met complexe

datasets. SVM heeft toepassingen in de bio-informatica, herkennen van handschriften, classifi-

ceren van gezichtsuitdrukkingen en anderen.


Figuur 2.4: Voorbeeld van twee mogelijke plaatsingen van de opsplitsende lijn bij een SVM

Marge

Support vectors

Figuur 2.5: Voorbeeld van de maximum-margin hyperplane en de marge bij een SVM

Frameworks

Een gekend Java framework voor support vector machines is LibSVM.

2.5.4 Neurale netwerken

Tegenwoordig wordt gewoon de term neuraal netwerk gebruikt om een artificieel neuraal netwerk

aan te duiden[11][12]. Neurale netwerken zijn opgebouwd uit eenvoudige eenheden (neuronen),

die met elkaar verbonden zijn door connecties met bepaalde gewichten (connection weights). Elk

neuron stelt een patrooneigenschap voor dat we willen analyseren of voorspellen. Het netwerk


is in staat zichzelf adaptief aan te passen door de gewichten van de connecties te wijzigen.

Door de gewichten aan te passen kan het netwerk dingen aanleren. Elk neuron bezit zijn eigen

lokaal geheugen en kan enkel werken op zijn eigen lokale data en op de invoer dat het krijgt

via de connecties. Tijdens het leerproces zal het netwerk bepaalde patronen of structuren leren

kennen door aan de hand van voorbeelden (koppels invoer en corresponderende uitvoer) zichzelf

te corrigeren en de gewichten voortdurend aan te passen. Neurale netwerken leren dus aan de

hand van voorbeelden, net zoals kinderen in het dagelijks leven het verschil tussen een auto en

een fiets leren kennen. Een neuraal netwerk neemt gewoonlijk de volgende structuur aan:

Input1

Input2

Input3

Hidden1

Hidden2

Hidden3

Output1

Output2

Output3

Input

Layer

Hidden

Layer

Output

Layer

Figuur 2.6: Structuur van een neuraal netwerk

De neuronen worden onderverdeeld in bepaalde lagen:

1. Een input layer Deze laag krijgt de data binnen die moet geanalyseerd worden.

2. Een output layer Deze laag bevat de uiteindelijke uitvoer.

3. Nul of meerdere hidden layers Deze lagen verwerken de data uit een vorige laag en

geven ze door aan een volgende laag. Deze lagen worden hidden layers genoemd omdat ze

verborgen blijven voor de externe omgeving die enkel communiceert met de input layer en

de output layer. Je kan zoveel mogelijk verborgen lagen achter elkaar plaatsen als nodig.

Het is ook mogelijk dat er geen hidden layers zijn.

Deze structuur laat toe om verbanden te vinden tussen invoer- en uitvoerdata of patronen

te ontdekken in de invoerdata. Neurale netwerken zijn uitermate geschikt voor parallellisme,

omdat de bewerkingen in neuronen grotendeels onafhankelijk gebeuren van andere neuronen.


Dit is een belangrijk voordeel wanneer een algoritme moet worden gekozen dat dient te werken

met beperkte resources.

Basisschema

De basiselementen van een neuraal netwerk zijn de neuronen. Een voorbeeld zie je in Figuur

2.7. Een neuron kan in twee modes functioneren: een trainingsmode en een operationele mode

Neuron

i1

Transfer functionf()i2

i3

o f(o)

trainingsinvoer

Figuur 2.7: Werking van een neuron

(beide modes kunnen ook gelijktijdig in werking zijn). Tijdens de trainingsmode kan een neuron

getrained worden om een fire te sturen voor een bepaalde invoer. Wanneer een invoerpatroon

ontdekt wordt bij de ingang van een neuron, wordt gekeken of het patroon een reeds gekend

invoerpatroon is. Indien het invoerpatroon reeds gekend is, dan vormt de uitvoer van het gekend

patroon de huidige uitvoer. Indien het invoerpatroon nieuw is dan zal het patroon vergeleken

worden met gelijkende patronen die gekend zijn en zal daaruit beslist worden of er al dan niet

een fire wordt gestuurd. Nemen we als voorbeeld een patroon van 3 cijfers (i1i2i3) zoals in

Figuur 2.7. Stel dat we het neuron leren om een fire (uitvoer 1) te sturen bij het patroon 111

en geen fire (uitvoer 0) bij het patroon 000. Indien het neuron dan nadien het patroon 100 als

invoer krijgt kan beslist worden om uitvoer 0 te sturen omdat 100 dichter aanleunt tegen 000

dan tegen 111.

Toevoegen van gewichten

Het schema in Figuur 2.7 is zeer beperkt. Om complexere verbanden te kunnen ontdekken

maakt men gewoonlijk gebruik van gewichten (Figuur 2.8). De verschillende invoerwaarden

worden nu gewogen zodanig dat elke beslissing ook afhangt van het gewicht van de waarde.

Wanneer we elke waarde vermenigvuldigen met het corresponderend gewicht en optellen krijgen


Neuron

i1

Transfer functionf()i2

i3

o f(o)

trainingsinvoer

w1

w2

w3

Figuur 2.8: Gebruik van gewichten bij een neuron

we een totale gewogen activatiewaarde. Deze waarde wordt vervolgens getransformeerd door de

transfer function en dit zorgt voor de eigenlijke uitvoer. Een voorbeeld van een mogelijke transfer

function is de threshold function: enkel indien de activatiewaarde een bepaalde drempelwaarde

overschrijdt, zal de neuron een fire (uitvoer 1) sturen. In het andere geval wordt er geen fire

gestuurd (uitvoer 0 of -1). Andere mogelijke transfer functions zijn de lineaire functie en de

Gaussiaanse functie.

Gebruik van neurale netwerken

Neurale netwerken worden in de praktijk vooral gebruikt voor classificatieproblemen en patroon-

herkenning. Een klassiek voorbeeld is het identificeren van een object of persoon aan de hand

van een foto. Invoerwaarden van het netwerk kunnen hier dan de RGB-kleurtabellen van de

verschillende pixels zijn terwijl de uitvoerklassen objecten of personen zijn. Een ander domein

waar neurale netwerken vaak voor gebruikt worden is het domein van regressie voor het vinden

van complexe relaties tussen invoer- en uitvoerwaarden. Over het algemeen kan een neuraal

netwerk het best zijn nut bewijzen bij problemen waarbij:

• de complexiteit van het probleem te hoog is om het door snelle en eenvoudige regels te

laten oplossen

• er voldoende invoerdata aanwezig is (de RGB-waarden van alle pixels in een foto levert

gewoonlijk duizenden invoerwaarden op)

Beperkingen

Een beperking van het standaard neurale netwerk vloeit voort uit het feit dat de leermethode

supervised is. De leerfase is een onmisbare stap in het algoritme van een neuraal netwerk.


Bijgevolg is het ook onmogelijk om data te gaan voorspellen die niet in de trainingsset bevat

is. Het neuraal netwerk moet dus altijd eerst getrained worden om een bepaald patroon te

herkennen.

Frameworks

Voor neurale netwerken werden twee belangrijke frameworks gevonden: Neuroph en Encog.

2.5.5 Regelgebaseerde systemen

Regelgebaseerde systemen[13] bestaan uit een lijst van regels die door een engine verwerkt wor-

den. De uitvoerende instructies worden afgeleid uit een lijst van data en regels. Dit is in tegen-

stelling met imperatieve programmeertalen waar de instructies in volgorde worden uitgevoerd.

Een groot voordeel hierbij is dat de kennisregels gemakkelijk kunnen aangepast worden door

externe personen (via een GUI). Een regelgebaseerd systeem bestaat meestal uit vier basis-

componenten. Deze componenten zijn onafhankelijk van elkaar, ze kunnen onderling vervangen

worden.

• Een lijst van regels of een regelbank (permanente data).

• Een interference engine of een semantic reasoner. Deze leidt informatie af of neemt acties

op basis van de input en regelbank. De interpreter voert een programma uit door het

navolgen van een match-resolve-act cyclus.

– Match: in deze eerst fase wordt de linkerkant van alle producties gematched tegen-

over de inhoud van het werkgeheugen. Resultaat is een conflict set die bestaat uit

de instanties van alle voldane producties. Een instantie van een productie is een

geordende lijst van werkgeheugenelementen die voldoen aan de linkerkant van de

productie.

– Conflict-Resolution: in deze tweede fase wordt een van de productie-instantiaties

in de conflict set gekozen om uitgevoerd te worden. Indien er geen producties worden

voldaan zal de interpreter stoppen.

– Act: in de laatste en derde fase worden de acties die in de vorige fase zijn gekozen

effectief uitgevoerd. Aan het eind van deze fase wordt er overgegaan naar de eerste

fase.

• Tijdelijk werkgeheugen (tijdelijke data).


• Een (grafische) user interface of andere connectie naar de buitenwereld toe. De user in-

terface bevindt zich tussen de user en de interference engine. Het vertaalt het antwoord

komende van het systeem dat is opgeslagen als een interne representatie naar iets dat

begrijpbaar is voor de gebruiker. De user interface staat ook in voor het doorgeven van

vragen naar de gebruiker en het controleren van de antwoorden (zoals bijvoorbeeld het

controlen op een negatief getal bij het vragen naar een leeftijd). Deze component behoort

in principe niet tot het basic reasoning proces, maar is praktisch gezien wel essentieel.

Kennis wordt opgeslagen als regels in de regelbank en zijn van de vorm

IF some condition THEN some action

In de conditie wordt het tijdelijk werkgeheugen getest. Bijvoorbeeld het aanwezig zijn van

bepaalde symbolen of patronen van bepaalde symbolen. In veel systemen worden de expressies

uitgedrukt als conjuncties, disjuncties of predikaten. In sommige systemen komen de condities

overeen met sensordata. Een actie kan uiteenlopend zijn, bijvoorbeeld een symbool of verza-

meling van symbolen verwijderen van of toevoegen aan het werkgeheugen. Ook acties zonder

betrekking op het werkgeheugen zijn mogelijk, zoals het aanzetten van een motor of uitprinten

van data.

In onze masterproef zou een kennisregel er als volgt kunnen uitzien:

IF

time = ‘13:00’ AND place = ‘dendermonde’ AND day = ‘saturday’

THEN

SET currentProfile = ‘HOME’

Dit systeem kan op zichzelf ook leren, wat zou betekenen dat bijvoorbeeld na enkele weken

het systeem geleerd heeft dat

IF

time between ‘13:00’ and ‘21:00’ AND place = ‘dendermonde’ AND day=‘saturday’

THEN

SET currentProfile = ‘HOME’

en het aldus zijn eigen regels zelf kan aanpassen.


Deze regel lijkt sterk op een if-then-else statement, maar verschilt in het feit dat een regel

alleen staat, en een if-then-else statement in een bepaalde volgorde wordt uitgevoerd ten opzichte

van andere if-then-else statements. Het voordeel hierbij is dat de regels gemakkelijk kunnen

worden aangepast, zonder dat dit invloed heeft op de rest van het systeem.

Regelgebaseerde systemen hebben een belangrijke rol voor het implementeren van expertsys-

temen (expertsystemen moeten echter niet noodzakelijk regelgebaseerd zijn). Een expertsysteem

is een computer programma dat de prestatie van een expert in een bepaald domein of intellectuele

expertise kan bereiken. Een expertsysteem kan bijvoorbeeld als hulpstuk gebruikt worden voor

een dokter om een diagnose te maken op basis van een aantal symptomen. Expertsystemen

hebben een aantal belangrijke voor- en nadelen.

In vergelijking met traditionele programmeertechnieken leveren expertsystemen flexibiliteit.

De regels kunnen gemodelleerd worden op basis van data in plaats van code. Hierdoor is het ook

gemakkelijk voor mensen met minder technische vaardigheden om aanpassingen te maken. In

praktijk worden expertsystemen gebruikt als aanvulling van de traditionele programmeertech-

nieken. Deze hybride aanpak laat toe om de sterktes van beide aanpakken te combineren. Rule

engines laten controle toe door middel van programma’s (user interfaces) geschreven in tradionele

programmeertalen aangevuld met de noodzakelijke functionaliteiten zoals interoperabiliteit met

hedendaagse databasetechnologie. Een nadeel van expertsystemen is dat ze enkel zinnige infor-

matie leveren wanneer zij met een aanzienlijke hoeveelheid correcte informatie wordt gevoed.

Wanneer de geleverde informatie onjuist is, zal het nooit een zinnig resultaat kunnen genereren.

Frameworks

De belangrijkste Java framework voor regelgebaseerde systemen is Drools. Dit framework is

ontwikkeld voor compilatie op een JVM. Android gebruikt echter zijn eigen virtuele machine

(Darvik). Normaalgezien zouden we dan de sources zelf kunnen compileren via de Darvik com-

piler in plaats van de jar toe te voegen, maar het probleem bij regelgebaseerde systemen ligt in

het feit dat tijdens het uitvoeren nieuwe code wordt toegevoegd aan het programma en er met

andere woorden ook nieuwe klassen moeten worden gecompileerd. Dit werkt echter niet wegens

de verwarring tussen de verschillende compilers. Op de compileerproblemen voor libraries komen

we later nog terug. Andere frameworks voor regelgebaseerde systemen zijn JEOPS, OpenRules

en AndrMate, maar deze werken momenteel echter evenmin op Android.

2.6 Stability Plasticity Dilemma 18

2.5.6 Verwantschapsanalyse

Verwantschapsanalyse[14] heeft als doelstelling om correlaties te vinden tussen verschillende

variabelen in een (grote) databank. Deze kennis wordt gemodelleerd door middel van associ-

atieregels. Een voorbeeld van een associatieregel zoals het kan gebruikt worden in een winkel:

{boter, brood} ⇒ melk

Dit betekent dat wanneer een klant boter en brood koopt, deze ook melk zal kopen. Ver-

wantschapsanalyse heeft toepassingen op verschillende gebieden: het kan gebruikt worden bij de

behandeling en evolutie van ziekten (als de symptomen X zich voordoen, dan ook symptomen

Y), inzichten te verwerven in bepaalde processen (als condities X zich voordoen, zullen prob-

lemen Y optreden), of bij het bepalen van voorwaarden om een doelstelling te bereiken (welke

X zijn vereist om een contract te kunnen verkopen). Opdat een associatieregel zinvol zou zijn,

dient er aan twee voorwaarden voldaan te zijn. Allereerst moet de itemset (dit zijn alle items

die voorkomen in de regel) van de associatieregel voldoende frequent voorkomen in de databank.

Om dit te bepalen, berekent men de support van de itemset. De tweede voorwaarde drukt uit

dat er voldoende vertrouwen moet zijn in de associatieregel. Om dit te bepalen, berekent men de

confidence van de associatieregel. Om een betrouwbare associatieregel te vinden dient de drem-

pelwaarden voor beide voorwaarden voldoende hoog gekozen te worden. Een basisalgoritme

voor de generatie van associatieregels bestaat uit de volgende twee stappen:

• Men gaat op zoek naar alle frequente itemsets, dit doet men door alle itemsets te beschouwen

waarbij de support hoog genoeg is. Een algoritme die deze stap efficient uitvoert is het A

Priori-algoritme.

• Met deze frequente itemsets gaan we associatieregels vormen. Enkel de associatieregels die

een voldoende hoge confidence hebben gaan we behouden.

Frameworks

Voor verwantschapsanalyse kunnen we terug gebruikmaken van het Weka-framework[5].

2.6 Stability Plasticity Dilemma

Een belangrijke dilemma binnen het domein van data mining is het Stability Plasticity Dilemma[15].

Hierbij stelt men de vraag hoe een systeem oude herinneringen kan onthouden maar tegelijkertijd

ook nieuwe herinneringen kan bijleren. De eerste vereiste waar een systeem aan moet voldoen

2.6 Stability Plasticity Dilemma 19

is dat het zowel nieuwe herinneringen moet kunnen bijleren als oude herinneringen (die men

zogezegd vergeet) moet kunnen afleren (Plasticity). Bij het aan- en afleren zou het systeem al

snel instabiel kunnen worden (irrelevante dingen leren, veel te veel vergeten, belangrijke zaken

vergeten). Dit vermijden vormt de tweede vereiste (Stability). Vaak is het moeilijk om deze twee

vereisten tegelijkertijd te realiseren en voldoet een systeem maar aan een vereiste, waardoor het

een ’dilemma’ genoemd wordt.

Wij moeten proberen om het Stability Plasticity Dilemma te vermijden in onze applicatie.

Bij de identificatie van profielen is het belangrijk dat de bestaande profielen die het systeem

stap voor stap heeft opgebouwd niet plotseling verdwijnen of drastisch veranderen (Stability).

Anderzijds is het even belangrijk dat het systeem geen applicaties aanbeveelt die een gebruiker

5 jaar geleden veel gebruikte, maar nu nooit meer (Plasticity). Ons systeem moet dus aan beide

vereisten voldoen.

ANDROID 20

Hoofdstuk 3

Android

3.1 Android Software Stack

De android software stack bestaat uit verschillende componenten[16][17]:

• Linux Kernel Behandelt de core services en biedt een abstractielaag tussen de hardware

en de rest van de stack.

• Libraries Op de kernel draaien een aantal bibliotheken waaronder:

– SQLite Voor native database ondersteuning.

– SSL en WebKit Voor een geıntegreerde webbrowser en internetveiligheid.

– Graphics libraries Bijvoorbeeld OpenGL voor 2D en 3D graphics.

• Android Run Time Dit is de engine dat de applicaties aanstuurt en vormt samen met

de libraries de basis voor het application framework.

• Application Framework Biedt de klassen aan die nodig zijn om een applicatie te maken

op Android. Het is ook een abstractie naar de hardwarelaag toe en beheert de user interface

en de gebruikte resources van applicaties.

• Applications Kunnen zowel native als third party zijn. Voorbeelden hiervan zijn email

client, SMS programma, browser,...

3.2 Activities

De activity component vormt de basis voor alle user interface displays. Voor elk nieuw scherm

dat zichtbaar moet zijn voor de gebruiker dient er een nieuwe activity aangemaakt te worden.

3.2 Activities 21

Figuur 3.1: Android architectuur.

Android applicaties hebben niet zelf de controle over hun eigen proces. De android run time

beheert het proces van elke applicatie, en dus ook elke activiteit hiervan.

Activities in het systeem worden beheerd door de activity stack. Het is een last-in-first-out

collectie van alle lopende activiteiten. Wanneer een nieuwe activiteit wordt gestart, wordt het

scherm dat momenteel in de voorgrond staat op een stack geplaatst. Wanneer de gebruiker

teruggaat via de Back button, of de huidige activiteit afsluit zal de volgende activiteit op de

stack actief worden.

Elke activiteit kan zich in vier mogelijke standen bevinden:

• Active Wanneer een activiteit zich op de top van de stack bevindt, staat ze op de voor-

grond van het scherm en heeft ze de focus. Android zal de activiteit levende houden ten

koste van activiteiten die zich lager op de stack bevinden. Wanneer een andere activiteit

actief wordt, zal deze zich pauzeren.

• Paused Wanneer de activiteit nog steeds in de voorgrond staat, maar geen focus heeft

bevindt ze zich in de paused state. Een gepauseerde activiteit gedraagt zich zoals een

actieve activiteit, maar het ontvangt geen user input events meer. Enkel wanneer het

systeem extreem weinig geheugen over heeft, zal deze activiteit worden gekilled.

• Stopped Wanneer een activiteit niet meer zichtbaar is, zal ze stoppen. De activiteit zal in

het geheugen blijven, maar van zodra het systeem meer geheugen wenst, zal de activiteit

worden afgesloten.

• Inactive Nadat een activiteit is gekilled en voordat ze is gelaunched, is ze inactief. Wan-

3.3 Services 22

neer ze terug aan de gebruiker wordt getoond, moet ze eerst herstarten en herstellen naar

de vorige staat.

Het is de bedoeling om al deze transitities onzichtbaar voor de gebruiker uit te voeren. De

gebruiker zou het verschil niet mogen zien tussen een activiteit die van paused, stopped of een

killed state naar een actieve state gaat.

3.3 Services

Activities bieden een grafische interface aan de gebruikers, services lopen in de achtergrond

en houden zich bezig met het afvuren van Intents, updaten van Content Providers,... Ze zijn

de beste manier voor het uitvoeren van code en het afhandelen van events zelfs nadat alle

activities van de applicatie onzichtbaar, inactief of afgesloten zijn. Dit alles zonder input van

de gebruiker te verwachten. Gestarte services hebben een hogere prioriteit dan inactieve of

onzichtbare Activities. Hierdoor is de kans kleiner dat ze worden gekilled door de Android run

time resource management. Android zal enkel een service stoppen wanneer het de enige manier

is voor een activiteit in de voorgrond om aan zijn memory resources te komen. Wanneer dat

gebeurt zal de service zich later automatisch herstarten.

3.4 Intents

Intents binnen android worden gebruikt om bepaalde berichten door te geven. Het bevat in-

formatie die interessant kan zijn voor de ontvangende component (actie die moet worden uit-

gevoerd, meestal samen met bepaalde data). Intents kunnen gebruikt worden om interactie

te voeren tussen verschillende componenten van verschillende applicaties. Dit maakt van een

collectie onafhankelijke componenten een samenhangend geheel. Met intents is het mogelijke

om nieuwe activiteiten te starten. Dit kan zowel expliciet (door aan te geven welke klasse moet

ingeladen worden) als impliciet (door het verzoeken van een actie op bepaalde data). Daarnaast

kunnen intents gebruikt worden voor het zenden van broadcast berichten over het ganse systeem.

Elke applicatie kan zich registreren voor broadcasts. Android gebruikt deze broadcast intents

voor het aankondigen van systeem eventen zoals het binnenkomen van een telefoonoproep of het

ontvangen van een SMS.

3.5 Widget 23

3.5 Widget

Een widget is een applicatie die zichtbaar is vanaf het hoofdscherm. Ze zijn ideaal om bepaalde

informatie steeds zichtbaar te hebben, zoals bijvoorbeeld ongelezen mails of een kleine kalender.

Gebruikers kunnen zelf bepalen welke widgets ze op hun homescreen willen hebben en waar. In

onze widget tonen we zes applicaties (door middel van een icoontje) waarop de gebruiker kan

drukken. Ze staan in de vorm van een pyramide. Applicaties die hoger staan hebben een hogere

recommendatiewaarde.

3.6 REST vs SOAP

Voor het implementeren van webservices op Android bestaan er ruwweg gezien twee verschillende

opties, namelijk REST en SOAP. REST[18][19] staat voor Representational State Transfer en is

een software-architectuur voor gedistribueerde hypermediasystemen zoals het World Wide Web.

Elke unieke URL is een representatie van een object. De meeste bedrijven die de REST API

gebruiken zijn er nog niet zo lang. REST is dus duidelijk een nieuwe trend onder de webservices.

SOAP[20] is een protocol om gestructureerd informatie uit te wisselen tussen verschillende

componenten. Het maakt gebruik van XML om berichten te sturen, meestal over HTTP. De

berichten die worden gestuurd worden vastgelegd in een bestand gedefinieerd in WSDL. Dit staat

voor Web Services Description Language en biedt een XML-taal om interfaces van webservices

te beschrijven.

Al reeds van vorig jaar heeft Google besloten om hun SOAP webservice stop te zetten[21].

Het is moeilijk te zeggen waarom, maar waarschijnlijk wil Google overstappen naar een REST

aanpak. Dit heeft te maken met de verschillende voordelen van REST tegenover SOAP.

• Betere performantie doordat het uitwisselformaat (JSON tegenover XML) veel eenvoudiger

is. XML is namelijk niet geschikt voor data-uitwisseling. JSON heeft een veel kleinere

grammair en komt beter overeen met de datastructuren die in de meeste programmeertalen

worden gebruikt.

• REST biedt betere antwoordtijd en belast de server minder door gebruik te maken van

caching.

• REST heeft een eenvoudige aanroep voor leesacties die URL gebaseerd is. Dit maakt REST

dan ook beter testbaar omdat niet eerst een POST-bericht dient gestuurd te worden.

• REST interfaces zijn makkelijker te implementeren dan SOAP interfaces. Verbs, exception

3.7 Compilatieproblemen met libraries op Android 24

semantics, caching semantics, versioning semantics, authentication en access control zijn

allen reeds gedefinieerd bij REST.

Om de REST-client werkende te krijgen op Android maken we gebruik van de Spring An-

droid Rest Template Module[27]. Deze verschaft ons een RestTemplate object die werkt in een

Android omgeving. Dit object is het hart van de Spring Android Rest Template library. Wan-

neer een nieuwe instantie van RestTemplate wordt gemaakt, zal de constructor verschillende

ondersteunende objecten aanmaken die samen instaan voor de RestTemplate functionaliteit.

Om objecten uit te wisselen via de webservice maken we gebruik van JSON marshalling. Een

third party bibliotheek die deze functionaliteit verschaft is de Jackson JSON Processor.

3.7 Compilatieproblemen met libraries op Android

In onze masterproef zal gebruik gemaakt worden van technieken zoals clustering. Hiervoor

maken wij gebruik van third party Java bibliotheken. Sommige van deze bibliotheken weigerden

echter te compileren op Android. Dit werd veroorzaakt door Dalvik, de virtuele machine van

Android.

Dalvik is een virtuele machine die geoptimaliseerd is voor beperkte geheugen- en verwerk-

ingscapaciteiten. De Dalvik virtuele machine kan echter enkel eigen byte code uitvoeren. De

standaard Java byte code dient dus eerst te worden omgezet. Deze omzetting gebeurt typisch

automatisch achter de schermen tijdens het compileren. Dit gebeurt echter niet altijd zonder

problemen: sommige klassen zoals Java AWT en Swing bibliotheken kunnen niet geconverteerd

worden naar Android. De IDE die wij gebruikten, namelijke Eclipse, gaf niet altijd aan waar

het probleem lag waardoor het werkende krijgen van zo’n bibliotheek onvermijdelijk samengaat

met veel uitproberen en giswerk.

EVALUATIE VAN TECHNIEKEN 25

Hoofdstuk 4

Evaluatie van technieken

4.1 Algemeen

De verschillende technieken uit onze literatuurstudie hebben elk hun voor- en nadelen wanneer

ze gebruikt worden voor bepaalde doeleinden. De belangrijkste overwegingen zijn de toepas-

baarheid op onze probleemstelling en de performantie wanneer we de technieken wensen te

gebruiken op een Android mobiel toestel. Echter, deze performantie is meestal afhankelijk van

de doelstelling die met de techniek moet bereikt worden. Bovendien bestaan voor de meeste

technieken veel verschillende algoritmes en implementatiewijzen. De technieken werden daarom

geevalueerd in functie van het doel dat we voor ogen hebben. Dit doel omvat twee belangrijke

use cases:

• Het ontdekken van structuur (bvb. profielen) in de ongestructureerde getraceerde data

• Het ontdekken van patronen in het gebruik van de applicaties

Bovendien moesten er nog een aantal belangrijke overwegingen in ons achterhoofd gehouden

worden:

• Is het algoritme gesuperviseerd, met andere woorden is er een duidelijk verschil tussen een

trainingsfase en een operationele fase?

• Indien gesuperviseerd, dienen de fases elkaar op te volgen of kunnen ze door elkaar gebruikt

worden?

• Kunnen de resultaten van de fases real-time gegenereerd worden of niet?

• Zijn iteratieve trainingen mogelijk?

Uit de evaluatie van de technieken en de overwegingen bleek dat we de eerste use case best

oplossen via clusteralgoritmes en de tweede use case via verwantschapsanalyse.

4.2 Clustering 26

4.2 Clustering

Voor het ontdekken van enige structuur in de initieel ongestructureerde data hebben we een

ongesuperviseerde methode nodig. De bedoeling is immers dat we een systeem ontwikkelen dat

zo intuıtief mogelijk is en waarbij de gebruiker van het toestel weinig input zal geven. Bovendien

dient het systeem gepersonaliseerd en contextafhankelijk te zijn waardoor we de applicatie niet

vooraf kunnen trainen met andere data. Hiervoor zullen we clustering[5] gebruiken.

Het doel van clustering is namelijk om op een ongesuperviseerde wijze structuur te vinden

in data waar men geen a priori kennis over heeft. Indien we de getraceerde data beschouwen

weten we niets over het lidmaatschap van de punten tot bepaalde klassen. Wat we wel kunnen

zeggen is dat er bepaalde punten bij elkaar zullen horen en bepaalde punten niet bij elkaar zullen

horen. Clustering gaat op zoek naar de punten die bij elkaar horen, dit noemt men een cluster.

We zullen op deze manier dan ook op zoek gaan naar de profielen uit onze probleemstelling.

4.2.1 Competitieve netwerken

Competitieve netwerken[22] zijn ongesuperviseerde neurale netwerken voor het categoriseren

van invoersequenties. De neuronen in een dergelijk netwerk zullen tegen elkaar vechten om

een fire te sturen, vandaar de naam competitief netwerk. Dit gebeurt via een winner-take-all

(WTA) leerregel. Voor elke invoer die een neuron krijgt zal het beter reageren dan de vorige

keer door zelf z’n gewichten aan te passen. Op die manier is een competitief netwerk in staat

om invoerdata op te splitsen in clusters waarbij de similariteit in eenzelfde cluster groter is dan

tussen verschillende clusters onderling. De similariteit wordt bepaald door een metriek waarvoor

vaak de Euclidische afstand wordt gebruikt.

Het grote voordeel van competitieve netwerken is dat ze ongesuperviseerd zijn. Dit laat toe

dat ze in de data afkomstig van het mobiel toestel clusters kunnen ontdekken zonder supervisie

of toedoen van de gebruiker. Het grote nadeel echter is dat de output nodes op voorhand gekend

moeten zijn. Dit betekent dat het aantal clusters op voorand dient gekend te zijn en dat er geen

mogelijkheid is om nieuwe clusters toe te voegen indien dat nodig zou zijn. Bovendien garandeert

een dergelijk netwerk ook geen stabiliteit van de clusters.

4.2.2 Adaptive Resonance Theory

De Adaptive Resonance Theory (ART)[15] ontwikkeld door Stephen Grossberg en Gail Carpen-

ter is een theorie dat een aantal neurale-netwerkmodellen voor patroonherkenning en predic-

tie beschrijft. In tegenstelling tot de competitieve netwerken zijn de ongesuperviseerde ART-

netwerken (ART1, ART2, ART3, ...) in staat om op een adaptieve wijze stabiele clusters te

4.2 Clustering 27

genereren. ART is speciaal ontwikkeld om het Stability Plasticity dilemma (zie sectie 2.6) te

vermijden in intelligente systemen.

Het ongesuperviseerd standaardmodel van ART is afgebeeld in Figuur 4.1. Dit model bevat

ﾲ

Comparison FieldF1 Layer

Recognition FieldF2 Layer

ResetModule

VigilanceParameter

p

. . . . . .

. . . . . .

. . . . . .

z w

Normalized Input

Reset F2

Figuur 4.1: ART standaardmodel

naast twee verzamelingen van gewichten de volgende componenten:

• Comparison field Dit veld bestaat uit neuronen die een eendimensionale invoervector

transformeren tot de best mogelijke match in het recognition field.

• Recognition field Dit veld bestaat uit neuronen die de kwaliteit van het neuron z’n

match met de invoervector vergelijken en volgens die kwaliteit hun uitvoer en gewichten

aanpassen.

• Vigilance parameter Deze parameter bepaalt of het patroon kan geclassificeerd wor-

den in een bestaande cluster of dat er een nieuwe cluster moet gegenereerd worden. Hoe

hoger deze parameter wordt ingesteld, hoe groter het aantal clusters en hoe meer gede-

tailleerd de geheugenherinneringen zullen zijn. Hoe lager de parameter, hoe algemener de

herinneringen en hoe lager het aantal clusters.

• Reset module De Reset module is de component die de match vergelijkt met de vigilance

parameter. Afhankelijk of het resultaat boven of onder een drempel is zal de specifieke

neuron aan- of uitgeschakeld worden om bij te leren. Op deze manier kan de graad van

similariteit worden bepaald tussen patronen die tot eenzelfde cluster behoren. Anderzijds

wordt de granulariteit van de clusters hierdoor bepaald.

Het ART-netwerk kan aldus de meest nabije cluster van een patroon bepalen en nadien de cluster

aanpassen om zich dichter bij het patroon te bevinden. De sterkte van ART zit in de capabiliteit

4.2 Clustering 28

om het aantal clusters zelf adaptief te bepalen. Wanneer een patroon niet genoeg lijkt op een

van de bestaande clusters wordt een nieuwe cluster gegenereerd.

Het nadeel van ART is dat het basisnetwerk (ART1) enkel eendimensionale vectors van

binaire waarden aanneemt. Hierdoor wordt het moeilijk om de complexe data die we hebben te

gebruiken als invoer. Er werd geen manier gevonden om deze data efficient om te zetten naar het

gewenste formaat voor ART1. Over de andere ART-modellen is bovendien weinig informatie te

vinden momenteel. Daarom bespreken we in de volgende sectie een algoritme dat meer geschikt

is voor onze scriptie: het EM-algoritme.

4.2.3 Expectation-Maximization algoritme

Het Expectation-Maximization (EM)[25] algoritme is een algoritme om de maximum likelihood

of de meest aannemelijke schatter te zoeken van opgegeven parameters. Gegeven een bepaalde

steekproefuitkomst en de (onbekende) parameters van de onderliggende distributies zal EM de

waarden van de parameters zoeken (of schatten) waarvoor de aannemelijkheidsfunctie maximaal

is. Dit betekent dat het EM-algoritme de kans van een steekproefuitkomst maximaliseert door

de onbekende parameterwaarden te zoeken die tot deze uitkomst leiden.

Stel dat we in ons geval een dataset hebben van gemonitorde gegevens op een smartphone.

Om de zoveel tijd wordt er bijvoorbeeld getraceerd op welke plaats we zijn (lengtegraad en

breedtegraad), wat onze huidige snelheid is, enzoverder. De clusters die we in dit geval willen

terugkrijgen bij het clusteren van de dataset maken gewoonlijk deel uit van een onbekende

distributiefunctie. Indien we met de trein naar het werk en terug rijden en de getraceerde punten

van lengtegraad en breedtegraad uitplotten in een tweedimensionaal vlak, dan vormen dit geen

arbitraire punten. De punten vormen daarentegen een datasample van een bepaalde functie die

onbekend is. Elke functie wordt gedefinieerd door bepaalde parameters. Wat het EM-algoritme

doet is niets anders dan het zoeken van de optimale parameterwaarden zodat de uitkomst het

meest aannemelijk lijkt. Wanneer dit bovendien kan gedaan worden voor meerdere functies door

elkaar dan zoekt het EM-algoritme uit een dataset de meest aannemelijk distributiefuncties en

kan het alle datapunten toekennen aan een van de functies. Wanneer we de functies en hun

bijhorende punten interpreteren als clusters dan is dit is per definitie clustering. In Figuur 4.2

en Figuur 4.3 wordt de sterkte van het algoritme duidelijk.

Normaaldistributies

In kansrekening wordt vaak de normaalverdeling of Gaussiaanse verdeling gebruikt als eerste

benadering om willekeurige reele variabelen aan te duiden die zich enigszins rond een gemiddelde

4.2 Clustering 29

Figuur 4.2: Expectation-Maximization algoritme: voor clustering

Figuur 4.3: Expectation-Maximization algoritme: na clustering

4.2 Clustering 30

waarde bewegen. Daarom wordt bij EM-algoritme de Gaussiaanse verdeling als basisfunctie

genomen voor de verschillende clusters. Een Gaussiaanse functie neemt de vorm in Figuur 4.4

aan en heeft de volgende formule:

Figuur 4.4: Vorm van een Gaussiaanse functie

P (x) = ae−(x−b)2/2c2

Hierbij zijn a, b en c de constante parameters waarbij a > 0. Deze parameters worden geschat

in het EM-algoritme. Naargelang de parameterwaarden kan de functie smal en hoog zijn maar

bijvoorbeeld ook zeer laag en uitgestrekt. Bovendien is de functie niet beperkt tot twee dimensies.

Hierdoor kunnen verschillende soorten clusters ontdekt worden. Zowel een locatiecluster waarbij

een gebruiker zich veel op zeer nabije plaatsen bevindt (bvb. thuis of op werk) alsook een

locatiecluster waarbij de punten zich veel meer uitstrekken in lengte- en breedtegraad (bvb. op

de trein) kunnen daardoor teruggevonden worden en van elkaar onderscheiden worden.

Algoritme

Het EM-algoritme voert alternerend telkens twee verschillende stappen uit:

• Expectation (E) Deze stap berekent de verwachtingswaarde van de log-likelihood op

basis van de huidige schattingen voor de parameters. De log-likelihood is het natuurlijk

logaritme van de likelihood.

• Maximization (M) Deze stap berekent vervolgens de parameterwaarden die de verwachte

log-likelihood uit de E-stap maximaliseren.

Het algoritme eindigt wanneer de oplossing convergent is of wanneer een bepaald aantal iteraties

wordt overschreden.

4.2 Clustering 31

Aantal iteraties

Het Expectation-Maximization algoritme is in staat om zelf uit te zoeken hoeveel clusters er

moeten aangemaakt worden door middel van cross-validatie:

1. Het aantal clusters wordt geınitialiseerd op 1.

2. De trainingsset wordt willekeurig verdeeld in 10 subsets.

3. Het Expectation-Maximization algoritme wordt 10 keer uitgevoerd voor deze 10 subsets.

4. Er wordt een gemiddelde log-likehood berekend over de 10 resultaten.

5. Wanneer de log-likehood gestegen is wordt het aantal clusters met 1 verhoogd en wordt

deze procedure herhaald vanaf stap 2. In het andere geval hebben we het finaal aantal

clusters gevonden.

4.2.4 Het EM-algoritme voor profielherkenning

Het EM-algoritme is een zeer krachtig clusteringalgoritme dat bruikbaar zou zijn voor onze use

case. De twee voornaamste redenen hiervan zijn:

• De clusters hebben een onderliggende distributiefunctie in de vorm van een Gaussiaanse

functie zodat clusters van zeer uiteenlopende vormen kunnen ontdekt worden. Niet enkel

samengehoopte clusters maar ook bewegingsclusters voor het lopen, rijden of reizen in het

algemeen kunnen beter teruggevonden worden.

• Het aantal clusters dat moet worden gevonden moet niet vooraf opgegeven worden en kan

door het EM-algoritme zelf uitgezocht worden.

Een belangrijk Java-framework voor clustering en andere data mining algoritmes is het Weka-

framework[5]. Deze library bevat bovendien ook een GUI waarmee geexperimenteerd kan worden

met verschillende algoritmes en parameters. Wij zullen Weka dan ook gebruiken om enkele

experimenten uit te voeren rond het EM-algoritme.

Opstelling

We gebruiken voor de experimenten enkele zelfgemaakte ARFF-testbestanden die het dagelijks

gebruik van een smartphone op een semi-realistische wijze representeren. Een header van een

dergelijk testbestand ziet er typisch als volgt uit:

4.2 Clustering 32

@relation profiles

@attribute longitude numeric

@attribute latitude numeric

@attribute dayofweek {Mon,Tue,Wed,Thu,Fri,Sat,Sun}

@attribute time numeric

@attribute velocity numeric

{?,Phone,Camera,Nieuws_en_weer,Talk,AlarmClock,Facebook,Weer,Gallery,

Nieuws,Agenda,Market,Music,Quickoffice,Aandelen,Email,Youtube,Browser,

Google_maps,GPS}

Indien de attributen uit deze header op een periodieke basis worden getraceerd op een Android

toestel dan kan een data-extract van 15 instanties uit het testbestand er alsvolgt uitzien:

51.04627,3.72495,Fri,12.2,0.0410891083838977,Phone

51.04609,3.72486,Fri,12.4,0.2680631371000381,Agenda

51.04609,3.72486,Fri,12.4,0.2680631371000381,Aandelen

51.04609,3.72486,Fri,12.4,0.2680631371000381,Market

51.04609,3.72486,Fri,12.6,0.0,?

51.04609,3.72486,Fri,12.8,0.0,?

51.04609,3.72486,Fri,13.0,0.0,Agenda

51.04609,3.72486,Fri,13.2,0.0,?

51.04609,3.72486,Fri,13.4,0.0,?

51.04609,3.72486,Fri,13.6,0.0,?

51.04614,3.72481,Fri,13.8,0.09424857559494501,?

51.04614,3.72481,Fri,14.0,0.0,Quickoffice

51.04614,3.72481,Fri,14.2,0.0,Email

51.04614,3.72481,Fri,14.2,0.0,Facebook

51.04614,3.72481,Fri,14.4,0.0,?

Wij zullen testbestanden gebruiken van ongeveer 3300 instanties wat gezien de traceerperiod-

iciteit van 12 minuten overeenkomt met een viertal weken gebruikersdata. Volgend scenario

wordt met deze data gerepresenteerd:

• De gebruiker heeft een 9 to 5 -job waarbij deze op weekdagen gaat werken op kantoor. De

gebruiker gaat steeds op dezelfde wijze op en af naar het kantoor (bvb. via de trein).

• Op zondagnamiddag gaat de gebruiker op bezoek bij een kennis ergens op een locatie

tussen thuis en het kantoor.

4.2 Clustering 33

Er kunnen in Weka nog een aantal belangrijke parameters ingesteld worden om de uitkomst

van het EM-algoritme te beınvloeden en te optimaliseren:

• maxIterations: hiermee kan de snelheid alsook de nauwkeurigheid gewijzigd worden

• seed: het random seed bepaalt het initieel aantal willekeurige clusters om te starten

• minStdDev: de Gaussiaanse distributies van de clusters hebben twee parameters die

geoptimaliseerd dienen te worden: een gemiddelde waarde en een standaarddeviatie. Voor

deze laatste parameter kunnen we een minimumwaarde opgeven zodat de clusters altijd

een zekere spreiding moeten hebben.

Proefondervindelijk werd vastgesteld dat de maxIterations en seed best niet te laag worden

ingesteld. Voor heel hoge waarden zijn de verschillen minder groot maar zal het algoritme

trager gaan, daarom worden ze beiden ingesteld op 1000. De bespreking van minStdDev volgt

later.

Resultaten

Figuur 4.5 bevat een overzicht van het Weka-resultaat wanneer we de data clusteren op de

attributen lengtegraad, breedtegraad en tijd. Hierbij is enkel de lengtegraad (y-as) uitgeplot in

functie van de indexnummers van de datapunten (x-as). We zien dat er drie verschillende clusters

ontdekt werden die overeenkomen met thuis, werk en trein. In Figuur 4.6 zoomen we even in

op een deelresultaat om het verschil tussen de clusters duidelijker te zien. De cluster voor het

slapen thuis is minder uitgespreid langs de y-as dan de cluster waar de gebruiker wakker is thuis.

De reden dat het EM-algoritme in staat was om het treinprofiel als een enkel profiel te

herkennen is omdat we ook rekening hebben gehouden met de dimensie tijd. Op het combineren

van verschillende dimensies zal nog dieper worden ingegaan in Hoofdstuk 5.

Voor het familiebezoek op zondag werd geen aparte cluster gemaakt. Dit kan een voor- of

nadeel zijn, afhankelijk van op welke schaal we clusters wensen. Momenteel wordt het bezoek tot

dezelfde cluster als de treincluster beschouwd omdat de tijden plaatsparameters te veel gelijken

op elkaar. We kunnen dit vermijden door nog extra dimensies toe te voegen zoals weekdag en

verplaatsingssnelheid. Gezien het bezoek op een andere weekdag valt dan de treinreizen (namelijk

op zondag) en een veel lagere verplaatsingssnelheid heeft zal het EM-algoritme dit nu wel als

een nieuwe cluster beschouwen. Dit merken we in Figuur 4.7.

Het nadeel is dat we nu enige onnauwkeurigheid hebben in het trein-profiel, dat in twee

clusters is opgedeeld. In de praktijk zal het uiteraard niet mogelijk zijn om alle profielen perfect

4.2 Clustering 34

Figuur 4.5: Clustering van profielen d.m.v. attributen lengtegraad, breedtegraad en tijd : op dex-as de index van het sample en de op de y-as de lengtegraad

Figuur 4.6: Deelresultaat van profielclustering: clusters thuis wakker (rood), thuis slapend(donkerblauw) en trein (lichtblauw), x- en y-as zoals in Figuur 4.5

nauwkeurig te genereren. Echter, we kunnen concluderen dat het EM-algoritme krachtig genoeg

is om goede resultaten te geven voor de use cases die we wensen.

4.2 Clustering 35

Figuur 4.7: Clustering van profielen dmv alle attributen samen: op de x-as de index van het sam-ple en de op de y-as de lengtegraad. Clusters thuis wakker (geel), thuis slapend (donkerblauw),werk (lichtblauw), familiebezoek (groen) en gebroken clusters trein (roos en paars)

Tot slot bespreken we nog kort te invloed van de Weka-parameter minStdDev voor het EM-

algoritme. Voor de vorige experimenten werd deze zeer laag ingesteld (10−8). Wanneer we echter

een hoge waarde kiezen (bvb. 100) verandert het laatste resultaat in het resultaat in Figuur

4.8. Doordat we de minimum-spreiding van de Gaussiaanse functies hebben vergroot is het

EM-algoritme nu in staat om zelfs een avond thuis in de week (de blauwe punten in de figuur) te

onderscheiden van een weekend thuis (de groene punten). Het nadeel is nu echter dat de halve

werkdag op vrijdag ook als weekend wordt beschouwd en zelfs de treinrit behoort tot dezelfde

cluster. We kunnen dus concluderen dat er een optimale afweging dient gezocht te worden van

de EM-parameters om in de meeste scenario’s een goed en realistisch resultaat te verkrijgen.

Performantie-overwegingen

Voor de evaluatie van het clusteralgoritme dient ook de performantie in rekening gebracht te

worden. De tijdscomplexiteit van k-means[8] clustering-algoritmes is O(nkl) met n het aantal

patronen, k het aantal clusters en l het aantal iteraties om te convergeren. De geheugencom-

plexiteit is O(k+n). De complexiteit van EM is moeilijker te bepalen omdat het aantal iteraties

niet op voorand gekend is en de complexiteit hier sterk vanaf hangt. Wel kunnen we zeggen

dat de complexiteit van EM sterk aanleunt bij deze van k-means, zowel voor kleine als grote

datasets.

Het EM -algoritme is bovendien lineair in de invoergrootte. Dit wil zeggen dat het algoritme

in vergelijking met andere clusteralgoritmes zoals bijvoorbeeld hierarchische algoritmes beter tot

zijn recht komt voor grotere datasets. Over het algemeen worden hierarchische clusteralgoritmes

4.2 Clustering 36

Figuur 4.8: Clustering van profielen met een hoge minimum-standaarddeviatie (minStdDev is100): op de x-as de index van het sample en de op de y-as de lengtegraad. Het algoritme onder-scheidt een avond thuis (blauw) van een weekend (groen) maar classificeert sommige samplesvoor werk en familiebezoek ook als weekend

eerder gebruikt voor kleinere datasets en worden partitioneringsalgoritmes zoals k-means en EM

vooral gebruikt voor grotere en complexere datasets. Naast het feit dat EM het clusteraantal

zelf kan bepalen (en k-means niet) kan het ook goed omgaan met hogere dimensionaliteiten, wat

in ons geval een groot voordeel is[26].

Ondanks het feit dat EM geen lage performantie heeft werd toch bevonden dat het algoritme

voor onze doelstellingen niet kan gebruikt worden op het Android-toestel zelf. De datasets zijn

zo groot en complex dat de clustering op het mobiel toestel veel te veel tijd in beslag neemt.

Testen hebben aangetoond dat een enkele clustering van een realistisch testbestand ongeveer 30

minuten duurt. Voor onze doelstelling hebben we bovendien een vijftal clusteringen nodig zodat

het clusteren op het mobiel toestel zelf volledig onrealistisch wordt. Daarom werd besloten om

de clustering en andere data mining technieken uit te voeren op een server en te werken met een

Client-Server-architectuur.

Porteerproblemen van Weka op Android

Voor de evaluatie van de performantie hebben we de clustering eerst geprobeerd op het Android

toestel zelf. Hiervoor zouden we gebruikmaken van de Weka library[5]. Deze bibliotheek was

echter niet direct compileerbaar op een Android device. Weka maakt gebruik van standaard Java

API zoals java.beans (klassen die instaan voor Java Beans ontwikkeling) , java.swing (grafische

interface) en java.lang.management (biedt een interface aan die instaat voor de controle en

4.3 Verwantschapsanalyse 37

beheer van de Java virtuele machine). Deze bibliotheken zijn echter niet beschikbaar op een

Android device. Aangezien we toch met Weka wouden werken, hebben we besloten om Weka aan

te passen zodat deze geen gebruik meer maakt van bovenstaande bibliotheken. Het grootste deel

van de omzetting bestond er in om alle GUI elementen te verwijderen, dit kon zonder problemen

aangezien we toch enkel de operationele functionaliteiten wouden gebruiken. Vervolgens moesten

alle klassen die afhankelijk waren van deze wijzigingen ook aangepast worden. Stap voor stap

hebben we alle noodzakelijke klassen aangepast, terwijl we steeds controleerden of de resultaten

die Weka produceerde nog correct waren.

4.3 Verwantschapsanalyse

De verschillende technieken uit de literatuurstudie werden eveneens geevalueerd voor het zoeken

van patronen in het gebruik van applicaties. Hierbij bleek verwantschapsanalyse een terechte

winnaar. Indien we elke log-actie op het mobiel toestel beschouwen als een transactie dan kun-

nen de verschillende attributen profiel, weekdag, plaats, tijd, applicaties, ... als items van de

transactie aanzien worden. Wat we wensen is bovendien niets anders dan alle mogelijke ver-

banden tussen deze attributen. Dit zijn de patronen waarnaar we op zoek zijn. Hierdoor kun-

nen patronen zoals bijvoorbeeld {WED, 14u} ==> FB of {WORK, MON, 15u} ==> QUICKOFFICE

gemakkelijk ontdekt worden.

Het grootste probleem bij deze aanpak is dat de waarden van de items in een transactie dis-

creet moeten zijn. Zo zullen {WED, 14u} ==> FB en {WED, 14u05} ==> FB worden beschouwd

als twee verschillende regels terwijl ze zeer weinig van elkaar verschillen. Een oplossing hiervoor

wordt besproken in Hoofdstuk 5. Voor de eigenlijke implementatie van het associatieregel-

algoritme werd gekozen voor het A Priori -algoritme.

4.4 Conclusie

In dit Hoofdstuk werden de toepasbaarheid en de performantie van de belangrijkste algoritmes

uit onze literatuurstudie geevalueerd. Hierbij werd besloten om het Expectation-Maximization-

algoritme en verwantschapsanalyse te gebruiken als hoofdalgoritmes. Bovendien werd gekozen

om een ClientServer-architectuur te gebruiken omdat de algoritmes voor onze doelstelling te

zwaar zijn voor het Android-toestel. De gekozen algoritmes zullen uitvoerig worden toegepast

op twee belangrijke use cases voor ons framework in Hoofdstuk 5 en Hoofdstuk 6. Dit vormt

meteen een inleiding voor het raamwerk dat zal worden besproken in Hoofdstuk 7.

GENEREREN VAN CLUSTERS EN PROFIELEN 38

Hoofdstuk 5

Genereren van clusters en profielen

5.1 Inleiding

In deze sectie illustreren we hoe we het zoeken van patronen en regels in de data zullen laten

voorafgaan door clustering-algoritmes. We kunnen de contextuele gegevens van een gebruiker pe-

riodiek monitoren. Contextuele gegevens zijn bijvoorbeeld de plaats en de tijd van de gebruiker.

Bovendien kunnen we nagaan welke applicaties de gebruiker allemaal opent. Het uiteindelijke

doel is om de applicaties die een gebruiker zou openen op elk moment te kunnen voorspellen aan

de hand van parameters zoals tijd, plaats, enzoverder. Een probleem waarmee we te kampen

hebben is de continuıteit van dergelijke parameters. Indien een gebruiker een applicatie opent

om 10:20:55 en een andere keer om 10:20:56 dan zijn dit twee verschillende tijdswaarden terwijl

deze waarden slechts een seconde verschillen van elkaar. Omdat voorspellingen niet tot op een

seconde nauwkeurig moeten zijn en dit bovendien veel te veel rekentijd zou innemen hebben we

nood aan een algoritme om functies af te platten en gelijkende waarden ook effectief gelijk te

stellen aan elkaar. Deze denkpiste geldt niet enkel voor de parameter tijd maar ook voor de

meeste andere parameters.

Waar we dus naar op zoek zijn is een algoritme om enige structuur te zoeken in een verza-

meling van initieel ongestructureerde datapunten. We weten ook niet hoe dicht twee param-

eterwaarden bij elkaar moeten liggen zodat ze bij elkaar zouden horen. Indien we de seconde

verschil in het voorbeeld veranderen door een minuut of een kwartier, horen ze dan nog steeds

bij elkaar of niet? Dit zijn zaken die moeilijk definieerbaar zijn en waarvan we hopen dat het

algoritme het zelf uitzoekt voor ons. De ideale techniek die aan al deze voorwaarden voldoet is

clustering.

5.2 Voorbeeldcase 39

5.2 Voorbeeldcase

Het monitoren van contextuele gegevens dient periodiek te gebeuren op een regelmatige basis.

Om zo goed mogelijk de verschillen tussen het applicatiegebruik in plaats en tijd te ontdekken

dient het verzamelen van gegevens minstens een tweetal weken te duren vooraleer we een model

kunnen opstellen dat voldoende betrouwbaar is. Indien alle gegevens van een enkele monitoractie

een data-element is dan zullen we wellicht enkele duizenden data-elementen bekomen, afhankelijk

van hoe regelmatig we monitoren. In dit hoofdstuk en de volgende hoofdstukken zullen we werken

met de voorbeeldcase uit Figuur 5.1. Dit is een klein extract van twaalf data-elementen uit zo’n

latitude longitude day of week time speed applications

51.03419 4.21742 Monday 7:40 0.027 km/h AlarmClock

51.03418 4.21739 Monday 7:50 0.025 km/h Agenda

51.03950 4.21611 Monday 8:00 71.255 km/h Music, Email

51.04300 4.21559 Monday 8:10 81.010 km/h Music, Facebook


51.05122 4.21401 Monday 8:30 0.020 km/h Quickoffice

51.05122 4.21400 Monday 11:00 0.015 km/h

51.05122 4.21415 Monday 15:20 0.028 km/h Phone


? ? Monday 17:10 ? Music, Email

51.03417 4.21742 Monday 22:30 0.027 km/h

51.03418 4.21738 Tuesday 0:05 0.025 km/h Youtube

Figuur 5.1: Extract van mogelijke data instances

verzameling van duizenden elementen. De elementen zijn chronologisch maar niet compleet.

Dit betekent dat er in de praktijk meer fine-granular gemonitord wordt ten opzichte van de

tijdsas en er dus tussen de rijen nog andere rijen zouden zijn. Bovendien moeten we inzien dat

in de praktijk de data cyclische herhalingen heeft waardoor we nauwkeuriger kunnen clusteren.

Immers, tijdstippen herhalen zich op nieuwe dagen, weekdagen herhalen zich in nieuwe weken,

enzoverder.

Indien we dit extract goed analyseren zien we dat de gebruiker bij de eerste twee rijen zich op

eenzelfde plaats bevindt en weinig beweegt (de lengtegraden en breedtegraden verschillen heel

weinig en de snelheid is zeer laag). We zien dat de gebruiker zich nadien op een snelle manier

beweegt naar een andere plaats. Op het einde keert de gebruiker weer terug.

Een gebruiker kan slechts een applicatie aan het gebruiken zijn (in de voorgrond hebben)

5.3 Eerste-niveau clustering: attributen 40

dus normaalgezien kan de kolom applications slechts een applicatie bevatten. Er is echter een

uitzondering voor Music. Dit is geen gewone applicatie maar een service die in de achtergrond

kan draaien. Daardoor is het dus mogelijk om twee applicaties tegelijk te gebruiken: Music en

een andere applicatie.

De zevende en de elfde rij bevatten geen applicaties. Het periodiek monitoren gebeurt

namelijk ook wanneer de gebruiker geen applicaties aan het gebruiken is (het toestel is bijvoor-

beeld in standby). Dit doen we om voor parameters zoals plaats vollediger en effectiever te

kunnen clusteren.

Tot slot zien we dat de gegevens die we zullen hebben niet altijd volledig zullen zijn. De

tiende rij ontbreekt waarden voor de lengtegraad, de breedtegraad en de snelheid. Dit zou

kunnen zijn omdat de GPS-functie van het toestel tijdelijk onbeschikbaar is. Hiermee zullen we

ook rekening moeten houden.

5.3 Eerste-niveau clustering: attributen

5.3.1 Locatie, snelheid, weekdag

Een eerste clustering van de data zal gebeuren op het niveau van de contextuele attributen

(longitude, latitude, day of week, time, speed). Stel, we willen clusteren op de parameter location.

Deze parameter is bepaald door de twee attributen latitude en longitude die geselecteerd zijn in

Figuur 5.2.








51.05122 4.21400 Monday 11:00 0.015 km/h

51.05122 4.21415 Monday 15:20 0.028 km/h Phone



51.03417 4.21742 Monday 22:30 0.027 km/h


Figuur 5.2: Selectie van de attributen latitude en longitude voor het clusteren van location


Indien een gebruiker zich tijdens de monitoring vooral op drie plaatsen heeft bevonden dan

is het wenselijk dat het clusteralgoritme ons drie resulterende clusters teruggeeft voor de locatie.

We weten echter niet op voorhand dat het aantal clusters gelijk moet zijn aan 3. Daarom

gebruiken we het Expectation-Maximization algoritme dat werd besproken in 4.2.3. Dit algoritme

zoekt zelf het aantal clusters uit en geeft ons deze clusters terug. In het voorbeeld wensen we

clusters zoals in Figuur 5.3 te krijgen voor de locatie.


Location 1 Monday 7:40 0.027 km/h AlarmClock

Location 1 Monday 7:50 0.025 km/h Agenda

Location 2 Monday 8:00 71.255 km/h Music, Email

Location 2 Monday 8:10 81.010 km/h Music, Facebook

Location 2 Monday 8:20 69.877 km/h Music, Email

Location 3 Monday 8:30 0.020 km/h Quickoffice

Location 3 Monday 11:00 0.015 km/h

Location 3 Monday 15:20 0.028 km/h Phone

Location 2 Monday 17:00 70.444 km/h Music, Facebook

Location 2 Monday 17:10 ? Music, Email

Location 1 Monday 22:30 0.027 km/h

Location 1 Tuesday 0:05 0.025 km/h Youtube

Figuur 5.3: Data geclusterd op location dmv de attributen latitude en longitude

Indien we hetzelfde zouden doen voor de weekdag en de snelheid wensen we een resultaat

zoals in Figuur 5.4.

In tegenstelling tot de locatie en de snelheid is de weekdag een parameter die we op een een-

voudigere manier kunnen clusteren. Gezien er slechts zeven weekdagen zijn hebben we hiervoor

reeds een goede onderverdeling en kunnen we de invoer gelijkstellen aan de uitvoer (met andere

woorden elke weedag stelt een cluster voor).

Doordat de parameter locatie bepaald is door twee attributen zal er worden geclusterd op

een tweedimensionaal vlak. Voorbeelden van clustering op een eendimensionaal vlak zijn de

parameters tijd en snelheid. In Figuur 5.5 zie je een visuele voorstelling van de clustering van

plaats en snelheid (voor een grotere verzameling punten dan in het voorbeeldextract). Hoewel

snelheid eendimensionaal is hebben we het voor de zichtbaarheid tweedimensionaal voorgesteld.

Merk op dat deze figuur enkel dient om een visueel beeld te krijgen van de clustering. De

verhoudingen tussen de punten ten opzichte van de assen zijn niet volledig correct maar zijn

aangepast om een duidelijker beeld te geven.



Location 1 Day 1 7:40 Speed 1 AlarmClock

Location 1 Day 1 7:50 Speed 1 Agenda

Location 2 Day 1 8:00 Speed 2 Music, Email

Location 2 Day 1 8:10 Speed 2 Music, Facebook


Location 3 Day 1 8:30 Speed 1 Quickoffice

Location 3 Day 1 11:00 Speed 1

Location 3 Day 1 15:20 Speed 1 Phone

Location 2 Day 1 17:00 Speed 2 Music, Facebook



Location 1 Day 2 0:05 Speed 1 Youtube

Figuur 5.4: Data geclusterd op location, day of week en speed

(a) Twee-dimensionaal vlak voor de locatie

latitude(decimal)

longitude (decimal)

51.03419 51.05122

4.21400

4.21742

(b) Locatie geclusterd

instance no

speed (km/h)

0.025

70

(c) Een-dimensionale ruimte voor de snelheid

instance no

speed (km/h)

0.025

70

(d) Snelheid geclusterd

Figuur 5.5: Attributen en het resultaat na clustering

Zoals we zien in Figuur 5.5 komt het resultaat dat we zouden wensen niet volledig overeen

met het resultaat dat we zouden krijgen. De datapunten waar we ons weinig bewegen en we


ons ongeveer op een zelfde plaats bevinden leveren de gewenste clusters op: een locatiecluster

per plaats en eenzelfde snelheidscluster voor beide plaatsen omdat we ons op beide plaatsen

ongeveer even traag bewegen.

Het fragment waar we ons echter met een hoge snelheid verplaatsen tussen de locaties levert

te veel clusters op. Dit komt omdat onze intuıtie niet overeen komt met de werkelijkheid.

Wanneer we ons in de auto of op de trein bevinden voelt dit aan als een enkele plaats, maar in

werkelijkheid zijn het er meerdere. Dit geldt ook voor de snelheid: gemiddeld rijdt de trein aan

een hoge snelheid maar er zijn momenten dat de trein traag rijdt of zelfs stilstaat. Hoe we dit

probleem grotendeels kunnen oplossen, daar komen we later nog op terug.

5.3.2 Tijd

Voor de parameters locatie, snelheid en weekdag hebben we steeds alle datapunten gebruikt om

te clusteren. Het is immers nauwkeuriger om plaatsclusters en snelheidsclusters te berekenen

aan de hand van zoveel mogelijk plaatsen waar de gebruiker zich heeft bevonden en niet enkel

aan de hand van de plaatsen waarop de gebruiker applicaties heeft geopend. Voor de parameter

tijd geldt deze denkpiste echter niet. Indien we alle datapunten in rekening brengen wanneer

er gemonitord werd dan doen we niets anders dan een uniforme tijdsas creeren. Indien er

echter in bepaalde fragmenten van de tijdsas nooit applicaties worden gebruikt hoeven we hier

geen clusters voor te maken. Hier moeten we dus wel rekening houden met de applicaties en

enkel wanneer een applicatie werd gebruikt mag het element in rekening gebracht worden. Een

voorbeeld zien we in Figuur 5.6.

5.3.3 Attributen combineren

In sectie 5.3.1 werden we geconfronteerd met het probleem dat we in bepaalde situaties te

veel clusters kregen als resultaat. We kunnen echter opmerken dat een dergelijk probleem zich

eigenlijk herhaalt over de verschillende attributen. Waar we in het fragment waarin we ons met

een hoge snelheid verplaatsen te veel clusters kregen voor snelheid kregen we er ook te veel voor

plaats. Hier kunnen we al vermoeden dat de verschillende attributen niet altijd onafhankelijk

zijn van elkaar. Wanneer we op de trein zitten is de verplaatsing een continue functie, maar

ook de tijd, de snelheid en de weekdag zijn continue functies. We kunnen bijvoorbeeld niet

bruut van een lage naar hoge snelheid overgaan zonder eerst geleidelijk te versnellen. Indien we

dus meerdere van deze dimensies combineren zal het voor het EM-algoritme gemakkelijker zijn

om goede clusters te vinden. Dit algoritme is namelijk geoptimaliseerd om dergelijke functies

te vinden. Het wordt hier ook duidelijk dat het belangrijk is om op een regelmatige basis te

5.4 Tweede-niveau clustering: applicaties 44


Location 1 Day 1 Time 1 Speed 1 AlarmClock

Location 1 Day 1 Time 1 Speed 1 Agenda

Location 2 Day 1 Time 2 Speed 2 Music, Email

Location 2 Day 1 Time 2 Speed 2 Music, Facebook


Location 3 Day 1 Time 2 Speed 1 Quickoffice


Location 3 Day 1 Time 3 Speed 1 Phone

Location 2 Day 1 Time 4 Speed 2 Music, Facebook



Location 1 Day 2 Time 5 Speed 1 Youtube

Figuur 5.6: Clustering van de data op time: enkel de punten met applicaties worden in rekeninggebracht

monitoren, zodat het mogelijk is uit de discrete dataset continue verbanden te vinden.

We kunnen het probleem uit sectie 5.3.1 dus oplossen door naast de gedane clustering nog

eens alle attributen te combineren en dit te clusteren. Figuur 5.7 illustreert dit principe voor de

combinatie van locatie en snelheid.

Doen we dit voor alle attributen dan hebben we een vijfdimensionale ruimte en komen de

resultaten goed overeen met de profielen die we in het dagelijks leven zoal kunnen hebben: thuis,

thuis aan het slapen, op de trein, op het werk, enzoverder. Dit zien we in Figuur 5.8.

Deze profielen kunnen we gebruiken om profielafhankelijke patronen te zoeken. Bovendien

kunnen we ze gebruiken voor tal van andere doeleinden op de smartphone zelf. Let wel dat deze

profielen geen vervanging zijn van de reeds gevonden clusters. Profielen zijn een speciaal type

clusters en we zullen alle soorten clusters gebruiken om patronen te ontdekkken.

5.4 Tweede-niveau clustering: applicaties

Een tweede clustering van de bekomen data zal gebeuren op het niveau van de applicaties. We

zullen clusters zoeken van applicaties die samen gebruikt worden. We moeten dus op zoek

gaan naar een criterium om te bepalen wanneer applicaties samen gebruikt worden, gezien op

elk moment maar een applicatie kan gebruikt worden (op uitzondering van de service Music).

Een manier is om de applicaties te clusteren ten opzichte van de tijdsas. Er is echter nog een

andere voor de hand liggende manier: nagaan wanneer het toestel in standby gaat. We kunnen


latitude(decimal)

longitude (decimal)

51.03419 51.05122

4.21400

4.21742

instance no

speed (km/h)

0.025

70

longitude (decim

al)

speed (km/h)

latitude (decimal)

Figuur 5.7: Combinatie van twee attributen naar een drie-dimensionale ruimte voor clustering


Profiel 1 AlarmClock

Profiel 1 Agenda

Profiel 2 Music, Email

Profiel 2 Music, Facebook


Profiel 3 Quickoffice

Profiel 3

Profiel 3 Phone



Profiel 1

Profiel 1 Youtube

Figuur 5.8: Clustering van alle attributen samen resulteert in de Android-profielen


over het algemeen veronderstellen dat een gebruiker tussen twee momenten dat hij het toestel in

standby laat gaan met gelijklopende zaken bezig is. We beschouwen alle unieke applicaties tussen

dergelijke momenten dan als een cluster. Zo’n cluster zal meestal slechts 1 tot 5 unieke applicaties

bevatten. Een voorbeeld van de clustering op attributen en de groepering van applicaties zien

we in Figuur 5.9.


Location 2 Day 1 Time 4 Speed 2 (Facebook, Youtube, Email), (QuickOffice), (Music, Email)

Location 3 Day 1 Time 2 Speed 1 (Youtube, Email)

Location 1 Day 2 Time 1 Speed 1 (Music, Email), (Phone)

Figuur 5.9: Eerste-niveau en tweede-niveau clustering: attributen en applicaties

ONTDEKKEN VAN PATRONEN EN STRUCTUUR 47

Hoofdstuk 6

Ontdekken van patronen en

structuur

In het vorige hoofdstuk hebben we verschillende clusteringtechnieken besproken die we zullen

gebruiken in onze applicatie. Deze technieken zullen we gebruiken als voorbewerking om meer

gedetailleerde structuur en patronen te ontdekken in de data. Een gebruiker van een smart-

phone kan bewust of onbewust verschillende patronen hanteren in het gebruik van applicaties

en contacten. Ons doel is om zoveel mogelijk structuren en patronen te herkennen in de initieel

ongestructureerde data. Hier volgt een opsomming van de patronen waarnaar we op zoek gaan:

1. Applicaties die typerend zijn voor een bepaald profiel De applicaties Quickoffice,

Agenda en Email kunnen bijvoorbeeld typerend zijn voor een werk-profiel.

2. Sequentiele structuren in de opeenvolging van applicaties Een voorbeeld is het

vaak na elkaar openen van applicaties. Een ander voorbeeld is dat aan het begin en aan

het eind van een profiel steeds terugkerende applicaties worden geopend.

3. Applicaties die vaak samen worden gebruikt De applicaties Facebook, Youtube en

Music kunnen bijvoorbeeld vaak samen gebruikt worden.

4. Applicaties die typerend zijn voor specifieke locaties, weekdagen, tijdstippen of

verplaatsingssnelheden. Een gebruiker kan bepaalde routines hebben zoals het steeds

openen van een applicatie na het opstaan, na het avondeten, voor het slapengaan, tijdens

het rijden, in de winkel, tijdens het weekend, enzoverder.

5. Applicaties die recent werden geopend Indien een gebruiker tijdens de laatste minuten

of uren applicaties veelvuldig heeft geopend bestaat de kans dat hij of zij deze applicaties

weldra opnieuw zal openen.

6.1 Grafenalgoritme voor profielafhankelijke patronen 48

De patronen in 1 en 2 zullen we zoeken via een profielafhankelijk grafenalgoritme. De patronen

in 3 en 4 zullen we zoeken via verwantschapsanalyse. Tot slot zullen we de patronen in 5 zoeken

via een statistisch algoritme. Een overzicht van deze werkwijze zien we in Figuur 6.1.

Location 1 Day 1 Time 1 Speed 1 AlarmClock

Location 1 Day 1 Time 1 Speed 1 Agenda


Location 2 Day 1 Time 2 Speed 2 Music, Facebook Email

Location 2 Day 1 Time 2 Speed 2

Location 3 Day 1 Time 2 Speed 1 Quickoffice

Location 3 Day 1 Speed 1

Location 3 Day 1 Time 3 Speed 1 Phone

Location 2 Day 1 Time 4 Speed 2 Music, Facebook, Email

Location 2 Day 1 Time 4 Speed 2

Location 1 Day 1 Speed 1

Location 1 Day 2 Time 5 Speed 1 Youtube

Profiel 1 AlarmClock

Profiel 1 Agenda


Profiel 2 Music, FacebookMusic, Email

Profiel 2

Profiel 3 Quickoffice

Profiel 3

Profiel 3 Phone



Profiel 4

Profiel 4 Youtube







51.05122 4.21400 Monday 11:00 0.015 km/h

51.05122 4.21415 Monday 15:20 0.028 km/h Phone



51.03417 4.21742 Monday 22:30 0.027 km/h


PROFIEL-AFHANKELIJKE

PATRONEN

PROFIELAFHANKELIJKEPATRONEN

GRAFENALGORITME

INTRA-CLUSTERCORRELATIE

ASSOCIATIEREGELS

KORTETERMIJN-GEHEUGEN

STATISTISCH ALGORITME

51.03419 4.21742 Tuesday 16:40 0.027 km/h Email

51.03418 4.21739 Tuesday 16:50 0.025 km/h Agenda

51.03950 4.21611 Tuesday 17:00 71.255 km/h Email

51.04300 4.21559 Tuesday 17:10 81.010 km/h Music,

51.04877 4.21504 Tuesday 17:20 69.877 km/h Music, Email

51.05122 4.21401 Tuesday 17:30 0.020 km/h Quickoffice

51.05122 4.21400 Tuesday 18:00 0.015 km/h Phone

51.05122 4.21415 Tuesday 19:20 0.028 km/h Phone

51.04328 4.21558 Tuesday 20:00 70.444 km/h Agenda

? ? Tuesday 20:10 ? Email



CLUSTERING

New instance: (51.03420, 4.21557, Tuesday, 21:00, 0.023 km/h,

[Music, Email])

New clustered instance: (Location 1, Day 2, Time 5, Speed 1, Profile 1, [Music, Email])

Recent instances

Original instances

INTRA-CLUSTER-CORRELATIE

ASSOCIATIEREGELS


STATISTISCHALGORITME


ASSOCIATIEREGELS

Figuur 6.1: Schema van clustering en patroonherkenning

6.1 Grafenalgoritme voor profielafhankelijke patronen

In het vorige hoofdstuk hebben we uitlegd hoe we via clustering verschillende profielen kunnen

ontdekken. Bij iemand die elke weedag naar het werk gaat met de trein zouden we minstens drie

profielen moeten vinden: thuis, op het werk en op de trein. Het gebruik van applicaties kan sterk

afhankelijk zijn van deze profielen. Thuis zal iemand meer vrijetijdsapplicaties gebruiken terwijl

men op het werk eerder zal gebruik maken van Office-applicaties, Email-applicaties, Agenda,

enzoverder. Onderweg kunnen dan weer applicaties zoals Google Maps, GPS, NMBS of Weer

gebruikt worden.


6.1.1 Opstellen van de graaf

Nu we de verschillende profielen hebben gedetecteerd kunnen we eenvoudigweg de applicaties

hieraan toekennen die in het profiel het meest gebruikt worden. Hiervoor moeten we enkel per

applicatie tellen hoeveel keer het in een profiel geopend werd. In Figuur 6.2 zie je een voorbeeld

voor een werk-gerelateerd profiel.

Email

QuickOffice

Agenda

Browser Phone

63

13

27

1542

Figuur 6.2: Knopen in een graaf voor het aantal keer dat een applicatie werd geopend

Als we naar deze figuur kijken wordt het al snel duidelijk dat we meer kunnen doen dan dit.

We zouden ook rekening kunnen houden met de sequentiele overgangen tussen applicaties. Het

zou bijvoorbeeld kunnen dat een zakenman na het bellen vaak naar zijn Agenda gaat om een

afspraak in te plannen, naar Email om iemand op de hoogte te brengen of naar QuickOffice om

een document aan te passen. Op deze manier krijgen we een gerichte graaf zoals in Figuur 6.3.

We kunnen de graaf nog uitgebreider maken. Stel dat de zakenman na het bellen bijna

altijd meteen naar zijn agenda gaat, gemiddeld na een vijftal minuten een email stuurt of na een

lange tijd naar QuickOffice gaat dan kunnen we deze gemiddelde tijdsafstanden ook in rekening

brengen. Dit zien we in Figuur 6.4.

Het voordeel hiervan is dat we bij de classificatie niet enkel kunnen kijken naar het aantal

keer dat de boog genomen werd, maar ook het tijdsverschil van de boog kunnen vergelijken met

het huidig tijdsverschil sinds de laatst geopende applicatie.

Aanpassen van de graaf

We kunnen de graaf eenvoudig aanpassen telkens wanneer een nieuwe applicatie wordt geopend.

Dit zien we in Algoritme 6.1. Hierbij is v de knoop van de geopende applicatie en is e de boog


Email

QuickOffice

Agenda

Browser Phone

63

13

27

1542

16

25 27 10

9 81

2 310

3

3

Figuur 6.3: Gerichte graaf voor de sequentiele overgangen tussen applicaties

Email

QuickOffice

Agenda

Browser Phone

63

13

27

1542

16

25 27 10

9 81

2 310

2''

4''

5''

1''50''

50''

1''

2''

1''

24''

3 4''

3

11''

Figuur 6.4: Gerichte graaf die ook rekening houdt met de tijdsverschillen tussen applicaties

van de vorige applicatie die werd geopend in het huidige profiel tot de nieuwe applicatie. De

tijd sinds de vorige applicatie wordt aangeduid met new time.

6.1.2 Berekenen van de theoretische probabiliteiten

Stel nu dat we willen weten hoeveel de theoretische kans is van elke applicatie een halve minuut

nadat we Phone hebben gebruikt. Indien we enkel zouden rekening houden met de aantallen

in de knopen bekomen we voor Email een kans van 41%, voor QuickOffice 8% en voor Agenda

16%. Ook de andere applicaties hebben een kans en al deze kansen zijn onafhankelijk van de


Algorithm 6.1 Algoritme voor het updaten van de graaf bij het openen van een applicatie

if first application in current profile thencountv ← countv + 1

elsecountv ← countv + 1counte ← (timee . counte + new time)/(counte + 1)counte ← counte + 1

end if

laatstgeopende applicatie (Phone).

Dit probleem hebben we niet meer wanneer we werken met de aantallen van de gerichte

bogen. Alle bogen die niet vertrekken uit Phone vallen hierdoor weg zoals in Figuur 6.5.

Email

QuickOffice

Agenda

Browser Phone

63

13

24

1242

10

8

10

5''

50''

1''

Figuur 6.5: Resulterende graaf bij het berekenen van de applicaties na het gebruik van Phone

Op die manier hebben we voor Email een kans van 36%, voor QuickOffice 36% en voor Agenda

28%. Voor de andere applicaties hebben we kans 0 omdat we de overgang nog nooit eerder hebben

gemaakt. Uiteraard werkt dit principe enkel wanneer het aantal voorbeeldelementen voldoende

groot is en in de praktijk zal een kans 0 zich bijna nooit voordoen.

Waar we echter nog geen rekening mee gehouden hebben is de tijd. We hebben de applicatie

Phone een halve minuut geleden geopend. Als we dan naar de figuur kijken dan zegt onze intuıtie

dat we een veel grotere kans hebben om Agenda te openen aangezien de tijden daar veel dichter

bijeenliggen terwijl de tijden naar Email en QuickOffice veel groter zijn (5 en 50 minuten).

We passen de kansen die we reeds hadden berekend aan door deze te vermenigvuldigen met de

tijdsverhouding. Als het tijdsverschil kleiner is dan de boogtijd dan wordt de verhouding steeds

groter naarmate de waarde dichter bij de boogtijd komt. Bij een gelijke tijd is de verhouding

6.2 Associatieregels voor intra-cluster correlatie 52

gelijk aan 1. Indien het tijdsverschil groter is dan de boogtijd dan wordt de verhouding steeds

kleiner.

Voor het tijdsverschil van een halve minuut geeft dit voor Email een kans van 20%, voor

QuickOffice 2% en voor Agenda 78%. Dit komt nu wel overeen met onze intuıtie. De applicatie

Agenda heeft nu een veel grotere kans.

Naarmate dat er geen applicatie wordt geopend zullen de kansen veranderen. Stel dat het

tijdsverschil later opgelopen is tot 10 minuten dan zijn de kansen respectievelijk 64%, 26% en

10%. De kans voor Email is dus nu het grootst en stilaan wordt deze van QuickOffice groter en

groter. Bij een tijdsverschil van 40 minuten hebben we 9%, 89% en 2%.

Het is belangrijk om in het achterhoofd te houden dat deze probabiliteiten enkel reken-

ing houden met het profielvenster. Patronen die rekening houden met andere overwegingen

bespreken we in de volgende secties.

6.2 Associatieregels voor intra-cluster correlatie

6.2.1 Intra-attribuut correlatie

Applicaties hoeven niet perse profielafhankelijk te zijn. Een gebruiker heeft vaak bepaalde rou-

tines zoals het openen van een applicatie na het opstaan, na het avondeten, voor het slapengaan,

tijdens het rijden, in de winkel, tijdens het weekend, enzoverder. Vaakgebruikte voorbeelden

zijn het dagelijks zetten van een alarmklok voor het slapengaan of het nakijken van een agenda

of emails na het opstaan. Dergelijke voorbeelden zijn eerder gebonden aan de individuele pa-

rameters apart dan aan een specifiek profiel. Een kotstudent zal een profiel kot en een profiel

thuis hebben maar zal in beide profielen zijn alarmklok instellen ’s avonds. Deze actie is dan ook

meer tijdsgericht. Wanneer iemand elke woensdag een specifieke applicatie opent is dit eerder

gebonden aan de weekdag dan aan een specifiek profiel.

Net zoals we in de clustering-stap profielclusters terugkregen hadden we ook clusters gevon-

den voor individuele parameters zoals tijd, locatie, enzoverder. Indien we deze clusters mappen

met de applicatieclusters die we hadden gevonden kunnen we met behulp van verwantschaps-

analyse verschillende associatieregels vinden. Enkele voorbeelden van dergelijke regels:

[88%] Location 1, Time 5 ==> AlarmClock

[74%] Location 1, Time 1 ==> Agenda

[53%] Location 1, Time 1 ==> Email

De premise van een dergelijke regel (bijvoorbeeld Location 1, Time 5) is waaraan voldaan

moet zijn om de consequence (AlarmClock) als consequentie te hebben met een bepaalde be-

6.2 Associatieregels voor intra-cluster correlatie 53

trouwbaarheid of confidence (88%). Bij het classificeren van een gebruiker kunnen we eenvoudig

nagaan welke regels voldaan zijn door de contextuele attributen van dat ogenblik te clusteren

en de resulterende clusters te vergelijken met de premises van de associatieregels. Indien deze

premise voldaan is krijgen we een applicatie met een bepaalde betrouwbaarheid. Deze betrouw-

baarheid vormt de probabiliteit van een applicatie.

Stel nu dat we bovenop de eerste associatieregel in bovenstaand voorbeeld ook de volgende

regels terugvinden:

[97%] Location 1, Time 5, Speed 1 ==> AlarmClock

[1%] Location 1, Time 1, Speed 2 ==> AlarmClock

Dan wil dit zeggen dat het grootste deel van de 88% in het eerste voorbeeld is ingenomen door

de snelheidscluster Speed 1. Wanneer we tijdens de classificatie ook weten dat onze huidige

snelheid zich in de cluster Speed 1 bevindt dan vergroot onze kans op Agenda van 88% naar

97%. Wanneer we ons echter in cluster Speed 2 bevinden dan verkleint deze kans naar 1%.

We moeten met andere woorden enkel rekening houden met de associatieregels waarbij de

premise zoveel mogelijk overeenkomt met onze contextuele parameters. De confidences die we

krijgen voor deze voldane regels vormen onze applicatiekansen.

Het bovenstaand voorbeeld bevat enkel applicaties in de consequence. We kunnen echter ook

rekening houden met de applicaties die we reeds geopend hebben sinds het toestel uit standby

is gegaan. Dan zijn regels zoals de volgende ook belangrijk:

[51%] Location 1, Time 5, Agenda ==> Email

[33%] Location 1, Time 1, (Agenda, Email) ==> GoogleMaps

Dergelijke regels bevatten namelijk ook applicaties in de premise.

6.2.2 Intra-applicatie correlatie

De associatieregels die we tot hiertoe hebben besproken houden telkens rekening met de ver-

schillende contextuele parameters zoals plaats, tijd, enzoverder. Dit is niet altijd nodig. Het

associatie-algoritme is immers ook in staat om regels te vinden tussen de verschillende appli-

caties wanneer deze patronen onafhankelijk zijn van contextuele parameters. Stel dat we vaak

de applicaties Facebook, Youtube en Email samen gebruiken, onafhankelijk van parameters zoals

de tijd en de plaats, dan is een regel zoals de volgende mogelijk:

[77%] Facebook, Email ==> Youtube

Met andere woorden, wanneer een gebruiker de applicaties Facebook en Email reeds heeft

geopend zal hij of zij in 77% van de gevallen ook Youtube openen.

6.3 Statistisch algoritme voor kortetermijngeheugen 54

6.3 Statistisch algoritme voor kortetermijngeheugen

Om applicaties aan te bevelen kunnen we ook rekening houden met de applicaties die een

gebruiker zeer recent heeft geopend. Indien een gebruiker recent voortdurend een welbepaalde

applicatie heeft geopend dan is dit wellicht een patroon en is de kans groot dat ze weldra

weer zal worden geopend. Om rekening te houden met recent geopende applicaties werken

we met een kortetermijnvenster. Dit venster stelt het kortetermijngeheugen voor en bepaalt

welke applicaties als recent beschouwd worden. Enkel deze applicaties krijgen een kortetermijn-

probabiliteit verschillend van 0. Indien een applicatie probabiliteit 0 heeft betekent dit dat de

applicatie onbelangrijk is indien we enkel zouden rekening houden met het recent verleden.

De venstergrootte bepaalt welke applicaties binnen het recent verleden vallen. In onze POC

zullen we deze grootte voor de eenvoud definieren als een aantal meest recent geopende appli-

caties. Stel nu dat in een simplistisch voorbeeld deze grootte gelijk is aan 9 en we de volgende

3 situaties hebben:

Situatie 1 Situatie 2 Situatie 3

Email X1 X1

Email X2 X2

Email X3 X3

X1 Email X4

X2 Email X5

X3 Email X6

X4 X4 Email

X5 X5 Email

X6 X6 Email

? ? ?

Hierbij zijn de applicaties Xi eender wat behalve Email. Stel nu dat we voor deze 3 situaties,

gegeven de 9 recent geopende applicaties, de kans willen berekenen dat de volgende applicatie

Email zal zijn. Dan merken we dat deze kans voor alle situaties gelijk is aan 3/9. Onze

verwachting is daarentegen dat de kans groter zal zijn in de laatste situatie omdat de 3 meest

recent geopende applicaties ook Email waren. In de eerste situatie verwachten we dat de kans

het kleinst is omdat de 6 laatste applicaties de eerste 3 instanties van Email als het ware doen

vergeten. Wat we wensen heeft te maken met het Stability Plasticity dilemma. Hierbij wenst

men nieuwe dingen bij te leren en oude dingen te vergeten zonder dat dit op een onstabiele

manier gebeurt.

6.4 Classificatie 55

Om dit te verwezenlijken zullen we rekening houden met het indexnummer. Hoe hoger dit

indexnummer is, hoe recenter de applicatie. De aangepaste kans wordt dan in de eerste situatie

gelijk aan (1+2+3)/3 = 2. In de tweede situatie hebben we kans (4+5+6)/3 = 5 en in de derde

situatie (7+8+9)/3 = 8. Deze kansen dienen uiteraard nog genormaliseerd te worden door ook

rekening te houden met de kansen van Xi.

Echter, het gemiddelde van de 9 indexnummers is 5. Dit is gelijk aan de kans van Email

in de tweede situatie. De genormaliseerde kans zal hier dus gelijk zijn aan 50% terwijl ze in

het eerste geval veel lager en in het derde geval veel hoger zal zijn. Dit komt overeen met onze

verwachtingen.

6.4 Classificatie

Tot slot kunnen de verschillende probabiliteiten van de applicaties gecombineerd worden om

een totale aanbeveling te verkrijgen. Experimenteel dient er gezocht te worden of we van cor-

responderende applicaties beter de maximum-probabiliteit nemen, een gewogen probabiliteit,

enzoverder. Figuur 6.6 toont dit concept. De functie f() combineert alle kansen van de ver-

schillende vensters tot totale applicatiekansen. Naargelang de doeltreffendheid kan deze functie

bijvoorbeeld ingevuld worden door een max -functie, door een gewogen-som-functie of door an-

dere geschikte functies.

Er bestaat in dit schema nog veel ruimte om te experimenteren. Naargelang we andere pa-

rameters gebruiken kunnen we betere resultaten bekomen. Volgende zaken zijn nog aanpasbaar:

• Periodiciteit van de monitoring van data

• Spelen met de parameters van het EM clustering-algoritme

• Filtering van associatieregels op basis van de support of de confidence

• Andere evaluatiecriteria dan de confidence bij de associatieregels

• De grootte van het kortetermijnvenster

• De invulling van de classificatiefunctie f()

• ...

6.4 Classificatie 56

CLUSTERING

AlarmClock P1Agenda P2Email P3Facebook P4Music P5Phone P6QuickOffice P7Youtube P8

AlarmClock P1'Agenda P2'Email P3'Facebook P4'Music P5'Phone P6'QuickOffice P7'Youtube P8'

Classificatie

f()

AlarmClock P1''Agenda P2''Email P3''Facebook P4''Music P5''Phone P6''QuickOffice P7''Youtube P8''

New clustered instance: (Location 1, Day 2, Time 5, Speed 1, Profile 1, [Music, Email])

AlarmClock P1'''Agenda P2'''Email P3'''Facebook P4'''Music P5'''Phone P6'''QuickOffice P7'''Youtube P8'''

PROFIELAFHANKELIJKEPATRONEN

GRAFENALGORITME


STATISTISCHALGORITME


ASSOCIATIEREGELS

Figuur 6.6: Finale aanbeveling: combinatie van de applicatiekansen door een classificatiefunctie

RAAMWERK 57

Hoofdstuk 7

Raamwerk

7.1 Inleiding

In dit hoofdstuk zullen we een oplossing beschrijven voor de probleemstelling in Hoofdstuk 1.

Aan de hand van enkele use cases zullen we beschrijven waaraan onze applicatie dient te voldoen.

Dit vormt de basis voor de architectuur. De technieken en algoritmes die we voor elk scenario

zullen gebruiken werden besproken in Hoofdstuk 5 en 6.

7.2 Deployment

Het systeem is ontworpen via een Client-Server-architectuur zoals weergegeven in Figuur 7.1.

De client-applicatie op het Android mobiel toestel bestaat uit een widget en een service. De

service communiceert met een Apache Tomcat server via het REST-protocol.

Weka Library

«device»Android Device «web server»

Apache Tomcat v7.0 Server

Spring Android REST Template

REST protocol

«Widget»InproWidget

«Service»InproClient

«Service»InproServer

Figuur 7.1: Deployment Diagram

7.3 Fix, Profiel en Classificatie 58

7.3 Fix, Profiel en Classificatie

De basis van de High Level architectuur van ons systeem zijn de objecten Fix, ProfileInfo en

Classification. Dit zijn de communicatie-objecten tussen de Android client en de server. De

client-applicatie zal op een periodieke manier contextuele gegevens van de gebruiker monitoren:

• plaats (lengtegraad en breedtegraad)

• weekdag

• tijdstip (in decimale vorm)

• gemiddelde snelheid waarmee de gebruiker zich rond die tijd voortbeweegt

• applicatie die zich op dat moment op de voorgrond bevindt

Voor de applicatie slaan we telkens de package-name van de applicatie op. Deze wordt bi-

jgehouden in het datatype String, bijvoorbeeld voor Facebook is dit com.facebook.home. De

bundeling van al de gegevens die gemonitord werden wordt doorgaans een Fix genoemd. Dit

wordt weergegeven in Figuur 7.2.

«Interface»Classification

+getProfile(): id+getApplications(): Application[]

«Interface»Fix

+getDate(): String+getDecimalTime(): double+getDayOfWeek(): String+getSpeed(): float+getLongitude(): double+getLatitude(): double+getApplications(): String[]+getMusicPlaying(): boolean

«Interface»ProfileInfo

+getId(): int+getAverageSpeed(): String+getAverageLongitude(): double+getAverageLatitude(): double

Figuur 7.2: Fix-, Classification- en ProfileInfo-object

Zoals we kunnen zien in Figuur 7.2 kan een Fix meerdere applicaties bevatten. Dit komt

omdat we dit Fix -object niet enkel zullen gebruiken voor monitoring maar ook voor classificatie.

Net zoals bij de monitoring zal er periodiek een classificatie gebeuren. Hierbij willen we op

basis van de huidige contextuele gegevens via de server te weten komen in welk profiel we ons

momenteel bevinden en wat de rangorde van de meest kanshebbende applicaties is. Tijdens

deze classificatie zal de server ook rekening houden met de applicaties die de gebruiker heeft

7.4 Diensten van de server 59

geopend sinds de laatste keer dat het toestel uit standby is gegaan. Aangezien dit meer dan een

applicatie kan zijn kunnen we in het Fix -object meerdere applicaties bijhouden. Het Fix -object

bevat ook een boolean-methode getMusicPlaying() omdat het afspelen van muziek op Android

geen applicatie is maar een service. Dit moeten we dan ook apart afhandelen.

We gebruiken een Fix -object dus voor de communicatie van de Android client naar de server.

Verder wordt er ook een lijst van standby-timestamps verzonden naar de server. Het nut hiervan

wordt later duidelijk. De twee andere basisobjecten worden gebruikt voor de terugkerende

communicatie van de server naar de client:

• ProfileInfo: dit object bevat informatie over een bepaald profiel. Naast een identificatie

van het profiel bevat dit object een uitgemiddelde snelheid en de typische locatie waarin

het profiel zich het meest situeert. Deze gegevens zullen in de client applicatie worden

gebruikt, zie sectie 7.6. De verschillende ProfileInfo-objecten zullen worden teruggegeven

bij het genereren of updaten van profielen.

• ClassificationInfo: dit object wordt gebruikt bij de classificatie en bevat de profielidenti-

ficatie en de rangorde van applicaties.

7.4 Diensten van de server

De diensten van de server kunnen we indelen in twee categorieen: clustering en classificatie. We

zullen eerst een algemeen beeld geven over wat beide categorieen juist inhouden in ons raamwerk.

Nadien zullen we op elk van de twee categorieen dieper ingaan en de gebruikte objecten meer

gedetailleerd illustreren.

Clustering

De verwerking op de server bestaat uit twee fases. De eerste fase is de clusteringsfase. Deze

fase wordt weergegeven in Figuur 7.7. We illustreren de fase aan de hand van het voorbeeld in

Figuur 7.3:

• Stap 1 De Fixes die de server ontvangt van de client worden eerst geclusterd. Zoals

geıllustreerd in Hoofdstuk 5 zal er eerst op de standaardattributen geclusterd worden. In

deze stap wordt de data geclusterd op het attribuut location. Dit geeft bijvoorbeeld 3

clusters zoals in de figuur. Voor elke cluster wordt een ClusteredAttribute aangemaakt met

het id van de cluster in het Weka-algoritme.

• Stappen 2 tem 5 Analoog worden in de volgende stappen de Fixes geclusterd op de

andere attributen.


ClusteredAttributeattributeName: Locationvalue: 1

ApplicationSetlocationspeed...profileapplications AttributeAssociationRule

confidence: 100%premise: Musicconsequence: Facebook


ClusteredAttributeattributeName: Speedvalue: 1

ClusteredAttributeattributeName: Speedvalue: 2


ClusteredAttributeattributeName: Profilevalue: 1



...

ApplicationSetlocationspeed...profileapplications

FacebookMusic

EmailBrowserQuickOffice

...

ApplicationSetlocationspeed...profileapplications

MusicFacebookMusic

location attribute

speed attribute

profile attribute

1

...

...

2

5

6

6

7

7

7

7

6

AttributeAssociationRuleconfidence: 66%premise: (Location, 2), (Speed, 1)consequence: Facebook

...

8

...

Figuur 7.3: Voorbeeld van de eerste serverstap: clustering

• Stap 6 Zoals geıllustreerd in Hoofdstuk 5 wordt er ook geclusterd op een tweede niveau: de

applicaties. De opeenvolgende applicaties worden geclusterd aan de hand van de standby-

timestamps die we krijgen van de client. In de figuur hebben we zo 3 groepen. De groepen

(Facebook, Music) en (Email, Browser, QuickOffice) zijn van elkaar afgescheiden omdat

de gebruiker daartussen in standby ging.

• Stap 7 Dit resulteert in een lijst van ApplicationSet-objecten van gegroepeerde applicaties.

Deze kunnen we in nu linken aan hun attribuutclusters door van de applicatiegroepen de


bijhorende attributen (locatie, snelheid, ...) te laten classificeren door Weka. Tijdens

het clusteren in stap 1 tot 5 heeft Weka immers een model opgebouwd waardoor we de

gegevens nu snel kunnen classificeren. Voor elk van de attributen zal Weka een cluster-id

teruggeven. Deze id’s identificeren de ClusteredAttribute-objecten.

• Stap 8 Deze ApplicationSet-objecten kunnen we meegeven aan het associatieregelalgo-

ritme die allerlei associatieregels zal ontdekken tussen de verschillende attribuutclusters

en de applicaties. Dit werd besproken in Hoofdstuk 6. Enkele mogelijke regels worden

weergegeven in de figuur.

Zoals in Figuur 7.7 te zien is wordt tijdens deze stap ook het profielvenster opgebouwd en worden

de profielclusters geanalyseerd. Deze clusters representeren de Android profielen waarvan de

gemiddelde snelheid en de gemiddelde lengte- en breedtegraad worden berekend. Deze informatie

wordt in de vorm van ProfileInfo-objecten teruggegeven aan de client-applicatie.

Classificatie

De tweede fase is de classificatie. We krijgen hiervoor een enkele Fix van de client om te

classificeren. De classificatie gebeurt analoog als in stap 7 in het voorbeeld uit Figuur 7.3. De

contextuele gegevens uit de Fix worden namelijk door Weka geclassificeerd en gelinkt aan de

attribuutclusters. Dit geeft een ApplicationSet-object. Vervolgens worden de applicatiekansen

van dit object berekend door de drie verschillende classificatievensters.

7.4.1 Clustering

De objecten voor clustering worden weergegeven in Figuur 7.4. Per attribuut dat er geclusterd

«enum»ClusteringType

Location, DayOfWeek, Time, Speed, Profile

«Interface»ClusterGroup

+getClusteringType(): ClusteringType+getNumberOfClusters(): int

Figuur 7.4: ClusterGroup- en ClusteringType-objecten

wordt zal er een ClusterGroup-object gegenereerd worden. Zo zal er een dergelijk object gemaakt

worden voor locatie, analoog een dergelijk object voor tijd, enzoverder. Om de modulariteit van

de server te optimaliseren werken we met een enum ClusteringType. Via dit enum wordt bepaald

op wat er moet geclusterd worden. Een cluster van het attribuut profiel is het resultaat van het


clusteren op alle andere attributen samen. Deze clusters vormen dan ook de eigenlijke Android

profielen uit ons systeem.

Een ClusterGroup-object bevat het attribuut waarvoor de clusters relevant zijn (aangeduid

via ClusteringType) en het aantal clusters in de groep. Enkel dit aantal wordt bijgehouden en

niet de verschillende Fix -objecten per cluster. Stel dat dit aantal gelijk is aan 3, dan weten we

dat er voor dit attribuut 3 clusters zijn met ids die respectievelijk gelijk zijn aan 0, 1 en 2.

7.4.2 Classificatie

Profielvenster

Om het profielvenster op te bouwen hebben we de basiscomponenten uit de grafentheorie nodig:

een object ProfileGraph die de graaf van het profiel voorstelt en objecten ApplicationVertex en

ApplicationEdge voor de knopen en de bogen. Deze worden weergegeven in Figuur 7.5. Op basis

«Interface»ApplicationEdge

+getFrom(): ApplicationVertex+getTo(): ApplicationVertex+getNumInstances(): int+getMeanTime(): double

«Interface»ProfileGraph

+getProfileId(): int+addVertex(vertex: ApplicationVertex)+getVertices(): List<ApplicationVertex>+addEdge(edge: ApplicationEdge)+getEdges(): List<ApplicationEdge>

«Interface»ApplicationVertex

+getApplicationName(): String+getNumInstances(): int

Figuur 7.5: ApplicationVertex-, ApplicationEdge- en ProfileGraph-objecten

van deze stap komen we per profiel te weten welke applicaties het meest gebruikt worden in het

profiel en welke sequentiele overgangen tussen de applicaties de meeste invloed hebben.

Het object ApplicationVertex dient enkel de naam van de applicatie te bevatten en het

aantal keer dat de applicatie reeds werd gebruikt in het profiel. Een ApplicationEdge bevat

de startknoop en de eindknoop (ApplicationVertex -objecten). Daarnaast worden ook het aantal

keer dat de transitie werd genomen en de gemiddelde tijd tussen de twee applicaties bijgehouden.

Een ProfileGraph-object bevat het id van het corresponderende profiel. Hier hebben we ook

methodes nodig om knopen en bogen toe te voegen aan de graaf.

7.5 Server architectuur 63

Associatieregels

De clustering in fase 1 levert een verzameling van ApplicationSet-objecten op. Hiervoor hebben

we een ClusteredAttribute-object nodig dat een koppel (naam, cluster) van een bepaald at-

tribuut voorstelt. De objecten ApplicationSet, ClusteredAttribute en AttributeAssociationRule

zijn te zien in Figuur 7.6. De ApplicationSet-objecten vormen de items voor het associatierege-

lalgoritme. Hierdoor kunnen we verbanden zoeken tussen de verschillende ClusteredAttribute-

objecten en de bijhorende applicaties, bijvoorbeeld:

(Location,2), (DayOfWeek,1), (Facebook, 1), (Youtube, 1), (Email, 1)

==>

(Browser,1)

Dit vormt de premise en de consequence van de regel (AttributeAssociationRule). Elke associ-

atieregel heeft ook een support en een betrouwbaarheidsfactor of een confidence.

«Interface»ClusteredAttribute

+getAttributeName(): String+getAttributeValue(): String

«Interface»ApplicationSet

+getlTime(): ClusteredAttribute+getDayOfTheWeek(): ClusteredAttribute+getSpeed(): ClusteredAttribute+getLocation(): ClusteredAttribute+getProfile(): ClusteredAttribute+getApplications(): List<String>

«Interface»AttributeAssociationRule

+getSupport(): double+getConfidence(): double+getPremise(): List<ClusteredAttribute>+getConsequence(): List<ClusteredAttribute>

Figuur 7.6: ApplicationSet-, ClusteredAttribute- en AttributeAssociationRule-objecten

Kortetermijngeheugen

Het laatste classificatiemiddel bevindt zich binnen een kortetermijnvenster. Dit is een eenvoudig

algoritme dat werd besproken in Hoofdstuk 6.

7.5 Server architectuur

We zullen nu de kerncomponenten van de architectuur van de server bespreken. In Figuur

7.9 zie je de verschillende componenten opgesplitst in webfunctionaliteit en kernfunctionaliteit.

Voor elke webfunctionaliteit hebben we een bijhorende kerncomponent. De twee hoofdfunction-

aliteiten zijn het genereren of updaten van profielen en het classificeren van de gebruiker. De


:ClusterEngine

bouw applicatiesets(arg: Fixes-lijst,

standby-timestamps)

cluster Fixes op 'locatie'

:Weka EM

return aantal clusters

cluster Fixes op 'profiel'

return profielen

...

1e niveau clustering: standaardattributen

2de niveau clustering: applicaties

genereer clustergroep voor 'locatie'

genereer clustergroep voor 'profiel'

cluster Fixes op applicatiesdmv standby-timestamps

return ApplicationSet-lijst

Profielen

:ProfileEngine

voeg items toe (arg: ApplicationSet-lijst) en bouw associatieregels

bouw associatieregelsreturn associatieregels

bouw profielvenster

opvragen van profielen

return aantal clusters

bouw profielvenster

Fixes

ProfileInfosgenereerProfileInfos

return profielen

:ProfileWindowEngine

:AssociationRule

Engine

standbytimestamps

Fixes

Figuur 7.7: Sequentiediagram van de eerste serverstap: clustering

lichtgrijze componenten leveren de high-level architectuur hiervoor. De meer low-level archi-

tectuur en de algoritmes voor clustering en classificatie worden verzorgd door de donkergrijze

componenten.


:Clu

ster

Eng

ine

clas

sific

eer

(arg

: Fix

)

clas

sify

Fix

op

'loca

tie'

:Wek

a E

M

retu

rn c

lust

er-id

clas

sify

Fix

op

'pro

fiel'

...

clas

sifi

cati

e: s

tan

daa

rdat

trib

ute

n

retu

rn A

pplic

atio

nSet

Pro

fiel

-id

:Ass

ocia

tion

Rul

eE

ngin

e

:Cla

ssifi

er bere

ken

appl

icat

ieka

nsen

ahv

eer

der

opge

bouw

de a

ssoc

itier

egel

s (a

rg: A

pplic

atio

nSet

)

upda

te p

rofie

lven

ster

en

bere

ken

appl

icat

ieka

nsen

(ar

g: A

pplic

atio

nSet

)

:Pro

file

Win

dow

Eng

ine

retu

rn c

lust

er-id

Fix

retu

rn a

pplic

atie

kans

en

retu

rn a

pplic

atie

kans

en

:Rec

ent

Win

dow

Eng

ine

upda

te r

ecen

t geh

euge

n en

ber

eken

app

licat

ieka

nsen

(ar

g: A

pplic

atio

nSet

)re

turn

app

licat

ieka

nsen

clas

sific

eer

kans

ento

t tot

ale

kans

envi

a cl

assi

ficat

iefu

nctie

f()

Cla

ssif

icat

ion

Fig

uu

r7.

8:Seq

uen

tied

iagr

amva

nd

etw

eed

ese

rver

stap

:cl

assi

fica

tie


Classify, rank applications

web

core

«component»

AssociationRuleEngine

«component»

ProfileManager

«component»

Classifier

«component»

ClusterEngine

«component»

ProfileWindowEngine

«component»

ShortTermWindowEngine

«webservice»

ProfileResource

«webservice»

ClassificationResource

Generate profiles

Figuur 7.9: Component Diagram Server 1


De Engine-klassen implementeren de core-functionaliteit en de data mining technieken. Alle

engines hebben een build -methode om de data mining uit te voeren en een get-methode om

de resultaten ervan op te vragen. Deze opsplitsing hebben we gemaakt omdat het opbouwen

en het opvragen niet altijd bij elkaar hoeven te horen. De associatieregels worden bijvoorbeeld

opgebouwd na de generatie en updating van de clusters terwijl deze regels pas bruikbaar zijn

bij de classificatie. Het is immers pas bij de classificatie dat we de nodige premise van de regels

kennen en weten welke associatieregels toepasselijk zijn.

7.5.1 ClusterEngine

De ClusterEngine zal alle Fix -objecten clusteren zoals besproken in Hoofdstuk 5. Dit levert

een lijst van ApplicationSet-objecten op. De eigenlijke clusteralgoritmes gebeuren door het

Expectation-Maximization algoritme in het Weka framework aan de hand van datastructuren

die we zelf meegeven. De interface van onze klasse is echter modulair en daardoor kan de

clustering ook door andere frameworks of algoritmes gebeuren. Tijdens deze clustering wordt

door Weka een clustermodel opgebouwd waardoor we nadien via hetzelfde model ook een nieuw

data-object kunnen clusteren in een van de gevonden clusters. Dit hebben we nodig tijdens de

classificatie om de contextuele gegevens van een gebruiker toe te kennen aan clusters. Dit levert

enerzijds een ApplicationSet-object op dat we kunnen mappen met de gevonden associatieregels.

Anderzijds weten we hierdoor in welk profiel de gebruiker zich bevindt.

7.5.2 AssociationRuleEngine

De AssociationRuleEngine dient methodes te bevatten om items aan de itemset toe te voegen

voor het A Priori algoritme. Daarnaast bevat het methodes om de associatieregels op te bouwen

en om ze op te vragen. Het eigenlijke A Priori algoritme wordt eveneens gebruikt via het Weka

framework aan de hand van onze eigen datastructuren. De items voor het algoritme zijn de

ApplicationSet-objecten. De resulterende associatieregels worden omgezet naar AttributeAsso-

ciationRule-objecten. Hierbij dient er nog een filtering te gebeuren. De volgende regel

(Location,4), (Facebook, 1), (Youtube, 1), (Email, 1)

==>

(DayOfWeek,1)

is een voorbeeld van een regel die voor bepaalde doeleinden nuttig kan zijn, maar voor de proof-

of-concept demonstrator dat wij willen maken is de regel niet echt bruikbaar. Dit komt omdat

de consequence geen applicaties bevat en naar dergelijke regels zijn we immers wel op zoek. Deze


filtering wordt meteen na het opbouwen van de regels gedaan zodat de eigenlijke opzoeking van

regels tijdens de classificatie performanter en efficienter kan gebeuren.

7.5.3 Andere engines

Tijdens de build -methode van het ProfileWindowEngine worden de grafen uit sectie 6.1 opge-

bouwd. Tijdens de classificatie zoekt de get-methode vervolgens uit wat de meest recent

geopende applicatie is en wanneer die werd geopend. Deze applicatie wordt dan vergeleken

met de graaf van het huidige profiel en op basis hiervan wordt voor elke applicatie bepaald wat

de theoretische probabiliteit is dat ze momenteel zal worden geopend.

De ShortTermWindowEngine bouwt een venster op van de meest recent geopende applicaties

zoals in sectie 6.3. Dit levert voor elk van deze applicaties alweer een probabiliteit op.

Add items, buildassociation rules

«component»

AssociationRuleEngine

«component»

ClusterEngine

«component»

ProfileWindowEngine

«component»

Classifier

«component»

ShortTermWindowEngine

«component»

ProfileManager

Build clustersand profiles

Build recent window,Get recent window

Get application names,Classify fix

Get fixes

Get profile window

Classification

Clustering

Buildprofilewindow

Getassociationrules

Figuur 7.10: Component Diagram Server 2

7.5.4 ProfileManager

De ProfileManager is het aanspreekpunt tussen de webservice ProfileResource en de kernfunc-

tionaliteiten. Deze component dient een methode te bevatten voor het genereren van clusters

en profielen. Deze methode zal eerst de build -methode van de ClusterEngine aanroepen. Dit

levert de nodige profielen. Vervolgens zullen er items worden toegevoegd aan de Association-


RuleEngine en zullen de regels worden opgebouwd. Tot slot zal ook het profielvenster van de

ProfileWindowEngine worden opgebouwd.

7.5.5 Classifier

De Classifier is het aanspreekpunt tussen de webservice ClassificationResource en de core-

functionaliteiten. Hier hebben we een methode nodig om een Fix te classificeren door een

profielidentificatie en een rangorde van applicaties terug te geven. Hiervoor zullen de verschil-

lende classificatietechnieken gecombineerd worden door eerst de get-methodes van Association-

RuleEngine, ProfileWindowEngine en ShortTermWindowEngine op te roepen en nadien een

totale gewogen som van alle probabiliteiten te berekenen.

7.5.6 Webservices

De webservices dienen ter communicatie met de client-applicatie. Dit gebeurt via het REST-

framework. Er dient per object-resource een klasse aangemaakt te worden. Daarom hebben we

een ProfileResource voor het genereren van profielen (ProfileInfo-objecten) en een Classifica-

tionResource voor de classificatie (ClassificationInfo-objecten).

7.5.7 Klassendiagram

In Figuur 7.11 worden alle servercomponenten weergegeven die we zonet hebben besproken.


«WebService»ProfileResource

+generateProfiles(fixes: List<Fix>, standbys: List<Date>): List<ProfileInfo>

«Interface»Classification

+getProfile(): ProfileInfo+getApplications(): Application[]

«Interface»Fix

+getDate(): String+getDecimalTime(): double+getDayOfWeek(): String+getSpeed(): float+getLongitude(): double+getLatitude(): double+getApplications(): String[]+isMusicPlaying(): boolean

«Interface»ShortTermWindowEngine

buildRecentApplicationWindow(fixes: List<Fix>): voidgetRecentApplicationWindow(): List<String>

«Interface»AssociationRuleEngine

+addItem(item: ApplicationSet)+setItems(items: List<ApplicationSet>)+buildRules(): void+getRules(): List<AttributeAssociationRule>

«Interface»Classifier

rankApplications(fix: Fix): Classification


+getId(): int+getAverageSpeed(): String+getAverageLongitude(): double+getAverageLatitude(): double

«Interface»AttributeAssociationRule

+getSupport(): double+getConfidence(): double+getPremise(): List<ClusteredAttribute>+getConsequence(): List<ClusteredAttribute>

«Interface»ApplicationSet

+getlTime(): ClusteredAttribute+getDayOfTheWeek(): ClusteredAttribute+getSpeed(): ClusteredAttribute+getLocation(): ClusteredAttribute+getProfile(): ClusteredAttribute+getApplications(): List<String>

«Interface»ClusteredAttribute

+getAttributeName(): String+getAttributeValue(): String

«enum»ClusteringType

Location, DayOfWeek, Time, Speed, Profile

«Interface»ProfileManager

+generateProfiles(fixes: List<Fix>, unsentFixes: List<Fix>): List<ProfileInfo>

«Interface»ClusterGroup

+getClusteringType(): ClusteringType+getNumberOfClusters(): int

«Interface»ProfileWindowEngine

buildProfileWindow(fixes: List<Fix>): voidgetProfileWindow(): List<ProfileGraph>

«Interface»ClusterEngine

+buildApplicationSets(fixes: List<Fix>, standbyDates: List<Date>): void+getApplicationSets(): List<ApplicationSet>+classifyFix(Fix fix): ApplicationSet+getClusterGroups(): List<ClusterGroup>+getApplicationNames(): List<String>

«WebService»ClassificationResource

+classifyFix(fix: Fix): Classification

«Interface»ApplicationEdge

+getFrom(): ApplicationVertex+getTo(): ApplicationVertex+getNumInstances(): int+getMeanTime(): double

«Interface»ApplicationVertex

+getApplicationName(): String+getNumInstances(): int

«Interface»ProfileGraph

+getProfileId(): int+addVertex(vertex: ApplicationVertex)+getVertices(): List<ApplicationVertex>+addEdge(edge: ApplicationEdge)+getEdges(): List<ApplicationEdge>

«Interface»Application

+getName(): String+getProbability(): double

«Interface»UnweightedApplication

+getName(): String+getProfileProbability(): double+getAssociationProbability(): double+getRecentProbability(): double

Figuur 7.11: Klassendiagram Server

7.6 Client architectuur 71

7.6 Client architectuur

7.6.1 Algemeen

De Client architectuur is opgebouwd via het Model-View-Controller Pattern.

«component»

Model

«component»

View

Android Widget: InproWidget

«component»

Controller

Notify changes

Android Service: InproClient

Change settings

Figuur 7.12: Component Diagram Android Client

InproWidget is een widget die instaat voor het visualiseren van informatie omtrent het

huidige profiel en de applicaties die geassocieerd zijn met dit profiel. Het toont informatie zoals

de gemiddelde locatie (longitude en latitude), gemiddelde snelheid en het id van het profiel.

Hiernaast wordt er voor elk profiel ook bijgehouden welke contactpersoon (of nummer) het

laatste gebeld is geweest. Wanneer de gebruiker naar deze persoon wil bellen, kan hij met een

simpele druk op de knop linksbovenaan deze persoon terug bellen. Voor elk van de profielen

is er ook een geluidsmodus instelbaar (normaal, stil of enkel trillen). De widget toont op elk

moment ook een piramide van de 6 hoogstgerecommendeerde applicaties. Men kan op elk van

deze icoontjes drukken waarna de desbetreffende applicatie zal openen. Een screenshot van de

widget wordt weergegeven in Figuur 7.13.

De InproClient is een service die instaat voor alle operaties die dienen te gebeuren op het

android-toestel. We kunnen vier grote operaties onderscheiden op de client:

• Het monitoren van gegevens op het toestel

• Het (intern) opslaan van de getrackte gegevens

• Het doorsturen van deze gegevens naar de server


Figuur 7.13: Screenshot van de widget

• Het aanbevelen van applicaties naar de widget toe

We zullen nu elk van deze operaties bespreken.

7.6.2 Monitoring

De klasse monitor staat in voor het tracken van volgende gegevens

• Tijd

• Locatie

• Snelheid

• Wordt er muziek gespeeld?

• Welke applicaties lopen er in de voorgrond

Deze informatie wordt opgeslagen in een object dat we Fix noemen. Via twee methodes kan de

huidige fix worden opgevragen via de klasse Monitor. Enerzijds door getMostRecentFix, deze zal

een fix genereren op het moment van aanroepen. De methode getMostRecentClusteredFix zal

ook een fix genereren, maar het verschil zit hem in de applicaties die in deze fix zijn opgenomen.

Bij de laatste zijn niet enkel de huidige applicaties opgenomen, maar alle unieke applicaties die

geopend zijn sinds de laatste keer dat het toestel in standby ging.


Het detecteren van standbymode hebben we als volgt gedaan: we hebben eerst een klasse

aangemaakt die BroadcastReceiver overerft. Hierdoor kunnen we intents opvangen die ges-

tuurd zijn via sendBroadcast. De intents die we met deze klasse willen opvangen zijn AC-

TION SCREEN OFF en ACTION SCREEN ON. Deze intents worden gebroadcast wanneer

het toestel in standby gaat, of terug wakker wordt. Een boolean met deze informatie wordt

doorgestuurd naar een service (UpdateService). Deze staat in communicatie met de klasse

Monitor en zorgt dat deze op de hoogte is van het toestand van het scherm.

Gegevens over locatie en snelheid ontvangt Monitor via de klasse LocationProvider. Deze

bevat een eigen implementatie van LocationListener. Deze zal bij het veranderen van de locatie

van het device een methode oproepen met als argument een Location object (deze bevat infor-

matie zoals longitude, latitude, snelheid,...). Deze informatie wordt vervolgens opgeslagen in de

klasse. Omdat niet elke provider de snelheid meegeeft aan het Location object hebben we ervoor

geopteerd om de snelheid zelf te berekenen. De nauwkeurigheid van de snelheid is niet steeds

optimaal, maar voldoende voor wat wij nodig hebben.

7.6.3 Storage

In de klasse Storage worden de fixes intern opgeslagen. Op een periodieke basis wordt de meest

recente fix opgevraagd aan de klasse Monitor en wordt deze opgeslagen in een lijst. Indien we een

aantal fixes hebben bereikt, zal de webservicemethode generateProfiles worden opgeroepen. We

geven als argumenten de ongezende fixes mee alsook de tijdstippen waarop het toestel in standby

ging. Een lijst met de gedetecteerde profielen wordt teruggegeven. Hierop zal Storage bij elk

nieuw profiel een bijhorende settingsbestand maken dat op de SD-card wordt bewaard. Wanneer

voor het eerst het aantal fixes is bereikt, zal de klasse Recommender worden aangemaakt.

7.6.4 Recommender

In de klasse Recommender wordt periodiek de webservice classifyFix aangesproken. Als argu-

ment wordt de meest recente fix meegegeven. Een Classification-object wordt teruggegeven en

dit wordt naar de widget gestuurd.

7.6.5 Webservices

In de klasse WebServiceCommunicator wordt gecommuniceerd met de server. Dit gebeurt via

RESTful web services.


7.6.6 Klassendiagram

In het klassendiagram uit Figuur 7.14 zien we de architectuur van de InproClient. De Main

zal de nodige instanties maken en services starten. Eerst zal Storage starten en periodiek

gegevens opslaan. Dit gebeurt met behulp van LocationProvider die luistert naar nieuwe locaties.

Wanneer het aantal fixes bereikt is, zullen ze via WebServicesCommunicator naar de server

worden gestuurd (als een FixList). Een ProfileInfoList-object wordt teruggegeven aan de client.

Hieropvolgend zal Recommender worden gestart en periodiek aan de server vragen wat het

huidige profiel is (aan de hand van een meegegeven fix). Hierbij wordt een Classification-object

teruggegeven.

«TimerTask»Recommender

+run()

«Class»WebServicesCommunicator

+generateProfiles(fixes: List<Fix>, standbyDates: List<Dates>)+classifyFix(fix: Fix): Classification

«TimerTask»Storage

+run()+getUnsentFixes(): List<Fix>+clearUnsentFixes()

«Class»Monitor

+getMostRecentFix(): Fix+getMostRecentClusteredFix(): Fix+getStandbyDates: List<Date>+setScreenOn: boolean

«Class»Classification

+getProfileInfo(): ProfileInfo+getApplications: String[]


+getId(): int+getSpeed(): double+getLongitude(): double+getLatitude(): double

«Class»Fix

+getDate(): String+getDecimalTime(): double+getDayOfWeek(): String+getSpeed(): float+getLongitude(): double+getLatitude(): double+getApplications(): String[]+getMusicPlaying(): boolean

«Class»LocationProvider

+getDecimalTime(): double+getDayOfWeek(): String+getSpeed(): float+getLongitude(): double+getLatitude(): double

«Service»InproClient

-STORAGE_INTERVAL: long-STORAGE_FIXES: long-RECOMMENDER_INTERVAL: long+onBind(intent: Intent): IBinder

«LocationListener»MyLocationListener

+onLocationChanged(location: Location)

«Activity»Main

+StartService(view: View)+StopService(view: View)

«Class»FixList

+getFixes: List<Fix>+getStandbyDates: List<Date>

«Interface»ProfileInfoList

+getProfileInfos: List<ProfileInfo>

Figuur 7.14: Klassendiagram Android Client

EVALUATIE 75

Hoofdstuk 8

Evaluatie

De evaluatie in deze scriptie zal zich vooral focussen op de nauwkeurigheid en de performantie van

de verschillende algoritmes voor clustering en classificatie. Een evaluatie voor profielherkenning

door middel van clustering werd reeds gedaan in Hoofdstuk 4. Daarom zal nu voornamelijk de

finale aanbeveling van applicaties geevalueerd worden. De verschillende classificatie-algoritmes

zullen zowel individueel als samen geevalueerd worden. Daarnaast zal ook de performantie van

de client-applicatie en de netwerktrafiek geevalueerd worden.

8.1 Testomgeving

Het grootste probleem voor de evaluatie in deze scriptie is het gebrek aan realistische en bruik-

bare testdata. Om structuren en patronen te kunnen vinden in het applicatiegebruik van een

persoon hebben we data nodig die dergelijke structuren en patronen effectief bevat. Een mo-

gelijke oplossing was om onze eigen Monitor-component in de client te gebruiken om data te

verzamelen door zelf een testtoestel te gebruiken en op een zeer regelmatige basis applicaties te

openen volgens bepaalde patronen en routines. Aan deze optie waren echter een aantal belan-

grijke nadelen verbonden:

• Een constante Internet-verbinding en dus een bijhorend abonnement is vereist.

• We kunnen de data niet meer aanpassen voor nieuwe requirements in de architectuur.

• Het verzamelen van deze testdata duurt lang dus wanneer er iets foutloopt tijdens het

tracken of in de data zelf kunnen we wellicht niet meer opnieuw beginnen binnen ons

tijdsframe.

• Het zelf toepassen en onderhouden van de patronen en routines vereist een grote aanpassing

in onze dagindeling. Bovendien zou dit slechts resulteren in een enkele case study waardoor

8.1 Testomgeving 76

we slechts beperkt kunnen evalueren.

Omwille van deze nadelen hebben wij gekozen voor een alternatief. We hebben zelf een tool

geschreven waarin we eenvoudig het applicatiegebruik van een persoon kunnen modelleren door

verschillende eigenschappen en parameters mee te geven. Dit model wordt nadien door de tool

vertaald naar testdata die we kunnen gebruiken voor analyse en als invoer voor onze evalu-

atiecomponent. Deze tool levert bovendien een aantal voordelen:

• Eens het applicatiegebruik gemodelleerd is kan het genereren en regenereren van data zeer

snel gebeuren.

• We kunnen meerdere case studies analyseren, van eenvoudige cases tot meer complexe.

• De tool laat veel ruimte om te experimenteren en wijzigingen in de testdata aan te brengen.

8.1.1 Modelling Tool

WAKE UPTRAIN (NORMAL)

WORK (NORMAL)

HOME (NORMAL)

TRAIN (NORMAL)

SLEEP (NORMAL)

WAKE UP

TRAIN (SLOW)

WORK (SHORT)

TRAIN (NORMAL)

WORK

WAKE UP

TRAIN

HOME

SLEEP

ApplicationPattern

AlarmClockaround

23h

ClusterPattern

EmailFacebook

P = 0,8

ClusterPattern

EmailFacebook

P = 0,8

ApplicationPattern

AlarmClockaround

23h

ClusterPattern

EmailFacebook

P = 0,8

RecentPattern

Youtube

ApplicationPattern

AlarmClockaround

23h

. . .

...

Agenda

Email

Facebook

Browser

Youtube

...

P1

P2

P3

P4

P5

8h9h

10h11h12h13h14h15h16h17h18h19h20h21h22h23h24h1h2h3h4h5h6h7h8h9h

10h11h12h13h14h15h16h17h18h19h20h21h22h23h24h1h

HOME (NORMAL)

Mon

Tue

StartProfilePattern

Agenda

ClusterPattern

EmailFacebook

P = 0,8

. . .. . .

Figuur 8.1: Ontwerp van de modelling tool

In Figuur 8.1 is het algemeen ontwerp van de Modelling Tool weergegeven. Het modelleren

van een bepaalde case gebeurt hierbij als volgt:

8.2 Opstelling 77

1. Als eerste stap kunnen we verschillende blokken genereren die vergelijkbaar zijn met de

profielen in onze applicatie. Voorbeelden van dergelijke blokken zijn Wake Up, Work,

Train, .... Deze blokken bevatten een reeks van coordinaten voor lengtegraad en breedte-

graad die een zekere random-component bevatten. Deze reeks van coordinaten kan varieren

in lengte voor bijvoorbeeld een volledige werkdag en een halve werkdag bij het blok Work.

2. Vervolgens kunnen we aan elk van deze blokken applicaties toekennen met een bepaalde

probabiliteit. In een Home-blok kunnen we bijvoorbeeld Facebook en Youtube een hogere

probabiliteit geven dan in andere blokken.

3. Er kunnen ook verschillende patronen gespecifieerd worden. Enkele voorbeelden van pa-

tronen zijn:

• Applicatiepatronen Een voorbeeld van een dergelijk patroon is het zetten van de

alarmklok, steeds rond 11u ’s avonds.

• Clusterpatronen Dit zijn applicaties die vaak samen gebruikt worden, bvb Facebook

en Email.

• Recente patronen Dit zijn patronen van applicaties die soms veelvuldig na elkaar

geopend worden.

Voor de meeste patronen kunnen we ook een probabiliteit toekennen. Bovendien kunnen

de meeste van deze patronen al dan niet gekoppeld worden aan een blok. Indien een

patroon gekoppeld wordt aan een blok is het enkel geldig voor dat blok. In het andere

geval is het patroon voor alle blokken geldig.

4. Eens we de blokken en patronen gedefinieerd hebben kunnen we verschillende blokken met

variabele grootte aan elkaar koppelen om aldus een dag- of weekindeling te genereren.

5. Tot slot wordt het model (de blokken en patronen) automatisch vertaald naar testdata.

Hierbij wordt periodiek data gegenereerd volgens een bepaalde tijdsas. Elke data-instantie

bevat algemene gegevens zoals lengtegraad, breedtegraad en tijdstip (afhankelijk van de

sequentiele blokken) en 0 of meerdere applicaties (afhankelijk van de toegekende proba-

biliteiten en patronen).

8.2 Opstelling

In Figuur 8.2 is de opstelling weergegeven die we gebruiken voor het evalueren van de profielgen-

eratie en de applicatierecommendatie. De idee is als volgt: indien we via hetzelfde model in de

8.2 Opstelling 78

Modelling Tool twee verschillende databestanden laten genereren zullen deze andere applicaties

bevatten, maar wel dezelfde structuren en patronen vertonen. Indien in het blok Work een hoge

probabiliteit werd toegekend aan een applicatie, dan zal dit in beide bestanden zichtbaar zijn,

ook al kan de applicatie in het ene bestand een aantal keer meer of minder geopend zijn. In-

dien een gebruiker steeds rond 11u ’s avonds een alarmklok instelt kan dit voor het ene bestand

gemiddeld om 11u02 zijn en de andere keer gemiddeld om 10u59, maar voor beide databestanden

zou rond 11u deze applicatie moeten worden aangeraden.

TESTCASE

B

USED

B

time, longitude, ... apps

TRAININGCASE

A

USED

A

time, longitude, ... apps

TESTCASE

B

time, longitude, ...

USED

B

apps

Clustering Classification

RECOMMENDED

apps

split

= ?~~

WAKE UPTRAIN (NORMAL)

WORK (NORMAL)

HOME (NORMAL)

TRAIN (NORMAL)

SLEEP (NORMAL)

WAKE UP

TRAIN (SLOW)

WORK (SHORT)

TRAIN (NORMAL)

. . .

8h9h

10h11h12h13h14h15h16h17h18h19h20h21h22h23h24h1h2h3h4h5h6h7h8h9h

10h11h12h13h14h15h16h17h18h19h20h21h22h23h24h1h

HOME (NORMAL)

Mon

Tue

Figuur 8.2: Testopstelling

Dit laat ons toe om de effectief gebruikte applicaties uit het tweede databestand te vergelijken

met de aanbevolen applicaties die opgebouwd zijn aan de hand van het eerste databestand. Voor

het voorbeeld van de alarmklok zou ons systeem een patroon AlarmClock rond 11u moeten

vinden indien we dit systeem trainen met het eerste databestand. Wanneer we het tweede

databestand dan gebruiken als test-case en we komen een data-instantie tegen waarin rond 11u

de alarmklok wordt geopend, dan kijken we of deze applicatie in de 6 aanbevolen applicaties zit.

Dit idee kunnen we dan ook toepassen voor alle data-instanties omdat elk van deze insanties

deel uitmaken van structuren of patronen die ook te vinden zijn in het trainingsbestand.

8.2.1 Bestaande metrieken

Concreet betekent dit dat we de lijst van gebruikte applicaties uit het testbestand sequentieel

overlopen en voor elke applicatie nagaan of deze zich in de recommendatieset bevindt. We zijn

8.2 Opstelling 79

eerst op zoek gegaan naar een bestaande metriek om elke aanbeveling goed te evalueren. Een

veelgebruikte metriek voor aanbevelingen is Kendall’s τ om de maat van similariteit te meten

tussen twee rankings. Wanneer de twee rankings hetzelfde zijn is de coefficient 1, wanneer

de ene ranking de andere ranking is in omgekeerde volgorde is de coefficient -1. Alle andere

mogelijkheden hebben een waarde tussen -1 en 1. Stel dat we bijvoorbeeld een set {A,B,C,D,E}hebben met de rankings R1 = (A,B,C,D,E) en R2 = (B,A,C,D,E). Dan zijn de rankings

duidelijk vrij gelijkaardig en geeft dit een coefficient van τ = 0.8. Het probleem bij deze metriek

is dat de twee rankings van eenzelfde grootte moeten zijn. In ons geval moeten we een ranking

van 6 aanbevolen applicaties vergelijken met 1 effectief geopende applicatie. Dit probleem bleek

moeilijk te vertalen voor de Kendall’s τ coefficient zonder aan nauwkeurigheid te verliezen.

Een andere veelgebruikte metriek voor data mining technieken is de Roc Curve. Deze

werkt aan de hand van de concepten true positives, false negatives, true negatives en false

positives. Echter, de concepten true negatives en false positives zijn in ons systeem zeer moeilijk

te definieren omdat de aanbevelingen met vele zaken rekening houden.

8.2.2 Eigen metriek

We zullen daarom een eigen metriek gebruiken die enkel gebruikmaakt van true positives en

false negatives. Voor elke applicatie uit het testbestand gaan we na of deze zich in de recom-

mendatieset bevindt. Vervolgens maken we een verhouding van het aantal gebruikte applicaties

die effectief aanbevolen waren ten opzichte van het totaal aantal gebruikte applicaties. We kun-

nen dergelijke metriek samenvatten in een formule die we de Information Parameter (IP) zullen

noemen:

IP (M,N, T ) = 100

T∑t=0

R(r(at))

T(8.1)

Hierbij is M de grootte van de recommendatieset en is N het aantal disjuncte applicaties. We

dienen M gelijk te stellen aan 6 vermits de piramide op het Android-toestel 6 applicaties kan

bevatten. Het totaal aantal disjuncte applicaties die de gebruiker kan openen en zich dus in de

testbestanden bevinden hebben we gelijkgesteld aan 17. Deze applicaties zien we in Figuur 8.3.

Verder is T het aantal data-instanties in het testbestand waar effectief een applicatie at gebruikt

werd en dus een aanbeveling dient te gebeuren. Om de nauwkeurigheid te garanderen zullen

we deze waarde hoog genoeg nemen (T = 1000). Verder is r(at) de recommendatiewaarde (een

8.2 Opstelling 80

nummer van 1 tem N = 17 waarbij 1 de belangrijkste waarde is) en is

R(r(at)) =

1 als r(at) <= M

0 als M < r(at) <= N

Hierop zullen we echter nog een normalisatie toepassen. Immers, indien de aanbeveling niet

zou werken en volledig random gebeurt, zou een gebruikte applicatie nog steeds een kans van

M/N = 6/17 hebben om in de recommendatieset van grootte M = 6 te zitten. Wat we

verwachten in dergelijk geval is echter een metriek die 0 % is omdat een random aanbeveling

niet goed is. Anderzijds, wanneer alle gebruikte applicaties in de recommendatieset zitten moet

deze metriek 100 % zijn. De aangepaste metriek zullen we de Normalized Information Parameter

(NIP) noemen:

NIP (M,N, T ) = 100

T∑t=0

R(r(at))

T − MN

1− MN

(8.2)

We zorgen er bovendien voor dat

• het aantal disjuncte applicaties voldoende groot is

• de kans dat een applicatie wordt geopend begrensd is tussen een minimum- en een maximum-

waarde (geen extreme waarden)

Figuur 8.3: Staafdiagram: verdelingen van N = 17 applicaties in het trainings- en testbestand

Hierdoor kunnen we de nauwkeurigheid van de metrieken maximaliseren. In Figuur 8.3 en

Figuur 8.4 worden de verdelingen van de applicaties getoond van het gebruikte trainingsbestand

en testbestand. Hierin wordt duidelijk dat we bovenstaande eigenschappen in rekening brengen

en dat hetzelfde model in de Modelling Tool inderdaad leidt tot gelijkaardige verdelingen van

applicaties.

8.3 Evaluatie van de applicatierecommandatie 81

Figuur 8.4: Curves: verdelingen van N = 17 applicaties in het trainings- en het testbestand

8.3 Evaluatie van de applicatierecommandatie

In deze sectie zullen we de beschreven metrieken gebruiken om de aanbeveling van de applicaties

te evalueren. Dit zullen we eerst apart doen voor het Profielvenster, de Associatieregels en het

Kortetermijngeheugen. Nadien zullen we de finale recommendatie evalueren wanneer de drie

algoritmes worden gecombineerd via een classificatiefunctie f().

8.3.1 Profielvenster

We zullen eerst de recommendatie evalueren wanneer enkel het Profielvenster toegepast wordt.

Hierbij werd voor de correctheid het algoritme uit sectie 6.1 gedeeltelijk aangepast. De bogen

uit de graaf werden in het geevalueerde algoritme gewijzigd om enkel rekening te houden met

het aantal keer dat ze genomen werden en niet met de tijdsverschillen. Dit werd gedaan omdat

de Modelling Tool geen tijdspatronen kan modelleren (dan zou de tool te complex worden).

In Tabel 8.1 en Figuur 8.5 wordt de verhouding weergegeven van de applicaties die werden

gebruikt en effectief werden aanbevolen (true positives) en de applicaties die werden gebruikt,

maar zich niet in de recommendatieset bevonden (false negatives).

In de tabel wordt de recommendatie eveneens in zijn geheel geevalueerd met behulp van

de metrieken Information Parameter (IP) en Normalized Information Parameter (NIP). Bij de

true positives maken we nog een onderscheid tussen de 6 verschillende recommendatiewaarden.

Hoe kleiner een dergelijke waarde is, hoe hoger de applicatie in de recommendatieset komt en

dus hoe beter de aanbeveling. We zullen voortaan de term bin gebruiken om alle applicaties

met eenzelfde recommendatiewaarde aan te duiden. Wat we wensen is dat het aantal applicaties

in bin i + 1 hoger is dan het aantal applicaties in bin i (i tussen 1 en M − 1 = 5). Voor het

profielvenster komen de resultaten overeen met deze vereisten.


1 2 3 4 5 6 FN IP NIP

18.58% 16.37% 11.95 % 7.96% 5.46% 4.28% 35.40% 64.60% 45.29%

Tabel 8.1: Profielvenster: % true positives per bin, % false negatives (FN), IP(6,7,1000) enNIP(6,7,1000)

Figuur 8.5: Profielvenster: Percentage van de true positives per bin samen met de false negatives(FN)

We merken echter dat we nog een percentage van 35.40% hebben voor de false negatives.

Dit komt omdat we enkel het profielvenster gebruiken. Dit algoritme is enkel in staat om

profielafhankelijke patronen te ontdekken. Patronen die bijvoorbeeld enkel afhankelijk zijn van

bepaalde clusters zoals plaats of tijd zullen niet ontdekt worden door dit algoritme. Dit in

acht nemende, samen met de observatie dat de bin-percentages monotoon dalen en de NIP een

matige waarde geeft, kunnen we concluderen dat dit algoritme matig tot goed presteert, maar

niet volstaat als enige recommendatietechniek.

8.3.2 Associatieregels

We zullen nu de recommendatie evalueren wanneer we enkel gebruikmaken van de associ-

atieregels. Tabel 8.2 en Figuur 8.6 bevatten een overzicht van de resultaten.

We zien dat we goede resultaten krijgen voor dit algoritme. We krijgen een waarde van

1 2 3 4 5 6 FN IP NIP

31.45% 21.36% 13.95% 11.28% 6.23% 5.64% 10.09% 89.91% 84.41%

Tabel 8.2: Associatieregels: % true positives per bin, % false negatives (FN), IP(6,7,1000) enNIP(6,7,1000)


Figuur 8.6: Associatieregels: Percentage van de true positives per bin samen met de falsenegatives (FN)

1 2 3 4 5 6 FN IP NIP

10.32% 13.13% 11.80% 9.88% 5.31% 5.90% 43.66% 56.34% 32.53%

Tabel 8.3: Kortetermijngeheugen: % true positives per bin, % false negatives (FN), IP(6,7,1000)en NIP(6,7,1000)

84.41% voor de NIP. Bovendien merken we dat de bin-percentages weer monotoon dalen. De

reden waarom deze NIP veel hoger is dan bij het profielvenster is omdat de associatieregels ook

veel profielafhankelijke patronen ontdekken. De associatieregels zoeken naar patronen tussen de

verschillende clusters en de profielen zijn eveneens clusters. Bepaalde patronen zoals patronen

waar applicaties veel na elkaar gebruikt worden (vaak openen van recente applicaties) zullen

dan weer niet kunnen gevonden worden door de associatieregels waardoor de NIP niet naar zijn

maximale waarde gaat. Een andere reden is dat er steeds een zekere random-component is in

het openen van applicaties waardoor de recommendatie-algoritmes niet altijd perfecte resultaten

zullen geven.

8.3.3 Kortetermijngeheugen

De resultaten voor het kortetermijngeheugen zijn weergegeven in Tabel 8.3. We merken dat

we een lage NIP hebben. Dit komt omdat het algoritme enkel zoekt naar sequentiele patronen

van zelfde applicaties die vaak na elkaar geopend werden. Deze resultaten zeggen op zich niet

zoveel omdat we niet weten hoe groot het percentage van louter sequentiele patronen is in het

testbestand. We kunnen de testbestanden aanpassen om enkel dergelijke patronen te bevatten,

maar dit konden we niet doen zonder dat de testopstelling en de metrieken te veel moesten

8.4 Performantie van de serverdiensten 84

f() IP NIP

Simple Recommender 42.14% 10.57%Associatieregels 89.91% 84.41%

Gewogen Classificatie 89.32% 83.49%Max Classificatie 90.07% 84.66%

Tabel 8.4: Vergelijking van een Simple Recommender met de best presterende recommen-datiefuncties: IP(6,17,1000) en NIP(6,7,1000)

inboeten aan nauwkeurigheid en waarheidsgetrouwheid. De enige conclusie die we hier kunnen

maken is dat de NIP veel groter is dan 0 waardoor dit algoritme zeker beter presteert dan een

random recommender (die een NIP van ongeveer 0 zou hebben). Bovendien weten we dat het

percentage van sequentiele patronen niet groot is waardoor een NIP van 32.53% niet onrealistisch

lijkt.

8.3.4 Totale classificatie

Tot slot kunnen we de totale classificatie evalueren die de drie algoritmes combineert via een

classificatiefunctie f(). Een overzicht van de resultaten We merken dat de max -functie iets beter

presteert dan de gewogen som. De max -functie geeft zelfs een NIP die maar nauwelijks hoger

is dan de associatieregels apart. Anderzijds is de verdeling van de bins bij de max -functie wel

beter aangezien we iets hogere percentages krijgen in de eerste bins dan bij de associatieregels.

Wellicht kunnen we deze classificatiefuncties nog optimaliseren of zijn er nog andere functies te

bedenken waardoor we de resultaten nog iets kunnen verbeteren.

Tot slot zullen we de best presterende functies vergelijken met een eenvoudige recommender

(Simple Recommender) waarbij enkel het totaal aantal openingen per applicatie in rekening

wordt gebracht. Hierbij wordt dus over heel de trainingsperiode een totale som gemaakt per

applicatie. De vergelijking is weergegeven in Tabel 8.4 en Figuur 8.7.

In Figuur 8.7 zijn de true positives grafisch voorgesteld. We zien dat we de beste aanbeveling

hebben bij de max classificatie. Deze functie heeft een vrij hoge NIP. Indien we een volledig

random-gebaseerde recommender zouden gebruiken, zouden we een NIP hebben die theoretisch

0% is. De Simple Recommender die we hier beschrijven heeft een NIP van 10.57%. De max

classificatie heeft daarentegen een NIP van 84.66%.

8.4 Performantie van de serverdiensten

De performantie van de verschillende data mining algoritmes en van ons raamwerk is een niet

onbelangrijke factor in de algemene evaluatie. Zoals eerder aangehaald zijn er twee soorten


Figuur 8.7: Vergelijking van een Simple Recommender met de best presterende recommen-datiefuncties

diensten op de server: clustering en classificatie. We zullen de performantie van deze twee

diensten apart evalueren. De resultaten zijn toegepast op een testen een trainingsbestand van

dezelfde grootte:

• 6 attributen (lengtegraad, breedtegraad, weekdag, tijdstip, snelheid, applicatie)

• lengtegraad, breedtegraad, tijdstip en snelheid hebben numerieke datatypes

• weekdag heeft een nominaal datatype bestaande uit 7 waarden voor de weekdagen

• applicatie heeft een nominaal datatype bestaande uit 17 waarden voor de applicaties

• 2046 data samples

De Weka-parameters voor het EM -algoritme zijn ingesteld op 1000 voor maxIterations, 10−6

voor minStdDev en 1000 voor seed. Deze voor het A Priori -algoritme zijn ingesteld op 0 voor

minMetric (de metriek is de confidence), 0, 01 voor minSupport en 1000000 voor numRules. De

testen zijn uitgevoerd op een Intel Core i5-520M (2,40 GHz) processor (2 Cores, 4 threads)

met een adresseerbaar geheugen van 5,80 GB en een 64-bit OS. De groottes van de L1, L2 en

L3-caches zijn respectievelijk 2x64 KB, 2x256 KB en 3072 KB.


Locatie Weekdag Tijdstip Snelheid Profiel Associatieregels Raamwerk Totaal

9,080 s 0,905 s 45,691 s 6,174 s 16,146 s 3,886 s 13,234 s 95,116 s

Tabel 8.5: Performantieresultaten van het opbouwen van clusters en associatieregels

8.4.1 Opbouwen van profielen en associatieregels

Bekijken we eerst de resultaten van het opbouwen van clusters en associatieregels. Deze vinden

we in Tabel 8.5. We merken dat de clustering van de verschillende attributen redelijk wat tijd

in beslag neemt. De kleinste tijd hebben we voor het attribuut Weekdag omdat we daar niet

gebruikmaken van complexe clusteralgoritmes. De andere attributen nemen meer tijd in beslag.

We hebben de grootste tijden voor de meerdimensionale attributen Locatie (tweedimensionaal)

en Profiel (vijdimensionaal) of het attribuut Tijdstip waarbij zeer weinig structuur of samenhang

te vinden is in de bijhorende data.

Het opbouwen van de associatieregels duurt minder lang dan de clustering. Het vinden van

een half miljoen regels in dit geval neemt slechts 3,886 seconden in beslag.

Tot slot is er nog de tijd die het raamwerk in beslag neemt voor dit opbouwen van clusters en

regels. Dit neemt gemiddeld 13,234 seconden in beslag. Deze tijd wordt voornamelijk ingenomen

door:

• Voorbereiding van de data De ontvangen data van de client (in de vorm van Fixes)

moet worden vertaald, getransformeerd en genormaliseerd naar data die kan ingeladen

worden in het Weka-framework. Dit wordt soms aangeduid als het Extract, Transform

and Load -proces.

• Nabewerkingen op de data De resultaten van het Weka-framework moeten nadien terug

omgezet worden naar interne objecten en datastructuren waar ons raamwerk efficient mee

kan werken en die klaar zijn om terug naar de client te verzenden.

• Filtering van de data Hier en daar dient er ook filtering te gebeuren op de resultaten van

Weka. Er zullen bijvoorbeeld verschillende associatieregels gevonden worden door Weka

die onbruikbaar zijn in ons systeem.

We kunnen besluiten dat de eerste dienst van de server redelijk wat tijd in beslag neemt. Echter,

deze stap dient niet vaak uitgevoerd te worden. Indien we initieel een tweetal weken data zouden

genereren op de client en daarna deze stap uitvoeren hoeven we nadien pas dagelijks, wekelijks

of zelfs maandelijks de stap opnieuw uit te voeren om de profielen en regels te updaten of om

nieuwe profielen te ontdekken. Die periodiciteit kan varieren afhankelijk van enkele factoren:


Profielvenster Associatieregels Kortetermijn Totaal

0,021 s 4,864 s 0,04 s 4,889 s

Tabel 8.6: Performantieresultaten van het classificeren

• Indien we reeds veel data hebben verzameld (bvb. meerdere maanden of jaren) heeft het

geen zin om nog dagelijks te updaten nadien.

• Indien we merken dat de data of de clusters zeer weinig veranderd zijn, kunnen we het

proces vroegtijdig afbreken.

De relatief hoge tijden voor deze serverdienst vormen aldus geen groot probleem gezien de stap

niet vaak hoeft te gebeuren. Bovendien moet het proces niet real-time gebeuren. Het is geen

enkel probleem indien de resultaten met vertraging toekomen bij de client. Dit betekent dat de

tijden geen probleem zullen vormen wanneer meerdere gebruikers tegelijk de server aanspreken.

8.4.2 Classificatie

Waar de tijden wel belangrijker zijn en de resultaten zo real-time mogelijk moeten toekomen

bij de client is bij de classificatie. Deze dienst zullen we nu evalueren. In Tabel 8.6 zijn de

resultaten weergegeven van de verschillende aanbevlingsalgoritmes en de finale recommendatie.

Uit de tabel blijkt dat het overgrote deel van de tijd wordt ingenomen door het mappen van de te

classificeren Fix met de opgebouwde associatieregels. De oorzaak van de hoge tijd is het filteren

van de vele associatieregels. Er moeten in dit geval ongeveer een half miljoen associatieregels

vergeleken worden met de Fix om te bepalen welke regels geldig en welke regels ongeldig zijn. Per

associatieregel moeten de geclusterde attribuutwaarden gemapt worden met de attribuutwaarden

in de Fix. Hierbij moet er dan ook enige wrapping en unwrapping van objecten gebeuren. Indien

deze mapping per regel gemiddeld slechts 0,01 milliseconden in beslag neemt zal dit voor een

half miljoen regels dan ook gemiddeld 5 seconden in beslag nemen.

Stel dat we dan elke minuut een classificatie willen doen dan is deze 5 seconden realiseerbaar

voor 1 gebruiker, maar veel minder realiseerbaar voor vele gebruikers tegelijkertijd. Dit probleem

zouden we kunnen oplossen door in de eerste stap van de server (clusteren en opbouwen van

regels) een goed classificatiemodel op te bouwen om veel efficienter regels te classificeren als geldig

of ongeldig. Dit kunnen we doen omdat de tijden tijdens de eerste stap veel minder cruciaal

zijn dan tijdens de classificatiestap. Op die manier kunnen we de real-time classificatietijden

sterk reduceren. Een mogelijke aanpak voor het opbouwen van een classificatiemodel is het

gebruikmaken van beslissingsbomen.

8.5 Performantie van de Android client 88

8.5 Performantie van de Android client

8.5.1 Vertragingen op GUI-niveau

Onze widget staat niet enkel in voor het visualiseren van interessante applicaties voor de ge-

bruiker, maar ook voor het berekenen en opslaan van bepaalde zaken (zoals wie er laatst is

gebeld in het profiel, welke mode bij het profiel hoort,...). Zo zal de widget een lijst van appli-

caties doorgestuurd krijgen, waarna de widget de gepaste Intent (om de applicatie te starten via

de widget) en icon gaat opzoeken. Dit zijn vrij intense zoekopdrachten die wel enkele seconden

kunnen duren. Daarom is het belangrijk om het interval waarmee de widget update niet te

hoog te zetten, zodat de widget de tijd heeft om deze af te werken en niet overstelpt wordt met

zoekopdrachten. Een goed interval zou hier bijvoorbeeld 30 tot 60 seconden kunnen zijn. De de-

veloper’s guide van Android raadt echter aan om zo weinig mogelijk te updaten, liefst niet meer

dan een keer per uur om de batterij te sparen. Dit is echter te weinig voor de functionaliteiten

die we met onze widget willen aanbieden (up-to-date informatie over het huidige profiel).

Een oplossing om de batterij meer te sparen en minder load op de widget te leggen is om

de zoekopdrachten naar de intents en icons in de client te doen. Deze stuurt dan een bericht

met daarin de gevonden objecten naar de widget. De widget moet dan nog slechts de grafische

interface updaten op de gepaste momenten.

8.5.2 Batterijverbruik

Een belangrijk aspect bij het maken van een mobiele applicatie is het batterijverbruik op het

toestel. Bij een te hoog batterijverbruik zal de gebruiker beslissen om de applicatie minder of niet

meer te gebruiken. Het batterijverbruik van onze client ligt jammer genoeg vrij hoog. De GPS

is bijna constant actief om zowel de snelheid als de locatie vast te stellen. Deze gegevens worden

steeds opgeslagen in het interne geheugen, en wanneer nodig naar de webserver gestuurd. Het is

mogelijk om het vastleggen van locaties, snelheid en het sturen van gegevens naar de webserver

minder frequent te laten gebeuren, maar dit zal steeds ten koste gaan van de nauwkeurigheid

van aangeboden functionaliteiten.

8.6 Netwerkbelasting tussen client en server

In onze applicatie worden berichten tussen client en server uitgewisseld. Deze berichten kunnen

varieren qua grootte en periodiciteit. In deze sectie zullen we de datatrafiek tussen de client en

server bestuderen. De client kan twee soorten berichten sturen. Enerzijds een aanvraag om te

8.6 Netwerkbelasting tussen client en server 89

clusteren en anderzijds een aanvraag om te classificeren.

8.6.1 Aanvraag tot clusteren

Wanneer de client een aanvraag verstuurt om te clusteren zal die als parameters een lijst met

fixes meegeven. Daarnaast wordt ook nog een lijst gegeven met tijdstippen waarop het toestel

in standby is gegaan. Via bepaalde constanten kan in de code van onze clientapplicatie de

periodiciteit waarmee fixes worden opgeslagen en het aantal fixes die nodig zijn om een bericht

te sturen, aangepast worden. Hieronder een voorbeeld van een bericht van client naar server:

Bericht 1 Aanvraag clusteren van client naar server

POST /InproServer/web/profile HTTP/1.1

Accept: application/xml, text/xml, application/*+xml, application/json

Content-Type: application/json

Content-Length: 714

Host: 192.168.0.5:8080

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Expect: 100-Continue

{"fixes":[{"applications":["com.thesis"],"date":1306070159563,"dayOfTheWeek":"Sun"

,"decimalTime":13.266388888888889,"latitude":51.026175,"longitude":4.1288177,

"musicPlaying":false,"speed":70.005,{"applications":["com.thesis"],"date"

:1306070161524,"dayOfTheWeek":"Sun","decimalTime":13.266944444444444,"latitude"

:51.026175,"longitude":4.1288177,"musicPlaying":false,"speed":33.212},

{"applications":["com.thesis"],"date":1306070163520,"dayOfTheWeek"

:"Sun","decimalTime":13.2675,"latitude":51.026175,"longitude":4.1288177

,"musicPlaying":false,"speed":2.232},{"applications":["com.thesis"],

"date":1306070165523,"dayOfTheWeek":"Sun","decimalTime":13.268055555555556,

"latitude":51.026175,"longitude":4.1288177,"musicPlaying":false,"speed":4.232}]

,"standbyDates":[1306071130431,1306071130431]}

Wanneer de server dit bericht ontvangt zal deze beginnen met het clusteren van deze fixes. Dit

kan een tijdje duren, afhankelijk van het aantal fixes die werden meegegeven. De client zal

ondertussen wachten op een antwoord. Indien dit antwoord niet binnen een bepaalde tijdspanne


gebeurt, zal deze een time-out opgooien. Daarom is het belangrijk om de time-out parameter

hoog genoeg in te stellen zodat de server de tijd heeft om zijn berekeningen uit te voeren en

een antwoord te verschaffen. Langs de andere kant mag deze parameter ook niet te hoog zijn:

wanneer de server offline blijkt te zijn dient de client hier zo snel mogelijk van op de hoogte te

zijn.

De lengte van zo’n bericht van server naar client met n fix is gemiddeld 577 bytes groot.

Elke fix die hierbij komt zal gemiddelde 173 extra bytes in beslag nemen. In Figuur 8.8 zien

we een grafiek waar we de grootte van dit bericht uitzetten tegenover het aantal fixes. Typisch

hangt de grootte van dit bericht ook af van het aantal tijdstippen waarin het toestel in standby

is gegaan. Deze grootte gaan we echter niet in rekening brengen omdat de grootte van n tijdstip

(gemiddeld 19 bytes) niet groot is, en het aantal tijdstippen dat wordt meegegeven is doorgaans

relatief klein bij normaal gebruik.

Figuur 8.8: De grootte van een bericht dat gezonden wordt van client naar server bij een gegevenaantal fixes.

Naast het aantal fixes, speelt ook de periodiciteit van de opslag van fixes een rol. Hoe

kleiner het interval, hoe sneller de fixes worden opgeslagen en hoe sneller het nodige aantal fixes

wordt bereikt. Vanaf dat het aantal fixes is bereikt, zal er een aanvraag tot clusteren gebeuren.

Hierdoor zullen er dus meer berichten worden verstuurd in hetzelfde tijdsinterval. Hieronder de

datatrafiek uitgezet in functie van de periodiciteit. Bij de datatrafiek per uur gaan we ervan uit

dat er per uur exact n bericht wordt verstuurd.


Periodiciteit (in s) Aantal opgeslagen fixes Datatrafiek per uur

10 360 62,857

30 120 21,337

60 60 10,957

300 12 2,653

600 6 1,615

1800 2 0,923

3600 1 0,75

Figuur 8.9: De datatrafiek per uur in functie van de periodiciteit waarop fixes worden opgeslagen.

Wanneer de server klaar is met zijn berekeningen zal hij volgend bericht terugsturen naar de

client:

Bericht 2 Antwoord server naar de client

HTTP/1.1 100 Continue

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: application/xml

Content-Length: 258


Date: Sun, 22 May 2011 13:15:52 GMT

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><profileInfoList>

<profileInfos>0,70.005,4.1288177,51.026175,1,0.30,4.1288177,51.026175,2,

70.005,4.1288177,51.026175,3,0.025,4.1288177,51.026175,4,0.30,4.1288177

,51.026175</profileInfos></profileInfoList>

Dit bericht bevat de verschillende profielen die de server heeft berekend op basis van de fixes

die werden gestuurd. Elk ProfileInfo-object bevat een unieke id, de gemiddelde snelheid en de

gemidelde locatie van het profiel. De lengte van dit bericht zal doorgaans niet zo groot zijn

(418 bytes voor 5 profielen bijvoorbeeld) omdat het aantal profileInfo-elementen in een bericht

beperkt zal zijn en de grootte van een profileInfo in het bericht ook vrij klein is (30 bytes).

8.6.2 Aanvraag tot classificeren

De client zal om de zoveel tijd een bericht naar de server sturen met een vraag om de meeges-

tuurde fix te classificeren. Aangezien dit bericht steeds maar n fix bevat is de grootte van dit

bericht vrij constant (rond de 480 bytes).

Bericht 3 Aanvraag classificatie van client naar server

POST /InproServer/web/classification HTTP/1.1

Accept: application/xml, text/xml, application/*+xml, application/json

Content-Type: application/json

Content-Length: 172

Host: 192.168.0.5:8080

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Expect: 100-Continue

{"applications":["com.thesis"],"date":1306070163520,"dayOfTheWeek":

"Sun","decimalTime":13.2675,"latitude":51.026175,"longitude":4.1288177,

"musicPlaying":false,"speed":2.232}

De server zal de fix classificeren en zal een lijst met recommandaties van applicaties samen met

het id van het profiel waarin de fix werd geclassificeerd. Dit bericht zal gemiddeld 444 bytes


groot zijn.

Bericht 4 Antwoord client naar server

HTTP/1.1 100 Continue

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: application/xml

Content-Length: 284

Date: Wed, 25 May 2011 12:06:00 GMT

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><classificationInfo>

<applications>Agenda,Email,Facebook,Browser,Youtube,AlarmClock,Nieuws,

Aandelen,Market,Quickoffice,Google_maps,GPS,Weer,Camera,Gallery,

Phone,Music</applications><profileInfo>4</profileInfo></classificationInfo>

VERDERE UITBREIDINGEN 94

Hoofdstuk 9

Verdere uitbreidingen

9.1 Dynamisch evalueren van profielen

In ons raamwerk werd geen oplossing gegeven voor het dynamisch evolueren van profielen. Stel

dat er voor een gebruiker reeds een aantal profielen werden opgebouwd voor zijn traditionele

leefomgevingen: thuis, op het werk, enzoverder. Wanneer de gebruiker dan op reis gaat kan

deze nieuwe situatie in principe niet meer als een bestaand profiel beschouwd worden. De

contextuele parameters zullen enorm verschillen en mogelijks zal de gebruiker ook andere appli-

caties gebruiken op reis. Wanneer de gebruiker een jaar later weer op reis gaat zou het nuttig

zijn dat de vorige reis reeds werd herkend als een profiel zodat voor de nieuwe reis een betere

recommendatie kan gebeuren.

Het probleem hierbij is echter de schaal van plaatsattributen (lengtegraad en breedtegraad).

Indien een gebruiker op reis gaat wijken deze parameters zeer veel af van de normale parameters.

Indien we hierover niet waakzaam zijn zal het clusteringalgoritme veel nauwkeurigheid verliezen

bij de traditionele profielen waardoor er slechts twee grote clusters zullen ontdekt worden: een

cluster voor de traditionele leefomgevingen en een reiscluster. Een oplossing voor dit probleem is

om op verschillende schalen te werken. Wanneer de gebruiker te veel afwijkt van de traditionele

coordinaten wordt er een nieuwe schaal gemaakt. Dit kan werken via het ART-model dat in

staat is om nieuwe clusters te maken indien een patroon te sterk afwijkt van de huidige clusters.

9.2 Optimalisatie van de recommendatie

Er kunnen nog optimalisaties gebeuren om het graafalgoritme en het algoritme voor het recent

geheugen te verbeteren. Verder kan er gezocht worden naar complexere classificatiefuncties om

de algoritmes beter te combineren zodat deze meer complementair zijn ten opzichte van elkaar.

CONCLUSIE 95

Hoofdstuk 10

Conclusie

In deze masterproef werd een raamwerk ontworpen voor gepersonaliseerde en contextafhankelijke

profielen op Android smartphones. Het raamwerk biedt een oplossing om op basis van verschil-

lende contextuele gegevens profielen te ontdekken en recommendaties te doen van applicaties en

contacten.

Er werden een aantal algoritmes geevalueerd om in de ongestructureerde getraceerde data

van het mobiel toestel structuren en patronen te ontdekken. Hierbij werd gevonden dat het

Expectation-Maximization-algoritme een krachtig instrument is om clusters en topologieen te

ontdekken waaruit verschillende profielen kunnen onderscheiden worden. De clusters en profielen

worden nadien gebruikt door verwantschapsanalyse en enkele eenvoudige algoritmes om patronen

te ontdekken in het applicatiegebruik. Tot slot werd naar een gebruiksvriendelijke manier gezocht

om de profielen en recommendaties te visualiseren op het Android mobiel toestel.

Uit de evaluaties bleek dat het EM-algoritme en het algoritme voor associatieregels het best

presteren in deze masterproef. Het EM-algoritme bleek een onmisbare factor in de flexibele

ontdekking van stabiele clusters. Het algoritme voor associatieregels bleek goede resultaten te

geven om patronen en verbanden te ontdekken in het applicatiegebruik met betrekking tot de ver-

schillende contextomgevingen. Daarenboven kunnen nog een aantal andere algoritmes gebruikt

worden om de recommendatie van applicaties te verbeteren. Hierbij kan een classificatiefunctie

gebruikt worden om verschillende algoritmes te combineren tot een finale recommendatie.

Tot slot werden nog enkele onderwerpen voor verder onderzoek aangeduid. Dit omvat o.a.

het dynamisch evolueren van profielen en de verdere optimalisatie van de aanbevelingen.

CONFIGURATIEGEGEVENS 96

Bijlage A

Configuratiegegevens

A.1 Gebruikte bibliotheken

Bij zowel de client als de server maken we gebruik van verschillende open source libraries.

Hieronder een opsomming:

• Client:

– Spring Framework for Android: een framework voor Android dat een robuuste,

populaire en op Java gebaseerde REST-client biedt.

– JACKSON Json processor: wordt gebruikt om java objecten te serialiseren.

• Server:

– Weka bibliotheek: biedt functionaliteiten voor clusteren en classificeren.

– Jersey: een open source JAX-RS implementatie voor het maken van RESTful Web

services.

A.2 Gebruikte webserver

Voor onze webserver maken we gebruik van Apache Tomcat 7.0.

A.3 Android versie

Zowel de client als de widget zijn gemaakt en getest voor Android 2.2.

A.4 LocalHost op emulator 97

A.4 LocalHost op emulator

Normaalgezien is het IP-adres van de localhost 0.0.0.0. Wanneer we op de emulator werken en

we willen het IP-adres van de localhost te gebruiken, dienen we echter 10.0.0.2 te gebruiken.

A.5 Instellen IP-adres op client

De klasse WebServiceCommunicator van de client bevat een constante met de naam SERVER IP.

Deze constante moet het IP-adres van de server toegewezen krijgen.

INHOUD VAN DE CD-ROM 98

Bijlage B

Inhoud van de CD-ROM

De CD-ROM bevat naast de digitale versie van onze masterproef en de Extended Abstract ook

een Installation Manual. Alle figuren zijn ook in originele grootte terug te vinden. Daarnaast

bevat de CD-ROM de volgende componenten:

• Code van Proof-Of-Concept Demonstrator:

– InproClient: de code voor de service op het Android-toestel

– InproWidget: de code voor de widget op het Android-toestel

– InproServer: de code voor de server op Apache Tomcat

• Code van de Modelling Tool

• Code van de geporteerde versie van Weka voor Android

• Evaluatiebestand gebruikt voor de evaluatie in Hoofdstuk 4

– inputH4.arff : het testbestand voor de evaluatie van EM

• Evaluatiebestanden gebruikt voor de evaluatie in Hoofdstuk 8

– trainingH8.arff : het trainingsbestand (Training Case A + Used A in Figuur 8.2)

– testH8.arff : het testbestand (Test Case B + Used B in Figuur 8.2)

– ProfielVenster.txt : de resultaten van de classificatie via het profielvenster

– Associatieregels.txt : de resultaten van de classificatie via de associatieregels

– KortetermijnVenster.txt : de resultaten van de classificatie via het kortetermijnvenster

– GewogenSomClassificatie.txt : de resultaten van de gewogen-som-classificatie

– MaxClassificatie.txt : de resultaten van de max-classificatie

– EvaluatieH8.xlsx : Excel-bestand met de summary data en grafieken

BIBLIOGRAFIE 99

Bibliografie

[1] John McCarthy. What is artificial intelligence?. http://www-

formal.stanford.edu/jmc/whatisai/whatisai.html. Computer Science Department (2007).

[2] Ray Kurzweil. The Age of Spiritual Machines. Penguin Books, ISBN 0-670-88217-8.

[3] Adalbert Wilhelm. Data and Knowledge Mining. http://fedc.wiwi.hu-

berlin.de/xplore/ebooks/html/csa/node201.html

[4] Guy De Tre. Concepts of Databases. Pearson Education (2007).

[5] Satnam Alag Collective Intelligence in Action Manning Publications Co. (2009)

[6] Osmar R. Zaıane. Principles of Knowledge Discovery in Databases - Chapter 8: Data Clus-

tering.http://www.cs.ualberta.ca/ zaiane/courses/cmput690/slides/Chapter8/index.html

[7] Toby Segaran. Programming Collective Intelligence. O’Reilly Media (2007).

[8] J.B. MacQueen. Some Methods for classification and Analysis of Multivariate Observa-

tions, Proceedings of 5th Berkeley Symposium on Mathematical Statistics and Probability.

Berkeley, University of California Press (1967).

[9] Christopher J.C. Burges A Tutorial on Support Vector Machines for Pattern Recognition.

Bell Labatories, Lucent Technologies

[10] SVM - Support Vector Machines. http://www.dtreg.com/svm.htm

[11] Herve Abdi Neural Networks University of Texas, Dallas

[12] Christos Stergiou, Dimitrios Siganos Neural Networks (January 4, 1999)

[13] Jocelyn Ireson-Paine. What is a rule-based system?. http://www.j-

paine.org/students/lectures/lect3/node5.html

BIBLIOGRAFIE 100

[14] Rakesh Agrawal, Ramakrishnan Srikant. Fast algorithms for mining association rules in

large databases. Proceedings of the 20th International Conference on Very Large Data Bases,

VLDB, pages 487-499, Santiago, Chile (September 1994).

[15] G.A. Carpenter, S. Grossberg Adaptive Resonance Theory. Boston University (2003)

[16] Reto Meier Professional Android Application Development. Wiley Publishing, Inc. (2009).

[17] Android Developer’s Guide. http://developer.android.com

[18] Leonard Richardson, Sam Ruby RESTful Web Services. O’Reilly (May 2007)

[19] Sameer Tyagi RESTful Web Services. http://www.oracle.com/technetwork/articles/javase/index-

137171.html

[20] Phil Adams, Peter Easton, Bhakti Mehta, Roland Merrick SOAP over Java Message Service

1.0. W3C (2009)

[21] Brady Forrest Google Deprecates Their SOAP Search API. O’Reilly (December 2006)

[22] David E. Rumelhart, David Zipser Feature Discovery by Competitive Learning. University

of California, Cognitive Science 9, 75-112 (1985)

[23] James L. McClelland Explorations in Parallel Distributed Processing: A Handbook of Mod-

els, Programs, and Exercices. Standford University (21 maart 2011).

[24] Bernd Fritzke Some Competitive Learning Methods. Institute for Neural Computation,

Rurh-Universitat Bochum (April 5, 1997).

[25] Osama Abu Abbas The Expectation-Maximization Algorithm. College of Computing, Geor-

gia Institute of Technology (Februari 2002)

[26] Frank Dellaert Comparisons Between Data Clustering Algorithms. The International Arab

Journal of Information Technology, Vol.5, No. 3, (July 2008)

[27] Roy Clarkson Spring Android Reference Manual. SpringSource Inc. (2011)

[28] L. Becchetti, U. Colesanti, A. Marchetti-Spaccamela, A. Vitaletti Self-Organized Recom-

mendation Systems: Models and Experimental Analysis. In Proc. of the IEEE International

Conference on Self-Adaptive and Self-Organizing Systems (2008, to appear)

[29] John A. Swets Signal Detection Theory and Roc Analysis in Psychology And Diagnostics.

Lawrence Erlbaum Associates, Publishers (1996)

LIJST VAN FIGUREN 101

Lijst van figuren

2.1 Het resultaat van clustering op een aantal elementen. In deze figuur worden de

elementen opgedeeld in vier clusters. . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Voorbeeld van hierarchisch clusteren. . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Voorbeeld van een beslissingsboom voor het al dan niet spelen van een voetbal-

match bij bepaalde weersomstandigheden . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Voorbeeld van twee mogelijke plaatsingen van de opsplitsende lijn bij een SVM . 11

2.5 Voorbeeld van de maximum-margin hyperplane en de marge bij een SVM . . . . 11

2.6 Structuur van een neuraal netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 Werking van een neuron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8 Gebruik van gewichten bij een neuron . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Android architectuur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 ART standaardmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Expectation-Maximization algoritme: voor clustering . . . . . . . . . . . . . . . . 29

4.3 Expectation-Maximization algoritme: na clustering . . . . . . . . . . . . . . . . . 29

4.4 Vorm van een Gaussiaanse functie . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.5 Clustering van profielen d.m.v. attributen lengtegraad, breedtegraad en tijd : op

de x-as de index van het sample en de op de y-as de lengtegraad . . . . . . . . . 34

4.6 Deelresultaat van profielclustering: clusters thuis wakker (rood), thuis slapend

(donkerblauw) en trein (lichtblauw), x- en y-as zoals in Figuur 4.5 . . . . . . . . 34

4.7 Clustering van profielen dmv alle attributen samen: op de x-as de index van het

sample en de op de y-as de lengtegraad. Clusters thuis wakker (geel), thuis slapend

(donkerblauw), werk (lichtblauw), familiebezoek (groen) en gebroken clusters trein

(roos en paars) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


4.8 Clustering van profielen met een hoge minimum-standaarddeviatie (minStdDev is

100): op de x-as de index van het sample en de op de y-as de lengtegraad. Het

algoritme onderscheidt een avond thuis (blauw) van een weekend (groen) maar

classificeert sommige samples voor werk en familiebezoek ook als weekend . . . . 36

5.1 Extract van mogelijke data instances . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Selectie van de attributen latitude en longitude voor het clusteren van location . 40

5.3 Data geclusterd op location dmv de attributen latitude en longitude . . . . . . . 41

5.4 Data geclusterd op location, day of week en speed . . . . . . . . . . . . . . . . . . 42

5.5 Attributen en het resultaat na clustering . . . . . . . . . . . . . . . . . . . . . . . 42

5.6 Clustering van de data op time: enkel de punten met applicaties worden in reken-

ing gebracht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.7 Combinatie van twee attributen naar een drie-dimensionale ruimte voor clustering 45

5.8 Clustering van alle attributen samen resulteert in de Android-profielen . . . . . . 45

5.9 Eerste-niveau en tweede-niveau clustering: attributen en applicaties . . . . . . . 46

6.1 Schema van clustering en patroonherkenning . . . . . . . . . . . . . . . . . . . . 48

6.2 Knopen in een graaf voor het aantal keer dat een applicatie werd geopend . . . . 49

6.3 Gerichte graaf voor de sequentiele overgangen tussen applicaties . . . . . . . . . . 50

6.4 Gerichte graaf die ook rekening houdt met de tijdsverschillen tussen applicaties . 50

6.5 Resulterende graaf bij het berekenen van de applicaties na het gebruik van Phone 51

6.6 Finale aanbeveling: combinatie van de applicatiekansen door een classificatiefunctie 56

7.1 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Fix-, Classification- en ProfileInfo-object . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 Voorbeeld van de eerste serverstap: clustering . . . . . . . . . . . . . . . . . . . . 60

7.4 ClusterGroup- en ClusteringType-objecten . . . . . . . . . . . . . . . . . . . . . . 61

7.5 ApplicationVertex-, ApplicationEdge- en ProfileGraph-objecten . . . . . . . . . . 62

7.6 ApplicationSet-, ClusteredAttribute- en AttributeAssociationRule-objecten . . . 63

7.7 Sequentiediagram van de eerste serverstap: clustering . . . . . . . . . . . . . . . 64

7.8 Sequentiediagram van de tweede serverstap: classificatie . . . . . . . . . . . . . . 65

7.9 Component Diagram Server 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.10 Component Diagram Server 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.11 Klassendiagram Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.12 Component Diagram Android Client . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.13 Screenshot van de widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


7.14 Klassendiagram Android Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.1 Ontwerp van de modelling tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.2 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.3 Staafdiagram: verdelingen van N = 17 applicaties in het trainings- en testbestand 80

8.4 Curves: verdelingen van N = 17 applicaties in het trainings- en het testbestand . 81

8.5 Profielvenster: Percentage van de true positives per bin samen met de false neg-

atives (FN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.6 Associatieregels: Percentage van de true positives per bin samen met de false

negatives (FN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.7 Vergelijking van een Simple Recommender met de best presterende recommen-

datiefuncties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8.8 De grootte van een bericht dat gezonden wordt van client naar server bij een

gegeven aantal fixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.9 De datatrafiek per uur in functie van de periodiciteit waarop fixes worden opges-

lagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

LIJST VAN TABELLEN 104

Lijst van tabellen

8.1 Profielvenster: % true positives per bin, % false negatives (FN), IP(6,7,1000) en

NIP(6,7,1000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.2 Associatieregels: % true positives per bin, % false negatives (FN), IP(6,7,1000)

en NIP(6,7,1000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.3 Kortetermijngeheugen: % true positives per bin, % false negatives (FN), IP(6,7,1000)

en NIP(6,7,1000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

8.4 Vergelijking van een Simple Recommender met de best presterende recommen-

datiefuncties: IP(6,17,1000) en NIP(6,7,1000) . . . . . . . . . . . . . . . . . . . . 84

8.5 Performantieresultaten van het opbouwen van clusters en associatieregels . . . . 86

8.6 Performantieresultaten van het classificeren . . . . . . . . . . . . . . . . . . . . . 87

Gepersonaliseerde en contextafhankelijke profielen op Android …€¦ · Gepersonaliseerde en...

Documents

Transcript of Gepersonaliseerde en contextafhankelijke profielen op Android …€¦ · Gepersonaliseerde en...