1 Introduction

The rise of life expectancy because of the vast advancements in the health domain is expected to modify significantly our society in the upcoming years. In particular, the global population aged 60 years or over is more than twice as large as in 1980 and it is expected to double again by 2050 [1]. As the average age of populations continues to rise, there is a necessity of solutions to address the needs and interests of older persons, including those related to housing, health care, social protection and other forms of solidarity between generations.

Ambient assisted living (AAL) encompasses technical services to support elderly people in their daily routine, and its main goal is to maintain the autonomy of these people and increase their safety [2]. Specifically, according to the latest survey by “Ageing in Place Technology Watch” [3] the technologies for active ageing can be classified into four categories: safety and security; health and wellness; communication and engagement; and learning and contribution.

In these systems, it is possible to understand the status of the elderly by using network connected devices and sensors that monitor their behaviour, activity and health status. Using the information accumulated by these devices systems can identify emergency cases and trigger specific actions, e.g. send an alarm notification to a family member or a caregiver. Thus, an essential component of such systems is a mechanism that can automatically select the most fitting services to be called in a single or a combined manner in case of emergency.

In addition, it is important for these AAL systems to incorporate and utilise unique characteristics of cognitively impaired users. Each user may require very specific AAL services in accordance with his/her life context. As a result, a particular service may be perfectly adequate for an individual and completely useless for another [4]. Moreover, as elderly people with cognitive impairments are more susceptible to information overload [5], it is essential to reduce the plethora of provided services and propose those that match better their needs. In holistic AAL solutions that provide numerous tools and services to support the autonomous living of elderly people, the challenge is not only to make solutions available to people at any time and at any place, but specifically propose the “right” tools at the “right” time [6].

The exploitation of each individual user’s unique characteristics and behaviour for the selection of the services to be presented can be achieved through the incorporation of personalisation techniques by a system [7]. Personalisation of content can be achieved through the matchmaking between user needs/preferences and content metadata [8] (in our case AAL services metadata).

This paper presents a hybrid matchmaking approach that supports the aforementioned key functionalities, i.e. service composition for the resolution of emergency cases and service proposition for the provision of personalised content to the users. It is a core module of the IN LIFE platform [9], a cloud-based ICT solution that has been designed for the AAL support of cognitively impaired elderly people. This matchmaking approach consolidates a rule-based matchmaker that exploits the semantic description of the registered services and a statistical matchmaker that utilises statistical algorithms that process the profiles and preferences of the users.

2 Related work

Personalisation is the process of adapting a product/service based on the specific needs and preferences of the corresponding end-user. In the context of social care, this means starting with the person as an individual with strengths, preferences and aspirations and putting them at the centre of the process of identifying their needs [10]. Personalisation usually involves the following two steps [11]: (1) assembling and analysing information about users, and (2) delivering the right content.

The collection of information that describes a particular user is called a user profile, and according to Adomavicius and Tuzhilin [12], there are two major components of a user profile: behavioural and factual. The factual component contains demographic and transactional information such as age, income and educational level, while the behavioural component contains information about the online activities of the user. For the provision of personalised services in AAL, it is important to take also into consideration the disabilities and cognitive impairments of the elderly users as part of the factual component.

The second step involves the matching of the user’s needs and preferences with the right content, which in our case is the AAL services. Typically, there are 3 different matchmaking mechanisms [13]: statistical, rule-based and hybrid.

A statistical matchmaker is a mechanism that tries to identify similarities between users by utilizing their preferences to come up with expectations or recommendations for a user, based on what users—identified as “similar” by a distance function expressed as their preference. It is a self-learning system that evolves and improves its personalisation capabilities over time by taking a large amount of information into account and as a result, it has a low maintenance cost. Nevertheless, its main limitation is the fact that its accuracy is highly dependent on the amount of information available for analysis [14]. Particularly, in “cold start” conditions, such a system cannot draw any inferences for users or services about which it has not yet gathered sufficient information. Typically, there are three kinds of cold-start problems [15]:

  • The new community problem refers to the start-up of the system when there is no sufficient information to be used;

  • The new user problem refers to the registration of new users when there is no interaction with the system yet, and therefore, they cannot receive any personalised content based on their preferences;

  • The new item problem arises due to the fact that a new item (AAL service in our case) that enters the system has not yet any interactions present.

In the literature, a common way of addressing the new user cold-start problem is the exploitation of user demographic attributes [16, 17]. Following this approach, the statistical matchmaker creates groups of similar users by utilizing their personal information instead of their preferences.

On the other hand, a rule-based matchmaker is based on a set of rules that match a user profile with a service by utilizing the metadata or characteristics used in services’ representation, ignoring the information concerning other users [13]. Rule-based systems, in general, are accurate, cost efficient and fast. In addition, they cope efficiently with the new item and new community problem. On the other hand, the implementation of such a system is time-consuming, and it requires a lot of manual work for the declaration of the rules and has a low learning capacity [18].

Finally, a hybrid matchmaker is a mechanism that combines effectively modules of a statistical and a rule-based matchmaker in order to overcome the weaknesses of single techniques and to improve the quality of the matchmaking [14].

