Een context-aware aanbevelingssysteem voor mobiele toestellen

Powered by TCPDF (www.tcpdf.org)

Academiejaar 2013–2014

Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 1 – 9000 Gent

Een context-aware aanbevelingssysteem voor mobiele toestellen

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Sebastiaan DUMOULEIN Promotoren: Marleen DENERT prof. dr. ir. Luc MARTENS prof. dr. ir. Wout JOSEPH Begeleider:

dr. ir. Toon DE PESSEMIER

Powered by TCPDF (www.tcpdf.org)

Academiejaar 2013–2014

Faculteit Ingenieurswetenschappen en Architectuur Valentin Vaerwyckweg 1 – 9000 Gent

Een context-aware aanbevelingssysteem voor mobiele toestellen

Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica

Sebastiaan DUMOULEIN Promotoren: Marleen DENERT prof. dr. ir. Luc MARTENS prof. dr. ir. Wout JOSEPH Begeleider:

dr. ir. Toon DE PESSEMIER

Abstract Nederlands Wanneer de gebruiker zich tijdens een zoektocht op het wereldwijde web niet exact kan uitdrukken of niet precies weet waar hij op zoek naar is, bestaat er een nood aan een betere begeleiding en ondersteuning tijdens zijn speurtocht. Aanbevelingssystemen kunnen persoonlijke suggesties geven op basis van een aantal voorkeuren van de eindgebruiker. Bij hedendaagse systemen wordt enkel rekening gehouden met de zoekgeschiedenis en niet met de context waarin de gebruiker zich bevindt. Deze context kan helpen om meer persoonlijke suggesties te geven. Dankzij de low-level sensordata van het mobiele toestel kan de gebruikerscontext bepaald worden. Routeherkenning detecteert eerder afgelegde trajecten en betrekt deze in de context. Deze wordt vervolgens verrijkt met extra informatie van andere bronnen zoals bijvoorbeeld weersinformatie. De applicatie is ontwikkeld voor Android en gebruikt de sensoren van het mobiele toestel om aanbevelingen voor bezienswaardigheden te geven. Low-level sensordata wordt verwerkt tot een high-level context, die meer inzicht geeft in de situatie en intenties van de gebruiker. De applicatie dient de high-level context situaties te decteren en toepasselijke aanbevelingen te geven. Waarderingen voor contextuele aanbevelingen kunnen tot tien procent hoger scoren dan deze voor klassieke aanbevelingssystemen. Kernwoorden: content, sensoren, high-level, aanbevelingssystemen, context, mobiel toestel, applicatie

English When the user can’t express himself exactly during a search on the world wide web or he doesn’t really know what to search for, there is a need for better guidance and support during his quest. Recommender systems are able to give personal suggestions based on the preferences of the end user. Contemporary recommender systems don’t take the user’s context into account. This can be significantly important when selecting content. Thanks to the low-level sensordata of mobile devices, it is possible to determine the context of the user. Route recognition detects previously traveled routes and uses this in the context. Following the initial retrieval there is an enrichment phase which adds extra information from different sources such as weather information. The application is written in Android and uses the sensors of the mobile device for recommending points of interest. Low-level sensordata is processed into a high-level context which provides more perception of the current situation and intentions of the user. The application automatically detects these high-level context situations and reacts with proper contextual recommendations. Contextual recommendations receive ratings that are up to ten percent higher than ratings for a classic recommender system. Keywords: Content, Sensors, High-level, Recommender System, Context, Mobile Device, Application

i

Woord vooraf

"Een context-aware aanbevelingssysteem voor mobiele toestellen" was een onderwerp dat me onmiddellijk aansprak. Wat is een context-aware aanbevelingssysteem precies en hoe wordt dit gebruikt op een mobiel toestel? Bij aanvang van deze masterproef waren er veel vragen waar ik geen pasklaar antwoord kon op geven. Net als iedere informaticus was ik nieuwsgierig naar de interne werking en logica van het onbekende. Het was het begin van een uitdagende zoektocht. Na het volgen van een inleidende cursus tot aanbevelingssystemen werd me meer duidelijk omtrent dit zeer uitgebreide vakgebied. De verschillende soorten systemen met elk hun pro’s en contra’s zijn een fascinerend gegeven met een enorme capaciteit. Het aantal toepassingen waar aanbevelingssystemen een meerwaarde kunnen bieden is oneindig. Deze nieuwe technologie ontwikkelen voor een mobiel toestel was iets wat me enorm aansprak. Een masterproef komt natuurlijk niet vanzelf tot stand en zou niet te vervolledigen zijn zonder de hulp van enkele personen. Mijn interne promotor Marleen Denert, wil ik bedanken voor de kritische kijk en het arendsoog waarmee de scriptie met elk detail tot zijn recht kwam. De externe promotoren Wout Joseph en Luc Martens voor de kans om dit eindwerk bij Wireless and Cables uit te voeren. Mijn begeleider Toon De Pessemier die met zijn uitgebreide kennis telkens een antwoord kon bieden op vragen en problemen. Hij leerde me om elke methode kritisch te bekijken en toonde aan dat er via verschillende invalshoeken oplossingen mogelijk zijn. Als laatste wil ik mijn vriendin Céline en mijn ouders bedanken, die me met hun onvoorwaardelijke steun telkens weer wisten te motiveren. Gent, juni 2014 Sebastiaan Dumoulein

ii

Table of Contents Abstract

i

Woord vooraf

ii

1 Situering 1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doel van de masterproef . . . . . . . . . . . . . . . . . . 1.3 Aanbevelingssystemen . . . . . . . . . . . . . . . . . . . 1.3.1 Klassiek aanbevelingssysteem . . . . . . . . . . 1.3.2 Verschillende soorten aanbevelingsalgoritmes 1.3.3 Aanbevelingssysteem in CARS . . . . . . . . . . 1.4 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Wat is context? . . . . . . . . . . . . . . . . . . . 1.4.2 Verschillende soorten . . . . . . . . . . . . . . . . 1.4.3 Hoe wordt de context opgehaald? . . . . . . . 1.4.4 Wanneer is context belangrijk? . . . . . . . . . 1.5 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Wat? . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Marketshare . . . . . . . . . . . . . . . . . . . . . 1.5.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Elementen van een Android applicatie . . . . . 1.5.5 Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Apache Lucene . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Wat? . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Logische structuur . . . . . . . . . . . . . . . . . 1.6.3 Lucene als aanbevelingssysteem . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

1 1 2 4 4 5 6 6 6 7 7 8 8 8 8 9 10 11 11 11 11 12

2 Onderzoek 2.1 Model . . . . . . . . . . . . . . . . . . . . . 2.1.1 Datastructuur . . . . . . . . . . . 2.2 Contextparameters . . . . . . . . . . . . . 2.2.1 Selectie . . . . . . . . . . . . . . . 2.2.2 Verrijking met weersinformatie 2.2.3 Generalisatie van de context . . 2.3 Gebruikersinstellingen . . . . . . . . . . 2.3.1 Privacy van de gebruiker . . . . 2.3.2 Quality Of Experience . . . . . . 2.4 Strategieën . . . . . . . . . . . . . . . . . . 2.5 Plaats-en routedetectie . . . . . . . . . . 2.5.1 Plaatsen . . . . . . . . . . . . . . . 2.5.2 Routes . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

13 13 13 14 14 15 16 17 17 17 21 23 23 24

. . . . . . . . . . . . .

iii

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2.6 Architectuur . . . . . . . . 2.7 Data . . . . . . . . . . . . . 2.7.1 Open Street Map 2.7.2 Google Places . . 2.8 Gebruikersprofiel . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

26 28 28 28 31

3 Implementatie 3.1 Sensoren op het mobiele toestel . . . . . . . . . . . . . . . 3.1.1 Clock: . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Bewegingsactiviteit: . . . . . . . . . . . . . . . . . . 3.1.3 Locatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Wifi en GPS online . . . . . . . . . . . . . . . . . . . 3.2 Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Context servlet . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Recommendation servlet . . . . . . . . . . . . . . . 3.2.3 Weather Controller . . . . . . . . . . . . . . . . . . . 3.2.4 Google Places Access Controller . . . . . . . . . . . 3.2.5 Database Controller . . . . . . . . . . . . . . . . . . 3.3 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Willekeurige context . . . . . . . . . . . . . . . . . . 3.3.3 Drempelwaarde trainen versus normaal gebruik . 3.4 Crashlytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Context prefiltering . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

32 32 32 32 34 36 37 38 38 40 40 41 42 42 43 43 44 45

4 Resultaat en conclusie 4.1 Gebruikerstesten . . . . . . . . . . . . . . . . . . . . . 4.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Impactwaarden . . . . . . . . . . . . . . . . . 4.2.2 Implementatie andere strategieën . . . . . . 4.2.3 Uitbreiding van de context . . . . . . . . . . 4.2.4 Uitgebreidere gebruikerstest . . . . . . . . . 4.2.5 Dynamische drempelwaarde routedetectie 4.3 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

49 49 51 51 51 51 52 52 53

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . . . . .

A Handleiding

58

B Digitale kopie

63

iv

Hoofdstuk 1

Situering 1.1

Probleemstelling

De klassieke keyword-gebaseerde zoeksystemen zijn niet meer voldoende om de eindgebruiker te helpen bij het filteren van de juiste informatie in de overvloed aan data die op het internet beschikbaar is. Vooral wanneer de gebruiker zich niet exact kan uitdrukken of niet precies weet naar wat hij of zij precies op zoek is, kunnen aanbevelingssystemen een betere oplossing zijn dan de traditionele zoeksystemen. Aanbevelingssystemen kunnen persoonlijke suggesties geven voor nieuwe content op basis van de voorkeuren van de eindgebruiker. Typische voorbeelden van systemen die gebruik maken van aanbevelingen zijn online shops (Amazon), videodiensten (Netflix, YouTube), muziekdiensten (lastFM, iTunes), geotagging apps (Foursquare), etc. Bij hedendaagse aanbevelingssystemen wordt echter de context van de gebruiker niet in rekening gebracht. De context kan echter belangrijk zijn bij de selectie van content. Zo kan een gebruiker ’s morgens in andere content geïnteresseerd zijn dan ’s avonds (bijvoorbeeld ’s morgens werk-gerelateerd, ’s avonds ontspannende content). Een ander voorbeeld is een pendelaar die dagelijks tien minuten op de bus zit. Een ideale aanbeveling is een korte tekst of video die binnen deze periode kan gelezen of bekeken worden. De pendelaar wil in dit geval geen lange film beginnen bekijken of een te lang artikel lezen. Het tijdstip is van groot belang: in het weekend zal de gebruiker misschien op zoek gaan naar andere content dan in de week. Ook de locatie kan een belangrijke invloed hebben: op vakantie willen mensen andere dingen lezen/bekijken dan thuis. De context heeft een grote invloed op de keuzes of voorkeuren van een gebruiker. Door de context niet in het aanbevelingsalgoritme te betrekken verliest het systeem veel informatie die een betere lijst aanbevelingen kan opleveren.

1

1.2

Doel van de masterproef

Bij hedendaagse aanbevelingssystemen wordt met impliciete acties, zoals het al dan niet klikken op links of de tijdsduur dat de gebruiker een artikel leest al rekening gehouden. Toch zijn er veel omgevingseigenschappen van de gebruiker die niet benut worden. De context heeft een grote rol in het bepalen van de content. Vaste computers beschikken niet over de sensoren om deze context te bepalen, bovendien blijft deze voor een vaste computer vaak gelijk, in tegenstelling tot mobiele toestellen waar de context regelmatig verandert. Dankzij de low-level sensordata van het mobiele toestel kan de gebruikerscontext bepaald worden. In deze masterproef wordt een applicatie voor Android ontwikkeld. Die gebruikt de sensoren van het mobiele toestel en maakt aanbevelingen voor bezienswaardigheden. De bekende contextparameters zijn de tijd (uurwerk) of de locatie (GPS1 ). Uit deze waarden kan meer bepaald worden dan enkel de ruwe data2 . Low-level sensordata wordt verwerkt tot een high-level context, die meer inzicht geeft in de situatie en intenties van de gebruiker. De applicatie dient de high-level context situaties te detecteren en er toepasselijk op te reageren. Dankzij de locatie kan de applicatie bijvoorbeeld de weersomstandigheden opvragen. Tijdens een regenachtige dag heeft de gebruiker nood aan andere content dan tijdens een zonnige dag. De contextuele situatie wordt verrijkt met extra informatie van andere bronnen. Context bestaat initieel uit een vast aantal parameters zoals bijvoorbeeld de route (bestaande uit een vertrekplaats, een aantal intermediaire punten en een bestemming), de tijd en het weer. Er wordt onderzocht als de locatie kan gebruikt worden om te bepalen of de gebruiker een vast traject volgt (bijvoorbeeld het rijden naar het werk of naar een sportcentrum). Het herkennen van deze situaties houdt in dat de activiteiten automatisch gedetecteerd worden zonder tussenkomst van de gebruiker en zonder kennis van de eindbestemming. Om de route te bekomen wordt er gewerkt met een tijdsinterval. Na een bepaalde periode krijgt de applicatie de locatie van het mobiel toestel. De opeenvolgende locaties worden in het geheugen bewaard en de afgelegde weg wordt vergeleken met routes die al in de database zitten. Een ingestelde marge zorgt er voor dat de gebruiker van de route mag afwijken, maar dat de route wel nog herkend wordt. Dit kan handig zijn tijdens wegomleidingen of ongelukken. De tijd kan opgedeeld worden in werkdagen, specifieke dagen of zelfs gewoon in ochtend, namiddag, avond en nacht. Het weer wordt opgevraagd via een webservice op basis van de locatie. De context wordt op een abstracte manier bewaard. Op deze manier kan men in een later stadium de context eenvoudig uitbreiden met meerdere parameters en dus een grotere maat van detail in de context verwerken. Bij een origineel aanbevelingssysteem worden in de databank -waarden opgeslagen. In het nieuwe systeem zal er tijdens het waarderen van een bepaald item een context 1 2

Global Positioning System Met ruwe data wordt verwezen naar de getallen die sensoren terug geven.

2

waargenomen worden, zodat er in de databank een -waarde kan opgeslagen worden. Er kunnen verschillende technieken gebruikt worden om samen met de context betere voorspellingen te maken. Een voorbeeld hiervan is context-prefiltering. Deze manier van werken zal enkel de waarderingen met een correcte context selecteren en op basis hiervan aanbevelingen maken. Activiteiten zoals lopen, fietsen, autorijden of stilstaan kunnen gedecteerd worden met behulp van de Android API3 . Deze activiteiten maken een onderdeel uit van de context en worden hierin betrokken. Recentere smartphones beschikken over sensoren die vroeger niet aanwezig waren. Sensoren zoals een vochtigsheids- of temperatuurmeter geven meer informatie over de omgeving en kunnen gebruikt worden om de context uit te breiden. Een overzicht van enkele gebruikte sensoren wordt schematisch in figuur 1.1 voorgesteld.

