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
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.
2.5 Technieken en frameworks 7
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
2.5 Technieken en frameworks 8
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
2.5 Technieken en frameworks 9
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.
2.5 Technieken en frameworks 10
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.
2.5 Technieken en frameworks 11
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
2.5 Technieken en frameworks 12
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.
2.5 Technieken en frameworks 13
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
2.5 Technieken en frameworks 14
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.
2.5 Technieken en frameworks 15
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).
2.5 Technieken en frameworks 16
• 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.
2.5 Technieken en frameworks 17
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 tijd- en 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.04877 4.21504 Monday 8:20 69.877 km/h Music, Email
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
51.04328 4.21558 Monday 17:00 70.444 km/h Music, Facebook
? ? 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.
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.04877 4.21504 Monday 8:20 69.877 km/h Music, Email
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
51.04328 4.21558 Monday 17:00 70.444 km/h Music, Facebook
? ? 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.2: Selectie van de attributen latitude en longitude voor het clusteren van location
5.3 Eerste-niveau clustering: attributen 41
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.
latitude longitude day of week time speed applications
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.
5.3 Eerste-niveau clustering: attributen 42
latitude longitude day of week time speed applications
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 2 Day 1 8:20 Speed 2 Music, Email
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 2 Day 1 17:10 Speed 2 Music, Email
Location 1 Day 1 22:30 Speed 1
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
5.3 Eerste-niveau clustering: attributen 43
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
latitude longitude day of week time speed applications
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 2 Day 1 Time 2 Speed 2 Music, Email
Location 3 Day 1 Time 2 Speed 1 Quickoffice
Location 3 Day 1 11:00 Speed 1
Location 3 Day 1 Time 3 Speed 1 Phone
Location 2 Day 1 Time 4 Speed 2 Music, Facebook
Location 2 Day 1 Time 4 Speed 2 Music, Email
Location 1 Day 1 22:30 Speed 1
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
5.4 Tweede-niveau clustering: applicaties 45
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
latitude longitude day of week time speed applications
Profiel 1 AlarmClock
Profiel 1 Agenda
Profiel 2 Music, Email
Profiel 2 Music, Facebook
Profiel 2 Music, Email
Profiel 3 Quickoffice
Profiel 3
Profiel 3 Phone
Profiel 2 Music, Facebook
Profiel 2 Music, Email
Profiel 1
Profiel 1 Youtube
Figuur 5.8: Clustering van alle attributen samen resulteert in de Android-profielen
5.4 Tweede-niveau clustering: applicaties 46
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.
latitude longitude day of week time speed applications
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, Email
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, Email
Profiel 2 Music, FacebookMusic, Email
Profiel 2
Profiel 3 Quickoffice
Profiel 3
Profiel 3 Phone
Profiel 2 Music, Facebook
Profiel 2 Music, Email
Profiel 4
Profiel 4 Youtube
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.04877 4.21504 Monday 8:20 69.877 km/h Music, Email
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
51.04328 4.21558 Monday 17:00 70.444 km/h Music, Facebook
? ? 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
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
51.03417 4.21742 Tuesday 20:30 0.027 km/h Youtube
51.03418 4.21738 Tuesday 20:50 0.025 km/h Youtube
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
KORTETERMIJN-GEHEUGEN
STATISTISCHALGORITME
INTRA-CLUSTER-CORRELATIE
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 Grafenalgoritme voor profielafhankelijke patronen 49
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.
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
6.1 Grafenalgoritme voor profielafhankelijke patronen 50
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
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
6.1 Grafenalgoritme voor profielafhankelijke patronen 51
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.
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
KORTETERMIJN-GEHEUGEN
STATISTISCHALGORITME
INTRA-CLUSTER-CORRELATIE
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.
7.4 Diensten van de server 60
ClusteredAttributeattributeName: Locationvalue: 1
ApplicationSetlocationspeed...profileapplications AttributeAssociationRule
confidence: 100%premise: Musicconsequence: Facebook
ClusteredAttributeattributeName: Locationvalue: 2
ClusteredAttributeattributeName: Speedvalue: 1
ClusteredAttributeattributeName: Speedvalue: 2
ClusteredAttributeattributeName: Locationvalue: 3
ClusteredAttributeattributeName: Profilevalue: 1
ClusteredAttributeattributeName: Profilevalue: 3
ClusteredAttributeattributeName: Profilevalue: 2
...
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
7.4 Diensten van de server 61
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
7.4 Diensten van de server 62
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
7.5 Server architectuur 64
: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.
7.5 Server architectuur 65
: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
7.5 Server architectuur 66
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
7.5 Server architectuur 67
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
7.5 Server architectuur 68
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-
7.5 Server architectuur 69
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.
7.5 Server architectuur 70
«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
«Interface»ProfileInfo
+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
7.6 Client architectuur 72
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.
7.6 Client architectuur 73
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 Client architectuur 74
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[]
«Interface»ProfileInfo
+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
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.
8.3 Evaluatie van de applicatierecommandatie 82
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)
8.3 Evaluatie van de applicatierecommandatie 83
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
8.4 Performantie van de serverdiensten 85
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 test- en 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.
8.4 Performantie van de serverdiensten 86
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:
8.4 Performantie van de serverdiensten 87
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
8.6 Netwerkbelasting tussen client en server 90
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.
8.6 Netwerkbelasting tussen client en server 91
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
8.6 Netwerkbelasting tussen client en server 92
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
8.6 Netwerkbelasting tussen client en server 93
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
LIJST VAN FIGUREN 102
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
LIJST VAN FIGUREN 103
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
Top Related