Incorporating Situation Awareness into Recommender Systems

Jeremias D

otterl, Ralf Bruns and J

urgen Dunkel

Hannover University of Applied Sciences and Arts, Ricklinger Stadtweg 120, 30459 Hannover, Germany

Keywords:

Situation Awareness, Context Awareness, Decision Support, Recommender Systems, Semantic Web Tech-

nologies, Complex Event Processing.

Abstract:

Nowadays, smartphones and sensor devices can provide a variety of information about a user’s current situa-

tion. So far, many recommender systems neglect this kind of information and thus cannot provide situation-

speciﬁc recommendations. Situation-aware recommender systems adapt to changes in the user’s environment

and therefore are able to offer recommendations that are more appropriate for the current situation. In this

paper, we present a software architecture that enables situation awareness for arbitrary recommendation tech-

niques. The proposed system considers both (semi-)static user proﬁles and volatile situational knowledge to

obtain meaningful recommendations. Furthermore, the implementation of the architecture in a museum of

natural history is presented, which uses Complex Event Processing to achieve situation awareness.

1 INTRODUCTION

Recommender systems provide users with personal-

ized recommendations to simplify and improve their

decision making. Today’s smartphones and sensor de-

vices can offer valuable information about a user’s

situation. Unfortunately, conventional recommender

systems do not consider this kind of context informa-

tion and therefore cannot compute situation-speciﬁc

recommendations. This lack of situation awareness

might reduce the users’ satisfaction as the usefulness

of recommendations is often affected by temporary

factors such as the users’ locations, intentions, or the

current weather. When users are at work, they might

not appreciate recommendations to visit the cinema to

see the latest blockbuster and when it is raining, they

might not appreciate recommendations for outside ac-

tivities like going to the beach.

In this paper, we propose a software architecture

that enhances arbitrary recommendation techniques

with situation awareness. The envisioned system of-

fers recommendations that are not only adapted to the

user’s personal interests but also to the current cir-

cumstances within the user’s environment. The sys-

tem processes situational knowledge in real-time and

connects it with domain knowledge to obtain mean-

ingful recommendations. User locations can be con-

sidered as a special type of real-time context. A real-

world scenario presented in the paper will show how

users’ indoor location can be derived by using Com-

plex Event Processing and iBeacon technology.

The remainder of the paper is organized as fol-

lows. Section 2 introduces recommender systems and

situation awareness. In section 3, we present our ar-

chitectural approach. Section 4 discusses the imple-

mentation of our approach in a museum of natural

history, which demonstrates the feasibility of our pro-

posal. Section 5 explores related work in the research

area of situation-aware recommender systems. Fi-

nally, in section 6 we draw conclusions and suggest

possible future work.

2 RECOMMENDER SYSTEMS

AND SITUATION AWARENESS

For the computation of recommendations, Content-

Based Filtering (CBF) and Collaborative Filtering

(CF) constitute the two major techniques. The char-

acteristics of these recommendation techniques are

well explored (Lops et al., 2011; Su and Khoshgof-

taar, 2009) and implementations are readily available

(e.g., Apache Mahout (Schelter and Owen, 2012)).

Because CBF and CF conceptually operate on a user-

items matrix, recommender systems using these tech-

niques are sometimes referred to as two-dimensional

(2D) (Adomavicius and Tuzhilin, 2008). Unfortu-

nately, 2D recommender systems do not incorporate

real-time context data and therefore cannot directly

consider the user’s current situation (Adomavicius

and Tuzhilin, 2005).

676

Dötterl, J., Bruns, R. and Dunkel, J.

Incorporating Situation Awareness into Recommender Systems.

DOI: 10.5220/0006385106760683

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 676-683

ISBN: 978-989-758-248-6

Figure 1: High-Level Architecture of a Situation-Aware

Recommender System.

Situation-aware recommender systems, on the

other hand, also take real-time context information

into account. This way, recommendations can be

provided that consider the user’s current situation.

To achieve situation awareness, context data has to

be gathered and interpreted in real-time. Situation-