Figuur 1.1: Applicatie voorstelling Om na te gaan of de context effectief een invloedrijke rol heeft, wordt de accuraatheid van het aanbevelingssysteem getoetst. Dit gebeurt via een vergelijking met een origineel aanbevelingssysteem die geen gebruik maakt van de contextparameters. Het testpubliek weet niet of het context-aware of klassiek systeem gebruikt wordt. Dankzij de data van de sensoren en de geschiedenis van de gebruiker wordt een gebruikersprofiel opgebouwd. Met dit profiel zal het aanbevelingssysteem contextuele voorspellingen maken voor de gebruiker.

3 Een Application Programming Interface is een verzameling van functies en methodes die de applicatie kan aanspreken om met een ander programma of onderdeel te communiceren.

3

De applicatie ‘Context-Aware Recommender System’ is gratis via de Play Store4 te installeren. De applicatie is te downloaden via het zoeken in de Play Store op ‘Context-Aware’ of het surfen naar onderstaande URL5 . Het is te herkennen aan het logo van CARS, zie figuur 1.2. Een handleiding om de applicatie te gebruiken is beschikbaar in bijlage A. https://play.google.com/store/apps/details?id=be.ugent.iii.cars Figuur 1.2: CARS logo

1.3 1.3.1

Aanbevelingssystemen Klassiek aanbevelingssysteem

Het aantal aanbevelingssystemen die op het wereldwijde web gebruikt worden zit in een stijgende lijn[1]. Denk maar aan koopsites of sociale media waar de inhoud voor de gebruiker bepaald wordt aan de hand van zijn interesses. Klassieke aanbevelingssystemen houden geen rekening met de context van de gebruiker. Hierdoor gaat informatie verloren die waarschijnlijk invloed heeft op de voorkeuren van de gebruiker. Aanbevelingssystemen streven om een waardering die een gebruiker zou geven aan een item te voorspellen. Eens voor alle niet-gewaardeerde items een score voorspeld is, kan een lijst met aanbevelingen opgesteld worden. Deze bevat typisch de items met de hoogst voorspelde waarderingen. Een klassiek, tweedimensionaal aanbevelingssysteem linkt een waardering aan twee entiteiten: items en gebruikers[2, 3]. Een gebruiker kan maximaal één waardering aan een item geven. Het gebruik van twee entiteiten per waardering resulteert in een tweedimensionale matrix, zie figuur 1.3. Voor iedere gebruiker en item is er een mogelijke beoordeling aanwezig in deze matrix. Lege velden hebben geen beoordeling gekregen en worden voorspeld door het aanbevelingssysteem. In het voorbeeld van figuur 1.3 heeft gebruiker 01 waarderingen gegeven voor items 01, 02 en 03. Het aanbevelingsalgoritme zal voorspellingen maken voor item 04 en 05 op basis van de reeds ingevulde waarderingen. Wat de moeilijkheden en gevolgen zijn wanneer de context wel gebruikt wordt is beschreven in hoofdstuk 2.1. 4 Via Google Play kunnen gebruikers gratis en betalende applicaties installeren voor Android-specifieke mobiele toestellen. 5 Een Uniform Resource Locator is een identificerende naam die verwijst naar data.

4

Figuur 1.3: Twee-dimensionale datastructuur

1.3.2

Verschillende soorten aanbevelingsalgoritmes

Content-based filtering De items die door het aanbevelingssysteem gewaardeerd worden bezitten karakteristieke eigenschappen of kunnen door sleutelwoorden omschreven worden. Per gebruiker wordt een profiel bewaard dat aangeeft welke eigenschappen of sleutelwoorden hij verkiest. De aanbevelingsalgoritmes gaan items aanbevelen die dicht tegen het gebruikersprofiel aanleunen. Een voorwaarde om een content-based algoritme te gebruiken is dat de content eigenschappen of sleutelwoorden bezit die representatief zijn voor de inhoud. Kunst is bijvoorbeeld niet eenvoudig te omschrijven. Collaborative filtering Methodes in deze categorie zijn gebaseerd op het verzamelen en analyseren van grote hoeveelheden informatie rond de activiteiten en voorkeuren van de gebruikers. Deze aanbevelingsalgoritmes voorspellen waarderingen door gebruikers, die een simultane voorkeur als de hoofdgebruiker hebben, te vinden. Indien deze gebruikers bepaalde items hoog waarderen, is er een grote kans dat de hoofdgebruiker dit ook leuk vindt. Het grote voordeel van collaborative filtering is dat complexe items kunnen aanbevolen worden zonder dat het systeem weet heeft van de eigenschappen van deze items. Hybride aanbevelingssystemen Recent onderzoek heeft aangetoond dat een combinatie van een collaborative filtering en contentbased in sommige gevallen een beter resultaat geeft[4]. Er zijn verschillende aanpakken mogelijk: de twee algoritmes apart aanbevelingen laten genereren en deze te combineren, door content-based methodes toe te voegen aan een collaborative-based aanpak (of vice-versa) of door deze te laten samensmelten in één model. Deze technieken kunnen enkele van de traditionele

5

tekortkomingen van aanbevelingssystemen oplossen zoals het koude-start probleem6 . Een hybride aanbevelingssysteem omvat ieder systeem die meerdere aanbevelingstechnieken combineert.

1.3.3

Aanbevelingssysteem in CARS

Voor de applicatie ‘Context-Aware Recommender System wordt een content-based aanbevelingssysteem gekozen. Dit wordt gemotiveerd door het kleine aantal testpersonen die de applicatie zal gebruiken tijdens de duur van deze masterproef en de grote hoeveelheid beschikbare bezienswaardigheden. Als content-based algoritme wordt Lucene gekozen. Dit wordt besproken in hoofdstuk 1.6. De implementatie van Lucene als contextgevoelig aanbevelingsalgoritme wordt met codevoorbeelden in hoofdstuk 3.5 uitgelegd.

1.4 1.4.1

Context Wat is context?

Context hangt af van het domein en de discipline waarin het gebruikt wordt. Ieder vakgebied heeft zijn eigen betekenis en interpretatie voor het woord ‘context’. In woordenboeken vinden we een ruime, vage betekenis.. “Verband of omgeving waarin iets gebeurt”7 “Samenhang, het woord ontleent zijn betekenis aan de context aan het overige deel van de zin”8 “De context is de achtergrond of referentie van elke uitdrukking of idee of gebeurtenis in welke het was uitgedrukt, in relatie tot welke het een bepaalde betekenis verkrijgt.”9 In aanbevelingssystemen kan context omschreven worden als alle eigenschappen die invloed hebben op de voorkeur van de gebruiker[2]. Deze context is uitgebreid en kan veel waarden bevatten. De uitdaging bestaat erin om de meest invloedrijke parameters te vinden. Enkele voorbeelden van contextparameters zijn: gezelschap, gemoedstoestand, temperatuur, uur van de dag, etc. Een mens zijn gewoontes spelen zich dikwijls af in een bepaalde context. Door met deze context rekening te houden, kan het systeem correcte aanbevelingen maken, bijvoorbeeld: “Als het zonnig is, ga ik graag naar een park.” “Om acht uur ’s avonds ben ik liever thuis.” 6

Nieuwe gebruikers die weinig of geen waarderingen voor items gemaakt hebben, geven weinig informatie om aanbevelingen op te baseren. 7 Gedefinieerd door Woorden.org: http://www.woorden.org/zoek.php?woord=context 8 Gedefinieerd door Van Dale: http://www.vandale.be/opzoeken?pattern=context&lang=nn 9 Gedefinieerd door Wikipedia: http://nl.wikipedia.org/wiki/Context_(taal)

6

1.4.2

Verschillende soorten

De verschillende soorten contextparameters zijn op te delen in verschillende categorieën. Niet alle contextparameters kunnen aan de hand van sensoren opgemeten worden en dienen door de gebruiker zelf ingesteld te worden. Fysische context: Omvat de fysieke omgeving van de gebruiker en is op te meten via de sensoren van het mobiele toestel, bijvoorbeeld: tijd, weer, licht, temperatuur, etc. Sociale context: Aanwezigheid van vrienden, kennissen of familie is niet op te meten met een sensor en dient door de gebruiker zelf aangegeven te worden. Interactieve media context: Details van het gebruikte mobiele toestel of informatie rond de media die als inhoud aanbevolen wordt, bijvoorbeeld: tekst, muziek, afbeeldingen, filmpjes, etc. Modale context: Omvat de gemoedstoestand of het humeur van de gebruiker en dient door hemzelf aangeduid te worden.

1.4.3

Hoe wordt de context opgehaald?

Niet alle contextparameters zijn op dezelfde manier te bepalen. Er dient steeds de vraag gesteld te worden of de parameter niet berekend kan worden op een server. Zo is het mogelijk om het seizoen op een mobiel toestel op te vragen, maar kan dit evengoed op een server berekend worden. Expliciet: Door de vraag rechtstreeks aan de gebruiker te stellen. Dit gaat om data die niet door sensors kan waargenomen worden zoals bijvoorbeeld het gezelschap, humeur of de gemoedstoestand. Impliciet: Door de context af te leiden uit de omgeving. Dit kan via allerhande sensoren en hun ruwe data, bijvoorbeeld: de locatie, het uur, de bewegingsactiviteit, etc. Inferring: Door gebruik te maken van statistiek en data mining10 methoden kunnen contextparameters gedetecteerd worden. Aan de hand van voorspelbare modellen kunnen gebruikerseigenschappen afgeleid worden. Het is bijvoorbeeld mogelijk om te bepalen als de gebruiker een man of vrouw is door de bekeken televisiezenders te observeren.

10

Datamining is het gericht zoeken naar statistische verbanden in gegevensverzamelingen.

7

1.4.4

Wanneer is context belangrijk?

In een aanbevelingssysteem zal de context de inhoud bepalen, maar er is ook een wederzijdse relatie, bijvoorbeeld: Op 27 januari (herdenkingsdag) krijgt ‘Schindler’s List’ 5 sterren terwijl deze op 24 juni slechts 3 sterren krijgt. Dit toont aan dat het belang van bepaalde contextparameters afhankelijk is van de inhoud zelf en is per item anders. Bij een andere film heeft de datum echter geen bijzonder betekenis maar kan een andere contextparameter belangrijker zijn. Er kan gesteld worden dat er een wederzijdse relatie tussen het item en de context aanwezig is. In een aanbevelingssysteem bepaalt de context de inhoud, maar bepaalt de inhoud de impact van de contextparameters.

1.5 1.5.1

Android Wat?

Er is gekozen om de applicatie voor het besturingssysteem Android te ontwikkelen. Android is een opensourceplatform11 en besturingssysteem voor mobiele telefoons. Het is gebaseerd op de Linux-Kernel en wordt ontwikkeld door Google. De grootste tegenhanger van Android is iOS, het besturingssysteem van de iPhone, en wordt ontwikkeld door Apple. Android heeft de troon overgenomen van Apple als meest verkochte besturingssysteem voor mobiele telefoons. Applicaties voor Android worden ontwikkeld via een SDK12 . Applicaties worden verspreid via de Play Store waar er gratis en snel een eigen applicatie kan gepubliceerd worden. Het grote voordeel van de Play Store is dat er geen goedkeuring van een selectie-orgaan nodig is om de applicatie te verspreiden. Android gebruikt XML-bestanden13 om de layout van de schermen te bepalen. De functionaliteit wordt geprogrammeerd in Java en bevat een structuur die zorgt voor een onderscheid in presentatie en logica.

1.5.2

Marketshare

Applicaties gemaakt voor Android zijn eenvoudig en zonder licensiekosten te ontwikkelen. Dankzij de enorme marketshare bereik de ontwikkelaar een groot publiek dat eenvoudig en zonder kosten de applicatie kan installeren, zie figuur 1.4. Android is de absolute marktleider met 79% gevolgd door iOS en Windows Phone 8. 11 Open Source als ontwikkelingsmodel geeft toegang tot de productie en ontwikkeling van de bronmaterialen van het eindproduct. 12 Een Software Development Kit is een verzameling hulpmiddelen die handig zijn bij het ontwikkelen van programma’s voor een bepaald besturingssysteem of type hardware 13 eXtensible Markup Language

8

Figuur 1.4: Android marketshare

1.5.3

API

Vervolgens is er de keuze van het API-niveau14 van de applicatie. Lage niveau’s van de API die vroeger ontwikkeld werden, zorgen voor het grootste doelpubliek. Nieuwe mobiele toestellen worden echter met de nieuwste API voorzien maar zijn backwards compatibel zodat reeds ontwikkelde applicaties steeds bruikbaar blijven op de nieuwste toestellen. Oudere versies van de API hebben minder functionaliteit dan recentere versies. Er wordt gekozen voor het laagst mogelijke API-niveau dat toch alle functionaliteit verzorgt. ‘Context-Aware Recommender System’ gebruikt versie 10 met codenaam Gingerbread en bereikt 98,8% van de Android gebruikers, zie figuur 1.5 en tabel 1.1.

Figuur 1.5: API gebruik 14

Application Programming Interface

9

Versie

Codenaam

API

Distributie

2.2

Froyo

8

1.2%

2.3.3 - 2.3.7

Gingerbread

10

19.0%

3.2

Honeycomb

13

0.1%

4.0.3 - 4.0.4

Ice Cream Sandwich

15

15.2%

16

35.3%

17

17.1%

18

9.6%

19

2.5%

4.1.x 4.2.x

Jelly Bean

4.3 4.4

KitKat

Tabel 1.1: Huidige Android versies

1.5.4

Elementen van een Android applicatie

Activity: Een activiteit is één enkel scherm of deel van een scherm met een user interface. Het heeft een specifieke taak en is een deel van de presentatielaag. Een activiteit wordt gestart door een andere activiteit en wordt geregistreerd in het manifest met de -tag. Broadcast Receiver: Een basisklasse die verantwoordelijk is voor het luisteren naar broadcastberichten. Er zijn twee soorten broadcasts die ontvangen kunnen worden. De normale uitzendingen zijn volledig asynchroon en worden in een niet voorspelbare orde aan alle luisteraars bezorgd. De geordende uitzendingen worden per cyclus aan één specifieke luisteraar bezorgd. Zo kan één bepaalde luisteraar een andere gaan beïnvloeden. Service: Een onderdeel van de applicatie die een langlopende taak uitvoert terwijl deze niet interageert met de gebruiker. Dit wordt meestal uitgevoerd in een aparte thread en met de <service>-tag in het manifest geregistreerd. Content Provider: Kan via een interface data delen met andere applicaties. Resources: Allerhande extra informatie bestaande uit afbeeldingen, tekst of kleuren worden bewaard in aparte mappen en bestanden. Deze structuur behoudt het onderscheid tussen weergave en logica.