Several matchmaking systems have been designed and implemented in the recent years trying to resolve the personalisation problem in different domains, such as tourism [19, 20], advertising [21], e-commerce [22,23,24] and film/TV/music [25, 26]. These matchmaking techniques can also be applied in the AAL domain to match user needs with supported AAL tools and services. The main issue is that they do not take into consideration possible disabilities and impairments that an elderly user may have in the matching procedure, thus making them unsuitable.

In the AAL domain, there are systems that try to profile the users according to their disabilities and impairments and then map them to the most appropriate services. Loitsct et al. [27] presented a matchmaker that maps the needs and preferences of a person with respect to accessibility with customisation features and accessibility aids available on the interactive devices that the person is using in a certain context. The REMBAD system [28] uses proactive recommendation technology to profile participants and groups with mild-to-moderate dementia and offers interactive multimedia content from the Internet to match these profiles. A predictive adoption model for a mobile phone-based video streaming system, developed for people with dementia, was presented by [29]. This model takes into consideration characteristics related to a person’s ability, living arrangements and preference.

Other solutions utilise the context of the user in order to make predictions. For example, [30] proposed a context-aware-based location recommender system that can monitor the location of the elderly and deliver appropriate location recommendations by considering context. On the other hand, Stiller et al. [31] used demographic attributes in order to provide personalised information about available services in the surroundings of elderly users, while Kitamura et al. [32] proposed a system for recommending social services to elderly by classifying social services and subjective experiences among the elderly using the World Health Organization’s (WHO) International Classification of Functioning, Disability and Health (ICF) [33].

Finally, there have also been hybrid solutions that try to combine different techniques. For example, Urbieta et al. [34] proposed a hybrid matchmaking service in AAL environments by introducing a contExt Aware web Service dEscription Language (wEASEL) that is an abstract service model to represent services and user tasks in AAL environments and presented several wEASEL-based service matching algorithms. Bianchini et al. [35] proposed a hybrid matchmaking mechanism that is purely ontology-based, and thus, it does not take into account any statistical information, but combines efficiently different semantic comparison strategies.

Although there are numerous different approaches, there is a lack of a solution in the AAL domain that can efficiently combine different techniques in order to match cognitively impaired people with AAL applications and services. The solution presented in this paper is a hybrid matchmaking approach, similar to the work presented by [36], that also exploits in the matchmaking process the cognitive impairments and disabilities of the users. Specifically, it consolidates the results of a rule-based matchmaker and a statistical matchmaker in order to provide personalised services to the elderly end-users and also identify and even combine services in case of emergency.

3 Proposed framework

The IN LIFE platform is an ICT solution that includes numerous registered applications/tools and web services for the support of cognitively impaired elderly people. It composes the proposed matchmaking procedure that provides the following functionalities: (1) propose applications/tools to the end-users, based on their role, status and context of use; (2) identify and resolve problematic cases by automatically selecting the most proper set of services to be called in a single or combined manner (service composition), based on user’s current activity and health status (e.g. if an elderly user has fallen while being outside, inform immediately through SMS the corresponding caregivers by providing also the position of the elderly).

Fig. 1
figure 1

Conceptual overview of the IN LIFE matchmaking approach

Full size image

The proposed hybrid matchmaking procedure combines the results of a rule-based matchmaker and a statistical matchmaker. These two techniques use as an input the initial preferences of the user, service specifications, data received by sensors connected to IN LIFE monitoring services and usage statistics. Three ontologies are used to gather all the aforementioned data.

The User Ontology is used for describing users’ personal information. It follows the modelling approach of the Profiling Ontology of universAAL [37] and of the ACCESSIBLE project [38] that is based on the International Classification of Functioning, Disability and Health (ICF) [33].

The Service Ontology is used for describing services’ specifications (e.g. input/output parameters, etc.) in a semantic manner. It is also used to store all the tool-service usages by the elderly. It is based on the universAAL Profiling Ontology [37] and OWL-S standard [39] for the proper technical description of a service. Additionally, it semantically describes the registered services from an AAL perspective, thus enabling their matching with the cognitive impaired users.

The Sensor Ontology aims at storing the data coming from the sensors (accelerometers, wearables, door sensors, etc.) connected to the IN LIFE monitoring services. It is based on the SSN ontology of W3C [40], which describes sensors along with their accuracy and capabilities, as well as observations and methods used for sensing.

A conceptual overview of the IN LIFE matchmaking approach is presented in Fig. 1. More specifically, matchmaking is applied on: (a) the user profile retrieved from the User Ontology, (b) data coming from the sensors connected to the IN LIFE monitoring services retrieved from the Sensor Ontology and (c) services specifications and usage statistics retrieved from the Service Ontology.