related context data includes GPS data, time, temper-

ature, calendar entries, noise, velocity, etc. For ex-

ample, if GPS data shows that the user is at his work

place and his phone is muted, this might indicate that

he is in a meeting. Or if the user receives multiple

text messages within a short time interval, he is prob-

ably engaged in a conversation with another person

via text messages. A situation is typically on a higher

abstraction level than the individual pieces of context

it is inferred from and is characterized by a potentially

short life span.

Figure 1 shows the high-level architecture of a

situation-aware recommender system that acquires

context data from mobile devices. In this architec-

ture, mobile devices interpret low-level data obtained

from their built-in sensors to infer high-level situa-

tions. The mobile devices provide the infrastructure,

which is responsible for the detection of situations.

Each mobile device sends the detected situations to

the recommender system, which gathers the situations

it receives from the different devices. Via the user in-

terface of the mobile device, the user can interact with

the recommender system. When the user requests a

recommendation, the recommender system uses the

collected situations to compute situation-aware rec-

ommendations and sends them back to the mobile de-

vice where they are displayed to the user.

While conventional recommender systems have

been exploiting the strengths of CBF and CF for many

years, situation-aware recommender systems cannot

use CBF and CF out of the box. In this paper, we pro-

pose a technology-independent approach to incorpo-

rate situation awareness into arbitrary recommenda-

tion techniques. For instance, 2D recommender sys-

tems can be used off-the-shelf, thus allowing the use

of mature and established recommendation libraries.

An adaptation of the libraries’ source code is not re-

quired.

3 SITUATION-AWARE

ARCHITECTURE FOR

RECOMMENDER SYSTEMS

Our architectural approach for situation-aware recom-

mender systems is shown in Fig. 2. The recommender

system receives a continuous stream of situations and

it accepts recommendation requests at arbitrary points

of time. The advent of a recommendation request trig-

gers the following recommendation process.

1. Situation Selection: Situations are ﬁltered to en-

sure recommendations guided by current and rel-

evant situations.

2. Request Reﬁnement: Recommendation requests

are enriched with constraints and hints which are

derived from the selected situations and which

control the subsequent pre- and post-ﬁltering

steps.

3. Pre-Filtering: To the set of items available for rec-

ommendation, a ﬁltering step is applied to discard

items that are unsuitable considering the selected

situations.

4. Recommendation Computation: A list of recom-

mendations is computed using established recom-

mendation techniques like CBF and CF, or alter-

native approaches such as Semantic Rules (Her-

moso et al., 2016).

5. Post-Filtering: To the list of recommendations, a

post processing step is applied which adjusts the

list to foster recommendations that are especially

well suited considering the selected situations.

To illustrate our approach, we will consider a rec-

ommendation system for a museum of natural history,

which is described in some more detail in section 4.

Imagine a user called Alice who is visiting the mu-

seum. In particular, Alice is interested in reptiles and

dinosaurs. Right now, it is 11:45a.m. and her usual

lunch time starts at 12:00a.m., which means she is al-

ready starting to feel hungry.

She is currently located in one of the exhibition

rooms and has time for visiting one more room be-

fore she intends to eat lunch in the museum’s restau-

rant. On her mobile phone, the recommender sys-

tem’s client app is running, which knows the begin-

ning of Alice’s usual lunch time in the near future

from her calendar. Alice requests a recommendation

and the recommendation process is triggered.

Incorporating Situation Awareness into Recommender Systems

677

Figure 2: Architecture for Recommender Systems That Enables Situation Awareness for Conventional Recommendation

Techniques.

Let S = {s

, s

, ..., s

} denote the set of situations

available to the recommender system, and r

the rec-

ommendation request issued by the the client of user

u on his or her behalf. Initially, S and r

are processed

by the Situation Selection component.

3.1 Situation Selection

When a recommendation request arrives, the Situa-

tion Selection component selects the subset of situa-

tions that should inﬂuence the recommendation com-

putation. This step is required to ﬁlter out stale situa-

tions and to limit the number of situations the recom-

mender system has to process. Situations can become