10

1.5.5

Lifecycle

Er zijn drie mogelijke staten waarin een activiteit zich kan bevinden. Als een activiteit van een bepaalde staat naar een andere gaat, worden specifieke functies opgeroepen. Hierdoor is het mogelijk om acties tussen overgangen van staten uit te voeren. Running: De activiteit heeft de focus van de gebruiker en bevindt zich op de voorgrond van het scherm. Paused: De activiteit is nog deels zichtbaar maar heeft geen focus. De informatie blijft behouden maar kan door het systeem in heel extreme omstandigheden gesloten worden. Stopped: De activiteit is niet meer zichtbaar maar bevindt zich in de achtergrond. Wanneer het besturingssysteem extra bronnen nodig heeft zal deze de activiteit stoppen.

1.6 1.6.1

Apache Lucene Wat?

Lucene is een hoog performante, tekstgebaseerde zoekmachine-library geschreven in Java. Het is een opensourceproject gesteund door de Apache Software Foundation en is beschikbaar voor verschillende programmeertalen. Oorspronkelijk werd Apache Lucene gebruikt voor internet of site-lokale zoekmachines. Omdat Lucene de tekst via opgebouwde indexen doorzoekt, wordt een grote snelheid gehaald. Zoeken via indexen kan vergeleken worden met het direct ophalen van de paginanummers en alinea’s waar een bepaald sleutelwoord zich bevindt. Dit kan best vergeleken worden met de index achteraan in wetenschappelijke boeken, waar wordt opgesomd waar de sleutelwoorden zich in het boek bevinden. Dit heet een geïnverteerde index. Het is evident dat het zoeken via indexen veel sneller verloopt dan het volledig sequentieel doorlopen van de tekst. Apache Lucene is beschikbaar onder de Apache License die zowel commerciële als open source programma’s toelaat.

1.6.2

Logische structuur

De logische structuur van Lucene gebruikt documenten bestaande uit tekstvelden. Voor iedere bezienswaardigheid wordt een Lucene document gecreëerd die de tags (zie hoofdstuk 2.7.2 ) van de locatie als tekstvelden bevat. De documenten worden geïndexeerd aan de hand van deze tekstvelden. Lucene laat toe om in de indexen te zoeken via een query. Het heeft zijn eigen query-taal, de Lucene Query Syntax, die toelaat om op bepaalde indexen te zoeken. Lucene zal aan ieder document een score toekennen, afhankelijk van de gebruikte query. Documenten met een hoge toegekende score worden als relevant beschouwd.

11

Boosten laat toe om aan bepaalde termen een hoger gewicht toe te kennen. Per woord wordt een boostgetal vastgelegd die het belang van de term cijfermatig weergeeft. Een groot getal stemt overeen met een invloedrijk woord en laat documenten met deze index hoger scoren.

1.6.3

Lucene als aanbevelingssysteem

Bij het gebruiken van Lucene als aanbevelingssysteem dient de content in documenten te komen. Veel soorten inhoud hebben geen of een beperkt aantal toepasselijke onderdelen om in documenten te plaatsen. Hierdoor kunnen eigenschappen van de inhoud in de documenten geplaatst worden. In het geval van bezienswaardigheden worden de verschillende types in documenten bewaard, zie hoofdstuk 2.7.2. In het gebruikersprofiel wordt per context voor ieder type een gewicht bijgehouden. Hierdoor is het mogelijk om met de Lucene Query Language een query op te bouwen die bepaalde types meer of minder gaat boosten. Bezienswaardigheden met types die een grote boostfactor hebben komen hoger in de lijst te staan. Vervolgens wordt aan de hand van de query een lijst van hoogst scorende documenten opgehaald. De volgorde van de opgehaalde documenten bepaalt de plaats van de aanbevelingen in de lijst.

12

Hoofdstuk 2

Onderzoek 2.1 2.1.1

Model Datastructuur

Een context is een ruim gegeven dat gevormd wordt door verschillende parameters. Wanneer één van deze parameters verandert in waarde wordt een andere context bekomen. Zo is een context om 11h ’s ochtends anders dan 20h ’s avonds. Items die in een bepaalde context gewaardeerd worden, kunnen opnieuw een waardering krijgen in een andere context. Het tweedimensionaal model van hoofdstuk 1.3.1 wordt uitgebreid met een derde dimensie, deze van de context. Deze derde entiteit zorgt voor een driedimensionale matrix, zie figuur 2.1. Voor iedere gebruiker en item is er per context een mogelijke beoordeling aanwezig.

Figuur 2.1: Driedimensionale datastructuur Een context-aware aanbevelingssysteem zal per context de lege velden voorspellen aan de hand van een strategie. Er zijn drie mogelijke strategieën om de contextuele informatie in het aanbevelingssysteem te verwerken: context prefilteren, context postfilteren en context modelling. Deze worden elk ontleed en onderzocht op hun voor- en nadelen in hoofdstuk 3.5. 13

2.2 2.2.1

Contextparameters Selectie

Mobiele toestellen hebben veel sensoren maar welke hebben de mogelijkheid om nuttige informatie toe te voegen aan de context? Niet alle contextparameters zijn met sensoren op te meten. Welke parameters er de selectie gehaald hebben om in de context aanwezig te zijn en hun origine ziet u in tabel 2.1. Contextparameter

Origine

Route Bewegingsactiviteit Gemoedstoestand Humeur Gezelschap Temperatuur Weeromschrijving Seizoen Weekend Tijd van de dag

Smartphone Smartphone Smartphone Smartphone Smartphone World Weather Online World Weather Online Webservice Webservice Webservice

Tabel 2.1: Verschillende contextparameters en hun origine

Een eerste parameter die gebruikt wordt, is de route waarop een gebruiker zich al dan niet bevindt. Als een gebruiker verschillende keren eenzelfde route naar een eindbestemming neemt, dan zal de applicatie deze route detecteren en verwerken in de context. Als hij zich niet op een route bevindt, wordt hier geen rekening mee gehouden. De bewegingsactiviteit kan eenvoudig via Android bepaald worden en wordt uitvoerig beschreven in hoofdstuk 3.1.2. Het resultaat beschrijft de bewegingsactiviteit van de gebruiker. Er worden momenteel vier bewegingsactiviteiten herkend: stilstand, wandelen, fietsen of autorijden. Deze worden vastgesteld via een combinatie van verschillende sensoren zoals de accelerometer1 en de GPS. Hierna volgen drie waarden die niet met een sensor op te meten zijn. Het gaat over de gemoedstoestand, het humeur en het gezelschap van de gebruiker. Aan de hand van een keuzemenu kan de gebruiker de juiste waarden ingeven. Voor de gemoedstoestand kan de gebruiker kiezen uit kalm of actief, voor het humeur uit gelukkig of triestig en voor het gezelschap uit: alleen, met de partner, met vrienden of met familie. Voor de temperatuur en de weersomschrijving gebruikt de applicatie de World Weather Online webservice, zie hoofdstuk 2.2.2. Ze geeft informatie over de weeromstandigheden op basis van de locatie van de gebruiker. 1

Meetapparaat dat de maat van versnelling volgens de drie assen registreert.

14

De laatste drie parameters zijn afhankelijk van de tijd en worden tijdens het bewaren of ophalen van de context op de server berekend. De tijd van de dag is één van de belangrijkste parameters van de context. Voorkeuren zijn ook seizoensgebonden, terwijl de weekendparameter bijhoudt als de context zich tijdens het weekend of een werkdag afspeelt. Het houdt in essentie bij als de gebruiker dient te werken of vrijaf heeft. Voorlopig wordt nog geen rekening gehouden met feestdagen of vakantie, waar de gebruiker ook niet hoeft te werken. De huidige locatie wordt niet in de context opgenomen omdat dit de algemene inhoud voor het aanbevelingssysteem bepaalt. Indien de locatie in de context verwerkt zou worden, verkrijgt het aanbevelingssysteem telkens dezelfde bezienswaardigheden en vervalt het belang van de overige contextparameters.

2.2.2

Verrijking met weersinformatie

Verrijking laat toe om aan de hand van de low-sensor gegevens, andere bronnen van informatie te raadplegen. World Weather Online World Weather Online biedt een ontwikkelaar de mogelijkheid om gebruik te maken van de Free Weather API2 . Dit is een weerdienst die via een webservice details over het weer geeft op basis van de locatie. Om de webservice aan te spreken is een API sleutel en een correcte locatie vereist. Wanneer er context moet vergeleken worden en de contextparameters temperatuur en weersbeschrijving zijn ingeschakeld, wordt de webservice aangesproken. Aangezien de last voor het mobiele apparaat zo laag mogelijk moet zijn, wordt het opvragen van de weersomstandigheden aan de serverkant uitgevoerd. Caching en gebruikslimieten Op het gebruik van de World Weather Online’s Free Weather API staan gebruikslimieten zodat deze niet onbeperkt bruikbaar is. Het maximaal aantal weersopvragingen van de server per minuut bedraagt 500, wat voor het doel van deze masterproef waarschijnlijk voldoende is. Om geen enkel risico te nemen wordt het weer per gebruiker in de applicatie 30 minuten bijgehouden. Indien de temperatuur of de weersbeschrijving nu ergens vereist zijn, kijkt de applicatie eerst of een recente versie in het geheugen zit. Als de temperatuur of weersbeschrijving ouder is dan 30 minuten wordt deze vervangen bij een volgende raadpleging van de context servlet, zie hoofdstuk 3.2.1. Generalisatie weersomschrijvingen Er zijn in het totaal 48 verschillende weercodes met elk hun eigen beschrijving. Deze gaan van ‘Hevige sneeuw met donder en bliksem’ tot ‘Aanvriezende nevel’ of ‘Zonning’. Om op niveau van 2 De gratis API bestaat uit drie verschillende delen: het lokale weer, weer op zee en weer in de bergen. In deze applicatie wordt enkel het lokale weer gebruikt. Voor meer informatie zie http://www.worldweatheronline.com/freeweather.aspx

15

weersomschrijvingen aan generalisatie te doen, is er een XML3 beschikbaar die de verschillende weercodes groepeert. Deze weercodes en hun overeenkomstige beschrijvingen worden bij de opstart éénmaal ingelezen en in het geheugen bewaard. Alle verschillende weercodes worden nu in zes verschillende categorieën verdeeld namelijk: storm, sneeuw, regen, bewolkt, licht bewolkt en zonnig.

2.2.3

Generalisatie van de context

Een contextuele aanbeveling voor een gebruiker is gebaseerd op zijn profiel in de huidige context en zijn locatie. Indien er enkel rekening gehouden wordt met waarderingen die tijdens een context gemaakt zijn die identiek is aan de huidige context, dan is de kans reëel dat er geen vroegere waarderingen gevonden worden. Dit komt omdat het uur, de temperatuur, de dag en elke andere contextparameter perfect gelijk moet zijn aan deze van een vorige context. Dit wordt opgelost met een generalisatiefunctie. Deze functie overloopt alle contexten in de externe databank en kent aan elk een score toe. De score geeft aan in welke mate de meegegeven context gelijk is aan deze van de databank. Bij het aanspreken van de generalisatiefunctie wordt een drempelwaarde en de huidige context meegegeven. Indien er geen enkele context in de databank een score boven de drempelwaarde heeft, dan is dit een nieuwe context, die wordt toegevoegd. Zijn er echter verschillende contexten die een score boven de drempelwaarde hebben, dan wordt de context geselecteerd met de hoogste score. De generalisatiefunctie geeft het ID van de nieuwe context terug of deze van de context met de grootste gelijkenis. De impact van een contextparameter stelt het gewicht voor in een context en is te zien in tabel 2.2. Zo is te zien dat de belangrijkste contextparameter de route is, gevolgd door de temperatuur en de tijd van de dag. De impacten zijn intuïtief bepaald en kunnen in een volgende stap voor alle gebruikers samen dynamisch bepaald worden of gebruikerafhankelijk ingesteld worden. Contextparameter Route Temperatuur Weeromschrijving Activiteit Seizoen Weekend Tijd van de dag Gemoedstoestand Humeur Gezelschap

Impactwaarde 1.0 0.8 0.3 0.7 0.3 0.5 0.8 0.3 0.3 0.7

Tabel 2.2: Impact per contextparameter

Om de score van een context te berekenen, wordt iedere contextparameter apart vergeleken, indien de waarden identiek zijn wordt hun impact aan de score toegevoegd. Deze score gedeeld door de maximumscore -die de som van alle impactwaardes van de meegegeven context is- geeft 3

eXtensible Markup Language

16

de uiteindelijke score van de context. Om op bepaalde contextparameters toch een kleine marge te hebben, zodat een waardering omstreeks 19h niet vervalt om 20h of een waardering bij 15◦ C niet vervalt bij 16◦ C, mag de tijd en temperatuur wat afwijken van de huidige waarden. Indien de waarde van de vergeleken contextparameter in het interval ligt van de meegegeven waarde en een bepaalde drempelwaarde, dan wordt deze contextparameter als gelijk beschouwd.

2.3

Gebruikersinstellingen

Eigenschappen van de gebruiker worden lokaal op het toestel bijgehouden in een SQLite database. Dit is een relationeel database management systeem. Er zijn vijf verschillende types van data die bewaard kunnen worden in de database namelijk integer, text, real, numeric of none. Ieder ander type wordt gecast naar ëën van deze vijf types.

2.3.1

Privacy van de gebruiker

Volgens de wensen van de gebruiker kan een eigen privacy-beleid bepaald worden. Hiervoor is een scherm beschikbaar waar de gebruiker kan bepalen welke contextparameters uit de sensoren worden opgehaald en in de context worden betrokken. Als het detecteren van de gebruikersactiviteit niet naar de zin van de gebruiker is, kan deze die uitschakelen in de instellingen van de context. Voor iedere contextparameter is een selectievak aanwezig, zie figuur 2.2. Standaard zijn alle contextparameters ingeschakeld, wat voor de meest nauwkeurige context zorgt. Het aanbevelingssysteem wordt op deze manier het meest context bewust. Hoe meer parameters de gebruiker uitschakelt, des te meer gewicht aan de overige contextparameters wordt toegekend. Als bijvoorbeeld enkel de weersbeschrijving ingeschakeld is, worden de aanbevelingen enkel op basis van waarderingen tijdens deze bepaalde weersbeschrijving gebaseerd. Indien alle parameters uitgeschakeld zijn verkrijgt men een traditioneel tweedimensionaal aanbevelingssysteem die onafhankelijk is van de context. Voor het opmeten van de sociale en modale context zoals de gemoedstoestand, humeur en gezelschap zijn geen sensoren aanwezig. Hiervoor moet rechtstreekse invoer van de gebruiker gevraagd worden. Als de gebruiker deze contextparameters niet relevant vindt voor de context kan hij ze uitschakelen in het instellingenscherm. Een voorbeeld van het profielscherm is zichtbaar op figuur 2.3. Door het klikken op een actieve profielstaat kan deze veranderd worden.