The selection of this hybrid approach and the exploitation of these two matchmaking approaches was in the context of taking advantage of the strengths of each and compensating for their weaknesses. Specifically, the rule-based matchmaker exploits the semantic knowledge provided by the ontologies, utilises rules that can create a User Profile for an elderly according to his personal information and matches this User Profile with the provided AAL services. Similarly, it can determine which AAL services must be called in case of an emergency and even combine them, based on their semantic description. On the other hand, the statistical matchmaker tries to identify similarities between users by utilising their preferences, personal information and cognitive impairments to come up with expectations or recommendations for a user, based on what similar users expressed as their preference.

For the implementation and fine-tuning of this framework, an iterative development approach was adopted, as it is depicted in Fig. 2. The iterative model is a specific implementation of a software development life cycle that focuses on an initial, simplified implementation, which then progressively gains more complexity and a broader feature set until the final system is complete. After an initial planning phase, a small handful of stages are repeated over and over, with each completion of the cycle incrementally improving and iterating on the software. Enhancements can quickly be recognised and implemented throughout each iteration, allowing the next iteration to be at least marginally better than the last.

Fig. 2
figure 2

Iterative development approach

Full size image

The first step includes an initial planning stage where the specifications and requirements are identified and generally prepares for the upcoming stages of the cycle. Once planning is complete, an analysis is performed to identify what will be required. The next step includes the coding and implementation of all planning, specification and design. Once this current build iteration has been coded and implemented, the next step is to go through a series of testing procedures to identify and locate any potential bugs or issues. Once all prior stages have been completed, it is time for a thorough evaluation of development up to this stage. All feedback from the evaluation process is brought back to the planning and development stage at the top of the list, and the process repeats itself all over again. Eventually, a point will be reached where the requirements are complete and the software can be delivered.

3.1 Rule-based matchmaking

The rule-based matchmaker is a mechanism that matches a user with two or more AAL services by exploiting the semantic description of the services and the semantic description of the user needs, preferences and current status. The goal of this mechanism is to identify and combine AAL services for the resolution of emergency cases and to propose personalised services to the end-users.

3.1.1 Emergency case resolution

One of the issues that the matchmaker resolves is the proper selection of AAL services to be called in case there is an emergency situation for an elderly. In this case the matchmaking process is separated into three stages:

  • User status update an alarm notification is received from the monitoring process that changes accordingly the user status;

  • Service selection a corresponding set of services is selected according to the user status;

  • Service composition a procedure that tries to combine the selected services (if possible) in order to be called in a sequential way is triggered.

For instance, a monitoring service that detects if a user has fallen and sends the corresponding alarm to the platform. Based on this alarm, the status of the user may change (i.e. from “standing” to “fallen”) and the aforementioned change of the status can trigger the call of an alarming service, in order to automatically inform the assisted person’s caregiver(s) about this situation. In case multiple services are selected, then a procedure that combines these services is initialised. For instance, if this event occurred outdoors, call a service that determines the location of the elderly and informs his/her caregiver(s) about the event along with the elderly’s coordinates. Below, each one of the steps is described in detail, along with all the notifications made in the ontologies and the rules exploited by the system.


User status update

In order to support the described functionality, it was necessary to expand the aforementioned system’s ontologies in order to semantically link the concepts of “Alarm”, “User Status” and “Service”. Specifically, each Alarm instance was mapped with an AlarmType instance through the object property hasAlarmType. The AlarmType class is something like a categorisation class for the Alarm instances, based on the type of action needed for each alarm. The AlarmType instances were mapped to a Status instance through the isMappedToStatus object property. Figure 3 demonstrates the aforementioned classes and properties, while Table 1 presents the rule that is executed in Semantic Web Rule Language (SWRL) format [41]. SWRL is a high-level abstract syntax introduced by W3C that allows users to write rules. It provides a human-readable syntax, where a rule has the following form: antecedent \(\rightarrow \) consequent. If the antecedent parts are true, then all consequent parts are also true. Using this syntax, a rule asserting that the composition of parent and brother properties implies the uncle property would be written:

parent(?a, ?b) \(\wedge \) brother(?b, ?c) \(\rightarrow \) uncle(?a, ?c)

Fig. 3
figure 3

Classes and properties related to change of user status and service selection according to a received alarm

Full size image
Table 1 Rule for status matchmaking on alarm level
Full size table

Service selection

For supporting the selection of AAL services according to the user status, each one of the services registered in the Service Ontology was mapped to a ServiceTerm instance through the isMappedToServiceTerm object property. The ServiceTerm class is actually a common dictionary created in order to describe AAL services that have similar functionality. For example, a ServiceTerm instance is the NotificationService that includes all services that notify someone. This class contains a priorityOfExecution datatype property that is defined by the administrator of the IN LIFE platform in order to indicate and maintain a logical sequence of execution among them.

Moreover, each of the available user statuses is mapped to one or more ServiceTerm instances, thus describing the types of AAL services to be called for each status. When the status of a user changes because of an alarm notification, the automatic service selection procedure is triggered. The classes described are connected to each other as shown in Fig. 3.

The problem of AAL service semantic matchmaking on status level is stated in finding the set of AAL services that should be called according to the service terms to which the user status is mapped. Table 2 demonstrates a rule in SWRL format that correlates a user with a AAL service by using his/her activity status.