stale because they are pushed into the recommender

system as soon as they are detected and the recom-

mender system keeps them in memory until they are

outdated.

Based on the input data S and r

, the Situation

Selection component creates a situation tuple s =

, S

i, where S

denotes the set of situations selected

for r

is constructed from S applying temporal and

spatial criteria. Only situations are selected that have

appeared recently and near user u or that directly con-

cern u like his intentions or state (movement, mood,

etc.).

In our scenario, only situations are selected that

happened recently in rooms near Alice’s location, and

that concern Alice directly. This includes her current

location and her intention to eat lunch soon. Tuple s =

Alice

, { “Alice is located in room 4”, “Alice’s lunch

time starts in 15 minutes” , ...}i is forwarded to the

Request Reﬁnement component

In practice, the situations are encoded in a machine-

readable format.

3.2 Request Reﬁnement

The Request Reﬁnement component accepts the sit-

uation tuple s and constructs a new tuple t =

, S

, C, Hi, where C is a set of constraints and H

is a set of hints.

• Set C = {c

, c

, ..., c

} contains conditions that

items must fulﬁll to be considered for recommen-

dation. Items that do not fulﬁll all constraints

c ∈ C should be ignored as they are not a good

match for the current state of affairs S

• Set H = {h

, h

, ..., h

} contains conditions that

items should fulﬁll to achieve high recommen-

dation scores. Items that match at least one hint

h ∈ H are a good match considering S

and thus

should have a higher chance to be recommended

to the user.

The sets C and H are directly derived from S

. The

creation of C and H is controlled by domain-speciﬁc

rules.

In our example, the following constraint and hint

are created.

• c

= { “Exhibit is not located in room 3” } be-

cause room 3 is currently overcrowded and thus

exhibits located in this room should not be rec-

ommended to further visitors.

• h

= { “Exhibit is located near the restaurant” }

because visiting a room near the restaurant would

be convenient for Alice as it keeps her walking

distance short.

Tuple t = hr

Alice

, S

, {c

}, {h

}i is forwarded to the

Pre-Filtering component.

3.3 Pre-Filtering

The Pre-Filtering component accepts tuple t as its in-

put.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

678

Via the Data Provider, the Pre-Filtering compo-

nent has access to all items (here the museum ex-

hibits) available for recommendation. The set of ex-

isting items is denoted as I. Furthermore, the Pre-

Filtering component has access to the Data Provider’s

knowledge K, which includes user proﬁles (e.g. their

interests, if known) and domain knowledge. Infor-

mation about user interests can be obtained with ex-

plicit approaches (user interrogation) or implicit ap-

proaches (observing user behavior) (Hanani et al.,

2001). The domain knowledge is provided by domain

experts.

Given I, C and K, the Pre-Filtering component

constructs the candidate item set I

= {i | i ∈ I ∧ ∀c(c ∈ C ∧ i satis f ies c)}

Whether an item i satisﬁes a given c ∈ C can be

checked by consulting K.

In our scenario, all items that are not located in

room 3 are members of I

. Tuple t and I

are passed

to the 2D-Recommender.

3.4 2D-Recommender

The 2D-Recommender computes personalized rec-

ommendations for u using conventional recommen-

dation techniques like CBF and CF. Only items from

candidate set I

are considered.

The 2D-Recommender computes a set of recom-

mendations, denoted as Σ. A recommendation σ is

deﬁned as a tuple σ = hi, f i with i ∈ I

and f ∈ R,

where i is the item that is being recommended and f

its assigned recommendation score expressed as a real

number.

To compute recommendations for u, the recom-

mendation techniques require the user’s ID, which is

contained in r

to access the user’s preferences, which

are contained in the knowledge base K. Note that the

2D-Recommender does not make use of S

, C, and H.

Situation awareness is enabled by the pre- and post-

ﬁltering steps, but not the 2D-Recommender. This

way, techniques that are not situation-aware by de-

fault, like CBF and CF, can be used without modiﬁ-

cation, which is a crucial beneﬁt of our approach.