2.3.2

Quality Of Experience

De gebruiker kan zijn ervaring verbeteren door enkele applicatie-specifieke opties in te stellen. Bij een zoekopdracht naar bezienswaardigheden worden locaties gerangschikt volgens afstand, zie figuur 2.4. Deze worden standaard in kilometer weergegeven, maar kunnen veranderd worden naar mijlen.

17

Figuur 2.2: Scherm met contextinstellingen Om de afstand in meter te berekenen wordt de haversine-formule gebruikt, zie formule 2.1[5]. De afstand, in vogelvlucht, wordt berekend tussen twee punten bestaande uit een lengte- en breedtegraad, respectievelijk ‘lng’ en ‘brd’ in de formule. haversine a = sin2 (4br d/2) + cos(br d 1) · cos(brd2) · sin2 (4lng/2) p p formule c = 2 · arctan 2( a, 1 − a)

(2.1)

a f st and = a · c

Hiernaast is er de mogelijkheid om geen pop-ups weer te geven. Als locatiebepaling via GPS of de wifi-antenne uitgeschakeld is, wordt de gebruiker hiervan op de hoogte gebracht via een pop-up. Dit laat de gebruiker toe om via een snelkoppeling naar zijn instellingen te gaan. Locatiebepaling via een combinatie van de GPS-sensor en de wifi-antenne geeft een hogere accuraatheid die mogelijk minder energie vereist. Bij het bekijken van de details van een bezienswaardigheid staat een snelkoppeling om naar het kaartscherm te gaan. Hier wordt de locatie van de gebruiker en deze van de bezienswaardigheid weergegeven zodat deze precies op één scherm staan, zie figuur 2.5. Een label maakt duidelijk dat het effectief om de aangeduide locatie gaat.

18

Figuur 2.3: Scherm met profielopties

Figuur 2.4: Gesorteerde weergave van een zoekopdracht

19

Figuur 2.5: Bezienswaardigheid op kaart weergegeven

20

2.4

Strategieën

De verschillende aanpakken om de contextuele informatie in het aanbevelingssysteem op te nemen kunnen gecategoriseerd worden in twee verschillende groepen: (1) aanbevelingen via context query en (2) aanbevelingen via contextuele voorkeur en schatting. Waar bij het eerste model de aanbevelingssystemen de contextuele informatie en aangeduide gebruikersinteresse querieën om de meest correcte content te selecteren, zal men bij de tweede aanpak de voorkeur proberen te leren via het model.

Een tweedimensionaal aanbevelingssysteem kan abstract omschreven worden als een functie die de voorkeursdata als input krijgt en geeft een lijst van aanbevelingen als output terug. Figuur 2.6 geeft het overzicht van een tweedimensionaal aanbevelingsproces en omvat drie componenten: data (input in de vorm van -waarden), tweedimensionaal aanbevelingsalgoritme (functie) en de lijst met aanbevelingen(output). Aanbevelingen worden gegenereerd door de aanbevelingsfunctie, gebaseerd op de respectievelijke gebruiker en alle gewaardeerde items. Hierdoor wordt een volgorde van alle items verkregen op basis van hun voorspelde waardering. Het context-bewuste aanbevelingsproces dat gebaseerd is op de contextuele gebruikersvoorkeur kan in drie strategieën verzameld worden. Voor een schematische voorstelling van iedere strategie, zie figuur 2.7.

Figuur 2.6: Klassiek aanbevelingssysteem

Context prefilteren: Door zich te baseren op de huidige context wordt er data geselecteerd. Informatie over de context wordt gebruikt om relevante datarecords op te halen. Hierna kunnen voorspellingen gemaakt worden via een tweedimensioneel aanbevelingssysteem. Deze strategie wordt voor de CARS-applicatie gebruikt en wordt volledig uitgelegd met codevoorbeelden in hoofdstuk 3.5. Context postfilteren: Contextuele informatie wordt initieel genegeerd, waardoor de voorspellingen gebeuren op basis van het volledige gebruikersprofiel en de complete dataset. Als resultaat wordt een lijst van aanbevelingen verkregen die voor iedere context dezelfde gaat zijn. Zoals aangegeven in de naam postfilteren, zullen er na het verkrijgen van de lijst aanpassingen

21

gemaakt worden. Deze zorgen voor verschuivingen in de ordening van de aanbevelingen. De verschuivingen worden gemaakt aan de hand van de huidige context. Indien in de gebruiksgeschiedenis enkel negatieve trends voor bepaalde eigenschappen waargenomen worden, kunnen alle plaatsen in de lijst met deze eigenschappen naar omlaag geschoven worden terwijl positieve trends een omgekeerde beweging maken. Als een gebruiker bijvoorbeeld alleen maar in het weekend graag naar een restaurant gaat, dan zal postfilteren tijdens werkdagen de restaurants naar beneden schuiven. Context modeleren: De derde en laatste strategie zal in het aanbevelingsalgoritme zelf een rol van betekenis spelen. Het wordt rechtstreeks ingewerkt in het scoremechanisme en geeft aan ieder item een waardering op basis van verschillende kenmerken. De hoogste scores worden in de lijst van aanbevelingen geplaatst. De uitwerking van deze methode hangt in grote mate af van de gebruikte library of framework die het aanbevelingsalgoritme implementeert.

Figuur 2.7: Verschillende strategieën

22

2.5

Plaats-en routedetectie

Indien de gebruiker zich herhaaldelijk op dezelfde route naar een bepaalde locatie verplaatst, of de gebruiker bevindt zich op een vaste plaats, dan behoren deze eigenschappen tot de context. Zo kan de gebruiker op weg naar het sportcentrum totaal andere inhoud vereisen, dan wanneer hij naar het werkt gaat. De locatie van de gebruiker wordt periodiek opgevraagd met een ingesteld interval. Er dient een goed evenwicht gevonden te worden tussen de accuraatheid van de locatie, het interval en de precisie van de route of plaats zodat het batterijniveau niet te snel daalt. De locatiebepalende functie is namelijk een resource-intensieve functie. De functionaliteit wordt gevraagd aan de Google Play Services4 . Hieraan kan een locatie met nodige accuraatheid opgevraagd worden die het minst batterijgebruik tot gevolg heeft. Google Play Services wordt automatisch geïnstalleerd op toestellen met Android 2.2 of hoger. Oudere toestellen beschikken niet over de Google Play Services, maar dit bedraagt een minimaal percentage van de gebruikte toestellen, zie 1.4 en 1.5. Toch dient altijd gecontroleerd te worden als de Google Play Services aanwezig zijn.

2.5.1

Plaatsen

Na elk interval krijgt de applicatie een update met een nieuwe locatie. De verkregen locaties worden in het geheugen bewaard en zodra er vijf locaties aanwezig zijn, wordt hiervan het gemiddelde berekend. Indien het gemiddelde teveel afwijkt van de huidige locatie betekent dit dat de gebruiker in beweging is. Als dit niet teveel afwijkt, bevindt hij zich ergens op een vaste locatie. Eens de gebruiker zich op een vaste locatie bevindt worden de overige locaties in het geheugen gewist zodat enkel de huidige locatie onthouden wordt. Er worden vijf locaties onthouden omdat GPS-locaties niet altijd even accuraat zijn en de fout hierdoor uitgemiddeld wordt, zie figuur 2.8. Als de applicatie na vijf updates stilstand detecteert, kan men de locatie opslaan. Dit zorgt ervoor dat de gebruiker eerst vijf minuten moet stilstaan eer een locatie bewaard wordt. Dit gebeurt dus niet onmiddellijk als hij ergens kort stilstaat. Er kan gezocht worden in de databank of de vaste locatie van de gebruiker reeds aanwezig is. Indien de locatie gevonden wordt, dan kan de huidige plaats in de applicatie bijgehouden worden. Zoniet wordt de huidige locatie in de databank bewaard. Als men een interval van één minuut gebruikt dan kan het tot vijf minuten duren eer een locatie kan gevonden worden. Hierdoor wordt er bij elke locatie-update gekeken of deze plaats al in de databank aanwezig is. Dit enkel als het aantal opgevraagde locaties kleiner is dan vijf.

4 Google Play Services is een Application Programming Interface beschikbaar voor Android. Het geeft applicaties toegang om op een eenvoudige manier te interageren met Google services.

23

Figuur 2.8: Routevoorbeeld

2.5.2

Routes

Opslaan van routes Een route wordt gedefinieerd door een vertrekplaats, een eindplaats en een reeks punten tussen deze twee plaatsen in. Hierdoor is het pas mogelijk om een route effectief in de databank te bewaren eens ze is afgerond. Indien de gebruiker in beweging is en er wordt opnieuw stilstand gedetecteerd, is er een route afgelegd. Er wordt gezocht in de databank of deze route al aanwezig is. Als dit nog niet het geval is, dan wordt de nieuwe route bewaard. Er wordt gecontroleerd als de punten niet dicht bij de vertrekplaats of de bestemming liggen. Deze punten zijn immers overbodig en hoeven niet bewaard te worden. Detecteren van routes Op het moment dat er beweging gedetecteerd wordt, komt de gebruiker van een vaste vertrekplaats. In het geheugen worden alle routes met die vertrekplaats opgevraagd en bijgehouden. Per locatie-update worden alle routes die zich nog in het geheugen bevinden, overlopen en per route wordt het routepunt opgevraagd dat zich dichtst bij de huidige locatie bevindt. Indien dit punt zich op een grotere afstand bevindt van de huidige locatie, het vertrekpunt of de bestemming dan een bepaalde drempelwaarde dan valt deze route weg uit het geheugen. Figuur 2.9 is een voorbeeld van een route bestaande uit GPS-punten. Voor een bepaald GPS-punt is de straal waarin de gebruiker gedetecteerd wordt weergegeven.

24

Figuur 2.9: Routevoorbeeld De drempelwaarde is een vast ingestelde waarde en resulteert in een constante straal waarin de gebruiker herkend wordt. Er is een groot verschil in snelheid wanneer de gebruiker aan het wandelen is of in de auto zit. Hierdoor zal de gebruiker tijdens een omweg met de auto sneller buiten bereik zijn dan als hij aan het wandelen is. Een optimalisatie voor de applicatie zou bestaan uit het dynamisch aanpassen van de drempelwaarde afhankelijk van de snelheid. Een andere mogelijkheid bestaat erin sneller GPS-locaties op te vragen als de snelheid van de gebruiker stijgt. Dit laatste heeft een groter batterijverbruik tot gevolg. Indien er geen routes overblijven in het geheugen, dan is dit een nieuwe route en wordt deze bewaard wanneer de gebruiker vijf minuten stilstaat.

25

2.6

Architectuur

Het belangrijkste waarmee er rekening moet gehouden worden als er geprogrammeerd wordt voor een mobiel toestel is, dat er enorm zorgvuldig met de resources moet omgesprongen worden. Deze worden met elke generatie smartphones opnieuw een stuk beter maar zijn nog niet te vergelijken met wat een desktop en laptop kan uitvoeren. Resources omvatten dus de batterij, CPU-cyclussen, dataverbruik, intern geheugen en dergelijke. Aanbevelingsalgoritmen kunnen veel intensiteit aan rekenkracht vereisen. Hierdoor is er gekozen om deze te berekenen op een server. Het mobiele toestel stuurt verschillende contextparameters door die vereist zijn bij een aanbeveling. De server zal vervolgens niet enkel deze data gebruiken in zijn aanbevelingen. Er wordt aan verrijking gedaan. Dit wil zeggen dat de ruwe data van het mobiele toestel gebruikt wordt om informatie van andere bronnen in de context te gaan betrekken. Een contextparameter die op het lokale toestel zelf bepaald wordt is de routeherkenning. Dit wordt niet op een server berekend omdat het versturen van locaties over het netwerk meer energie vereist dan het lokaal te berekenen. Wanneer een aanbeveling vereist is, verstuurt het mobiele toestel een request naar de server. Deze request omvat alle ruwe data en contextparameters die de aanbeveling nodig heeft. De ruwe data bestaat uit de bewegingsactiviteit en de GPS-locatie. Naast deze sensordata zit er ook nog een lijst van parameters die aangeeft welke data in de aanbeveling opgenomen mag worden. Eens de server de aanbevelingen berekend heeft, wordt die teruggestuurd naar het mobiele toestel. Dit wordt getoond aan de gebruiker en die kan hieruit vervolgens een nieuw item kiezen. Indien de gebruiker tijdens het consumeren van het vorige item een score heeft ingegeven, wordt deze waardering naar de server gestuurd en daar bewaard in een databank. Als de gebruiker liever heeft dat een contextparameter niet gebruikt wordt, dan zal deze niet mee verstuurd worden en zal de aanbeveling deze parameter negeren. Op figuur 2.10 en 2.11 is het databankschema van het mobiele toestel en de server weergegeven.

26

Figuur 2.10: Databankschema langs de serverkant

Figuur 2.11: Databankschema langs de kant van het mobiele toestel

27

2.7 2.7.1

Data Open Street Map

Welke locaties worden aanbevolen? Er zijn enkele open source databanken die hun collectie point of interests ter beschikking stellen. Zo is er Open Street Map waar er informatie over straten, rivieren, kroegen en gebieden te vinden is. Deze data is vrij toegankelijk en iedereen kan interessante punten toevoegen. Deze informatie is vrij te downloaden per stad, land of zelfs werelddeel. De extensie van dit bestand is OSM en staat voor een Open Street Map-bestand. Er zijn tools beschikbaar voor het parsen van deze data zoals Osmosis. Het nadeel van deze informatie is dat ze veel punten bevat die geen algemeen nut hebben. Zo zijn er veel gebouwen of torens waar geen extra informatie aan gekoppeld is. Indien er wel een interessant punt gevonden wordt, dan is hier weinig informatie over beschikbaar. Zo is er een gebrek aan types of contactgegevens. Een restaurant heeft enkel een naam en een restaurant tag. Er is niet geweten of het gaat over een eetcafé of een vijfsterrenrestaurant. Het is niet mogelijk om te controleren of het restaurant open is en er zijn geen afbeeldingen beschikbaar.

2.7.2

Google Places