Table 2 Rule for service semantic matchmaking on status level
Full size table

Service composition

In the final stage of the emergency case resolution, new rules are applied to the set of services that has been returned during the previous step, in order to try and combine them and call them in a sequential way. In order to achieve this, it was necessary to semantically link the inputs and the outputs of the registered AAL services. For each supported AAL service, a hasInput object property defines the input parameters of this service and a hasOutput object property defines its outputs. The inputs and outputs are all instances of the Parameter class. Each Parameter instance was mapped to a ParameterTerm instance through the isMappedToParameterTerm object property. The ParameterTerm class works as a common dictionary that describes service parameters. Figure 4 demonstrates the structure described.

Table 3 Rule for creating service combinations
Full size table
Fig. 4
figure 4

Classes and properties related to service composition

Full size image

For the automatic service composition, there are two rules used. The first one takes all selected AAL services from the first phase and creates all possible combinations between them (ServiceCombination instances). Each ServiceCombination instance has a sequence of two AAL services, where the first one has higher priority than the second and by default, this combination is tagged as valid. Table 3 demonstrates how all the ServiceCombination instances are created.

The second rule applies in all ServiceCombination instances a different logic-based OWLS-MX filters [42]: Exact and Plug in. The Exact filter matches two services when the input parameters of the second match perfectly with the output parameters of the first, while the Plug-in filter matches two services when the input parameters of the second is a subset of the output parameters of the first. By applying the aforementioned logic, the rule defines which of the created service combinations are truly valid. A service combination is considered as valid when all inputs of the second service are matched with the outputs of the first service by comparing their parameter terms, thus meaning that these two services can be called in a sequential way. Table 4 shows the rule that applies the filters and defines which service combinations are valid and can be called sequentially.

Table 4 Rule for applying the OWLS-MX filters
Full size table

3.1.2 Tool recommendation

All registered tools in the IN LIFE platform can be accessed by the users through a web application called Application Centre.Footnote 1 It is a web interface that can be accessed by end-users with different roles and it provides a personalised control panel for each user with different functionalities per user role. Moreover, for each end-user, the most suitable tools are identified and recommended according to their role, status and context of use.


Selection of tool categories

The implemented rule-based matchmaker identifies the tools to be displayed for each user by determining the user needs from his/her personal information. In order to do so, an efficient way to classify semantically the registered tools is needed, along with a mechanism responsible for the clustering and modelling of the users.

The registered tools are classified in four tool categories: (1) Independent Living Support includes services targeting the enhancement of the independent living capacity of the elderly in daily functions, (2) Carers Support includes services for supporting the caregivers of the elderly, (3) Travel Support includes services for mobility enhancement, and (4) Socialisation and Communication Support includes services for supporting the communication and socialisation activities of the elderly considering also multilingual and multicultural issues.

In addition, the personal information of the cognitively impaired individuals is used in order to cluster the users according to a user taxonomy. Specifically, all assisted persons are clustered based on (a) capacity to function in terms of daily life activities or of disability-free status, and (b) socio-economic status. The 4 supported taxonomies (i.e. dependent, assisted, at risk and active) represent 4 archetypes of users with different needs. For each supported taxonomy, different tool categories are displayed.

The classification of all AAL tools in the aforementioned categories, along with the clustering of the users in the described taxonomies, was based on the feedback received by experts from the elderly caregiving domain, during the iterating evaluation of platform in the development phase.

Table 5 Rule that defines user taxonomy
Full size table

Table 5 shows one of the rules used to define the taxonomy of the user utilizing his/her personal attributes, while Table 6 demonstrates another rule that relates a tool category to a user according to the pre-defined user taxonomy.

Table 6 Rule that relates tool categories to a user
Full size table

Tool order definition

Besides the selection of the proper tool categories for each user, the matchmaking process also defines the display order of the tools by calculating the similarity between tools and recommending those that match the preferences of this specific user (Fig. 5). This content-based approach does not need data from other users, produces good results for users with unique tastes and is able to recommend new and unpopular items.

Fig. 5
figure 5

Representation of how the content-based approach works

Full size image

For the calculation of the semantic similarity between the tools, the so-called Semantic Cover Rate (SCR) [43] similarity metric is used. The SCR computes the distance between two classes in the same ontology.

Let us assume that T: T1, … Tk are all the tools to be presented to a user U according to his taxonomy and IR: IR1, … IRk the initial recommendation value of each tool, which is the number of usages by U, normalised in the range [0,1]. In order to calculate the final recommendation value of a tool Ti, the similarity of this tool with all the others must be calculated by using the SCR metric, thus giving this list of similarities values: SIMi: SIMi1, …SIMik. Then by using the following formula, a set of similarity recommendation values is calculated SRVi: SRVi1, … SRVik. Finally, the maximum value of the set SRVmaxis compared to the IRi and it overrides it in case it is greater.

$$\begin{aligned} \mathrm{SRV}_{i,j} = \mathrm{SIM}_{i,j} \times \mathrm{IR}_j \end{aligned}$$
(1)