The 2D-Recommender passes t and the recom-

mendations Σ to the Post-Filtering component.

3.5 Post-Filtering

The Post-Filtering component accepts t and Σ and cre-

ates a modiﬁed recommendation set Σ

. The Post-

Filtering component applies two types of modiﬁca-

tions to the set Σ to construct set Σ

1. The scores of items are increased according to the

number of matching hints in H, as those items

ﬁt the current set of situations S

especially well.

Again, whether item i satisﬁes h ∈ H can be

checked by consulting K.

2. If the size of set Σ, denoted as |Σ|, exceeds a cer-

tain threshold ω, the items with the lowest scores

are dropped such that |Σ

| ≤ ω. This is required to

limit the number of recommendations that have

to be processed by subsequent components and

to limit the number of recommendations that are

eventually displayed to the user.

Let us assume Σ contains two recommendations

= h“tyrannosaur in room 2”, 0.85i and σ

h“local aquatic birds in room 1”, 0.80i. Let us fur-

ther assume room 1 is located next to the museum’s

restaurant, whereas room 2 is not. As declared above,

hint h

states that the recommended item should be

located near the restaurant. In this scenario, σ

satis-

ﬁes h

, while σ

does not. Consequently, the recom-

mendation score of σ

is increased while the score of

remains unchanged. Depending on the used algo-

rithm, the ranking might change in favor of the local

birds in room 1 (σ

), which are conveniently located

on Alice’s way to the restaurant.

The newly created set Σ

is transmitted to the mo-

bile device that requested the recommendations and is

displayed to the user.

4 CASE STUDY:

RECOMMENDATIONS IN A

MUSEUM SCENARIO

A prototype of our system is currently developed in

cooperation with the Landesmuseum Hannover (mu-

seum of natural history) to ensure the feasibility of our

approach. Figure 3 illustrates the set-up in the mu-

seum, which provides the required technical infras-

tructure.

Figure 3: Technical Infrastructure in the Museum.

• Beacons: The dots on the museum’s ﬂoor plan

show the positions of the beacons, each of them

marking a Point-of-Interest (POI) such as an ex-

hibit in the museum. Beacon hardware and pro-

Incorporating Situation Awareness into Recommender Systems

679

tocols (such as iBeacons

and Eddystone

) have

recently been introduced to enable proximity ser-

vices. A beacon device uses Bluetooth LE to send

in a conﬁgurable frequency a unique ID that can

be read by any smartphone.

• Smartphones: The personal smartphones of users

serve as readers of the beacon signals. As soon

as a user approaches a beacon within its signal

range, the smartphone triggers an event carry-

ing the unique beacon ID. These beacon events

can be exploited to derive a user’s indoor posi-

tion. The smartphones serve as the user interface:

they show information about an exhibit, which is

adapted to the user’s interest and capabilities (age,

language skills, interests). Furthermore, they dis-

play the recommendations given by the system.

• Recommender System: This component is run-

ning on a server and receives user requests, user

interests, and situations from the smartphones.

Thereby our implementation focuses on user loca-

tion as a particularly important piece of situation

data. The Recommender System implements the

core of the recommendation process as described

in section 3.

Situation Selection can be realized with Complex

Event Processing (CEP) (Luckham, 2001). CEP is

a software technology to process a stream of events

in real-time. A core concept of CEP is a declarative

event processing language (EPL) to express patterns

in the data streams: So-called event processing rules

(CEP rules) are formulated for specifying event pat-

terns that discover situations of interest.

Common EPLs contain the boolean operators ∧

and ∨, the sequence operator →, and time and length

windows. The following event pattern, for exam-

ple, detects all occurrences of an event of type A

followed by either an event of type B or C, but

only considers occurrences of the last 60 seconds:

(A → (B ∨ C))[win:time:60s]

With these building blocks, Situation Selection

rules can be expressed.

In the given scenario, Situation Selection rules

work on the event model as shown in Fig. 4. The ab-

stract type Event serves as a common supertype for

all other types. The type RecommendationRequest

is used for events that represent requests sent by the