De negatieve punten van Open Street Map worden bij Google Places niet teruggevonden. Plaatsen hebben een reeks types die de eigenschappen van de locatie beschrijven. Contactgegevens zoals het telefoonnummer en de website zijn beschikbaar en afhankelijk van de plaats zijn foto’s aanwezig. Een negatief punt van Google Places dat niet bij Open Street Map aanwezig is, is het verbod om de informatie in grote hoeveelheden af te halen en zelf op te slaan. Hierdoor moet bij elke aanbeveling een aanvraag voor bezienswaardigheden gebeuren bij de Google Places webservice. Deze aanvraag brengt een kleine vertraging met zich mee. Een tweede negatief punt is dat er in één aanvraag maximaal twintig interessante locaties opgehaald worden. Hier wordt later een oplossing voor geboden, zie hoofdstuk 3.2.4. Locaties kunnen opgevraagd worden aan de hand van een Place Search. Dit laat de ontwikkelaar toe om te querieën op plaatsinformatie en categorieën. Er bestaat ook de mogelijkheid om te zoeken op de naam van een plaats en om deze te sorteren volgens afstand. De Google Place Search geeft een lijst van locaties terug met beknopte informatie. In deze informatie staat een unieke code die gebruikt kan worden om de details van een plaats op te vragen via een Place Details query. De verplichte URL-parameters voor deze Place Search zijn in tabel 2.3 beschreven. Indien een verplichte URL-parameter niet ingevuld wordt, krijgt de aanvraag geen resultaten terug. Vervolgens zijn er nog een aantal optionele URL-parameters. Deze geven extra mogelijkheden om de zoekresultaten zo correct mogelijk weer te geven, zie tabel 2.4.

28

Sleutelwoord Key Location Radius Sensor

Omschrijving De unieke sleutel van de applicatie die gebruikt wordt voor het berekenen van de gebruikslimieten De breedte en lengte waarrond er bezienswaardigheden opgevraagd worden. De straal rond de locatie waarin de bezienswaardigheden zich moeten bevinden. Komt de aanvraag van een toestel met een locatiesensor, dan wordt true meegegeven. Dit heeft geen impact op de resultaten. Tabel 2.3: Verplichte urlparameters bij Google Places Search

Sleutelwoord Name Rankby Types Pagetoken

Omschrijving Eén of meer termen die vergeleken worden met de namen van de verschillende plaatsen. Geeft de mogelijkheid om de resultaten te sorteren op basis van afstand of op basis van een score. Limiteert de resultaten tot de meegegeven types, zie tabel 2.5. Vraagt de volgende 20 resultaten terug van een vorige zoekrequest.

Tabel 2.4: Belangrijkste optionele URL-parameters bij Google Places Search

29

Types Om de verschillende interessante bezienswaardigheden te kunnen onderscheiden en groeperen gebruikt Google Places types. De types beschrijven over welke bezienswaardigheid het precies gaat, zie tabel 2.5. Wanneer een gebruiker waarderingen geeft voor bezienswaardigheden, zal er in de databank een gebruikersprofiel bijgehouden worden. In dit profiel zijn het de types van bezienswaardigheden die bewaard worden, samen met het totaal aantal waarderingen voor dat type en de score. accounting art gallery bar bowling alley car dealer casino clothing store department store embassy florist gas station hair care home goods store laundry local government office meal takeaway moving company park physiotherapist post office rv park spa subway station travel agency

airport atm beauty salon bus station car rental cemetery convenience store doctor establishment food general contractor hardware store hospital lawyer locksmith mosque museum parking place of worship real estate agency school stadium synagogue university

amusement park bakery bicycle store cafe car repair church courthouse electrician finance funeral home grocery or supermarket health insurance agency library lodging movie rental night club pet store plumber restaurant shoe store storage taxi stand veterinary care

Tabel 2.5: Verschillende soorten locatietypes

30

aquarium bank book store campground car wash city hall dentist electronics store fire station furniture store gym hindu temple jewelry store liquor store meal delivery movie theater painter pharmacy police roofing contractor shopping mall store train station zoo

2.8

Gebruikersprofiel

Per gebruiker wordt op de server een profiel bijgehouden. Voor iedere context bevat dit profiel enkele types, samen met een gewicht en een aantal stemmen, zie 2.12. Zo is het mogelijk om de gemiddelde waardering te berekenen die gebruikt wordt tijdens het vormen van de Lucene query. Als voorbeeld: een gebruiker heeft een score van 18 en 5 stemmen voor het type ‘Park’, dan heeft deze een gewicht van 3,6.

Figuur 2.12: Gebruikersprofiel Voor context prefilteren wordt enkel het profiel opgehaald dat gelinkt is aan één enkele context. Dit profiel geeft weer hoeveel interesse de gebruiker heeft in de verschillende types van bezienswaardigheden tijdens deze context. Indien een gebruiker een nieuwe waardering aan een bezienswaardigheid geeft, volgt er een update van het profiel. Voor ieder type van de bezienswaardigheid wordt de waardering aan de score opgeteld en wordt het aantal stemmen geïncrementeerd. Bij het veranderen van een waardering wordt per type de vorige waardering verwijderd en de nieuwe erbij opgeteld. Een bestaande waardering is enkel te veranderen en niet te verwijderen.

31

Hoofdstuk 3

Implementatie 3.1 3.1.1

Sensoren op het mobiele toestel Clock:

De datum is de eenvoudigste contextparameter om te bepalen. Uit een datum kan meer afgeleid worden dan het uur alleen. Het seizoen, werkdag of weekend, ’s ochtends of ’s avonds en het gewone uur kan allemaal afgeleid worden uit de datum. Ondanks de eenvoud worden alle contextparameters afhankelijk van de tijd op de server berekend.

3.1.2

Bewegingsactiviteit:

Om de bewegingsactiviteit te herkennen wordt er gebruik gemaakt van de Google Play Services. De activity recognition service is een laag-energetisch mechanisme dat de applicatie in staat stelt om periodiek updates te ontvangen over de gedetecteerde bewegingsactiviteiten. De updates worden periodisch gegenereerd door eerst het toestel op te wekken en vervolgens kort de sensordata te lezen. De mogelijke bewegingsactiviteiten zijn op de fiets, met de auto, te voet en stilstaand. Deze twee laatste zijn onbelangrijk voor de context en worden vervolgens weggelaten. Voor iedere update die er ontvangen wordt kan de hoogst waarschijnlijke bewegingsactiviteit opgevraagd worden. De huidige activiteit van de gebruiker wordt bijgehouden in de applicatie en wordt pas aangepast eens de waarschijnlijkheid van de activiteit zich boven een bepaalde drempelwaarde bevindt. Om de activiteitsherkenning te gebruiken, dienen de ConnectionCallbacks- en OnConnectionFailedListener interfaces geïmplementeerd te worden. Deze voorzien functies die opgeroepen worden als er een verbinding verbonden of onderbroken wordt of wanneer de verbinding niet slaagt. Om de applicatie te verbinden met de service wordt er een ActivityRecognitionClient gemaakt waar de context, connectionCallbacks en onConnectionFailedListener aan meegegeven wordt, zie codevoorbeeld 3.1.

32

1 2

//

Connect

to

the

ActivityRecognitionService

ActivityRecognitionClient

mActivityRecognitionClient

ActivityRecognitionClient ( this ,

3

this ,

= new

this ) ;

mActivityRecognitionClient . connect () ;

Codevoorbeeld 3.1: Ontvangen van locatie-update via google play services In het onConnected() event wordt er een intent gemaakt van de serviceklasse en meegegeven met een pendingintent. Dit is een token die aan een andere applicatie wordt gegeven die toelaat om deze applicatie te gebruiken met de rechten van de huidige applicatie. Vervolgens worden er periodische updates aan de RecognitionClient gevraagd, zie codevoorbeeld 3.2

1 2 3 4

//

Called

public

when

void

Intent

a

connection

to

onConnected ( Bundle intent

PendingIntent

= new

the

ActivityRecognitionService

connectionHint )

Intent ( this ,

callbackIntent

=

is

established .

{

MyIntentService . c l a s s ) ;

PendingIntent . g e t S e r v i c e ( this ,

0,

intent ,

P e n d i n g I n t e n t .FLAG_UPDATE_CURRENT) ;

5 6

mActivityRecognitionClient . requestActivityUpdates (30000 ,

callbackIntent ) ;

}

Codevoorbeeld 3.2: Ontvangen van locatie-update via Google Play Services De gegevens die bepaald worden in de service worden gebroadcast in de applicatie zodat ze met een broadcastreceiver opgevraagd kunnen worden, zie codevoorbeeld 3.3.

33

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

//

Service

Intent

i

= new

I n t e n t ( "ACTIVITY_UPDATE" ) ;

i . putExtra ( " A c t i v i t y " ,

activityName ) ;

i . putExtra ( " Confidence " ,

confidence ) ;

sendBroadcast ( i ) ;

//

App

//

receiver

receiver

om

de

= new

broadcasts

van

de

BroadcastReceiver ()

service

op

te

vangen

{

@Override public

void

String

onReceive ( Context

v =

" Activity

context ,

Intent

+

intent . getStringExtra (" Activity ")

+

"

+

i n t e n t . getExtras () . getInt ( " Confidence " ) ;

"

+

intent )

{

:"

" Confidence

:

"

tvActivity . setText (v) ; } };

//

receiver

IntentFilter

registreren ; filter

= new

IntentFilter () ;

f i l t e r . a d d A c t i o n ( "ACTIVITY_UPDATE" ) ; registerReceiver ( receiver ,

filter ) ;

Codevoorbeeld 3.3: Broadcast versturen en ontvangen Om de activiteit op te vragen, dient er in het manifest een ACTIVITY_RECOGNITION-toestemming toegevoegd te worden. Hiernaast wordt ook de service vermeld die de applicatie gaat gebruiken, zie codevoorbeeld 3.4.

1


a n d r o i d : name="com . g o o g l e . a n d r o i d . gms . p e r m i s s i o n .

ACTIVITY_RECOGNITION"

2 3 4 5 6

/>

<s e r v i c e a n d r o i d : name=" b e . u g e n t . i i i . c a r s . A c t i v i t y R e c o g n i t i o n I n t e n t S e r v i c e " a n d r o i d : e x p o r t e d=" f a l s e " a n d r o i d : l a b e l =" @ s t r i n g / app_name " >

Codevoorbeeld 3.4: Registreren van de service

3.1.3

Locatie

Om de locatie op te halen, wordt opnieuw de Google Play Services gebruikt. De locationClient is het toegangspunt om alles omtrent localisatie te bepalen. Er wordt aan de locationClient gevraagd om periodiek de plaats van de gebruiker op te halen. Dit doet de client via verschillende technieken, zoals de GPS, wifi-netwerken en gsm-masten. Hoe dit allemaal in zijn werk gaat, hoeft de programmeur niet te weten. Android beslist, onder de motorkap, op welke manier het de gevraagde nauwkeurigheid kan geven, met het minste verbruik. 34

De periodieke updates worden aangevraagd met een locationRequest. Dit verzoek omvat de nauwkeurigheid van de locatieaanvraag en kan ingesteld worden op verschillende waarden, zie tabel 3.1. Sleutelwoord

Omschrijving

PRIORITY_BALANCED_POWER_ACCURACY

Block-level nauwkeurigheid (ongeveer 100m)

PRIORITY_HIGH_ACCURACY PRIORITY_LOW_POWER PRIORITY_NO_POWER

Meest accurate beschikbare locatie Stadsniveau nauwkeurigheid (ongeveer 10km) Beste nauwkeurigheid zonder extra krachtconsumptie. Indien een toepassing op het mobiel toestel een locatie opvraagt, wordt deze doorgespeeld naar alle toepassingen.

Tabel 3.1: Mogelijke nauwkeurigheden voor een locationRequest

Aangezien er in de applicatie een accurate locatiebepaling nodig is voor onder andere de routebepaling, wordt de PRIORITY_HIGH_ACCURACY: gebruikt. Bij de aanvraag dient er ingesteld te worden met welk interval de locatie wordt opgevraagd en wat het snelste interval is die de applicatie aankan. Indien een applicatie de locatie opvraagt, dan wordt deze doorgespeeld naar alle andere applicaties die aan het luisteren zijn naar de locatie. Hierdoor dient deze maar een keer opgehaald te worden en niet voor iedere applicatie apart, zie codevoorbeeld 3.5.

1 2 3 4 5 6 7 8 9

//

nieuwe

location

mLocationClient

client

= new

maken

LocationClient ( this ,

this ,

this ) ;

mLocationClient . connect ( ) ;

//

er

kan

al

een

mLocationRequest

locationrequest =

geconfigureerd

worden

LocationRequest . c r e a t e ( ) ;

m L o c a t i o n R e q u e s t . s e t P r i o r i t y ( L o c a t i o n R e q u e s t . PRIORITY_HIGH_ACCURACY) ; m L o c a t i o n R e q u e s t . s e t I n t e r v a l (UPDATE_INTERVAL) ; m L o c a t i o n R e q u e s t . s e t F a s t e s t I n t e r v a l (FASTEST_INTERVAL) ;

Codevoorbeeld 3.5: Maken van een locationclient Het registeren van de location updates gebeurt als volgt:

mLocationClient.requestLocationUpdates(mLocationRequest, this) De activiteit implementeert de interface LocationListener, die heeft de methode onLocationChanged. Deze wordt telkens opgeroepen indien er een locatie-update is, vergezeld van een location object. 35

1 2 3 4

@Override public

void

onLocationChanged ( L o c a t i o n

location )

{

/ /ROUTE- EN PLAATSDETECTIE }

Codevoorbeeld 3.6: 0nLocationChanged Om de locatie te kunnen opvragen dient in het manifest een ACCES_FINE_LOCATION toestemming toegevoegd te worden. Dit omvat de toestemming om GPS te gebruiken alsook om het netwerk (wifi en gsm-masten) te gebruiken, zie codevoorbeeld 3.7.

1


a n d r o i d : name="com . g o o g l e . a n d r o i d . gms . p e r m i s s i o n .

ACCES_FINE_LOCATION"

/>

Codevoorbeeld 3.7: Enable GPS en wifi locatietoegang

3.1.4

Wifi en GPS online

Een opgenomen locatie moet zo correct mogelijk zijn. Om een goede accuraatheid te verkrijgen moeten de wifi- en GPS sensor wel ingeschakeld zijn. Indien dit niet het geval is en de locatie enkel bepaald kan worden via de gsm-masten, dan is de nauwkeurigheid ongeveer één kilometer. Dit wordt gecontroleerd als wifi en GPS ingeschakeld zijn. Is dit niet het geval dan wordt dit aan de gebruiker gemeld. Er wordt gebruikt gemaakt van een AlertDialog.Builder klasse die toelaat om custom Dialogs te maken, zie codevoorbeeld 3.8. Het GPS-instellingenscherm wordt weergegeven met een nieuwe intent van de klasse ACTION_LOCATION_SOURCE_SETTINGS, de wifi instellingen via ACTION_WIFI_SETTINGS. Met een simpele druk op de knop wordt de gebruiker begeleid naar het instellingenscherm van de betreffende instelling.

