Per Christian Roeine

Tourist Application for Android

Specialisation project, fall 2010

Faculty of Information Technology, Mathematics and Electrical Engineering

Department of Computer and Information Science
Supervisor: John Krogstie
 i

Abstract
TODO
ii
 iii

Preface
TODO
iv
 v

Acknowledgments
TODO

Per Christian Roeine

Trondheim, December 14, 2010
vi
Contents

1 Introduction and Overview 1

1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Description 5
2.1 Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Introducing Pertinent Master Theses 9

3.1 The Mobile Tourist Service Recommender . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Recommender System for Tourism . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Implementation 13
4.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Client- vs. Server-Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 User- and Item-Model Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Architecture and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Evaluation and Conclusion 17

5.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.1 User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.2 Finding Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.3 Recommender System Testing . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.4 Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.5 General Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bibliography 21
viii Contents
List of Figures

3.1 Functional server architecture (courtesy of Wium [2010]) . . . . . . . . . . . . . . 10

3.2 An overview of the recommendation process (courtesy of Lillegraven and Wolden
[2010]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
x List of Figures
List of Tables

4.1 Needed demographics from the user (courtesy of Lillegraven and Wolden [2010]) 15
4.2 Features attached to items (courtesy of Lillegraven and Wolden [2010]) . . . . . . 16
xii List of Tables
Chapter 1

Introduction and Overview

Mobile technology is a field of rapid development. Especially over the past few years, the im-
provements in mobile technology has been tremendous. The increase in performance of these
devices, as well as the additional hardware in form of GPS, sensors, etc., make them powerful
devices which can develop comprehensive services to aid people in their everyday tasks. However,
the small screens, wireless network and battery presents challenges that need to be addressed
carefully.
As one of the biggest sectors in the world, the tourism industry is a very attractive sector
for mobile technology[Kabassi, 2010]. Tourists spend considerable time planning their activities,
both before and during their visit. The plans made do not take personal preferences into account
other than that the tourist chooses attractions based on what he/she thinks are good places to
visit. In some cases, reviews from other tourists are available but the user have no knowledge
whether this other tourist share the same passions or preferences.
Most mobiles today have features that are helpful in tourist-situations. GPS (or other means
to locate the user’s position), accelerometer and maps to mention a few, provides useful informa-
tion that can be used to aid users. Further, these features combined with a recommender system
provide good assistance to users.
In fall 2010 two master theses were written, one targeted recommender systems for tourist
applications while the other designed and developed a tourist application. This project aims to
develop these further and merge them to achieve an even better application. The end product
is a personalized tourist application for smartphones using Android where users are able to find
points of interest and their opening hours, receive recommendations, read reviews, give feedback
and more.

1.1 Background and Motivation

This project involves two fields, namely tourist applications and artificial intelligence (AI).
Recommendation systems face some tough challenges. The cold-start problem is one of them
where the problem is giving accurate recommendations to a user who is new to the recommender
system. One way to address this is to use demographic user data. In this approach, users are
required to enter some information about themselves which is used to provide good recommen-
dations. Several papers present recommender systems based on demographic information. Lam
et al. [2008] gets the most promising results[Lillegraven and Wolden, 2010] by training a proba-
bilistic model and depend their recommendations entirely on this. Ask to rate is another way of
dealing with this. Rashid et al. [2002] states that the most direct way of acquiring information
2 Research Method

is to present items to the user and have them rate these items. Other approaches include fast
learners, trusted users, tagging and geographic position data.
Cheverst et al. [2000] presents GUIDE which is a tourist service spanning the city of Lancaster
using a client-server model. GUIDE employed a map-based interface and provided information
on tourist attractions filtered by context information. Location and previously visited places of
the user are among the context information used to provide points of interest (POIs). The user
evaluation showed a high level of acceptance, but also presented some challenges regarding its
customization strategy in relation to context information.
The Mobile Tourist Service Recommender application, MTSR, is a personalized mobile tourist
application which is developed for smartphones with Android OS. MTSR also uses a map-based
interface and provides search-functionality for POIs, recommendations, complete travel plans,
and more. Context awareness is central in MTSR’s design, and user’s preferences are used to
provide good recommendations. In addition of searching for recommended POIs, the system
will send suggestions that the user might enjoy. These suggestions are known as pro-active
recommendations. MTSR also provides general information about places, as well as ratings from
other users regarding the POI in question. The recommendation algorithm used is designed
especially for tourist applications and is developed by Lillegraven and Wolden [2010].

1.2 Research Method

This project has its basis in the design science paradigm which we will describe in this chapter,
as well as how it was useful in our work. As the project is an extension of the M̈obile Tourist
Service Recommender, some of the guidelines will be linked to Wium [2010].
Research in design science focuses on the development and performance of artifacts aiming
to improve the functional performance where artifacts include, but are not limited to, human-
/computer-interfaces (HCIs), and algorithms. Regarding such research, Hevner et al. [2004]
presents a set of guidelines.

Guideline 1: Design as an Artifact

The definition of result in design science research is a purposeful artifact in form of a construct,
model, method or instantiation. The application itself is in this case the artifact and is mainly
described in Wium [2010], but new parts are presented in chapter 4.

Guideline 2: Problem Relevance

This guideline requires that a technology-based solution is developed to important and relevant
business problems. We introduced the tourism industry in Chapter 1 which is a major market
and the need of information systems in this sector is clearly a business problem.

Guideline 3: Design Evaluation

Properties such as utility, quality and efficacy of the artifact need to be thoroughly demonstrated
with well-executed evaluation methods. Due to time-issues, we were not able to perform thorough
testing which is left for future work.

Guideline 4: Research Contributions

Clear and verifiable contributions made by the research must be provided. The contributions
made in this project involve the recommender system and identification of areas that may be
further developed.
Introduction and Overview 3

Guideline 5: Research Rigor

Guideline 5 states that design science relies on the use of rigorous methods in both the construc-
tion and evaluation of the design artifact. We have chosen methods based on exploration and
analysis of previous research.

Guideline 6: Design as a Search Process

You have to continuously search for an effective solution to the problem which you find during
the iterative process of the research. As Wium [2010] states, “the goal . . . is not to solve the
problem of information support in the tourist domain, but rather to gain a better understanding
of how the optimal solution might look like. As we are using theory as a heuristic, the result of
our research process will be presented as design suggestions that might guide future iteration”.
These design suggestions can be found in Wium [2010].

Guideline 7: Communication of Research

Proper communication to both technology-oriented and management-oriented audiences is im-

portant and must be presented effectively. Description of newly acquired features is presented
in Chapter 4.

1.3 Thesis Structure

Chapter 2 presents usage scenarios and requirements. In Chapter 3 we introduce the two master
theses that form the basis of this project, before we look at the implementation in Chapter 4.
Finally, we present our evaluation and conclusion in Chapter 5.
4 Thesis Structure
Chapter 2

Description

In this chapter we will take a closer look at how this system is used and state requirements to
this solution.

2.1 Usage Scenarios

We will here present some usage scenarios that illustrate the desired solution. The three sce-
narios listed are from Wium*ref* - the reason for using the same scenarios is that they are well
formed and the usages of the application is the same.The only change in the application is the
recommender system and a demographical survey that goes with it.

Scenario 1 Receiving and evaluating information

Tony is a tourist walking around in an unfamiliar city. He is running MTSR on his mobile phone.
Suddenly his phone gives a light buzz. When looking at the screen of the phone, Tony can see
that he has received some recommendations for things to do close to his current position (R5).
One of the places is a museum of modern art.
Tony sees from the description of the museum that it might be interesting. He then consults
the explanation of why the recommendation was sent to him, and he learns that the museum
has received high average rating from people that also have liked his favorite museums in other
cities (R6). This was all the persuading he needed, and decides to go over to the museum. Tony
can easily find the way by following the route indicated on the mobile screen (R3).
It turned out that the museum was perfect for Tony. He therefore wants to use MTSR to see
if the people that recommended the museum have other places to offer as well. This leads him
to information about an old church, located only five hundred meters away (R3). As he is about
to leave for the church, MTSR asks him if he would like to provide the system with his opinion
about the museum he has just visited (R8, R9, R10). Tony gladly does this, as he enjoyed it
very much.

Scenario 2 Actively searching for information

Meadow is a backpacker visiting an unfamiliar city. She has just arrived by train and would like to
find a place to eat dinner. She starts up MTSR on her cell phone and requests a place to eat close
to her current position. Meadow don’t want the hassle of going through many restaurant options,
so she chose to receive only restaurants that are recommended for her personally (R1).The system
presents her with a couple of options, and she picks the closest one. Meadow then enjoys a long
6 Requirements

dinner. When she is finished eating, it’s starting to get late. As most backpackers, she has not
booked her accommodation upfront, and she now realizes that she needs to find a hostel to stay
for the night. The hostel must be close, as she doesn’t want to go far with her heavy backpack.
She starts up MTSR again, and requests a place to sleep maximum 2 kilometers from her current
position. The system could not find any recommended places within this range. Meadow does
another search, but this time not only for recommended places (R7).
Safely in her room Meadow decides that she want to read some information about an old
fortress she visited some weeks back. MTSR is set to her current destination, but she quickly
changes to the focus over to the city the fortress is located in. She then do specific search to
locate information about it (R7, R2).

Scenario 3 Using the travel plan

Silvio and his wife Gabriella is a married couple enjoying a holiday cruise up the Norwegian
coastline. This morning they float into an unfamiliar city for an entire day stop over. During
breakfast Silvio starts up MTSR on his cell phone and request a itinerary for the day (R4).
MTSR presents him with a set of activities as well as places to eat lunch and dinner. The
system has recommended a cathedral and two museums. For lunch the system believes they will
enjoy light seafood, and for dinner they are recommended a steak house. Silvio is pleased with
the recommended plan, but he does not want to eat steak for dinner. He quickly finds another
restaurant recommendation, and places this into the plan (R4).

2.2 Requirements
In this section we will state the requirements for the application. Again, as this project empha-
sizes the implementation of an improved recommender system, the requirements in this section
are the same as presented by Wium [2010].
Allow tourists to easily find information on- and physically locate points of interest
• Requirement 1 (R1): The system must have pre-defined requests for typical tourist
services as part of the user interface.
• Requirement 2 (R2): The system must allow the user to search freely after information
• Requirement 3 (R3): The system must provide the user with the distance and route to
each service from the user’s current location
• Requirement 4 (R4): The system must allow the user to request and manage complete
travel itineraries
• Requirement 5 (R5): The system must provide the user with automatic/proactive rec-
ommendations
Facilitates transparency and user control in the personalization process
• Requirement 6 (R6): The system must provide explanations of the personalization
process to the user
• Requirement 7 (R7): The system must allow the user to override the adaption strategy
taken by the system
Gather information on the user’s preferences in a way that is non-obtrusive, accurate and requires
little effort from the user
Description 7

• Requirement 8 (R8): The user must be able to control the personal preferences used to
create recommendations
• Requirement 9 (R9): The system must allow the user to express his opinion about the
services presented

• Requirement 10 (R10): The system must automatically provide the user with an
overview of places the user has visited
8 Requirements
Chapter 3

Introducing Pertinent Master

Theses

In this chapter, two master theses will be presented. These master theses are the basis of the
project, hence we will provide a short presentation of them.

3.1 The Mobile Tourist Service Recommender

The Mobile Tourist Service Recommender (MTSR) was presented by Wium [2010] in Spring
2010. MTSR is a personalized mobile tourist application for smartphones using the Android
operative system. Information is primarily displayed in an interactive map where the user can
zoom and pan the map. The user may search for points of interests (POIs), complete travel
itineraries and rate places he/she has been. The recommender system present is only created to
fill the basic need for such a system.

3.1.1 Architecture
The server architecture has three layers (see Figure 3.1) which all got their own tasks and
responsibilities. In addition, a database is used to store various information. The business layer
and the data access layer are the most important parts of the architecture in this project. MTSR
is made modular, meaning that it should be more convenient to change specific modules. The
data access layer provides an interface to the underlying spatial database, and represent tables
in the database as Java-objects to the business layer.
In this architecture the server provides recommendations by sending lists to the client. The
server is responsible for all calculations, thus conserving client battery and probably reducing
wait time. Request- and response-messages uses XML (eXtensible Markup Language) that are
parsed and handled by both sides.
As the client only has minor changes which do not affect the architecture, the client will not
be addressed in this section.

3.2 Recommender System for Tourism

Lillegraven and Wolden [2010] presents a recommender system designed for tourism using a
Bayesian model. The recommender system also addresses the cold-start problem by using a de-
10 Recommender System for Tourism

Figure 3.1: Functional server architecture (courtesy of Wium [2010])

mographical survey involving six characteristics, namely age, gender, occupation, type of holiday,
nationality and budget. The presented overview of the recommendation process is illustrated in
Figure 3.2 and consists of several stages. One of the more interesting parts of this process is that
the client is designed to do most of the work. The server updates the Bayesian reasoning model
and item information, the rest is left to the client. We will look into this in a coming section.

3.2.1 Architecture
If a new user enters the system, the person concerned will have to submit some demographical
information before the server sends updated item information to the client. The client is now
in possession of all items, these are sent to the service filter in order to minimize the number of
valid items that will be used to calculate the preference rating. By using the Bayesian reasoning
model, a sorted list of items is presented to the user. The ratings made are stored on the client
until the user goes online again. At this point the ratings are uploaded to the server which
updates the Bayesian reasoning model and sends the latest reasoning model and item list back
to the client.
By using several matrices with simple Boolean-variables, they increase the speed of calcula-
tions. This, however, requires a specific user- and item-model.
Introducing Pertinent Master Theses 11

Figure 3.2: An overview of the recommendation process (courtesy of Lillegraven and Wolden
[2010])

3.2.2 Concerns
Smartphones are more powerful than they have ever been, but they still face challenges like
unstable and variable networks, lack of processing power and battery consumption. The archi-
tecture described above requires more computations to be done at the client, decreasing battery
life and perhaps increasing the time to handle a request. Lillegraven and Wolden [2010] argue
that this approach increases scalability drastically and that the user now do not have to be online
to receive recommendations.
12 Recommender System for Tourism
Chapter 4

Implementation

In this chapter we will describe how the new recommender system is integrated, and how this
affects the architecture and design of the MTSR system.

4.1 Challenges
During the project we met some challenges which will be presented in this section.

4.1.1 Client- vs. Server-Approach

In Chapter 3, we investigated how the MTSR-system was build before we looked at the archi-
tecture of the new recommender system. They presented two very different approaches where
recommendations from the original MTSR-system were generated at the server, while they were
produced by the client in the second system. Both solutions have their advantages and limita-
tions, however considering the limited capabilities of smartphones and that this matter has not
yet been investigated, the safer choice is to have the server handle recommendation requests.
The feasibility of the client-approach is left for future work.

4.1.2 User- and Item-Model Issues

As MTSR is modular, it should be easy to replace the old recommender system. However, the
new system relies on specialized user- and item-models to achieve the intended advances in the
calculation process.
This issue complicates the replacement-process as these models need to be handled in some
matter. In addition to replace the system itself, the database needs to store these additional
attributes and some sort of porting has to be done between the matrices of user- and item-data
and the original design of these data.

4.2 Architecture and Design

The overall architecture will remain the same for both server and client. The recommender system
is replaced and complex matrix-calculations are added. Both the user- and item-model have
acquired an additional attribute, namely a matrix that is used by the recommender algorithm.
The old models kept all information in separate variables. To keep consistency between the old
14 How It Works

and the new model, we have added porting-functionality between the information-variables and
matrices.

4.3 How It Works

Needed demographics are shown in Table 4.2 and consists of six features, namely age, gender,
occupation, type of holiday, nationality and budget. Each item has its features displayed in
Table 4.2. These attributes are represented in their respective matrices, one matrix for each user
and one for each item. Each row in the Boolean-variable column is either 0 or 1 (False or True),
meaning that each user will have a matrix with dimension 1x34.
Having a matrix with 34 values for each user seems much, but these are only Boolean-variables
and they make the calculations more effective. The same applies for items. We will now describe
the new process, and as the solution for users and items behave in the same way we will in some
sections only present the user-model.
As we have to keep information in both variables and matrices, we encounter new challenges.
We have to keep consistency between them, and we do not have the luxury to only keep one of
them (discussed why in Chapter 5). This means that for every occurrence of an update to either
a user or an item, the system must perform porting of the updated information to the respective
matrix.
Implementation 15

User features
Feature Boolean variable
Age <25

25-44
45-64
64<
Gender Male
Female
Occupation Student
Science, Education and Academia
Customer Service
Sales
Technology and Engineering
Health care
Artists
Retired
Unemployed
Other
Type of holiday One-day stay
Regular city break
Backpacker
Occupation Norwegian
Other Nordic
United Kingdom and Ireland
Germany and Benelux
Southern and Western Europe
Eurasia
Central Europe
North America
Other America
China and North-West Asia
Other Asia
Afirca
Budget Low
Medium
High

Table 4.1: Needed demographics from the user (courtesy of Lillegraven and Wolden [2010])
16 How It Works

Item features
Feature Boolean variable
Night-life Nightclub
Pub
Alcoholic beverage
Sightseeing Art museum
Other museum
Architectural landmark
Cuisine Italian cuisine
Mexican cuisine
Norwegian cuisine
Fast-food
Asian cuisine
Budget Low
Medium
High
Feature Other variable
average rating continuous between [0.0-1.0]
location coordinates

Table 4.2: Features attached to items (courtesy of Lillegraven and Wolden [2010])
Chapter 5

Evaluation and Conclusion

5.1 Discussion
The potential in this application is very good. The tourism industry is one biggest sectors in the
world, meaning that the number of users that would benefit by this application is very high. Also,
the rapid development in mobile technology provides good resources that will aid applications
to achieve better recommendations, interfaces, accuracy and higher performance.
Keeping information in both variables and matrices makes the process less delicate. Having to
store information two places requires more storage and functionality to keep consistency between
the two elements. The matrices are not user-friendly considering that when a new user is added
the provider of the information (typically the user) would require knowing what each entity in
the matrix indicates. By adding some complexity, the system could to this translation for the
user. However, we would still have to store both the information variables and matrices as MTSR
uses information variables throughout its system and the new recommender system must have
matrices to do the calculations as they were meant to.
Converting the system to only use matrices seems feasible. However, before going through
with such a major operation, in-depth research of how this will affect performance should be
completed. Future iterations should look into this matter.
Servers are supreme in terms of performance and storage compared to smartphones. Lille-
graven and Wolden [2010] argue that leaving the process of achieving recommendations to the
client increases scalability drastically and the necessity to be online disappears. MTSR’s current
implementation performs the recommendation process on the server which probably is the best
solution. Scalability can also be achieved using multiple servers, and the limited resources of
smartphones make it less attractive to let the client do all the work. It will probably drain more
battery and maybe increase waiting time, which will lower user satisfaction. Widely popular
tourist applications should use multiple servers as these can be deployed when needed or when
the coverage area is expanded. As the demand increases, the service will deploy more servers to
cope with the requests.
The advantages of a pure client approach is that it does not require wireless access and the
client is able to perform operations on its own. As smartphones become more powerful, this
approach becomes more feasible and may already be beneficial on some devices. Two versions of
the software, one client-based and one with more server-influence, will probably be a good idea
in the future but not necessary.
There is no functionality to handle users other than to hard-code their properties. The system
would clearly benefit of such functions and is necessary in order to let new users sign up for the
18 Summary

service themselves.

5.2 Summary
The implementation of the improved recommender system presented unforeseen challenges de-
spite the modular nature of MTSR. We were, however, able to solve this by adding an additional
attribute to the existing user-model and one to the item-model, and porting between information
and matrices. The unexpected challenges, and complexity of MTSR and the new recommender
system, made us unable to perform thorough testing in the time at hand. The limited testing so
far has showed promising results, but proper testing and further improvements are necessary.

5.3 Contributions
During this project, we have developed MTSR further by implementing a new recommender
system. The new recommender system implemented is presented by Lillegraven and Wolden
[2010], and uses a Bayesian model to acquire better recommendations.
We have also identified further improvements which are presented in the next section.

5.4 Future Work

As mentioned before, this application has high potential but further testing and development is
necessary. In this section we will look at topics that should be addressed.

5.4.1 User Acceptance Testing

In Wium [2010] only a few users tested the framework presented and the test endured over a
short period of time. Wium [2010] points out that conducting an evaluation of MTSR applying
the so called Mobile services acceptance model is the natural next step.

5.4.2 Finding Content

MTSR uses a database where the content has to be inserted manually. This is time consuming
and highly ineffective. An approach with dynamic content and where data can be fetched from
external providers would significantly improve this part of the system. Ratings given by users at
the external provider’s service will also prove helpful.

5.4.3 Recommender System Testing

The new recommender system should be tested to see that it actually provides better recom-
mendations, and by how much. From a theoretical point of view the new recommender system
should outperform the original one. A test, however, is necessary to prove that it actually
performs better and to provide test data which can be compared to other systems.

5.4.4 Web Interface

A web interface to manage the server and collect statistics of usage. This interface will mainly
have administrative tasks and responsibilities, including correction of data.
Evaluation and Conclusion 19

5.4.5 General Improvements

The master thesis of MTSR presents a few improvements highlighted by the test subjects.

• A more user-friendly search, by using a auto completing search field that also give sugges-
tions on geographical areas that will yield results
• Map that move accordingly to the keyword chosen from the search field

• Option to specify search strategy in terms of ”search for everything”, ”search for stuff
recommended for me”, and ”search for top rated points of interest”

Further improvements include:

• The user should be able to set the frequency of pro-active recommendations, and also turn
the service off
• If a search within a geographical location does not provide any results, the result area
should automatically be expanded and display that area

• Users should be able to change the geographical area used for searches easily, perhaps by
providing some additional input
• Search results should be categorized by type (restaurant, sight and hotel) for better ordering
• Considering travel itineraries, when users want to add an element they should be able to
ask for new recommendations instead of having to find them manually
• The current version of MTSR has no functionality to handle users beyond that they are
hard-coded with username and password. Implementing a system regarding this matter
must be addressed.

• If feasible, the user should be able to download information prior to their visit. In this
way the user will not be depended on the network and its price, but it might raise a
battery-concern
20 Future Work
Bibliography

Cheverst, K., Davies, N., Keith Mitchel and, A. F., and Efstratiou, C. (2000). Developing a
context-aware electronic tourist guide: Some issues and experiences. Proceedings of CHI 2000,
pages 17–24.
Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004). Design science in information systems
research. MIS Quartely, 28(1):75–105.
Kabassi, K. (2010). Personalizing recommendations for tourists. Telematics and Informatics,
27(1):51–66.
Lam, X. N., Vu, T., Le, T. D., and Duong, A. D. (2008). Addressing cold-start problem in
recommendation systems. ICUIMC ’08: Proceedings of the 2nd international conference on
Ubiquitous information management and communication, pages 208–211.
Lillegraven, T. and Wolden, A. C. (2010). Location-aware bayesian recommender systems. Mas-
ter’s thesis, Department of Computer and Information Science, Norwegian University of Sci-
ence and Technology (NTNU).
Rashid, A. M., Albert, I., Cosley, D., Lam, S. K., McNee, S. M., Konstan, J. A., and Riedl, J.
(2002). Getting to know you: Learning new user preferences in recommender systems. IUI ’02:
Proceedings of the 7th international conference on Intelligent user interfaces, pages 127–134.

Wium, M. (2010). Design and evaluation of an personalized mobile tourist application. Master’s
thesis, Department of Computer and Information Science, Norwegian University of Science
and Technology (NTNU).