user’s mobile device. The type TechnicalEvent is

the abstract supertype for low-level technical events

like the sensing of a beacon signal (BeaconEvent).

The type Situation serves as an abstract super-

type for all types that characterize concrete situations.

https://developer.apple.com/ibeacon/

https://developers.google.com/beacons/

Concrete situations like the user’s location are de-

tected by the user’s mobile device and transmitted to

the recommender system.

Figure 4: Event Model.

Location Inference Rule: The following CEP rule

is running on the smartphones and performs a sensor

fusion step and infers the new position of its user.

CONDITION: B e a co n E v e n t AS b [ wi n : ti me : 5 se c on d s ]

∧ b. R S S I = max ( R SS I )

ACTION: c re a te Us e r L o c a t i o n ( u se r ID , b . b ea c on I D )

This rule collects all beacon events that have been

read within a small time window. (Here: every

5 seconds a new window is started.) That beacon

event with the maximum signal strength (RSSI) cor-

responds to the beacon next to the user, and a new

UserLocation event with its beaconID is created.

From the beaconID, the system can infer the room

the user is currently located in.

Situation Selection Rule: The next CEP rule of the

Recommender Component selects all situations of the

last 5 minutes that occurred in the area of the user that

issued the request.

CONDITION: ( U s e rL o c at i o n AS ul

∧ S i t u a t io n AS s it )[ wi n : ti me : 5 mi nu t es ] AS s

→ Re c o m m e n d a t i o n R e q ue s t A S req

∧ ul . u se r I D = r eq . u s er ID

∧ i s N e ar ( sit . l oc at io n , u l . be a co n Id )

ACTION: f o rw a r d ( req , s )

The rule triggers when the event stream contains a

RecommendationRequest event req that is preceded

by a UserLocation event ul that contains the loca-

tion of the user that issued the request. Furthermore,

the rule selects all Situation events (and sub types

thereof), referred to as s, that occurred near the user’s

location ul during the last 5 minutes. When such a

pattern occurs in the event stream, the selected situa-

tions s are, together with the request req, forwarded

to the Request Reﬁnement component.

The collection of selected CEP events s is the set

of our architectural concept and contains Alice’s

location and intention to eat lunch soon.

Request Reﬁnement can be realized with Jena

Rules

. Via the Data Provider, reﬁnement rules have

access to domain knowledge.

https://jena.apache.org

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

680

Domain knowledge is modeled as an OWL on-

tology (Hitzler et al., 2009) and contains informa-

tion about the museum’s different rooms and exhibits.

The OWL ontology is the technical realization of the

knowledge base K and the item set I.

: r e s ta u r an t rdf : t yp e : R e s ta u r an t .

: r oo m 1 rdf : t yp e : R oo m ;

: n e xt To : r e st a u r a n t .

: c r o co d il e rdf : t yp e : I te m ;

rdf : t yp e : R e pt i le ;

: in : r oo m 1 .

: b r o n t o s a ur u s rdf : t yp e : I te m ;

rdf : t yp e : D i n o s a u r ;

: in : r oo m 2 .

: t y r a n n o sa u r rdf : t yp e : I te m ;

rdf : t yp e : D i n o s a u r ;

: in : r oo m 3 .

Before entering the Request Reﬁnement compo-

nent, the selected situations are translated into RDF

triples (World Wide Web Consortium, 2014), which

allows the reﬁnement rules to operate on both (rather

static) domain knowledge and (volatile) situational

knowledge. In RDF, the set of selected situations S

related to Alice at a certain point of time may look as

follows.

: a li c e : i s L o c a t ed I n : r oo m 4 .

: a li c e : is R e a d y F o rL u n c h t ru e .

: r oo m 3 : i s O cc u p ie d tr ue .

Reﬁnement Rule 1: The following reﬁnement rule

declares that recommended items must not be located

in a room that is occupied.

[ (? r oo m rd f : ty p e : R oo m ) , ( ? ro om : is O c c u p ie d tru e )

-> mu s t N o t (: in , ? r oo m ) ]