36

1 2 3 4

private

void

final

buildAlertMessageGps ( boolean

AlertDialog . Builder

builder

gps )

= new

{

AlertDialog . Builder ( this ) ;

b u i l d e r . s e t M e s s a g e ( g e t R e s o u r c e s ( ) . g e t S t r i n g (R . s t r i n g . g p s E r r o r ) ) ; b u i l d e r . s e t P o s i t i v e B u t t o n ( g e t R e s o u r c e s ( ) . g e t S t r i n g (R . s t r i n g . t o S e t t i n g s ) , DialogInterface . OnClickListener ()

5 6

public

7 8 9

}

void

onClick ( f i n a l

s t a r t A c t i v i t y ( new

new

{

DialogInterface

dialog ,

final

int

id )

{

Intent ( android . provider . S e t t i n g s .

ACTION_LOCATION_SOURCE_SETTINGS) ) ;

}) ; b u i l d e r . s e t C a n c e l a b l e ( f a l s e ) . s e t N e g a t i v e B u t t o n ( g e t R e s o u r c e s ( ) . g e t S t r i n g (R . string . cancel ) ,

10 11 12 13 14 15 16

public

void

new

DialogInterface . OnClickListener ()

onClick ( f i n a l

DialogInterface

dialog ,

final

{ int

id )

{

dialog . cancel () ; } }) ; final

AlertDialog

alert

=

builder . create () ;

a l e r t . show ( ) ; }

Codevoorbeeld 3.8: Snelkoppeling naar instellingenscherm

3.2

Webservice

Aangezien er voor een mobiel toestel ontwikkeld wordt, moet er zorgvuldig met de resources omgesprongen worden. Dit houdt in dat er zo weinig mogelijk rekenkracht en geheugen gebruikt wordt. Indien er veel berekend of bewaard moet worden, dan moet keuze gemaakt worden of het opweegt om dit door te geven aan een server. Het versturen naar een server vraagt namelijk ook extra energie.

Figuur 3.1: Webservice Architectuur 37

De gebruikte webservice bestaat uit twee aparte servlets die alle aanvragen van het mobiele toestel afhandelen. De Context Servlet ontvangt de contextparameters van het mobiele toestel en geeft een context-ID terug, terwijl de aanbevelingsservlet een locatie, context-ID en het type aanbevelingen krijgt en een lijst van aanbevolen bezienswaardigheden teruggeeft. De architectuur van de servlets en de controllers is te zien in figuur 3.1.

3.2.1

Context servlet

De Context Servlet wordt aangesproken wanneer een gebruiker het ID van zijn huidige context wil weten. Alle nodige contextparameters worden doorgestuurd naar de Context Servlet. Deze verwerkt alle contextparameters en verrijkt indien nodig de context met weersinformatie.

Figuur 3.2: Aanspreekmethode context servlet Eens alle informatie beschikbaar is, wordt de generalisatiefunctie op de server uitgevoerd die de contexten in de databank vergelijkt met deze die meegegeven is. Een bestaand of nieuw contextID is het resultaat van de generalisatiefunctie. Het context-ID samen met de weersinformatie wordt in JSON-formaat1 teruggestuurd naar de mobiele applicatie, waar deze in het geheugen bewaard wordt. Het verloop van deze communicatie wordt getoond in figuur 3.2.

3.2.2

Recommendation servlet

Indien de gebruiker een lijst van aanbevelingen vraagt, wordt de Recommendation Servlet aangesproken. De servlet ontvangt het ID van de gebruiker, zijn context en het type filter (zie tabel 3.2) die gebruikt wordt voor de aanbevelingen. De server haalt alle interessante bezienswaardigheden uit de omgeving van de gebruiker op via de Google Places Acces Controller. De logica van deze controller wordt verder besproken in hoofdstuk 3.2.4.

1 JavaScript Object Notation is een leesbare tekst gebruikt om data objecten bestaande uit naam-waarde paren te verzenden. Typisch wordt dit gebruikt tussen een server en webapplicatie, het is een alternatief voor XML.

38

Type

Omschrijving

cbf prefiltercbf combine

Een gewone content-based filter Een context-aware content-based filter Een combinatie van een cbf en prefiltercbf

Tabel 3.2: Type aanbevelingssystemen

Afhankelijk van het type aanbevelingssysteem dat gevraagd werd, wordt er een aanbevelingssysteem gekozen. De aanbevelingssystemen geven een lijst van bezienswaardigheden in een bepaalde volgorde, die voor de gebruiker het meest aantrekkelijk is. Deze aanbevelingen worden vervolgens in JSON-formaat naar de gebruiker teruggestuurd. Er wordt ook meegestuurd of de aanbeveling van een context-aware systeem afkomstig is of niet. Dit is belangrijk in het geval van een gecombineerd aanbevelingssysteem. Het verloop van deze communicatie is te zien in figuur 3.3.

Figuur 3.3: Aanspreekmethode recommendation servlet

Aanbeveling voor een profiel zonder overeenstemmende context Indien er contextuele aanbevelingen gemaakt moeten worden, baseert het aanbevelingssysteem zich op het profiel van de gebruiker gevormd door voorgaande waarderingen tijdens een soortgelijke context. Als er nu voor een bepaalde context geen voorgaande waarderingen zijn dan heeft de Lucene Context Based Prefilter geen basis om aanbevelingen te maken. In dat geval wordt het volledige profiel van de gebruiker onafhankelijk van de context opgehaald, zie figuur 3.4. Verschillende types die in meerdere contexten voorkomen worden gegroepeerd 39

Figuur 3.4: Gebruikersprofiel zonder juiste context en hun scores en stemmen worden opgeteld. Hierdoor komt ieder type in het algemene profiel slechts eenmaal voor. Het context-ID is overbodig en wordt weggelaten. Als er vroeger bijvoorbeeld tijdens slecht weer een positieve waardering aan casino’s gegeven werd en tijdens warm weer goede ratings aan cafés, dan zal de gebruiker tijdens aanbevelingen zonder overeenstemmende context de cafés en casino’s aanbevolen krijgen, ongeacht de context.

3.2.3

Weather Controller

De Weather Controller is verantwoordelijk voor de communicatie met de World Weather Online Free API webservice. Het weer wordt opgevraagd aan de hand van request en bevat als URLparameters de locatie, het uitvoerformaat, het aantal dagen in de toekomst waar het weer voor gekend moet zijn en de verkregen API sleutel van de applicatie. Aangezien enkel het weer op het huidig moment belangrijk is, wordt voor het aantal dagen één meegegeven en voor het uitvoerformaat kiezen we JSON.

3.2.4

Google Places Access Controller

De Google Places Acces Controller is verantwoordelijk voor het ophalen van locaties in de buurt van de locatie van de gebruiker. Dit gebeurt aan de hand van een http-request naar de Google Places webservice2 . Elke aanvraag haalt 20 locaties op, maar bezit een token om de volgende 20 locaties op te halen. Als dit geautomatiseerd werd om maximaal 60 locaties op te halen, werden enkel de eerste 20 opgehaald. Dit komt omdat Google wat tijd nodig heeft om de volgende 20 2

Voor meer informatie en details over de syntax, zie https://developers.google.com/places

40

locaties die bij de vorige zoekopdracht hoorden te verzamelen. Dit wordt programmatorisch opgevangen met een slaap periode. Tussen het ophalen van locaties zit telkens een slaap van 2500 wat overeenkomt met 2,5 seconden. In de databank van Google Places zitten enorm veel verschillende types van locaties, waaronder een deel niet bruikbaar voor een aanbevelingssysteem. Indien de gebruiker zich op een route begeeft, dan weet de applicatie welke eindbestemming de gebruiker heeft. In deze situatie haalt de Google Places Acces Controller ook de locaties van de eindbestemming op en verwerkt het aanbevelingssysteem deze in zijn eindaanbevelingen. Dit zorgt ervoor dat indien de gebruiker zich op een route navigeert, deze zowel aanbevelingen rond zijn huidige locatie zal ontvangen als aanbevelingen van bezienswaardigheden die gelegen zijn bij zijn eindbestemming.

3.2.5

Database Controller

Indien er iets gewijzigd of gelezen moet worden uit de databank wordt de database controller gebruikt. Er wordt gebruik gemaakt van een MySQL3 databank en deze wordt via een JDBC driver aangesproken. Bij het eerste gebruik van de controller wordt er éénmaal een methode uitgevoerd die de impactwaarden en de naam van de contextparameters mapt op het ID. Deze maps worden in het geheugen bijgehouden, zodat bij het gebruik van de Database Controller deze waarden niet meer opgehaald moeten worden. De aanbevelingssystemen hebben het gebruikersprofiel nodig om persoonlijke aanbevelingen te maken. Deze gebruikersprofielen worden in de databank bewaard en via de Database Controller opgehaald. Er is de mogelijkheid om het profiel volledig op te halen, onafhankelijk van de context en de mogelijkheid om deze contextspecifiek op te halen.

3 MySQL is een open-source managementsysteem voor relationele databanken. Structured Query Language (SQL) wordt gebruikt om een databank op te bouwen en te ondervagen.

41

3.3 3.3.1

Training Doel

Als de gebruiker voor de eerste maal de applicatie start en inlogt, dan worden een aantal trainingsschermen voorgeschoteld. Dit zijn willekeurige bezienswaardigheden in en rond België waar een willekeurige context aan gekoppeld is. Deze trainingsbezienswaardigheden geven een idee wat de gebruiker qua informatie kan verwachten van een bezienswaardigheid en dienen om een aantal gebruikersprofielen voor verschillende contexten te verkrijgen. De gebruiker krijgt de gegenereerde context samen met gegevens van de bezienswaardigheid te zien op het scherm, zie figuur 3.5. De types en contactgegevens worden weergegeven, aangezien de aard van de bezienswaardigheid niet altijd uit de naam af te leiden is. Eens de gebruiker 15 trainingslocaties gewaardeerd heeft, kan hij aanbevelingen aan het systeem vragen.

Figuur 3.5: Details trainingslocatie

42

De locatie wordt willekeurig bepaald en heeft tot gevolg dat er voor sommige locaties geen enkele bezienswaardigheid gevonden wordt. Een voorbeeld hiervan is een locatie die in de zee ligt. Dit wordt opgelost door een while-lus die pas stopt als een locatie gevonden wordt die een bezienswaardigheid bevat.

3.3.2

Willekeurige context

Voor iedere parameter wordt bepaald of deze al of niet in de context betrokken wordt. Indien dit het geval is, wordt een willekeurige waarde voor deze parameter berekend. Contextparameters die op de server berekend worden, zoals het seizoen en de tijd van de dag, worden tijdens het regulier gebruik als ‘true’ meegegeven in de URL. Tijdens de trainingsfase moet echter niet het huidige seizoen of de tijd van de dag berekend worden, maar de gegenereerde waarden van de willekeurige context worden gebruikt. Hierdoor wordt de ‘true’ vervangen door de gegenereerde waarde in de URL, zie codevoorbeeld 3.9. De Context Servlet ontvangt de URL-parameters en controleert als het gaat om een trainingsbezienswaardigheid of om regulier gebruik.

3.3.3

Drempelwaarde trainen versus normaal gebruik

Bij het opvragen van de context aan de Context Servlet wordt een drempelwaarde meegegeven. Deze bevat het minimum percentage waarin twee contexten moeten overeen komen om als ‘gelijk’ beoordeeld te worden. In de trainingsfase wordt deze drempelwaarde hoog ingesteld zodat zoveel mogelijk verschillende contexten bekomen worden. Tijdens het regulier gebruik van zoeken en aanbevelen staat deze drempelwaarde lager. Hier is het namelijk belangrijk om zoveel mogelijk bestaande contexten te vinden. De drempelwaarde wordt meegegeven in de URL-parameter ‘treshold’, zie codevoorbeeld 3.9.

1 2

// C o n t e x t u r l

tijdens

trainingsproces :

w i c a w e b 7 . i n t e c . u g e n t . b e : 8 0 8 0 / c a r s / c o n t e x t ? t r e s h o l d = 0 . 8 5&mood=happy&s e a s o n=s p r i n g& t i m e o f d a y =15& a c t i v i t y =o n _ f o o t

3 4 5

// C o n t e x t u r l

tijdens

regulier

gebruik :

w i c a w e b 7 . i n t e c . u g e n t . b e : 8 0 8 0 / c a r s / c o n t e x t ? t r e s h o l d = 0 . 7& l a t i t u d e = 5 1 . 0 3 6 2 5 6 3 & l o n g i t u d e = 3 . 7 3 5 0 9 5 7 & t e m p a t u r e =13& s e a s o n=t r u e&t i m e o f d a y=t r u e&mood=happy

Codevoorbeeld 3.9: Verschillende URL-parameters

43

3.4

Crashlytics

Tijdens het ontwikkelen is het enorm belangrijk om te kunnen vaststellen hoe en waarom de applicatie crasht. Als de gebruiker een applicatie gebruikt waar een crash in voorkomt, zal deze de applicatie niet snel meer opnieuw gebruiken. Om ook na de uitgave van de applicatie op de hoogte te blijven van eventuele crashes of fouten wordt Crashlytics4 gebruikt. Crashlytics is een crash reporting tool die bruikbaar is voor iOS en Android. Het werd in 2011 opgericht en werd in januari 2013 overgekocht door Twitter voor 100 miljoen dollar. Op het moment dat er bij een gebruiker een crash voorkomt, zal alle nodige informatie omtrent de crash en de smartphone van de gebruiker verzameld worden. De ontwikkelaar wordt onmiddellijk op de hoogte gesteld van dit probleem en kan alle details bekijken. Om Crashlytics te implementeren dient de ontwikkelaar de Crashlytics library toe te voegen. Als de applicatie gestart wordt, dient de startfunctie van Crashlytics opgeroepen te worden met de applicatiecontext als argument, zie codevoorbeeld 3.10.

1 2 3 4 5 6 7 8 9 10 11 12

import

com . c r a s h l y t i c s . a n d r o i d . C r a s h l y t i c s ;

public

class

MainActivityLogin

extends

Activity

{

@Override protected

void

o n C r e a t e ( Bundle

savedInstanceState )

{

super . onCreate ( s a v e d I n s t a n c e S t a t e ) ;

//

Start

crashlytics

Crashlytics . start ( this ) ; } }

Codevoorbeeld 3.10: Implementatie van Crashlytics

4

Voor meer Android-specifieke informatie en details, zie http://try.crashlytics.com/sdk-android