Two different algorithms use the aforementioned logic and produce recommendation values for each tool. These algorithms use different characteristics for the calculation of the similarity of the tools

The first one calculates the similarity according to a more detailed categorisation of the tools. The TAALXONOMY project [44] provides a comprehensive and above all practical taxonomy for effective classification of AAL products and services. It contains 8 level-one categories based on the scope of the application and 43 level-two categories based on the field of the application. All TAALXONOMY categories and subcategories were stored in the Service Ontology as instances of the TAALXONOMY class.

The second recommendation algorithm is based on the features provided by the tools. For the purposes of this module, a tree-like feature ontology was constructed and stored as part of the Service Ontology. Each one of the tools has multiple tags to describe the features and functionalities provided.

Each one of the two aforementioned recommendation algorithms produces a recommendation value in the range [0,1] for each tool, whenever a user tries to access the Application Centre. These results are combined by the hybrid matchmaker described in the following section, in order to define the order of the tools presented to a user.

3.2 Statistical matchmaking

Besides the rule-based matchmaker described in the previous section, a statistical matchmaker was designed and implemented in order to enhance the accuracy of the system by utilizing characteristics and behaviours of similar users. Specifically, this approach makes recommendations to a user based on the preferences of other similar users (Fig. 6).

Fig. 6
figure 6

Representation of how the statistical matchmaker works

Full size image

Collaboration filtering

One of the methods used for the tool recommendation is the collaboration filtering (CF). In collaboration filtering, a database of preferences for items by users is used in order to predict items that a new user might like. That means, that the similarity between 2 users is determined by the similarity in their preferences. In a typical CF scenario, there are a list of m users U = U1, U2, … Um and a list of n items I = I1, I2, … In, and each user has a list of items IUi, which have been rated by the user. The goal is to find item suggestions for a distinguisher user Ua \(\in \) U [45, 46].

Most collaborative filtering-based recommender systems build a neighbourhood of likeminded users using a pre-selected measure of proximity (Pearson correlation, cosine similarity, etc.). The main goal is to find for a user Ua an ordered list of k users N = N1, N2, …, Nk such that Ua \(\notin \) N and sim(Ua, N1) is maximum, sim(Ua, N2) is the next maximum and so on, where sim(Ua, Ni) indicates similarity between 2 users [46]. Using these similarity values and the ratings of each user that belongs to N, a prediction value is calculated for each tool. Prediction Pa, I expresses the predicted opinion score of item Ii for the active user Ua.

In our case, the list of m users consists of all the system users, the list if n items is actually a list with all registered tools and the IUi for each user contains the number of usages of the user for each tool. The algorithm developed is using the number of tool usages to calculate the similarity between users. The Prediction Pa, i is then computed as the weighted average of the ratings for the items from those users which are similar, where the weight is the computed coefficient. The formula for a prediction for an item for a user Ua is [47]:

$$\begin{aligned} P_{a,i} = {\text{avg}}_a + \frac{\sum \nolimits _{x=1}^k ({\text{corr}}_x \times ({\text{rating}}_{x, i}-{\text{avg}}_x))}{\sum \nolimits _{x=1}^k ({\text{corr}}_x)}, \end{aligned}$$
(2)

where avga is the mean rating for the user Ua, corrx is the Pearson’s correlation coefficient of user x with the user Um, avgx is the average rating (the average of the user ratings for the used tools in common) for user x, and k is the total number of users in the system that belong to the same neighbourhood with user Ua.

In order to avoid the sparsity and scalability issues [45, 48], the Scalable Neighbourhood Using Clustering method is used as it proposed by Sarwar et al. [46]. The idea here is to partition the users of a collaborative filtering using a clustering algorithm and use the partitions as neighbourhoods in order to calculate the prediction value. This method has two benefits: first, it reduces the sparsity of the data set, and second, due to the dimensionality reduction and use of a static pre-computed neighbourhood, the prediction generation is much faster. The user partitions are updated several times during the day, using each time the updated data retrieved by the Service Ontology.


Demographic filtering

An extra recommender was implemented that uses demographic filtering and it is justified on the principle that individuals with certain common personal attributes (socio-economic status, country, education level, etc.) will also have same preferences [49, 50].

The logic described in the collaborative filtering approach is used here as well. The main difference is that for calculating the similarity between the users and the clusters, instead of tools usages, we are using the information provided by the user’s profile. Specifically, for the assisted persons the following data are retrieved from the User Ontology: age, gender, education level, socio-economic status, capacity to function, diseases, impairments, functional limitations and disabilities. Diseases and impairments are grouped using the ICF classification [33].

The selection of the features used for clustering the elderly was based on several medical researches. Several papers [51, 52] demonstrate that there is a significant association between the race of the elderly with cognitive impairment. Furthermore, studies [53, 54] have shown that people who are older and single had lower level of education, lower social support and lower lipid level, and impaired physical function and physical inactivity had higher cognitive impairments rates. Finally, there are numerous papers [54, 55] that link cognitive impairments with gender.

The adoption of this recommendation approach does not only resolve the new user cold-starting problem but also exploits the cognitive impairments of the elderly people for the provision of personalised content.