If a binding for the variable ?room exists such that

the two triples on the left hand side of the arrow

are present in the knowledge base, the rule ﬁres and

the functor on the right hand side of the arrow is

invoked. As shown above, room 3 is currently oc-

cupied. Therefore, the functor mustNot is invoked,

which constructs a constraint object that represents

the fact that items located in room 3 should be ex-

cluded from recommendation.

Reﬁnement Rule 2: A second reﬁnement rule

checks whether the current user is ready for lunch. In

this case a hint is created declaring that recommended

items should be located in a room next to a restaurant.

[ cu r re n t Us e r (? u ) , (? u : i s R e a d y F o r L u nc h tr u e ) ,

(? ro om : n e xt T o ? re s ) , (? r es rd f : ty pe : R e s t au r a n t )

-> sh ou l d (: in , ? ro om ) ]

Note that the situation ’a certain room is occupied’ can

be derived by an appropriate CEP rule that counts the num-

ber of users located in that room.

The invocation of the currentUser functor binds Al-

ice’s user ID (which is contained in the recommenda-

tion request) to the variable ?u. Because a triple ex-

ists that states that Alice is ready for lunch and a room

exists that is located next to a restaurant, the rule ﬁres

and the should functor is invoked. The invocation of

the should functor creates a hint that states that rec-

ommended items should ideally be located in room 1,

the only room directly located next to the museum’s

restaurant.

The collection of constraints and the collection of

hints, which resemble the sets C and H, are passed to

the Pre-Filtering component.

Pre-Filtering uses the constraints to select the

items that will be considered for recommendation. As

the items are stored in a RDF knowledge base, they

can be queried with SPARQL (Harris et al., 2013).

From the given constraints, a SPARQL query can al-

gorithmically be constructed that selects all items that

match the given constraints.

Pre-Filtering Query: The following query selects

all items that are not located in the occupied room 3.

SE LE C T ? i te m WH ER E {

? i te m rd f : ty pe : I te m .

MI NU S { ? i te m : in : ro om 3 . }

}

Executed on the knowledge base, the query returns

:crocodile and :brontosaurus, which are located

in room 1 and 2 respectively, but not :tyrannosaur,

which is located in room 3. Together, the se-

lected items constitute the set I

= { :crocodile,

:brontosaurus}.

The 2D-Recommender assigns recommendation

scores to the selected items I

to obtain the recommen-

dation set Σ. For this task, any 2D recommendation li-

brary can be used, e.g., Apache Mahout

, which pro-

vides an implementation of CF. CF operates on item

identiﬁers and user preferences, which are provided

by the Data Provider. The 2D-Recommender ex-

plicitly does not use situations, constraints, and hints

as this allows to easily exploit recommendation li-

braries that do not consider situational knowledge. In

our scenario, the 2D-Recommender constructs Σ = {h

:crocodile, 0.80i, h :brontosaurus, 0.85i}.

Post-Filtering can be realized – similarily to the

Pre-Filtering step – with SPARQL. From the given

hints, SPARQL queries are constructed that check

which items i ∈ I

match the given hints. For each

hint an item matches, the item’s score is increased.

Post-Filtering Query: The following SPARQL

query selects all items that satisfy the earlier con-

structed hint.

https://mahout.apache.org

Incorporating Situation Awareness into Recommender Systems

681

SE LE C T ? i te m WH ER E {

? i te m : in : r o o m1 .

}

Because the museum’s area about crocodile is

located in room 1 (and therefore on Alice’s way

to the restaurant), it is selected by the query and

its recommendation score is increased accordingly.

For the brontosaurus, on the other hand, the hint

is not satisﬁed and the recommendation score keeps

unchanged. Therefore: Σ

= {h :crocodile, 0.90i, h

:brontosaurus, 0.85i}

An impression about the implemented app gives

Fig. 5. For a more detailed description of the pre-

sented approach, please refer to (D

otterl, 2016).

Figure 5: Museum Recommender App.

5 RELATED WORK

A large number of different approaches exist to in-

fer situations from given context data, which in-