44

3.5

Context prefiltering

Zoals al eerder vermeld in hoofdstuk 2.4 zijn er verschillende strategieën om aan context-based filtering te doen. De webservice gebruikt om aanbevelingen te maken is modulair5 opgebouwd. Hierdoor is het mogelijk om een andere strategie of algoritme te ontwikkelen en dit als module toe te voegen. Deze kan vervolgens met één enkele parameter geselecteerd worden in de Recommendation Servlet. In de applicatie wordt context prefilteren gebruikt. Door te kijken naar de geschiedenis van de gebruiker, tijdens een bepaalde context, kan een contextgevoelig gebruikersprofiel opgehaald worden. Lucene krijgt dit profiel samen met een lijst van bezienswaardigheden gelegen nabij de gebruiker. Het aanbevelingsalgoritme is een klassieke, tweedimensionale content-based filter en produceert een lijst van contextgevoelige aanbevelingen.

Figuur 3.6: Context prefilter dataflow Wanneer een gebruiker aanbevelingen opvraagt, verstuurt hij zijn gebruikers-ID, context-ID, type filter en zijn locatie naar de Recommendation Servlet. Het contextueel gebruikersprofiel wordt aan de Database Controller opgevraagd. Dit bevat de voorkeur van de gebruiker tijdens zijn huidige context in de vorm van . Dit profiel wordt aan het Lucene aanbevelingsalgoritme bezorgd. Indien de gebruiker een gekende route aan het afleggen is, heeft de Recommendation Servlet 5 Modulair programmeren splitst de functionaliteit van het programma op in uitwisselbare modules. Elke module voert een coherent deel van het programma uit.

45

ook deze locatie ontvangen. Via de Google Places Controller worden op basis van de doorgestuurde locaties bezienswaardigheden gevraagd. Alle informatie van de bezienswaardigheden wordt in lokale objecten bewaard, zie 3.11.

1 2

//

Transforms

private

a

static

jsonobject POI

to

a

point

of

interest

J S O N t o P O I s i m p l e ( JSONObject

j ,

int

nummer )

throws

JSONException

{

3 4 5 6 7 8 9 10 11 12 13 14 15 16

//

Create

new

L i s t <S t r i n g > JSONArray if

jArray

( jArray for

list tags

!=

( int

to

=

=

the

different

types

of

the

location

A r r a y L i s t <>() ;

j . getJSONArray ( " t y p e s " ) ;

null ) i

contain

= new

0;

{ i

<

jArray . length ( ) ;

i ++)

{

t a g s . add ( j A r r a y . g e t S t r i n g ( i ) ) ; } } // POI

Construct s

= new

new

point

of

interest

POI ( j . g e t S t r i n g ( " i d " ) ,

j . getString (" vicinity ") ,

j . g e t S t r i n g ( " name " ) ,

j . getString (" icon ") ,

j . getString (" reference ") ,

tags ,

j . getJSONObject ( " geometry " ) . getJSONObject ( " l o c a t i o n " ) . g e t D o u b l e ( " l a t " ) , j . getJSONObject ( " geometry " ) . getJSONObject ( " l o c a t i o n " ) . g e t D o u b l e ( " l n g " ) ) ;

17 18 19 20 21 22 23 24

//

Set

if

( j . has ( " photos " ) )

the

first

photo

of

a

poi

only

if

the

location

contains

any

photos .

{

s . s e t P h o t o U r l ( j . getJSONArray ( " p h o t o s " ) . g e t J S O N O b j e c t ( 0 ) . getString ( " photo_reference " ) ) ; } return

s ;

}

Codevoorbeeld 3.11: Demarshall van JSON-bezienswaardigheden Elke bezienswaardigheid die opgehaald werd via de Places Search wordt aan Lucene toegevoegd als document. Ieder type van deze bezienswaardigheid wordt toegevoegd aan een lijst, zie codevoorbeeld 3.12. Deze lijst wordt vervolgens als tekstveld aan het document toegevoegd.

46

1 2 3 4 5 6 7 8 9 10 11 12

// for

Each

location

( Map . E n t r y

is

added

pairs

POI

p =

for

( String

( POI )

:

to

Lucene

as

a

document

locationsmap . entrySet () )

with

a

tags - f i e l d

{

p a i r s . getValue ( ) ;

tag

:

p . getTags ( ) )

{

l o c a t i o n t y p e s . add ( t a g ) ; if

( ! a l l t y p e s . contains ( tag ) )

{

a l l t y p e s . add ( t a g ) ; } } addDoc ( w ,

( String )

p a i r s . getKey ( ) ,

locationtypes ) ;

locationtypes . clear () ; }

Codevoorbeeld 3.12: Documenten toevoegen aan Lucene Iedere bezienswaardigheid is geïndexeerd waardoor er via een query snel gezocht kan worden. Lage waarderingen worden nog altijd omhooggeduwd desondanks het feit dat ze negatief zijn. Hierdoor wordt de RMS-waarde6 berekend en gebruikt als boostfactor. Aangezien geen negatieve boosting is toegelaten in de Lucene Query Syntax worden alle negatieve types geboost met een factor 0.1. Types die in de gebruikersgeschiedenis nog niet gewaardeerd zijn hebben de boostfactor 1.0, zie figuur 3.13.

1 2 3

gym^ 2 . 0

bowling_alley^2.0

cafe^1.7

night_club^ 1 . 0

park^ 1 . 0

parking^1.0

campground^ 0 . 1

f l o r i s t ^0.1

food ^1.7

amusement_park^ 1 . 1 7

bar^ 1 . 1 3

restaurant^1.0

liquor_store^0.1

movie_theater^ 0 . 1

art_gallery^0.1

Codevoorbeeld 3.13: Lucene Query Een query op de bezienswaardigheden zal naar de tekstvelden van de documenten kijken en voor ieder document een score geven. Aan de hand van een TopScoreDocCollector worden de bezienswaardigheden volgens score opgehaald, zie codevoorbeeld 3.14. De lijst met aanbevelingen wordt nu gemarshalled naar JSON-formaat en teruggegeven aan de applicatie. 6 Root Mean Square is de effectieve waarde met gemiddelde 0 en wordt veel gebruikt in de elektrotechniek, voor meer informatie zie http://mathworld.wolfram.com/Root-Mean-Square.html

47

1 2 3 4 5 6 7 8 9 10

//

Parse

Query

// int

the

query

Read

the

query = new

results

hitsPerPage

IndexReader

Q u e r y P a r s e r ( V e r s i o n . LUCENE_47,

=

reader

IndexSearcher

from

=

= new

IndexSearcher ( reader ) ;

collector

s e a r c h e r . s e a r c h ( query , =

query

I n d e x R e a d e r . open ( i n d e x ) ;

searcher

hits

analyzer ) . parse ( querystr ) ;

locationsmap . s i z e () ;

TopScoreDocCollector

ScoreDoc [ ]

the

" tag " ,

=

TopScoreDocCollector . c r e a t e ( hitsPerPage ,

collector ) ;

c o l l e c t o r . topDocs ( ) . s c o r e D o c s ;

Codevoorbeeld 3.14: Documenten laten scoren en ophalen

48

true ) ;

Hoofdstuk 4

Resultaat en conclusie Zijn contextuele aanbevelingen beter of accurater dan deze afkomstig van een traditioneel aanbevelingssysteem? De onderzoeksvraag van deze masterproef is rechttoe rechtaan. Omvat de toekomst van aanbevelingssystemen de betrekking van contextuele parameters of is dit de grotere implementatietijd en kost niet waard? Een betere of accuratere aanbeveling is een subjectief gebeuren. Voor de ene gebruiker is een bezienswaardigheid beter, voor een andere is deze niet interessant. Door het gebruik van de gebruikersprofielen worden persoonlijke aanbevelingen gegeven. Het verschil tussen een contextueel en een klassiek aanbevelingssysteem is af te leiden uit de gemiddelde waardering gegeven aan de aanbevelingen in de applicatie. De oorsprong van een bezienswaardigheid kan verschillend zijn. Zo wordt een lijst van bezienswaardigheden via een zoekopdracht opgevraagd of is het een onderdeel van de trainingsdata. Bij het berekenen van aanbevelingen wordt bewaard welke bezienswaardigheid van een klassiek of contextueel systeem afkomstig is. Per waardering is deze oorsprong bewaard, ze bestaat uit vier mogelijke waarden: traditioneel, contextueel, zoekopdracht en training. Waarderingen van bezienswaardigheden tijdens het trainen of zoeken zijn niet gelinkt aan een aanbevelingssysteem en worden vervolgens niet geanalyseerd. Het verschil tussen beide aanbevelingssystemen is af te leiden uit het rekenkundig gemiddelde van de waarderingen met als oorsprong traditioneel en contextueel.

4.1

Gebruikerstesten

De applicatie werd getest door 19 gebruikers die 160 aanbevelingen gewaardeerd hebben in een periode van 16 dagen. In de applicatie kan de gebruiker een lijst van aanbevelingen opvragen. Deze zijn berekend op de server en afkomstig van een combinatie van de Lucene Content-based Filter (traditioneel) en de Lucene Content-based Prefilter (context-aware). De gebruiker heeft geen weet van de oorsprong van de bezienswaardigheid. Hierdoor kan de gebruiker niet beïnvloed worden om bepaalde bezienswaardigheden een hogere waardering te geven. De resultaten van beide aanbevelingssystemen worden afwisselend in één lijst geplaatst en doorgestuurd naar de applicatie. De eerste bezienswaardigheid is afkomstig van een klassiek systeem. De gebruiker verwacht namelijk dat de meest relevante bezienswaardigheid op de eerste plaats staat, net zoals de eerste link op Google het meest overeenstemt met de gezochte query.

49

Het vergelijken van beide systemen bestaat uit het vergelijken van de waarderingen die voor de bezienswaardigheden van elk systeem gemaakt zijn. De verschillende waarderingen gaan van één tot en met vijf en de verdeling is te zien op figuur 4.1. Waarderingen voor bezienswaardigheden van een traditioneel aanbevelingssysteem scoren gemiddeld 2.67/5. Ook al zijn er 28 waarderingen met vier of meer sterren, toch is de meerderheid van de waarderingen in de lage regionen van één of twee sterren gelegen, wat het gemiddelde gevoelig doet dalen. Dit in tegenstelling tot de contextuele waarderingen waar er een meer gelijkaardige spreiding plaats vindt, met een kleine klemtoon op de hogere waarderingen. Het verschil tussen beide bedraagt 0.5 en is een verbetering van 10%, ondanks de eerste positie van een klassieke aanbeveling.

Figuur 4.1: Verdeling waarderingen Een kleinschalige test als deze dient met enige korrel zout genomen te worden. Om dit te bevestigen dient een uitgebreidere en langere testperiode gebruikt te worden. Toch duidt dit al enigszins aan dat er betere aanbevelingen mogelijk zijn door de context te betrekken in een aanbevelingssysteem. Waar een traditioneel aanbevelingssysteem enige tijd nodig heeft om het profiel van de gebruiker goed te onderbouwen, heeft een context-aware aanbevelingssysteem aanzienlijk meer tijd nodig. Hierdoor is het aannemelijk dat de waarderingen op het einde van een langere testperiode hoger zullen liggen, zie 4.2.4.

50

4.2

Future work

Het aantal uitbreidingen die mogelijk zijn bij het betrekken van de context in aanbevelingen is eindeloos. Het spreekt dan ook vanzelf dat niet alle ideeën of optimalisaties in de scope van deze masterproef vallen. Wat hierop volgt zijn enkele verbeteringen of ideeën die een verbeterde gebruikerservaring of een uitbreiding van onderzoeksresultaten kunnen geven.

4.2.1

Impactwaarden

In de huidige versie van de applicatie is er voor iedere contextparameter een statische constante die het belang van de parameter in de context uitdrukt. Deze impact is voor elke gebruiker dezelfde en verandert vooralsnog niet. De applicatie kan veranderd worden, zodat deze trends zal gaan opmerken die gelinkt zijn aan bepaalde contextparameters. Indien meer veranderingen in voorkeur gemerkt worden tijdens het veranderen van één bepaalde contextparameter ten opzichte van een andere, dan kan deze een grotere impact krijgen terwijl de andere in impact kan dalen. Op deze manier worden impactwaarden dynamisch voor de gehele applicatie en worden trends in voorkeurgedrag correct gedecteerd. Voor sommige gebruikers zal hun gemoedstoestand een grotere rol spelen dan het gezelschap terwijl dit voor anderen niet zo is. Deze impacten kunnen ook gebruikersspecifiek gemaakt worden zodat elke gebruiker een eigen impact per parameter heeft. Deze waarden kunnen zelf instelbaar zijn of dynamisch herkend worden door het systeem.

4.2.2

Implementatie andere strategieën

Voorlopig is enkel de module van contextueel prefilteren geïmplementeerd in de webservice. Om de verschillen en de resultaten tussen de verschillende aanbevelingsstrategieën te achterhalen, dienen de contextuele postfilteringsmodule en het contextueel modelleren nog geïmplementeerd te worden. Een uitgebreide gebruikerstest kan onderling de verschillen en gelijkenissen uit de resultaten halen. Waar voorlopig de lijst met aanbevelingen bestaat uit een gewone content-based filter en uit de context prefilter, zou deze nu uit resultaten van verschillende contextuele aanbevelingsalgoritmes kunnen komen.

4.2.3

Uitbreiding van de context

De context bestaat nu uit maximaal tien parameters maar kan onbeperkt uitgebreid worden. Nieuwe sensoren die in de recentste smartphones aanwezig zijn of het verrijken van de context met informatie uit het verkeer. Er zijn enorm veel mogelijkheden. De applicatie is geschreven om de context als een abstracte verzameling van parameters te beschouwen. Hierdoor is het eenvoudig om nieuwe contextparameters aan de context toe te voegen. Er dient wel rekening gehouden te worden dat met de uitbreiding van de context met

51

een aantal parameters, er een grotere nood is aan generalisatie. Het vergroten van de context met één enkele parameter geeft namelijk al de mogelijkheid tot honderden nieuwe contexten.

4.2.4

Uitgebreidere gebruikerstest

Waar een normaal content-based systeem het profiel van de gebruiker éénmaal moet leren, zal een context-aware content-based systeem voor iedere context de voorkeur van de gebruiker moeten leren. Afhankelijk van de drempelwaarde van de generalisatiefunctie en het aantal contextparameters zijn er een verschillend aantal contexten mogelijk. CARS werd gedurende 16 dagen getest, wat te weinig is om voor iedere context een voldoende groot gebruikersprofiel op te bouwen. Een grotere en langere gebruikerstest kunnen uitsluitsel geven over de resultaten van het onderzoek.

4.2.5

Dynamische drempelwaarde routedetectie

