The Intuitive Context-Aware Recommender with Explanations (ICARE) framework leverages data mining algorithms to provide contextual recommendations, together with their explanations, useful to achieve a specific and predefined goal. We apply ICARE in the healthcare scenario to infer personalized recommendations related to the activities (fitness and rest periods) a specific user should pursue or avoid in order to obtain a high value for the sleep quality score, while also considering their current context and the physical activities performed during the previous days.
that happen in succession. Each event is labeled with a timestamp reporting the exact time at which it is collected, thus the temporal feature is one of the contextual dimensions that can be leveraged to obtain useful knowledge, e.g. whether events are correlated to any additional contextual feature, such as weather conditions or personal circumstances.
In this paper, we will describe ICARE (Intuitive Context-Aware Recommender with
Explanations), a framework presented in [
The paper is structured as follows: Section 2 informally introduces the proposed algorithm and Section 3 describes our proposal to adopt mined sequential rules to provide both positive and negative suggestions toward a specific goal. Section 4 describes the implemented mobile App, and Section 5 summarizes the state of the art. Finally, 6 concludes the paper and outlines future work.
τw D Augmentation DTw
Ro R
query
minconf, minsupp r+ rIn this Section, we describe the overall approach of ICARE and the ALBA (Aged LookBackApriori) algorithm used to infer sequential rules that are then used to provide contextual recommendations. As shown in Figure 1, ICARE needs as input a temporal dataset (in our scenario, the log of physical activity levels collected by Fitbit), enriched with contextual information. For our scenario we leverage the temporal dimension to capture the user’s habits on some specific days, i.e., we distinguish if each day is either a weekday or part of the weekend. Whenever it is possible, we also utilize weather conditions to establish if they afect the user’s preferences. The dataset is fed into ALBA, which then considers a temporal window to conMax Memory usage
Total time 60 s nd40 o
ALBA
GSP
800
600
B
where and are two sets of ordered data items, such that ∩ = ∅
, according to specific
thresholds for confidence and support [
The recommender system orders with the criteria introduced in Section 3.1 to produce a set of totally ordered sequential rules that can be queried to extract a positive recommendation + and a negative recommendation − . This last step is explained in Section 3.2. Diference with other approaches:
A sequential pattern-mining algorithm identifies frequent sub-sequences of items in the data. The algorithm typically involves two main steps: candidate generation and pattern pruning. In the candidate generation step, the algorithm generates a set of candidate patterns by exploring the search space of possible sequences. In the pruning step, the algorithm removes any pattern that does not reach the minimum support threshold, i.e., the minimum number of sequences for a pattern to be considered frequent.
We also follow this approach but with a slight diference in the candidate generation step,
where the order of the itemsets is encoded in the itemsets themselves. This allows us to generate
fewer candidates than usual sequence mining algorithms, resulting in less memory usage and
computation time. In Fig. 2 we compare the performance of ALBA with GSP [
LBA
In our use case scenario, the transactional dataset is a log of physical activity levels and sleep
quality extracted from Fitbit, where for each day , the user’s physical activities, such as heavy
activity (HA), light activity (LA), steps (ST), rest periods (R), sleeping score (SL) and their related
intensities are encoded. These values are enriched by the tag
, if represents a day that falls
on a weekend, and by additional codes relating to the weather conditions (S=sunny, C=cloudy,
R=rainy), if the location of the user during is available. Weather conditions are extracted
through the API of OpenWeather [
In this dataset, the timestamp is related to an interval including the fitness activities and the subsequent sleeping period. For simplicity, we will call this time unit day. After frequent itemsets have been mined, non-contextual sequential rules will be generated and in our scenario, they will be of the form ∶
−( −1) ∧ ⋯ ∧ −2 ∧ −1 → 0 [ , ]. sleeping activity) and fitness activities, performed considering at most
This shows, with support and confidence , the correlation between the sleep quality (i.e., our target function) for the current day 0 (see the itemset 0 in the consequent related to the days, where is the considered temporal window. We remind the reader that the sequence of itemsets in the antecedent does not need to be complete. For example, a mined rule stating that after a day with medium heavy activity (HA: 2) and a long stretch of rest (R: 3), and the subsequent day with a low level of light activity (LA: 1), the predicted sleeping quality for the current day will likely be medium (SL: 2), has the form { ∶ 2, ∶ 3} −2 ∧ { ∶ 1} −1 → { ∶ 2} 0 [ , ].
When the Fitbit log is enriched with contextual information, ICARE mines sequential rules of the form ∶ −( −1) ∧ ⋯ ∧ −2 ∧ −1 → 0 [ , ], where each itemset in the antecedent of the rule contains, besides the information about frequent fitness activities, also the related contextual conditions, if available. For example, a mined rule stating that after a cloudy day with a medium level of heavy activity (HA: 2) and a long stretch of rest (R: 3), and the subsequent rainy day, during a weekend, with a low level of light activity (LA: 1), the predicted sleeping quality for the current day will likely be medium (SL: 2), has the following form: {, ∶ 2, ∶ 3} −2 ∧ {, , ∶ 1} −1 → { ∶ 2} 0 [ , ]
To discover the best rule for predicting the answer to the query “How well will I sleep tonight?”, we need to match the mined rules to a portion of the user’s Fitbit log = ⟨ −′( −1), … , −′2, −′1⟩ related to the established temporal window. This partial log will be hereafter called query. Note that if the user constantly wears the smartwatch, the query will contain information for each day, always enriched with contextual information related to the day of the week ( or not), and sometimes the weather conditions, when available. For example, during the previous 3 days the user log/query may be: = ⟨{ ∶ 1, ∶ 3, ∶ 2, ∶ 3} −3, { ∶ 3, ∶ 1, ∶ 1, ∶ 3} −2, { ∶ 2, ∶ 2, ∶ 3, ∶ 2} −1⟩.
Note that refers to weekdays (the item related to the weekend is not present) and the weather information is not available (i.e., the user did not declare his/her current location). The algorithm will then need to sift through all the mined rules to find one that matches the query in the antecedent and the goal in the consequent. 3.1. Rule Ordering The set of rules is ordered using the following criteria: 1) confidence, 2) completeness, 3) support, and 4) size. Ordering by confidence and support is straightforward, as they are simple float values. A rule with better support will be prioritized over a rule with less support and the same goes for the confidence. On the other hand, ordering by completeness means that the rules that have at least one type of activity per timestamp in the considered temporal window will be prioritized over those that lack information in specific days. Let us define the subset of empty itemsets in a rule as ∅ ∶ { ∈ ∣ = ∅}. We can define the completeness order between two rules 1, 2 as 1 > 2 → | ∅1| < | ∅2| and 1 = 2 → | ∅1| = | ∅2|.
If two rules 1, 2 have the same support, confidence and 1 = 2, then the rule with more itemsets will be prioritized: 1 > 2 ∶ | 1| > | 2|. 3.2. Rule Search The recommender system is designed to be goal-oriented, so the rules are first filtered (according to their consequent) into two diferent sets ℛ+() and ℛ−() , that will contain the recommendations on the fitness activities that may lead to better sleep quality and to worse sleep quality, respectively.
The two sets of rules are then searched separately to produce a positive recommendation and its negative counterpart. Before defining how rules are matched with queries, we need to define the similarity of itemsets and items. Every item is either a contextual item or a physical activity represented by its intensity and duration, thus two items are considered similar if they have the same type, i.e., LA:3 is similar to LA:2 but not to MA:3. Note that the contextual value can match only with itself. Given an ordered set of rules, obtained through the above criteria, the algorithm needs to find the best rule that matches the query. The query is a list of activities and contextual information, if any, in sequential time slots and it is matched to the antecedent of a rule through the following criteria: 1. EXACT_MATCH → the query is exactly the antecedent of the rule:
Query: { ∶ 3} Match: { ∶ 3} −3 ∧ { ∶ 2} −3 ∧ { ∶ 2} −2 ∧ { ∶ 3} −1 −2 ∧ { ∶ 3} −1 2. MATCH → all of the items in the matching rule appear in the right time slot in the query: −3 ∧ { ∶ 2} −2 ∧ { , ∶ 1, ∶ 3}
−1 −3 ∧ { ∶ 2} −2 ∧ { , ∶ 3} −1 3. PARTIAL_MATCH → some of the items in the query appear in the right time slot in the matching rule, while others have ”similar” counterparts in the right time slot: 4. SIMILAR_MATCH → every time slot in the query contains one item that is ”similar” to one item in the corresponding time slot of the matching rule: Query: { ∶ 2, ∶ 3} Match: { ∶ 3} Query: { ∶ 2, ∶ 2} Match: { ∶ 3} Query: { ∶ 3, ∶ 2} Match: { ∶ 3} −3 ∧ { ∶ 2} −2 ∧ { ∶ 2, ∶ 2}
−1 −3 ∧ { ∶ 2}
−2 ∧ { ∶ 3} −1 −3 ∧ { ∶ 3} −2 ∧ { ∶ 2, ∶ 1}
−1 −3 ∧ { ∶ 2}
−2 ∧ { ∶ 3} −1
The search algorithm then iterates over the ordered rules and returns the best match (or no match at all) according to the criteria above. If an exact match is encountered, the algorithm immediately returns the corresponding rule iteration proceeds until the end and collects the other types of matching rules in their respective lists. At the end, the best rule is the first rule in the first non-empty list in the order established above and is of the form:
∶ −( −1) ∧ ⋯ ∧ −2 ∧ −1 → 0 If all lists are empty, the algorithm returns NULL. This process is executed for both ℛ+() and ℛ−() , thus returning the best possible positive recommendation and the best negative recommendation. The two sets are of the form:
ℛ+() = { −( −1) ∧ ⋯ ∧ −2 ∧ −1 ∧ If0 → 0∗
ℛ−() = { −( −1) ∧ ⋯ ∧ −2 ∧ −1 ∧ If0 → 0∗
ℎ
ℎ
0∗ > 0}
0∗ < 0}
The set ℛ+ is composed of the rules with the same past activities of , but with a suggestion of
iftness activities for the current day (i.e., If0) and with a higher sleeping quality in the consequent.
On the contrary, the rules in ℛ− are those with the same past activities of , but with a suggestion
of fitness activities for the current day (i.e., If0) that may lead to worse sleeping quality in the
consequent. The order relation > depends on the function we want to optimize. Note that the
antecedent of a sequential rule is the explanation of the current suggestion, i.e., it is the recent
behaviour of the user that leads to a certain sleep quality. It is important to highlight that, when
using sequential rules to provide recommendations, the sequential relationship between each
itemset is important. Indeed, the user performs activities on particular days and under precise
contextual conditions, thus the order is important. This is the reason why we have developed
our approach without starting from well know algorithms, like GSP [
We implemented an Android app with a Python backend which recommends activities to perform during the current day, either a weekday or during the weekend, in order to increase the sleeping quality w.r.t. the predicted value, as well as the activities to avoid.
The app is written in Ionic, an open-source framework used to create hybrid mobile apps. Its main features resemble many existing health-related apps, collecting data from the user such as their weight, sleep quality, and activity levels. The latter are obtained directly from a Fitbit device worn by the user and are used mainly in the sleep quality prediction and the activity recommendation phases. The main view and the sleep quality prediction page, together with its explanation, can be seen in Figure 4(a), while positive and negative recommendations are shown in Figure 4(b). The ICARE app provides a personalized prediction by giving a sleep quality evaluation for the following night, with a visual representation of the related confidence, describing the expected likelihood that the prediction will turn out to be true. Moreover, we provide the user with an explanation for highlighting why that prediction was proposed. In particular, physical activities performed in the previous days, and considered as the prevision reason, are summarized. This way users are given an insight into the motivations that led to a prediction, and thus they can better understand how activities and desired goals are intertwined. Starting from the description of the present situation and the related prediction, ICARE provides users with personalized suggestions that are diferent for diferent users. The app shows the goal to reach, together with positive and negative recommendations describing activities to perform and to avoid, respectively, in order to achieve the given goal. Proposed suggestions change over time and are strictly related to user context.
Data Mining algorithms considering the temporal dimension have been proposed in the literature
and mainly infer sequences of events [
The impact of contextual information has been investigated in the state of the art and
considered relevant for providing personalized suggestions, since Context-Aware Recommendation
Systems (CARS) are able to provide more accurate recommendations by adapting them to the
specific context the user is acting in [
In the recommendation field, the importance of explanations has been also emphasized, since
they could help users fulfill their needs more easily and in an intuitive way, but also accept
the suggestions [
The paper introduces ICARE, a framework for collecting and enriching wearable device data to produce contextual sequential rules. Sequential rules correlating sequences of past events with a specified future goal are discovered by analysing temporal data. Finally, ICARE provides explainable recommendations by means of an intuitive application. As for future work, we plan to extend the ICARE app in order to collect the user’s opinion on the received predictions and recommendations, and to infer not just the frequent activity patterns, but also the average duration of each activity correlated with additional external information (e.g., the daily schedule). Indeed, it could be useful to suggest the next best activities on the base of the user’s free time, whilst factoring the current time, the available remaining time interval, and the average duration of the activities to be recommended.