clude techniques like fuzzy logic, bayesian networks,

or complex event processing (Renners et al., 2012;

Rizou et al., 2010; Ye et al., 2012). To add

situation awareness to recommender systems, of-

ten knowledge-based solutions are employed where

recommendations are computed via domain-speciﬁc

rules operating on ontologies (Bouzeghoub et al.,

2009; Ciaramella et al., 2009; Hermoso et al., 2016).

In these approaches, the two major recommendation

techniques CBF and CF are generally neglected. Our

architecture combines both worlds: ontology-based

situation awareness and the recommendation tech-

niques CBF and CF are merged into a single solution.

There also exist different proposals that aim to in-

corporate situation awareness into conventional rec-

ommendation techniques (Chen, 2005; Karatzoglou

et al., 2010). However, these approaches modify the

algorithms themselves and thus cannot be applied to

third-party recommendation libraries without modi-

ﬁcation of the libraries’ source code. In our archi-

tecture, conventional recommendation techniques are

encapsulated in the 2D-Recommender component,

which can be perceived as a black box.

To consider contextual information in recom-

mender systems without modifying the recommen-

dation algorithms themselves, Adomavicius and

Tuzhilin (Adomavicius and Tuzhilin, 2008) suggest

the use of pre- and post-ﬁltering. In our architecture,

pre- and post-ﬁltering is controlled by constraints and

hints that are determined by the request reﬁnement

step. Constraints and hints represent characteristics

of items that are suitable and relevant for the given set

of situations. Furthermore, we added a particular sit-

uation selection step, which is required to handle the

incoming live data in form of temporary situations.

The strengths of combining knowledge-based rec-

ommendations with CBF and CF have been exploited

by researchers in the past, mainly with the goal to re-

duce the so-called cold start problems CBF and CF

suffer from. Different hybridization methods exist

to integrate knowledge-based recommendation tech-

niques with CBF and CF (Burke, 2002). In a sense,

our architecture can be perceived as an application of

the Cascade Method: Pre-Filter, 2D-Recommender,

and Post-Filter form a cascade in which the subse-

quent component reﬁnes the recommendations com-

puted by the previous component.

6 CONCLUSION

In this paper, we have presented a software architec-

ture for recommender systems that enhances arbitrary

2D recommendation techniques with situation aware-

ness. We put forward a technology-independent rec-

ommendation process that yields recommendations

adapted to both the user’s preferences and current sit-

uation.

Our approach has several beneﬁts. It provides

context and situation awareness: domain knowledge

and situational knowledge is used to prevent unsuit-

able recommendations (pre-ﬁltering) and to foster

recommendations that ﬁt the current situation espe-

cially well (post-ﬁltering). Furthermore, established

and mature recommendation libraries can be used out

of the box. Because our approach explicitly refrains

from modifying recommendation techniques such as

CBF and CF themselves, these libraries can be used

without adapting their source code. This way, imple-

mentation costs can be reduced.

Moreover, we described a real-world case study

that uses CEP and Semantic Web Technologies to im-

plement the proposed architecture. The use of RDF,

Jena Rules, and SPARQL results in a ﬂexible applica-

tion that can be adapted and extended easily by main-

taining the domain ontology and reﬁnement rules.

User feedback allows recommender systems to

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

682

understand a user’s personal preferences. Stor-

ing the situations in which the user expressed

his (dis-)satisfaction with a certain recommendation

could allow the system to learn in which situations

this speciﬁc recommendation is appropriate. Future

research efforts should investigate how our approach

can be extended to recommend items to the current

user that other users in similar situations have liked.

Extensions of our architecture should adhere to the

current black box approach and not require a reim-

plementation or modiﬁcation of existing recommen-

dation algorithms.

REFERENCES

Adomavicius, G. and Tuzhilin, A. (2005). Toward the next

generation of recommender systems: A survey of the

state-of-the-art and possible extensions. IEEE Trans.

on Knowl. and Data Eng., 17(6):734–749.

Adomavicius, G. and Tuzhilin, A. (2008). Context-aware