One of the main difficulties in clustering the users according to their demographic information is related to the fact that the data used are both numerical and categorical. Clustering algorithms try to group similar entities usually by applying mathematical operations such as summation or averaging. In case of non-numerical or, in other words, categorical, the total mismatches between two objects are quantified: the smaller this number, the more similar the two objects. For clustering entities with both numerical and categorical data, there is the k-prototypes [56] algorithm which combines the aforementioned techniques.

After using k-prototypes, all users are portioned in clusters where each cluster represents the neighbourhood of a user. The distance between 2 users is used to determine their similarity. Finally, the same formula as in the collaboration filtering is used to calculate the prediction Ra, j.

3.3 Hybrid matchmaking

Because both rule-based matchmaking and statistical matchmaking have their advantages and drawbacks, a hybrid matchmaker has been designed and implemented in order to combine the advantages of both systems and minimise the number of drawbacks. Burke [57] was one of the first to categorise hybrid recommender systems in function of their combining strategies: weighted, switching, mixed, feature combination, cascade, feature augmentation and meta-level.

The approach selected for the hybrid matchmaker was a user-specific weighted hybridisation design with adjusted weights, where the outcomes of all recommendation algorithms are combined into a single recommendation value. Each one of the algorithms is associated with a weight, and the final prediction is calculated using the following formula:

$$\begin{aligned} {\text{HP}} =\frac{ W_1 \times P_1+W_2 \times P_2+\cdots +W_k \times P_k}{ W_1+W_2+\cdots +W_k} \end{aligned}$$
(3)

where k is the number of the different algorithms combined (in our case 4), Wi is the weight applied to each algorithm, Pi is the prediction value produced by each algorithm, and HP is the combined prediction that the hybrid matchmaker produces.

Furthermore, a dynamic weighting scheme is used and an offline procedure re-adjusts the weights for each user in order to optimise the predictions of the system. The objective function used for the evaluation of the system is root mean squared error and is defined as:

$$\begin{aligned} \mathrm{RMSE} =\sqrt{\frac{1}{|T|}\sum \limits _{(u,i)\in T} ({\text{pr}}_{ui}-tr_{ui})} \end{aligned}$$
(4)

where system predicted ratings prui are compared with true ratings trui contained in a certain test set T of user-item pairs (u, i).

The selected approach resembles to the P-Tango system presented by Claypool et al. [47], and its selection was based on the work of Doom et al. [58], where several different hybrid recommender systems were compared and the weighted hybrid system outperformed all other hybrid strategies. Furthermore, although most of the weighted parallelised models described in bibliography use a set of weights for all users, recent research is moving away for generalizing users and towards a per user focus. Ekstrand et al. [59] showed that recommenders fail (and succeed) on different items and users (although their focus was on switching hybrids). Hybrid recommender systems would obviously benefit from being able to predict which recommendation algorithm works best for which user. The importance of the individuality of users was also noted by the work of Kille et al. [60], in which they tried to model the difficulty of generating recommendations for individual users.

More specifically, each user has a specific set of weights, which at the beginning are uniformly distributed. This set contains one weight for each algorithm, and it is used for the calculation of the prediction for each user through the utilisation of Eq. 3. Periodically, in order to update and find the most efficient weights for each user, different weight combinations are evaluated through the utilisation of formula 4, by taking into consideration the user’s selections and preferences since the previous weight update. Each weight is allowed to take values from 0 to 1 with a step value 0.1, and all possible weight combinations are tested. The selection of this step was based on the iterative evaluation of the platform during the development phase, through the feedback received by all 3 different evaluation groups.

Let us demonstrate a specific example of exactly how the aforementioned approach works. For simplicity reasons, we will suppose that there are only 5 tools and 2 recommendation algorithms. Let us suppose that a new user enters the system for the first time. All algorithms will have a uniform weight distribution for this specific user calculated by dividing 1 with the number of recommendation algorithms. In our case, that means that each algorithm has a weight of 0.5. Table 7 contains the recommendation values of the two algorithms and the combined recommendation values calculated using formula 3.

Table 7 Recommendation values
Full size table

Let us assume that the user actually used the tools 1 and 4. Table 8 demonstrates the root mean squared error (see formula 4) for different weight combinations for the user’s selected tools. Each time the weights are modified by 0.2 (we are using different step here for simplicity reasons), thus providing 5 different combinations. The weight combination with the minimum RMSE is the one selected, and the user’s weights adjust accordingly. This procedure occurs periodically 4 times during the day, and the weights of each user are modified according to his preferences. It includes, as it was mentioned before, 4 different algorithms, 19 tools and a much greater number of weight combinations for the optimisation of the predictions of the system.

Table 8 Weight adjustment
Full size table

The k-means used for clustering in the collaboration filtering, the k-prototypes clustering used in the demographic filtering and the similarity calculation between all tools are performed offline and recomputed at a certain period of time ensuring the scalability of the system. Notice that if there is a new user with no usages, then the recommendation will be based on the demographic filtering. This solves the new user cold-starting problem. Similarly, if there is a new tool with no uses yet, it will be proposed using the content similarity.