Tijdens het rijden op een route mag een gebruiker maximaal een vast ingestelde drempelwaarde van het traject afwijken. Indien hij verder gaat dan wordt de route niet meer herkend en wordt deze als nieuw beschouwd. De drempelwaarde wordt sneller bereikt als de gebruiker in de auto zit dan als hij aan het wandelen is. Hiervoor moet deze drempelwaarde dynamisch berekend worden aan de hand van de snelheid.

52

4.3

Conclusie

Het bestuderen en ontwikkelen van aanbevelingssystemen is een recent gebeuren. Veel onderzoeksaspecten worden nog onder de loep genomen en andere delen worden onderzocht of ze een beter resultaat kunnen geven. Het betrekken van de context in een aanbevelingssysteem behoort tot die laatste groep. Het is van in het begin de bedoeling geweest om verschillende soorten data samen te brengen die ogenschijnlijk geen verband hebben. Althans geen voor de hand liggende eenvoudige één op één relaties. Het zijn eigenlijk relaties die pas beginnen te ontstaan na verloop van tijd, door nauwkeurig alle gegevens zorgvuldig bij te houden en te zoeken naar patronen. De mens is een gewoontedier en die gewoontes komen pas na verloop van tijd boven drijven. Ons systeem heeft een leerproces nodig om deze gewoontes te detecteren en om vervolgens daar proactief te kunnen op inspelen. De algoritmen die de inhoud aanbieden, kunnen pas optimaal renderen bij veel data. Daar deze data bij de start van het systeem niet voor handen is en systematisch moet worden opgebouwd vraagt dit in de loop van het begin meermaals finetuning van de opzoeklogaritmen. De meeste gebruikers hebben wellicht geen idee welke massa van gegevens ze achter zich laten. We weten wel dat ons surfgedrag wordt opgeslagen en na de onthullingen van Edward Snowden weten we dat Big Brother veel meer present is dan een loutere inkijk in onze cookies [6, 7]. Maar eigenlijk zijn we daar als individu niet mee bezig, laat staan dat we beseffen dat al onze fysieke bewegingen via onze smartphone kunnen worden opgevolgd. Het is dus niet van de gebruikers dat we druk mogen verwachten om een verstrenging van de de wetgeving te vragen. Momenteel loopt de wetgeving rond de bescherming van onze internetprivacy een stuk achter, laat staan dat we op korte termijn initiatieven mogen verwachten op de recente snelle technologische evolutie die momenteel aan de gang is op gebied van smartphone of andere minicomputer gadgets. Dankzij deze massa aan data is het mogelijk om een goede context van de gebruiker in te schatten. Iets wat meer en meer een grote rol begint te spelen in hedendaagse applicaties. Steeds meer mobiele toestellen zijn beschikbaar tegen lage prijzen en bezitten alle nodige sensoren om een correcte context te bepalen. Smartphones en gadgets zoals wearables traceren veel data van de gebruiker [8]. Het zal er op neer komen deze data meer en meer te centraliseren om vervolgens verbanden te leggen en proactief content aan te bieden aan de gebruiker van al deze computers. De mogelijkheden die hedendaagse toepassingen verkrijgen door in te spelen op de context van de gebruiker zijn legio. De resultaten van deze masterproef tonen de potentiële meerwaarde die de kennis van de context van een gebruiker heeft. Inspelen op de context geeft ook voor de applicatie Context-Aware Recommender System een betere uitkomst. Aanbevelingen afkomstig van een contextgevoelig algoritme hebben tien procent betere waarderingen dan die afkomstig van een traditioneel aanbevelingssysteem. Toch zijn enkele bemerkingen te geven op dit goede resultaat.

53

Een context-gevoelig systeem heeft een grote leercurve ten opzichte van een klassiek aanbevelingssysteem. Voor iedere context houdt het systeem een gebruikersprofiel bij. Elk profiel dient dus voor zijn respectievelijke context getraind te worden. Afhankelijk van het aantal mogelijke contexten zijn er dus meerdere profielen en kan het trainen langer duren. Naarmate een profiel aangevuld wordt met waarderingen, wordt het steeds meer een representatie van de werkelijke voorkeur van de gebruiker. Voor een context met enkele waarderingen in het gebruikersprofiel zal de voorspelling nauwelijks accuraat zijn. Bij het verder gebruik leert het aanbevelingssysteem meer over de gebruiker zijn voorkeuren en worden de aanbevelingen alsmaar persoonlijker. Lucene als aanbevelingssysteem heeft enkele grote troeven. Zo is het eenvoudig te implementeren en enorm snel. Voor het context prefilteren en postfilteren is het een goede keuze. Het manipuleren van de data voor en na het aanbevelen heeft namelijk geen impact op de werking van het aanbevelingsalgoritme. Het is echter moeilijk om met Lucene context modelling toe te passen. Om deze methode te implementeren dient het scoremechanisme van het aanbevelingssyteem aangepast te worden. Dit is in Lucene wel mogelijk, maar niet eenvoudig en zou vereisen om de open source code te bekijken en aan te passen. De applicatie geschreven voor het Android-besturingssysteem heeft enkele positieve indrukken nagelaten. Vooral de open applicatiemarkt waar elke ontwikkelaar gemakkelijk een applicatie kan op posten, zonder goedkeuring van een selectie-orgaan. Zo is het mogelijk om in enkele minuten een applicatie met de wereld te delen. De sensoren zijn bovendien makkelijk aan te spreken en via de Google Play Services kan er eenvoudig aan positiebepaling en activiteitsherkenning gedaan worden. Dit alles is een evolutie die, mede gestuwd door commercie en geldgewin, niet meer te stoppen is. Wat als de boordcomputer van mijn wagen signaleert dat mijn rijbereik nog 100 kilometer bedraagt en ik binnen twee minuten een tankstation zal bereiken? Misschien het ideale moment om een advertentie via de head-up display op de voorruit te plaatsen [9]. Wat als mijn hartslag en lichaamstemperatuur op een bepaald tijdstip net iets hoger zijn dan normaal en ik dat via mijn uurwerk kan traceren? Misschien het moment om een reclame voor koortswerend medicijn op mijn tablet te krijgen. Als de gebruiker kort daarna beseft dat hij ziek wordt, zal hij wellicht dat medicijn bij de apotheker vragen. De mogelijkheden van big data zijn ontelbaar en de evolutie onstopbaar [10]. Applicaties en aanbevelingssystemen worden meer en meer op maat van de gebruiker gemaakt, iets wat dankzij contextbepaling in de toekomst niet meer weg te denken valt. Dit uitdagende en verrijkende project leerde me een aantal belangrijke vaardigheden die als basis zullen dienen in verdere projecten van mijn beginnende carrière. Verlies nooit de focus, werk resultaatgericht, denk twee keer na vooraleer de eerste regel code neer te schrijven en pak problemen stapsgewijs aan. En last but not least, be positive.

54

Lijst van figuren 1.1 1.2 1.3 1.4 1.5

Applicatie voorstelling . . . . . . . . CARS logo . . . . . . . . . . . . . . . Twee-dimensionale datastructuur Android marketshare . . . . . . . . API gebruik . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 4 5 9 9

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

Driedimensionale datastructuur . . . . . . . . . . . . . . . Scherm met contextinstellingen . . . . . . . . . . . . . . . Scherm met profielopties . . . . . . . . . . . . . . . . . . . Gesorteerde weergave van een zoekopdracht . . . . . . Bezienswaardigheid op kaart weergegeven . . . . . . . . Klassiek aanbevelingssysteem . . . . . . . . . . . . . . . . Verschillende strategieën . . . . . . . . . . . . . . . . . . . Routevoorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . Routevoorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . Databankschema langs de serverkant . . . . . . . . . . . Databankschema langs de kant van het mobiele toestel Gebruikersprofiel . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

13 18 19 19 20 21 22 24 25 27 27 31

3.1 3.2 3.3 3.4 3.5 3.6

Webservice Architectuur . . . . . . . . . . . . Aanspreekmethode context servlet . . . . . . Aanspreekmethode recommendation servlet Gebruikersprofiel zonder juiste context . . . Details trainingslocatie . . . . . . . . . . . . . Context prefilter dataflow . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

37 38 39 40 42 45

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . . .

4.1 Verdeling waarderingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.1 A.2 A.3 A.4 A.5 A.6 A.7

Inlog- en registreerscherm . . . Trainingsscherm en boodschap Contextscherm . . . . . . . . . . Zoekscherm . . . . . . . . . . . . Details- en kaartscherm . . . . . Aanbevelings- en profielscherm Instellingenschermen . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

55

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

58 59 60 61 61 62 62

Lijst van codevoorbeelden 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14

Ontvangen van locatie-update via google play services Ontvangen van locatie-update via Google Play Services Broadcast versturen en ontvangen . . . . . . . . . . . . . Registreren van de service . . . . . . . . . . . . . . . . . . Maken van een locationclient . . . . . . . . . . . . . . . . 0nLocationChanged . . . . . . . . . . . . . . . . . . . . . . Enable GPS en wifi locatietoegang . . . . . . . . . . . . . Snelkoppeling naar instellingenscherm . . . . . . . . . . Verschillende URL-parameters . . . . . . . . . . . . . . . . Implementatie van Crashlytics . . . . . . . . . . . . . . . . Demarshall van JSON-bezienswaardigheden . . . . . . . Documenten toevoegen aan Lucene . . . . . . . . . . . . Lucene Query . . . . . . . . . . . . . . . . . . . . . . . . . . Documenten laten scoren en ophalen . . . . . . . . . . .

56

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

33 33 34 34 35 36 36 37 43 44 46 47 47 48

Bibliografie [1]

J. Ben Schafer, J. Konstan en J. Riedl. “Recommender Systems in E-Commerce”. In: (1999). Geraadpleegd op 13/03/14, p. 1–3. url: http://www.win.tue.nl/~laroyo/2L340/resources/ recommender-systems-e-commerce.pdf .

[2]

G. Adomavicius en A. Tuzhilin. “Context-Aware Recommender Systems”. In: (2011). Geraadpleegd op 08/11/13, p. 3–13.

[3]

P. Lamere en O. Celma. “Music Recommendation and Discovery Remastered”. In: (2011). Geraadpleegd op 10/03/14, p. 33–44.

[4]

G. Adomavicius en A. Tuzhilin. “Toward the Next Generation of Recommender Systems: A Survey of the State-of-the-Art and Possible Extensions”. In: (2005). Geraadpleegd op 10/03/14, p. 1–15.

[5]

C. Veness. Calculate distance, bearing and more between Latitude/Longitude points @ONLINE. 2010.

[6]

E. Maceskill en G. Dance. NSA Files: Decoded @ONLINE. Geraadpleegd op 31/05/14. 2013. url: http://www.theguardian.com/world/interactive/2013/nov/01/snowden- nsa- lessurveillance-revelations-decoded.

[7]

T. W. Adorno, E. Frenkel-Brunswik, D.J. Levinson en R. N. Sanford. The Authoritarian Personality. Geraadpleegd op 31/05/14. 1950, p. 1–5.

[8]

Kiana Tehrani en A. Michael. Wearable Technology and Wearable Devices: Everything You Need to Know @ONLINE. Geraadpleegd op 02/06/14. 2014. url: http://www.wearabledevices. com/what-is-a-wearable-device/.

[9]

J. Alabaster. Pioneer launches car navigation with augmented reality, heads-up displays @ONLINE. Geraadpleegd op 02/06/14. 2013. url: http : / / www . computerworld . com /

s/article/9240445/Pioneer_launches_car_navigation_with\augmented\reality\heads\ up\displays.

[10]

A. Jacobs. “The Pathologies of Big Data @ONLINE”. In: (2009). Geraadpleegd op 08/06/14, p. 1–6.

57

Bijlage A

Handleiding De applicatie ‘Context-Aware Recommender System’ is gratis via de Play Store te installeren. De applicatie is te downloaden via het zoeken in de Play Store op ‘Context-Aware’ of het surfen naar volgende URL: https://play.google.com/store/apps/details?id=be.ugent.iii.cars . Bij het openen van de applicatie kan de gebruiker inloggen door zijn gebruikersnaam en paswoord in te geven. Om een account te creëeren kan onderaan het scherm op register gedrukt worden. Op het registreerscherm dient de gebruiker de verschillende velden in te vullen, zie figuur A.1. Na validatie en het drukken op Go! wordt de applicatie gestart.

Figuur A.1: Inlog- en registreerscherm

58

Als de gebruiker voor het eerst inlogt of hij heeft nog niet de training afgewerkt, worden trainingsbezienswaardigheden voorgeschoteld, zie figuur A.2. Er wordt een context gesimuleerd waarin de gebruiker een bezienswaardigheid zal waarderen. Na 15 waarderingen te geven, is de training afgelopen.

Figuur A.2: Trainingsscherm en boodschap Eens de gebruiker ingelogd is en zijn training afgewerkt heeft, kan de applicatie volledig gebruikt worden. Het contextscherm toont de gebruiker zijn huidige context. Elke contextparameter wordt op dit scherm weergegeven samen met zijn waarde. Om een overzicht van alle schermen te krijgen, klikt de gebruiker op de drie punten rechtsbovenaan, zie figuur A.3. Als de gebruiker op het vergrootglas in de actionbar drukt, kan hij zoeken naar types van bezienswaardigheden. De mogelijke types zijn weergegeven en na het zoeken krijgt de gebruiker een lijst van bezienswaardigheden, gesorteerd volgens afstand, zie figuur A.4. Als de gebruikers de details van een bezienswaardigheid willen bekijken, kan er in het zoekscherm op een bezienswaardigheid gedrukt worden. Het detailscherm toont de naam, types, contactgegevens en eventueel een foto van de bezienswaardigheid. Als de gebruiker wil bekijken waar de bezienswaardigheid op de kaart ligt, drukt hij op Show on map, zie figuur A.5.

59

Figuur A.3: Contextscherm Bovenaan het kaartscherm kan de gebruiker een lijst van aanbevelingen opvragen. Deze lijst bestaat uit aanbevelingen van een tweedimensionaal context-based aanbevelingssysteem en van een context-aware content-based aanbevelingssysteem. Een gebruiker kan zijn profiel aanpassen door bovenaan op de drie punten te drukken en op profile te klikken, zie figuur A.6. De laatste schermen geven aan de gebruiker de mogelijkheid om de applicatie meer op zich af te stemmen en om de context te configureren. Door een checkbox uit te vinken, wordt de instelling uitgeschakeld, zie figuur A.7.

60

Figuur A.4: Zoekscherm

Figuur A.5: Details- en kaartscherm 61

Figuur A.6: Aanbevelings- en profielscherm

Figuur A.7: Instellingenschermen 62

Bijlage B

Digitale kopie

63