recommender systems. In Proceedings of the 2008

ACM Conference on Recommender Systems, RecSys

’08, pages 335–336, New York, NY, USA. ACM.

Bouzeghoub, A., Do, K. N., and Wives, L. K. (2009).

Situation-aware adaptive recommendation to assist

mobile users in a campus environment. In 2009 In-

ternational Conference on Advanced Information Net-

working and Applications, pages 503–509.

Burke, R. (2002). Hybrid recommender systems: Survey

and experiments. User Modeling and User-Adapted

Interaction, 12(4):331–370.

Chen, A. (2005). Context-aware collaborative ﬁltering sys-

tem: Predicting the user’s preference in the ubiquitous

computing environment. In Proceedings of the First

International Conference on Location- and Context-

Awareness, LoCA’05, pages 244–253, Berlin, Heidel-

berg. Springer-Verlag.

Ciaramella, A., Cimino, M. G. C. A., Lazzerini, B., and

Marcelloni, F. (2009). Situation-aware mobile service

recommendation with fuzzy logic and semantic web.

In 2009 Ninth International Conference on Intelligent

Systems Design and Applications, pages 1037–1042.

otterl, J. (2016). Situation-aware recommender systems.

Master thesis, Hannover University of Applied Sci-

ences and Arts, Germany.

Hanani, U., Shapira, B., and Shoval, P. (2001). Informa-

tion ﬁltering: Overview of issues, research and sys-

tems. User Modeling and User-Adapted Interaction,

11(3):203–259.

Harris, S., Seaborne, A., and Prud’hommeaux, E. (2013).

Sparql 1.1 query language. W3C Recommendation,

21.

Hermoso, R., Dunkel, J., and Krause, J. (2016). Situation

Awareness for Push-Based Recommendations in Mo-

bile Devices, pages 117–129. Springer International

Publishing, Cham.

Hitzler, P., Kr

otzsch, M., Parsia, B., Patel-Schneider, P. F.,

and Rudolph, S. (2009). Owl 2 web ontology language

primer. W3C Recommendation.

Karatzoglou, A., Amatriain, X., Baltrunas, L., and

Oliver, N. (2010). Multiverse recommendation: N-

dimensional tensor factorization for context-aware

collaborative ﬁltering. In Proceedings of the Fourth

ACM Conference on Recommender Systems, RecSys

’10, pages 79–86, New York, NY, USA. ACM.

Lops, P., de Gemmis, M., and Semeraro, G. (2011).

Content-based Recommender Systems: State of the

Art and Trends, pages 73–105. Springer US, Boston,

MA.

Luckham, D. C. (2001). The Power of Events: An Intro-

duction to Complex Event Processing in Distributed

Enterprise Systems. Addison-Wesley Longman Pub-

lishing Co., Inc., Boston, MA, USA.

Renners, L., Bruns, R., and Dunkel, J. (2012). Situation-

aware energy control by combining simple sensors

and complex event processing. In Proceedings of the

Workshop on AI Problems and Approaches for Intel-

ligent Environments (AI@IE 2012 in conjunction with

ECAI 2012), Montpellier, France, CEUR-WS.org, vol-

ume 907, pages 29–34.

Rizou, S., H

aussermann, K., D

urr, F., Cipriani, N., and

Rothermel, K. (2010). A system for distributed con-

text reasoning. In 2010 Sixth International Conference

on Autonomic and Autonomous Systems, pages 84–89.

Schelter, S. and Owen, S. (2012). Collaborative ﬁltering

with apache mahout. Proc. of ACM RecSys Challenge.

Su, X. and Khoshgoftaar, T. M. (2009). A survey of col-

laborative ﬁltering techniques. Adv. in Artif. Intell.,

2009:4:2–4:2.

World Wide Web Consortium (2014). Rdf 1.1 primer.

Ye, J., Dobson, S., and McKeever, S. (2012). Situation

identiﬁcation techniques in pervasive computing: A

review. Pervasive Mob. Comput., 8(1):36–66.

Incorporating Situation Awareness into Recommender Systems

683