4 Use case

The functionality of the IN LIFE hybrid matchmaker can be illustrated by two main scenarios:

  1. 1.

    Emergency case resolution: an alarm notification is received for a user, and the system selects and combines (if possible) the most appropriate services;

  2. 2.

    Tool recommendation: a user uses the Application Centre, and personalised content is provided according to his role, context, status and preferences.

4.1 Emergency case resolution

Let us suppose that an alarm notification is received for a user named Alex that indicated that he has fallen. This alarm notification will trigger the execution of the rule presented in Table 1 that will identify first the mapped AlarmType (“Fall”) and then the corresponding mapped status (“fallen”) and will change accordingly the status of the user.

The second rule (Table 2) uses the user’s status in order to identify which services must be called. Specifically, it finds for this status two mapped ServiceTerm instances: the NotificationService and the LocationService. The LocationService has lower priorityOfExecution property value than the NotificationService, meaning that it has higher priority of execution. The rule also finds all the registered services that are mapped to these service terms. In particular, a service that finds the latitude and longitude of a user ((CoordinationService) is mapped to the LocationService and a service that sends an SMS with coordination (CoordinationSMSService) is mapped to the NotificationService.

The rule-based matchmaker will check whether it is possible to combine the 2 resulted services. The rule in Table 3 will create a new ServiceCombination instance that has as first service the CoordinationService and as second the CoordinationSMSService. This service combination is considered by default valid. The rule in Table 4 checks whether this combination is truly valid by applying the OWL-MX filters. Specifically, it identifies the outputs of the CoordinationService that are mapped to the parameter terms longitude and latitude, and the inputs of the CoordinationSMSService that have the same parameter terms. That means that these two services can be combined and called in a sequential way and an SMS with the coordination of Alex is sent to his connected caregiver.

4.2 Tool recommendation

The tool recommendation functionality can be divided into two parts: the selection of the most suitable tool categories and the definition of the order of the tools to be presented.

4.2.1 Selection of tool categories

Let us suppose that there are two users: George and Alice. George has low socio-economic status and high capacity to function. As a result, the rule in Table 5 will cluster him to the “At Risk” taxonomy. Alice has both these attributes high, and as a result, she will be clustered to the “Active” taxonomy. After the taxonomy definition, the rule presented in Table 6 will define which tool categories will be presented to each user. Figure 7 demonstrates the tool categories for each user as they are displayed in the Application Centre.

Fig. 7
figure 7

Tool categories presented to users of different taxonomies

Full size image

4.2.2 Tool order definition

Regarding the tool order, let us assume that a new user named Kate decides to use the platform. The matchmaker because of the absence of any tool usages data related to Kate (new user cold-starting problem) uses her personal and health information in order to produce recommendations. Specifically, Kate will be clustered according to her demographic data and the preferences of the users that belong to the same cluster are used to define the tool order, as shown in Fig. 8a.

Fig. 8
figure 8

a Tool order for Kate when first logs in. b Tool order for Kate after several tool usages

Full size image

Kate decides to use the Guardian angel tool several times. These recorded tool usages will affect the recommendations of the matchmaking mechanism (Fig. 8b). In particular, the Guardian angel tool moved up one position in the tool order. The physical activity monitoring tool also moved up two positions because of the high similarity value with the Guardian angel, although it has never been used by Kate. Similarly, a new tool that may register to the platform (new item cold-starting problem) may have high recommendation value for a user although it has never been used, because of its similarity with other tools.

5 Evaluation

In the context of the IN LIFE H2020 project,Footnote 2 for the evaluation of the IN LIFE platform and all services, pilot plans were thoroughly designed for assessing the impact of the platform upon the cognitive and health status of the elderly, along with the usefulness and willingness to use the Application Centre and the provided AAL services. Specifically, the site pilots that were conducted took place in six European countries: Greece, Slovenia, Spain, Sweden, Netherlands and the UK.

There were two distinct phases for the evaluation of the proposed approach. The first one was part of the iterative model used during the development and described in one of the previous sections. The main objective of this phase was the design and implementation of a platform that would enable the provision of personalised AAL services to users. During this phase, each pilot site evaluated the Application Centre and the described matchmaker by using its own approach. In summary, there were 3 different approaches:

  • Using real users, a small number of real users (elderly and caregivers) were properly trained, used and evaluated the Application Centre and the matchmaker;

  • Using experts from the elderly caregiving domain, a number of experts in the domain of care of elderly pre-tested the platform and provided feedback about how to improve it and make it more useful for older adults and formal/informal caregivers;

  • Using technology specialist staff, pilot site’s partners used technology specialist staff in order to evaluate the Application Centre and the matchmaker from a more technological perspective.

The feedback received by the aforementioned groups of people through the iterative development process helped in the determination and refinement of the proposed infrastructure. More specifically, during the evaluation of the first versions of the matchmaker, users tended to use tools with low recommendation value. By modifying the number of weight combinations to be evaluated during the weight adjustment, we were able to fine tune the recommendations provided. In addition, although the proposed matchmaker provides specific tool categories to the users according to their taxonomy, a button that enabled the presentation of all tool categories has been added in the Application Centre. The monitoring of the usage of this button provided helpful feedback related to the effectiveness of the tool classification and user taxonomies and helped in their refinement to their current form.

After the finalisation of the platform, a second evaluation phase began. In total, 1958 users made use of the IN LIFE platform through the Application Centre for a period of 10 months. Of the participants, 1163 were elderly users with cognitive impairments, 362 informal caregivers (mainly family members) and 407 health care professionals. In addition to the elderly and their caregivers, 26 stakeholders were involved in the on-site pilots of IN LIFE.

This large-scale longitudinal study was conducted in two distinct conditions based on the idea to compare the everyday living experience of elderly with cognitive impairment and their formal/informal caregivers with (on-site pilot) and without (baseline assessment) the IN LIFE platform and services. The main objective of this phase was the evaluation of the impact that the platform had in the health status and the everyday living of the elder users. A small part of this phase was also dedicated in the evaluation of the Application Centre in terms of usability.

A number of questionnaires including scientifically defined and internationally accepted scales of measurement were used addressing the following:

  1. 1.

    General demographic data;

  2. 2.

    Information about familiarity, accessibility and usage of technology;

  3. 3.

    Barthel Basic Activities of Daily Life Questionnaire [63];

  4. 4.

    Instrumental Activities of Daily Life Questionnaire [64];

  5. 5.

    Mini-Mental State Examination (MMSE) [65];

  6. 6.

    Mood and affect by PANAS [66];

  7. 7.

    Health through the SF-12 [67];

  8. 8.

    Quality of Life through EUROQOL 5D [68] and QOL-AD  [69];

  9. 9.

    Questions about Mobility, Communication, Leisure, Safety, and Physical Exercise;

  10. 10.

    Specific questions related to benefits of using the system;

  11. 11.

    Feedback provision related to the usability of the platform.

From the aforementioned list of sub-questionnaires, only 1, 2, 10, 11 were mandatory for all pilot sites. Parts 3 to 9 that are used for assessing the cognitive, physical and emotional functioning of the elder people, as well as overall well-being and Quality of Life, were optional and each pilot site was free to select one or more of these.

In addition, only parts 1, 10 and 11 were used for the evaluation of the matchmaking mechanism. These parts are relevant to some aspects like the usability of the system that are closely related to the matchmaking process. This is because the matchmaking results are used for the determination of the user interface and the provision of personalised content. The following results (Tables 9 and 10) were extracted regarding the easy to use and the willingness to use the platform again in the future. Moreover, the questionnaires included an area where the users could provide some feedback related to the usability of the platform that helped in the refinement of the matchmaking mechanism. For example, there were some comments where a number of users expressed a strong preference to specific tools that helped refine the rule-based mechanism related to the tool recommendation.

Table 9 IN LIFE platform ease of use
Full size table
Table 10 Willingness to use IN LIFE in the future
Full size table

In spite of the fact that the scope of the pilots was the evaluation of the IN LIFE platform as a whole, it must be taken into consideration that the proposed hybrid matchmaker is a core component of the IN LIFE platform. Nevertheless, a more in-detail evaluation that will focus on the matchmaking is needed as a next step, in order to accurately evaluate the quality of its results. Traditionally, the evaluation of these systems is made by using metrics of algorithmic accuracy and precision, though in recent years, there is a change towards evaluation from a user-centric perspective [61]. In this context, the ResQue model [62] that consists of 60 question items is going to be utilised for characterizing and evaluating the user experience and users’ subjective attitudes towards the results produced by the matchmaker. This model evaluates the accuracy of a matchmaker and the context compatibility of the recommended items, along with the ease of use and the perceived usefulness among others.

6 Conclusions

This paper presented a hybrid matchmaking approach which focuses on providing personalised AAL services to elderly people with cognitive impairments by also resolving emergency cases through service composition. Its core components are: (a) a rule-based matchmaker that utilises the semantic description of the services in order to identify the most proper set of services to be called in problematic cases, combine them and call them in a sequential way. Moreover, by also combining the current activity and status of a user, it selects the most suitable tool categories and tools for the user to be displayed; (b) a statistical matchmaker that improves the recommendation accuracy of the rule-based matchmaker by utilizing collaboration filtering techniques and solves the new user cold-starting problem by using demographic filtering.

The hybrid matchmaker consolidates efficiently the results of these two components, thus utilizing the advantages of different techniques, and favourites those that are more suitable for each user. This mechanism uses user-specific weights for the effective combination of the results of all used techniques and regularly re-adjusts them.

Future work includes the improved evaluation of the presented matchmaking approach via the ResQue model [62] that will enable us to identify possible limitations and further improve it. Moreover, our matchmaking approach can be further extended with the addition of new rules (e.g. new rules that will take into account more user characteristics for the classification of the users), as well as with the implementation of more statistical algorithms (e.g. deep learning algorithms or SVD).