1. Introduction
The research in the fields of smart home, ambient assisted living (AAL) and domestic healthcare has strongly increased during the last ten years. One of the reasons of this attention lies in the remarkable increase of the ageing population (aged 65 or more), who is expected to reach the 30% of the European population over the forthcoming decades [
1]. This segment of population is often characterized by a loss of independence in several activities of daily living (due to functional limitations or to the onset of disabilities), and by a diminishing sense of safety—which could potentially lead to injuries while performing activities inside the house [
2]. In this context, the smart home is expected to deliver to its inhabitants tailored services able to assist the dwellers for a better, healthier and safer life in their everyday living environment. Therefore, the smart home has been widely addressed as a set of technologies with the potential to help ageing population in living independently, monitoring their safety and well-being, and preventing injuries and accidents in the domestic environments [
3].
However, it has been highlighted how the possibility to rely on the set of technologies deployed in a smart home may raise some concerns in the ageing population. For instance, the user-friendliness of the devices and the need for training dedicate to older residents in the use and management of the smart home are two remarkable barriers that can jeopardize the real adoption of AAL solutions [
4]. Besides, unfamiliarity with the devices and residents’ concerns regarding stigmatization have also been reported as non-negligible issues for older residents [
5]. Finally, privacy concerns can represent an obstacle for the adoption of monitoring devices in a smart home [
6].
A solution for the problems raised by ageing population can therefore rely on a simple reconfiguration of a standard home with a set of appliances that can support the residents in co** with their impairments while performing activities of daily living [
7]. This kind of reconfiguration appears promising to balance the support provided to the elderly inhabitants, and their concerns related to the unfamiliarity with the devices and to their privacy. Works related to the reconfiguration of living environments are mainly focused on ubiquitous computing and context-aware systems—distributed systems have been discussed as a promising tool to support the reconfiguration of domestic devices [
8,
9]. The possibility to have residents programming their own pervasive computing environments has also been investigated with the purpose of hel** dwellers to be involved in the reconfiguration of their own domestic environments [
10]. Another area where research is focused regards the possibility to provide adaptation over the time (reconfiguration) of the services provided by an intelligent environment [
11,
12]. Nonetheless, to the best of authors’ knowledge, no work in literature faces the problem of providing ageing population with a set of existing and familiar tools (such as everyday appliances) designed to (or presenting some features that) help them to cope with their limitations.
The “Design For All” (D4All) [
13] and “Future Home for Future Community” (FHfFC) [
14] projects tackle the issue of easing the reconfiguration of existing domestic environments with familiar appliances by relying on semantic web technologies. These technologies (in particular ontology) are connected with decision-making processes, since they provide a formal (logic-based) and sharable interpretation of knowledge. Semantic models are exploited in DSSs’ development since they can foster information integration; moreover, ontologies can support automatic reasoning processes, thus allowing to infer new information starting from the knowledge stated in the model [
15].
Through the exploitation of a semantic knowledge base, a Decision Support System (DSS) aimed at hel** architects and smart home designers to provide the inhabitants with a set of appliances that can help them in everyday-life activities is deployed. Through the use of the DSS, dwellers (especially those characterized by mild or moderate impairments and elderlies) can rely on familiar appliances that facilitate them in the execution of some activities. The DSS is designed starting from the characterization of the dwellers, i.e., the end-users of the AAL solutions and appliances, and relies on a standard and holistic framework for the description of their health conditions. The developed DSS is then exploited in an application designed to support designers and smart home architects during the reconfiguration process.
The remainder of this paper is organized as follows:
Section 2 presents the existing works in the field of semantic-based DSSs, with a focus on AAL and user-oriented solutions. In
Section 3, the methodology exploited for the creation of two use cases and the framework for health conditions description are introduced, as well as the key factors that led to the identification of the domains of interest for the ontology.
Section 4 deepens into the application ontology description, illustrating the different solutions adopted for its development. The result of the development process constitutes the main component of the DSS, which takes advantage of semantic web-leveraged reasoning process to deliver sets of appliances suitable for each of the dwellers identified in the use cases.
Section 5 describes an application using the DSS (RecAAL), and discusses the results obtained from reasoning process, while
Section 6 provides the results of a preliminary testing conducted on RecAAL.
Section 7 analyses the limits and future perspective of the DSS. Finally, the Conclusions summarize the main outcomes and sketch the future steps that need to be implemented to enhance the DSS.
2. Related Works
The topic of modeling the health-data is one of the main issues when tackling the interoperability among various data sources. Data integration is not a trivial task: The possibility to link different health-data is complicated by the heterogeneity of data formats and different naming conventions. The major importance of this topic gave birth to the Semantic Web for Health Care and Life Sciences Interest Group [
16], whose mission is to advocate, support and develop the adoption of semantic web technologies across clinical research, healthcare and life sciences. In Reference [
17], the authors relied on ontologies to integrate electronic health records to foster integrated care. In this work, ontology-based case-finding algorithms are exploited to enhance the accuracy of the diagnosis of Type 2 Diabetes and to foster the integration of different health-related data to improve the quality of care. A unified data model provided by ontology is the backbone of the method for accessing health data in Reference [
18]; in the context of emergency medical services, the method allows IoT devices to access distributed and heterogeneous data. In Reference [
19], the authors described an adaptive mediation system (ARIEN) leveraging ontologies to provide an accurate and seamless integration of heterogeneous medical data, enhancing data interoperability. To tackle the issues of the health-related concepts measured with differential accuracy from diverse data sources, the authors of Reference [
20] designed a semantic-based application (PopHR), that was able to automates the integration and extraction of health-related data; the application uses an ontological framework to describe data relevant to chronic diseases. Ontologies are also exploited to normalize and integrate structured and unstructured data from multiple sources. In Reference [
21], a semantic annotation lightweight model for healthcare data is presented; this model is intended to provide interoperability among diverse IoT devices monitoring patients’ health, and adopts Resource Description Framework (RDF) [
22] as modelling language, and SPARQL (SPARQL Protocol and RDF Query Language) [
23] for health-records extraction. A framework for the management and reuse of clinical archetypes and data is described in Reference [
24]; the framework allows to semantically annotate and transform health data in order to make them interoperable. With regard to the context of mobile health, Reference [
25] illustrated a patient monitoring system for the IoT; the architecture of the system relies on an ontology that enables the monitoring of patients’ health status. Inferences provided by the ontology are used to recommend workout routines and improving eating habits of patients. Datta et al. [
26] presented an IoT architecture to provide personalized and connected healthcare services; part of this architecture leverages ontologies to manage and gather health-related knowledge, while semantic rules are exploited to combine cross-domain knowledge.
In the field of AAL solutions, some interesting examples of semantic-based DSS can be traced in the literature. The possibility of enabling reasoning processes and inferring new knowledge on context, dwellers’ activities and comfort metrics gathers a great deal of interest [
27]. Osman et al. [
28] conceived a DSS for supporting independent living for people suffering from dementia is described. This DSS leverages the semantic representation of context information and semantic rules (modelled with Semantic Web Rule Language(SWRL) [
29]), in order to build a knowledge base able to capture changes in the situational conditions and the inferred information are provided to clinical personnel to help them in their decisions. Zentek et al. [
30] proposed an interesting use of ontologies to provide flexible management of AAL environments configuration. The framework takes into account two key factors of AAL solutions: the heterogeneity of settings and home environments, and the changing over the time of the user’s needs. Zhang et al. [
31] developed a sharable clinical DSS system providing clinical personnel with patient-based recommendations support clinical-decision process. The knowledge-base of the system takes advantage of both ontologies and SWRL rules to provide automatic suggestions.
Ontology-based technologies are a key factor in many works related to Internet of Things (IoT) and AAL solutions, since they allow to provide a formal description of many domains of knowledge involved. Energy efficiency and consumption is a relevant topic in smart homes and ambient intelligence, where semantic web technologies can play an important role. Fotopoulou et al. [
32] presented an energy-aware IT ecosystem that leverages ontologies to provide recommendations related to energy consumption to the residents. The architecture collects energy, environmental and behavioral-related data and combines them to generate recommendations tailored on the residents’ lifestyles. Fensel et al. [
33] described the OpenFridge platform, which leverages ontologies to transform into triples users’ collected measurements of their refrigerators and analyzes the resulting semantic data with SPARQL. OpenFridge exploits specialized ontologies for representing and linking refrigerators’ data in RDF format, with the ultimate aim of contributing to appliances’ energy efficiency. Madrazo et al. [
34] implemented a semantic-based energy information system, connecting several and various data sources exploiting ontologies; semantic models are used to integrate the information regarding energy certificates, building descriptions, energy monitoring in buildings and climate data. Bonino et al. [
35] developed an ontology-based model for describing electrical energy consumption in a smart home; this ontology (PowerOnt) provides the means to support energy efficiency measures in residential homes.
Ontologies cover a pivotal role also in describing the interactions between the residents and the smart home (its services, devices, locations, etc.). Huang et al. [
36] presented a dialog system for residents, who can inquire the smart home system for information related to appliances using their voice. The system adopts a semantic approach to manage residents’ vocal inputs and transforming them into service requests. In Ni et al. [
37], ontologies are exploited as a mean to represent human activity within the smart home, thus allowing the detection of residents’ behaviors. The proposed semantic model is built as a network of ontologies describing the resident, the environmental context and the activities.
Contrary to the main trend in AAL, the DSS presented in this work is not dedicated to support the deployment of context-aware or ubiquitous systems: The DSS fosters the reconfiguration of domestic environments using everyday appliances, which are more familiar to the residents. In RecAAL’s DSS the dwellers’ health status and its formalization assume a central role.
3. Use Case Definition: A Dweller-Centered Approach
Traditional design is usually oriented toward “standard individuals”, a generalized abstraction of real end-users, which often lacks an adequate comprehension of users’ needs [
38]. In fact, this kind of approach does not consider many variables regarding the users, such as their skills, limitations and knowledge. Furthermore, the under-representation of resident’s needs and the general scarceness of residents-related studies are among the factors that hinder the widespread adoption of AAL solutions [
3].
To overcome the limits of a generalized abstraction of residents, a new and holistic design paradigm has started to stand out: The “Universal Design”. This paradigm aims at taking into consideration the different features characterizing human users; it focuses on proposing solutions able to adjust according to the needs of specific categories of users. The main principles of this discipline can be applied also in the field of AAL too. In this context, D4All and FHfFC projects aim at applying the guidelines of Universal Design into domotic and inclusive domestic environment. The design of this kind of environments for elderlies, people with disabilities or families requires a set of heterogeneous tools during its whole lifecycle process (e.g., design, utilization, control and monitoring). The outcome of the projects works to provide different categories of users with a set of tools able to help them co** with the limitations they have, and to grant them the possibility to perform autonomously several activities of daily living that would otherwise be precluded, dangerous or strenuous.
The development of the DSS and its underlying semantic knowledge-base starts from the definition of the dwellers—the end-users of the results generated by the DSS. Considering that a smart home must be able to provide tailored services to its residents, by anticipating their desires and hel** them in co** with their impairments, the possibility to describe the dwellers and their health conditions in a holistic way is a topic of a paramount importance. Health conditions’ description must define the appropriate level of detail for the physical and physiological status of an individual over time, such as their abilities in the environments where they live, and the eventual cognitive decline occurring with ageing. In order to cover these crucial aspects of dweller-related knowledge, the ontology relies on the International Classification of Functioning, Disability and Health (ICF) [
39].
ICF is used to describe potential residents (
Section 3.2); designers can then exploit this piece of information as an input of the DSS to provide a suitable reconfiguration of the set of domestic appliances (
Section 3.3) to the dweller characterized with ICF.
3.1. The International Classification of Functioning, Disability and Health
The International Classification of Functioning, Disability and Health (ICF) is a standard World Health Organization-endorsed framework, aimed at providing a tool for the description of an individual’s health and its related statuses. It conceptualizes the functioning of an individual as a “dynamic interaction between a person’s health condition, environmental factors and personal factors” [
39]. ICF is a tool able to ease the communication among the health-stakeholders (therapists, clinicians) providing a standard and worldwide comparable description of the functional experiences of the individuals. Due to its vocabulary, which is easily interpretable also by non-clinical personnel, ICF can also be used in a variety of health-related domains, such as AAL, as a common means to support and facilitate the collaboration and the exchange of information among different actors. Indeed, ICF has found interesting applications in several fields outside the strictly clinical field (but still related to individual’s health and its description), such as work reintegration [
40,
41], home- and age-care [
42] and disability management [
43]. Therefore, the exploitation of ICF, leveraging on a common framework for disability and health description, can represent a solid base for the development of practical instruments aimed at assessing health conditions and functioning of people with disabilities.
The Classification is organized in two main parts, each of which is further categorized into components: The first part, “Functioning and Disability”, provides a description of the components “Body Functions”, “Body Structures”, and “Activities and Participation”; and the second part, “Contextual Factors”, provides the means to describe the impact of the components “Environmental Factors”, and “Personal Factors”. Each component (with the exception of Personal Factors) is further explained and categorized into Chapters, which identify the addressed domain of functioning. As a result of this framework, a person’s functioning is described through the interaction between their health condition, and the context where they act.
Each of the four components is identified by a letter (“b” for Body functions, “s” for Body structures, “e” for Environmental factors, “d” for Activities and Participation) and can be detailed by adding digits. According to the number of digits following the letter, it is possible to get a code (up to five digits), whose length indicates the level of granularity. The lesser the number of digits following the letter is, the more general the health related-concept is described; contrariwise, the higher the number of digits is, the more extensively and thoroughly a health-related concept is represented. The following
Figure 1 shows an excerpt of the whole classification representing some of the problems related to visual and hearing functions:
Figure 1 shows how under the same chapter both visual and hearing-related functions can be listed; to address properly the problems related to the “Quality of Vision”, another level must be enabled—the fourth level item, characterized by a five-digits code.
The complete classification encompasses more than 1400 domains, organized according to the abovementioned hierarchy of concepts. Specifically, “Body Functions” component’s domains aim at providing categories for the description of the functioning of human body systems, while “Body Structures” domains identify the anatomical parts of such systems. “Activity and Participation” domains describe the execution of tasks and actions in every-day situations, while the “Environmental Factors” domains provide the means to assess the social and physical impact of the environment on the individual, together with the possibility to describe the existence of physical barriers or facilitators in the environments where the individuals usually perform tasks.
The functioning or disability of an individual can be assessed selecting the suitable category and its corresponding code and then adding one or more qualifiers. A qualifier records the presence and assesses the severity of a problem in specific domains of functioning, personal or societal level. A generic qualifier can be added at the end of the domain code and serves as an indicator of the level of severity characterizing the domain; this generic qualifier can acquire a set of integer values:
cXXX.0—indicates the absence of impairments or a negligible problem in a domain;
cXXX.1—indicates a mild impairment in a domain;
cXXX.2—indicates a moderate impairment in a domain;
cXXX.3—indicates a severe impairment in a domain;
cXXX.4—indicates a complete impairment in a domain;
cXXX.8—indicates that the qualifier is not specified;
cXXX.9—indicates that the qualifier is not applicable.
The value 8 is used when the information gathered to decide the qualifier are not enough, while 9 is used when no specification can be given about a specific domain (for instance, when coding b650 “Menstruation Functions” for a male person). The generic qualifier assumes the meaning of descriptor of barriers (defined as physical, social and attitudinal factors that could force an individual to perform below their capacities), or facilitators (factors that can ease or enhance the performance of the individual) for the specification of the Environmental Factors domains. The simple qualifier represents the impact of a barrier (e410.1 a mild barrier/negative impact in the “Individual attitudes of immediate family members”), while a qualifier presenting the “+” sign indicates a facilitator (e410.+2 a moderate facilitation/positive impact in the “Individual attitudes of immediate family members”).
Each component can make use of other qualifiers (following the generic one) according to the qualifiers structure [
39], reported in
Figure 2.
ICF’s component “Personal Factors” is yet to be completed, therefore the classification can rely on the remaining four components—enough to provide a sound and complete description of health-related issues, since “Personal Factors” are the particular background of an individual’s life and living [
45]. Although ICF presents many advantages, it has to be underlined that this framework is characterized by some shortcomings, such as problems regarding incongruent classification of some concepts, a lack of clarity between activities and their qualities, incorrect parent-child relationships of concepts and an overemphasis on subsumption [
46,
47,
48]. The ICF has also been modelled into an ontology [
49], which can be used as a reference model for other domain ontologies and that inherits all the flaws belonging to the classification.
For the purpose of the DSS, the developed ontology relies on the generic qualifiers and adopts the whole “Body Functions”, “Body Structures”, and “Activity and Participation” components (up to fourth level items).
3.2. Identification of the Personae
To identify prototypical residents, for which the DSS can provide a helpful set of appliances, the methodology described by Cooper [
50] was adopted. The first phase of this methodology concerns the identification of the proper personae, fictional characters created to represent the users’ types who benefits from the work of designers and architects using the DSS. Personae have been sketched also to facilitate communication between the different partners composing the projects stakeholders [
51]. The five personae identified correspond to the target residents, and are defined as follow:
Elderly characterized by frailty—a persona that comprises men or women of 65 or more years old, characterized by unstable health condition and by one (or more) of these four criteria: (1) Involuntary loss of weight of 4.5 kg in the last year; (2) asthenia or sense of fatigue for at least three days in a week; (3) limited physical activity and sedentary life style; (4) limited walking speed, with a time required to cover 4 m greater than 6 s [
52].
User with visual impairments—people with a visual impairment that compromises (totally or partially) their social and working activity.
User with hearing impairments—this persona includes people characterized by a partial or total hearing loss.
User with cognitive impairments—a persona comprising people affected by alterations or dysfunctions of fundamental cognitive functions, such as memory, language, visuospatial abilities and executive functions [
53]; severe mental conditions and illnesses are excluded from this category.
User with motor impairments—a persona collecting people affected by a specific neuro-motor deficit; this persona comprises all the people affected by pathologies comprising the neuro-motor system.
The sketched personae are drafted together with the clinical partners of the two projects and reflect the range of possible dwellers. Each of them is a wide collection of specific cases that needs to be further explored and specified with the use of ICF framework.
Persona 1: Silvia is a 72-year-old woman living alone in her house. Although she is independent, she has started suffering from asthenia, loss of weight, weariness in the last two years. Her muscular weakness makes her strenuous using her arms in many activities, thus reducing her mobility. Silvia’s health condition described with ICF reports the following domain as afflicted by some limitations (the generic qualifiers indicate the magnitude of the limitations):
b4200.1—Increased blood pressure
b4202.1—Maintenance of blood pressure
b4550.2—General physical endurance
b4552.2—Fatigability
b530.2—Weight maintenance functions
b7102.1—Mobility of joints generalized
b7300.1—Power of isolated muscles and muscle groups
b7356.2—Tone of all muscles of the body
d4102.2—Kneeling
d4105.2—Bending
d4300.2—Lifting
d4305.1—Putting down objects
d630.1—Preparing meals
s73002.183—Muscles of upper arm (indicating an unspecified change in the structure of both arms)
Persona 2: Giovanni is a 69-year-old widowed man living alone in his house. Starting from the age of 67, Giovanni has suffered some vision-related issues, and even if he wears his glasses the problems do not seem to be solved. This makes several activities difficult for him, such as reading a book or a newspaper, understanding icons and writings on appliance and food’s packages, using text-based devices (such as mobile phone). Giovanni’s health condition described with ICF reports the following domains and qualifiers:
b21000.2—Binocular acuity of distant vision
b21001.2—Monocular acuity of distant vision
b21002.1—Binocular acuity of near vision
b21002.1—Monocular acuity of near vision
b220.1—Sensations associated with the eye and adjoining structures
d110.1—Watching
d360.1—Using communication devices and techniques
d166.2—Reading
d325.2—Communicating with/receiving written messages
d345.2—Writing messages
d630.2—Preparing meals
(No alterations in the structures of the eyes are registered).
Clinical personnel involved in the projects tried to refer to the minimum amount of ICF domains to provide a proper description of the two personae’s health conditions; for the codes involving Activity and participation domains, the qualifier choice was limited to the first (indicating how a person performs activities inside their environments and with devices such as glasses, cane, etc.). In Silvia’s last code the full set of Body Structures qualifiers was used to represent that fact that the problem affects both of her arms. It is here intended that domains not specified in the above lists are not interested by any form of impairment.
3.3. Definition of the Use Case
In the second phase of Cooper’s methodology, the identified personae were portrayed in use cases, in which they became the subject of a designer’s activity of kitchen reconfiguration. The design of a use case consists in the allocation of different tasks and functions to the actors, and encompasses the narration of what happens during the interactions among the actors as expected outcome.
The use case scenario is focused on the possibility to configure a specific room of the smart home for two of the abovementioned personae with the help of a designer. In this scenario, a designer sets up a kitchen for specific categories of dwellers providing it with appliances suitable to cope with its impairments. The kitchen has been chosen as one of the most relevant domestic environments considering that:
It is the room that can benefit most from AAL tailored solutions [
54];
It is the place where older people suffer from most domestic injuries [
55];
It is where one of the Instrumental Activities of Daily Living takes place (meal preparation) [
7].
The following is the description of the use case related to the reconfiguration of the kitchen.
In the use case a designer is required to design the kitchens using a Decision Support System able to select the most suitable appliances for the two end-users, who are specifically:
Both users are characterized by moderate impairments that could jeopardize their safety and make their activities strenuous in the kitchen. The designer acquires the user’s kitchens blueprints and the users’ health conditions, via an application; users’ sensible data (address, health conditions) cannot be seen directly by the designer, who can only see an aggregate information, such as a string reporting “user with moderate visual impairment” or “user characterized by mild frailty”; the designer elaborates virtual models of the two kitchens. In these models, the individual can place the most suitable appliances to cope with the users’ impairment(s), such as an oven, refrigerator, cooktop, dishwasher and useful sensors (e.g., air quality detection, user’s presence detection, luminance measurement), choosing them from a list. This list is the result of the activities of the DSS (an ontology-based reasoning process), which (according to the users’ health conditions) automatically selects from the catalogues of appliances only those options that are suitable to improve end-users’ autonomy. At the end of the design phase, the designer can save the kitchens’ reconfiguration projects. During the reconfiguration the designer meets the users for who the reconfiguration projects are designed; the individual can discuss with them the choices of appliances and (according to their feedbacks) modify such choices. Then the designer can save again the project and export it in a construction drawing format.
In this use case the designer selects the most suitable appliance options together with the end-users of the reconfigured environment, so that dwellers’ desires in terms of appliances’ functionalities, interaction modalities and aesthetical characteristics (color, shape, etc.) can be met.
4. The Ontology-Based DSS
In this section the application ontology underlying the DSS is described, starting from its specifications and the methodology followed for the development. An application ontology is an explicit specification of a conceptualization engineered for a specific use or application focus and whose scope is specified through testable use cases [
56,
57]. The application ontology refers to canonical ontologies to construct ontological classes and relationships between classes and is used when modelling cross-domain concepts.
The application ontology at the base of the DSS is divided in two modules, each of which describes some specific concepts of domains of knowledge.
4.1. Specification and Methodology
The use case depicted in the previous paragraph allows highlighting the key points that the application ontology must include. Following a bottom-up approach (from the most concrete to the most abstract) [
58], the key points are used to identify some of the concepts, which will be deepened through the NeOn methodology’s [
59] steps and through the compiling of the Ontology Requirements Specification Document (ORSD) [
60]. This activity considerably simplifies the identification of the knowledge to represent in the form of an ontology, also providing useful indications about the foreseeable granularity of the model and its extent.
The compiling of the ORSD also allows to answer several other questions regarding the model. Referring to the NeOn methodology, it is possible to identify reusable ontological resources and therefore proceed to the development of the whole application ontology.
4.1.1. DSS’s Ontology Requirements Specification Document
The ORSD is a tool that describes what a semantic model supports, the domain of application of the ontology, the intended users and uses for the model. It is useful to provide support to ontology engineers while evaluating the inclusion or exclusion of concepts in a model, as well as to guide the choice of reuse of existing knowledge sources [
61]. The compiling of this document has been carried out according to the list of task provided in Reference [
62], where an accurate methodology to compile the ORSD is specified. The tasks for the compiling of the ORSD start with the identification of the purpose for which the semantic model is developed, the scope of the ontology and the definition of the implementation language. The
purpose of the ontology is to provide a holistic description of different kinds of users, which has to be realized with a language understandable by clinicians, caregivers and rehabilitation therapists. The model must also be able to provide a description of the different smart objects located in the user’s home. Hence why the
scope of the ontology must focus on the diverse extents: The description of the users’ health condition; the description of the appliances and their features. Resource Description Framework (RDF) [
22], and Ontology Web Language (OWL-DL) [
63] are the selected
implementation languages (with the use of Semantic Web Rule Language (SWRL) [
29]), and the open-source ontology editor, Protégé, is the tool chosen to develop the semantic model. These languages are endorsed by the W3C consortium and therefore widely used.
The successive tasks foresee the identification of the intended end-users and uses of the ontology. End-users of the model are clinicians, caregivers and rehabilitation therapists, who access to the users’ health condition data; the designers who have to configure the users’ smart kitchens can access the aggregate data regarding the type of impairments characterizing the users; they can also access the appliances list and taxonomy to complete the domestic environment configuration.
Regarding the acquisition of a set of requirements that the ontology must satisfy, as non-functional requirements, one of the characteristics already emerged from the discussion of the use case regards the possibility to represent the users’ health conditions using the ICF standard. The same consideration is valid for the possibility to express the appliances features in a standardized way, including the ones deriving from the sensors of the first use case.
The output of the
functional requirements tasks are Competency Questions (CQs—a list of the questions that an ontology should be able to answer [
64]), which can be grouped into categories. An excerpt of the outcome of this task is represented in
Table 1, where different CQs are grouped into three categories and where the provided answers to the questions are used in the ontology.
The final task foresees the extraction of the terminology from the CQs and their answers to form a pre-glossary of terms. These terms were later formally represented into the ontology, in the form of concepts, instances and relationships. The terms with a higher frequencies highlight the domains for which an activity of research of existing or reusable knowledge sources must be conducted.
4.1.2. Development of Ontology with the NeOn Methodology
Following the NeOn methodology, the efforts focused on the development of a set of interconnected modules (smaller ontologies focusing on specific aspects of the domains of interest), characterized by domain-dependent relationships. This methodology is based on a set of scenarios that may occur during the development of an ontology [
59]. These scenarios encompass a variety of situations, from the development of semantic model from scratch to the reuse of existing models. The NeOn methodology includes nine scenarios, which are: (1) Development of an ontology from scratch—this scenario starts with the development of an ORSD and lead to the development of a new semantic model. (2) Reuse and reengineering of non-ontological resources—taxonomies, thesauri, schemes and other knowledge resources existing in a non-ontological form and covering the domain of interest can be transformed into ontologies or contribute to the development of a semantic model. (3) Reuse of ontological resources—it is a possible scenario when the developers find ontological resources reusable as they are. (4) Reuse and reengineering of ontological resources—similar to the previous scenario, in this case the found ontological resources can be reengineered to serve the intended aim. (5) Reuse and merging of ontological resources—this scenario applies when a variety of ontological resources for the same domain are found and are eligible for reuse. These resources can be merged into a new model or mapped or aligned. (6) Reusing, merging and reengineering of ontological resources—in this scenario the outcomes of the previous scenarios can be reengineered into a model suitable for the aims. (7) Reusing design patterns—this scenario takes place in the conceptualization phase of the ontology engineering process and suggests reusing ontology design patterns [
65]. (8) Restructuring ontological resources—in this scenario, the outcomes deriving from the other scenarios that must be integrated into a new ontology must be reworked somehow (modularizing, pruning, extending or specializing one or more parts). (9) Localizing ontological resources—in this scenario the terms of the ontology are translated in different natural languages.
The development process of the ontology underlying the DSS considered the scenario (1) and the scenario (4), develo** new ontologies from scratch and adapting already existing models to the project’s needs. In the following paragraphs, the chosen approaches are specified for each module. The ontology was developed in English. The reusable ontologies identified following this methodology was one: The ICF Ontology [
49].
4.2. Dwellers and Their Health Condition Module
This module describes the users and their health conditions. This application ontology is composed of two main sub-modules: The “Dweller’s Registry Records and classification” and the “Health Condition”, which provides an ICF-based description of the health conditions of the residents.
4.2.1. Dwellers’ Registry Records and Classification
Each of the residents is identified through a list of identity records, which constitute a sort of ID-card of the dweller describing static data about the resident. This module is composed of a T-Box containing a single class, “Dweller” an object property “hasHealthCondition” that links a dweller to their Health Condition and the datatype properties useful to assert facts about a resident. With these properties, it is possible to assert the resident address (street, city and country), their date of birth, their age (expressed in years), their email address, the first name(s) and the surname, telephone number(s), the Tax Identification Number. The domain of these properties is the class “Dweller”. In the ABox it is possible to assert a list of residents, describing their identity records through these ten datatype properties. The class “Dweller” also presents another subclass, “Dweller with impairment”, which gathers the “Vision Impaired Dweller”, the “Motor Impaired Dweller”, the “Cognitive Impaired Dweller”, the “Hearing Impaired Dweller”; these subclasses are then deepened, classifying the resident according to their grade of impairment.
4.2.2. Health Condition
Resident’s Health Condition consists of their ICF-based assessed health status. The modeling of the ICF-based Health Condition required the recourse to the information modeled in the ICF Ontology. Considering the scope of the projects and its ontology, a partial pruning and reengineering process was conducted on this model. The result is a simplified TBox containing the ICF’s components “Body functions”, “Body Structure”, “Activity and Participation” under the class “ICF Category”. Each Chapter making up the components is further detailed by modeling the sub-classes for the second-level, third-level and fourth level items. A datatype property allows to specify the generic qualifier for each ICF domain (the list of acceptable integer numbers are 0, 1, 2, 3, 4, 8, and 9, and represent the generic ICF qualifier denoting the severity of an impairment, or the performance for Activity and Participation domains).
A resident’s health condition can then be described by specifying the ICF categories interested by an impairment and the magnitude of the disability by using a descriptor, an individual that gathers one ICF domain and its qualifier. An example of health condition description for a resident is given in
Figure 3.
The TBox provides a description of the user’s “Health Condition”, allowing to distinguish them among “Vision Impaired Health Condition”, “Motor Impaired Health Condition”, “Hearing Impaired Health Condition”, and “Cognitive Impaired Health Condition”. For each of these subclasses, a further sub-classification regarding the grade of impairment is provided according to ICF qualifiers, as shown in
Figure 4.
A dweller is linked to the individual’s health condition through the object property “hasHealthCondition” and each health condition is associated with a dateTime Stamp value through the datatype property “isAssessedOnDate”; in this way it is possible to keep track of the evolution of a dweller’s physical and physiological status over time.
4.3. Appliances and Sensors
The main goal of this module of the ontology is to provide a description of appliances and the sensors that populate the DSS. This module is composed of two sub-modules: The “Appliance and sensors” module, which collects the list of appliances and sensors and provide a description for each of them; the “Programs descriptor” module, which describe the programs used by each appliance; the “Reconfiguration project” module, which describes the reconfiguration projects performed by a designer.
4.3.1. Appliances and Sensors Classification
This module is composed of a TBox and an ABox and collects the appliances that can be placed in the resident’s home. For each appliance, it is possible to specify several information using specific datatype properties: Application and physical protocol, hardware and software version, mac-address, manufacturer and model. An object property “hasProgram” links the appliances with their programs. It is also possible to sub-classify each appliance according to its typology (with the classes “Cooktop”, “Dishwasher”, “Oven”, “Refrigerator”, “Washer”, “Microwave”) and also environmental sensors can be detailed in the same way (“Air quality sensor”, “Gas detector sensor”, “Smoke detector sensor”, “Luminance sensor”, “Thermo-hygrometric sensor”, “User presence sensor”). A set of classes to further classify the appliances according to the type of residents with disability they can support is also developed: As an example for all the classes of appliance above identified, a dishwasher can be further specified as a “Dishwasher suitable for Visually-impaired Resident”, “Dishwasher suitable for Cognitive-impaired Resident”, “Dishwasher suitable for Hearing-impaired Resident”, “Dishwasher suitable for Motor-impaired Resident”.
This module did not reuse any of the several existing ontologies developed for the classification and description of appliances or sensors (such as “SAREF—Semantic Appliance Reference ontology” [
66] or “SSNO—Semantic Sensor Network Ontology” [
67]); most of them contain a grade of detail that exceed the scope of the DSS, therefore a development from scratch has been chosen.
4.3.2. Empirical Methodology for Populating the Appliances and Sensors Module
To populate the “Appliances and Sensors” module with instances, a group of experts (composed by an architect, a designer and a biomedical engineer) was appointed to select a list of appliances and to classify them as being suitable for particular categories of residents with impairments. The appliances were selected by searching the main online vendors on the web for appliances designed for people with disabilities. For an appliance to be evaluated by the group of experts, its webpage had to be provided with the following information:
Full specifications for the appliance (dimensions, accessories, buttons and controls description, power requirements and energy performances, programs installed):
A description of the appliance’s program(s)—especially those programs intended for people with disabilities;
A photo gallery to allow the group to evaluate the relevant design features of the appliances.
The result of this search led to the inclusion of both ADA compliant (appliances compliant to the Americans with Disabilities Act [
68]) and non-ADA compliant appliances in the list, which is composed of a total of 25 appliances (five ovens, five refrigerators, five cooktops, four dishwashers, three washers, three microwave ovens; see
Appendix A for the complete list).
The group identified the selected appliances according to at least one of these features:
The appliance has (at least) a program that is able to help a person with a specific disability in performing activities in the kitchen (cooking, cleaning, etc.);
The appliance’s design features (colors, design, shape, etc.) makes it easy to use for people with disabilities.
The 25 appliances found were then classified according to the benefit(s) they can supply: The group worked to empirically assess whether an appliance was able to help the resident to cope with one or more of their impairments, selecting specific ICF domains where appliance’s features could enhance the performing of activities or mitigate a disability. For instance, cooktops characterized by large button controls, digital and wide backlit display, high contrast design (such as a dark-colored surface with bright-colored controls) have been classified as somehow helpful for people with specific visual impairments (b21002, b21000 for the acuity of near/distant vision). Lift ovens, whose door opens following a vertical movement, can be particularly suited for wheelchair users (thus hel** users with impairments in the structures specified in “s120 Spinal cord and related structures”, “s110 Structure of brain” and in the functions specified in the codes from “b760 Control of voluntary movement functions” to “b780 Sensations related to muscles and movement functions”); nonetheless, this type of oven can help people who cannot bend (“d4105 Bending”) or suffers from muscular problems (b7300, b7356).
The impossibility to physically evaluate each specimen of the selected appliances led to the application of the empirical methodology described above. By relying merely on manufacturer provided information, the DSS’s knowledge base can be incremented by applying the same methodology to appliances not previously enlisted. The group of experts substantially acted as prospects (persons motivated to purchase an item) usually do when they want to purchase an appliance: They search information on the products (on the internet or in stores) they are interested in, but only rarely they can test it (contrary to automotive industry, home appliance industry does not allow to test the products before purchasing them).
Appliances’ assessment has been conducted assuming that all appliances have to be installed in a house following the appropriate specifications and expedients, which means for example that in order for a lift oven to be of some advantage for a wheelchair user, the appliance must be installed taking into account the user’s height on their wheelchair (the height can indeed vary according to the type of wheelchair adopted and its settings).
The results of this work make use of a specific object property (“helpsCo**With”), to state where an appliance can provide support for specific impairments, as illustrated in the following
Figure 5.
Evidently an appliance can be classified as suitable to help different categories of dwellers with disabilities, thus belonging to two or more of the subclasses discussed above.
Sensors can also be classified following a similar approach. For instance, smoke and gas detectors can be helpful for people whose sense of smell is compromised (“b255 Smell functions”), while luminance sensors can be used to assess the environmental conditions for individuals with vision-related impairments. Sensors do not take advantage of the “helpsCo**With” object property since they provide measurements and observations that can be used to monitor the safety and the quality of the environment regardless of the user.
4.3.3. Programs Description
The lists of appliances’ programs are detailed with the subclasses “Dishwasher Program”, “Washer Program”, “Microwave oven Program” and “Oven Program”, the only categories of appliances that foresee specific programs for their functioning. Each of the programs is described with datatype properties that specify the program name, providing a textual description of the program. Programs are associated to an appliance through the object property “isProgramOf”, which is the inverse of “hasProgram”.
4.3.4. Reconfiguration Projects Module
The last module of the application ontology provides the means to formalize the reconfiguration projects executed by the designers. This simple module consists in a class (“Project”) collecting all the projects performed by a designer. For each individual belonging to this class, it is possible to specify the following information: The resident for which the project has been designed (via the “isDesignedFor” object property); the appliances selected by the designer and their features, choosing them from the results generated by the reasoning process of the DSS (“includesAppliances”); the designer executing the project (“designedBy”); an identification number for the project (with the datatype property “hasID”).
4.4. Reasoning with the Application Ontology of the DSS
The application ontology can support reasoning processes and querying. Reasoning in ontologies allows to derive facts which are not explicitly expressed in the knowledge base. The DSS exploits the reasoner Pellet [
69] to classify residents’ modelled health conditions into the classification, described in
Section 4.2.2, and to retrieve a list of appliances suitable for a resident. With a set of SWRL rules it is possible to define the conditions for matching appliances with dwellers’ health conditions, basing on the ICF domains specified both for persons and appliances.
Classification of dwellers’ health condition is performed with a simple SWRL:
Dweller (?p), hasHealthCondition (?p, ?hc), HealthCondition (?hc), isDescribedBy (?hc, ?des), Descriptor (?des), describes (?des, ?icf), SeeingAndRelatedFunctions(?icf) -> HealthConditionWithVisualImpairment (?hc)
To further classify the health condition according to the value of the generic qualifier, a set of rules is specified; the following SWRL rule specifies the conditions for which a health condition is inferred to suffer for a moderate vision-related impairment:
Dweller (?p), hasHealthCondition (?p, ?hc), HealthCondition (?hc), isDescribedBy (?hc, ?des), Descriptor (?hc), describes (?des, ?icf), SeeingAndRelatedFunctions(?icf), qualif-value (?des, 2) -> ModerateVisualImpairment (?hc)
Classes, described in
Section 4.2.2, are further detailed with the use of OWL restrictions, as the following excerpt in XML/RDF syntax [
70] illustrates:
<owl:Class rdf:id=“DwellerWithVisionImpairment”>
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource=“#hasHealthCondition” />
<owl:someValuesFrom rdf:resource=“#HealthConditionWithVisualImpairment” />
</owl:Restriction>
</owl:equivalentClass>
</owl:Class>
Once the residents are classified according to their health condition, it is possible to retrieve a list of appliances that have been classified as able to help dwellers to cope with some of their impairments. This matching can be performed with a set of SWRL rules, like the following one, which is associated with appliances to a specific health condition with visual impairments:
DwellerWithVisionImpairment (?p), hasHealthCondition (?p, ?hc), HealthConditionWithVisualImpairment (?hc), isDescribedBy (?hc, ?des), Descriptor (?des), describes (?des, ?icf), SeeingAndRelatedFunctions(?icf1), OvenSuitableForVisualImpairedResident (?app), helpsCo**With (?app, ?icf), SameAs (?icf, ?icf) -> suitableApplianceFor (?app, ?p)
This rule allows each appliance recognized as hel** residents in co** with a specific impairment of their health condition to be linked to the dwellers via the object property “suitableApplianceFor”.
The application ontology, uploaded on a semantic repository, can be queried using the SPARQL Protocol and RDF Query Language (SPARQL) [
23]. In this way, it is possible to retrieve the results inferred by the reasoner with a simple SPARQL query like the following:
PREFIX r: <http://www.stiima.cnr.it/RecAAL/>
SELECT ?appliance
WHERE
{?appliance r:isSuitableFor r:Silvia }.
Querying with SPARQL also allows to retrieve the list of all appliances belonging to specific classes, retrieve the list of residents with specific impairments, the list of programs and details specified for each appliance.
5. The RecAAL Application
To ease the exploitation of the results of the reasoning deriving from the DSS, the RecAAL application is developed. RecAAL is a PC-based application developed using Unity 3D [
71]. Once the designer has acquired the blueprints of the resident’s current kitchen, the resident is able to design a virtual 3D model of the domestic environment in the application. Then, the designer opens the application, selects the resident, and reconfigures the kitchen, as illustrated in
Figure 6. The selection of the resident triggers SPARQL querying of the ontology and allows the retrieval of the appliances suitable for the resident.
Within the virtual 3D environment, the designer can add the appliances into the kitchen’s model, choosing them among the ones provided by the semantic reasoning process. Suitable appliances’ list is updated in real-time querying the application ontology with SPARQL, as illustrated in
Section 4.4, and depicted in
Figure 7.
The use of a 3D model allows the designer to apply changes to the 3D environment, while the residents can see the modifications in the appearance of the kitchen. For each appliance that can be selected, the designer can open an interface illustrating the options provided by the DSS; designer and resident can choose together which of the available options can help most the dweller in their activities in the kitchen.
The designer can also select sensors to be installed in the kitchen. The list of sensors selected appears on the blackboard (as illustrated in
Figure 8). At the end of the reconfiguration activity, the reconfigured project can be saved, and can be saved in the semantic knowledge base with a SPARQL query inserting a new project or modifying an existing one.
5.1. Preliminary Evaluation of RecAAL
The interface interaction experience of RecAAL for domestic environment reconfiguration has been tested in a preliminary study aimed at providing an expert evaluation of the interface functioning. The sample involved seven subjects (five males, and two females, with a mean age 30; the sample is composed of PhD candidates and students from Engineering and Informatics disciplines). The main goal and the general functioning of the application were illustrated to the involved subjects prior to the execution of the test.
Subjects were then asked to test RecAAL knowing resident’s impairment conditions. All of participants’ comments and feedback were noted.
In order to evaluate perception of prospective usefulness, the following outcomes were evaluated at the end of each participant’s experience through the administration of questionnaires:
Technology Acceptance Model 2 (TAM2) questionnaire [
72]—the original version of TAM aimed at assessing how a user come to accept and use a certain technology, through the evaluation of its perceived usefulness and its perceived ease of use [
73]. With the respect to this first version, TAM2 has been extended to evaluate technology acceptance also in terms of social influence (subjective norm, voluntariness, and image) and cognitive instrumental (job relevance, output quality, result demonstrability, and perceived ease of use) processes. All the questionnaire’s items are assessed using a 7-point Likert scale, ranging from 1 (“strongly disagree”) to 7 (“strongly agree”).
System Usability Scale (SUS) [
74]—it consists of a ten-item questionnaire with five response options for respondents (from 1, “strongly disagree” to 5, “strongly agree”). SUS allows evaluating a wide variety of products and services in terms of user-friendliness, consistency, ease in learning their functioning, cumbersomeness.
Section C of Mobile App Rating Scale (MARS) [
75]—the rating scale assesses app quality on four dimensions, i.e., engagement, functionality, aesthetics, information. In this case, the evaluation was limited to the graphical aspects (Section C). All items are rated on a 5-point scale from 1 “Inadequate” to 5 “Excellent”.
5.2. Results
5.2.1. Technology Acceptance Model 2 Questionnaire for evaluating the interaction
Overall mean of TAM2 questionnaire is 5.25 (SD = 0.61), corresponding to “somewhat agree” on the 7-points Likert scale. Highest scores are reported on items 8 (“Interacting with the system does not require a lot of my mental effort”), 9 (“I find the system to be easy to use”), and 10 (“I find it easy to get the system to do what I want it to do”), belonging to the “Perceived Ease of Use” scale. Lower scores are reported for items 11 (“In my job, usage of the system is important”), and 14 (“I have no problem with the quality of the system’s output”.) They correspond to the “Job Relevance” and “Output Opportunity” scales (
Table 2).
5.2.2. System Suability Scale
According to literature data [
76], scores of 68 are considered as “usability average”. RecAAL’s overall score is 72.5 (SD = 9.61), a borderline result that indicate an average outcome with improvements needed (as shown in
Figure 9). In particular, lower scores are related to perception of various function integration and to the interaction with the 3D environment.
5.2.3. Mobile Application Rating Scale
Mobile Application Rating Scale (MARS)_section C mean score is 3.38 (SD = 0.25), corresponding to “acceptable value” (
Table 3). Critical aspects highlighted by participants’ comments include mainly graphic elements.
5.2.4. Participants’ Comments
During the execution of the tests, participants manifested some comments and concerns regarding the application. These outputs are briefly reported hereinafter:
Low readability of appliances names because of the small font (five subjects);
User needs or clinical condition are not made explicit in the application when the designer starts the reconfiguration project (four subjects);
Lack of residents customized icon (three subjects);
Dweller choice is not well shown (three subjects);
Concerns related to a low understanding of the logical link between residents and appliances choices—without a preliminary explanation (three subjects);
Redundant icons on the appliance choice menu (two subjects);
Need for emphasizing appliances when the cursor hovers over one of the selectable options (three subjects).
5.3. Discussion
Applied technology research uses extensively models of Technology Acceptance in order to predict the intended use. In particular, TAM was used in many works in order to examine acceptance of different technologies [
77]. Regarding the DSSs evaluation, TAM model has been used to understand acceptance inclination of manager’s in business organization [
78]; evaluation of a DSS is also conducted in Reference [
79], where a sample of airline companies’ employees assessed the benefits deriving from the use of a DSS. Other examples of DSS evaluation with TAM can be traced in research fields related to the planning of environmental development [
80] and to the clinical setting [
81,
82]. The authors of this work are not aware of any study that measures TAM’s variables in a DSS designed for AAL. Moreover, since DSSs’ interface plays a pivotal role in technology acceptance, and it constitutes the only means through which the operator exploits the system, a comparison with similar systems is not possible.
Generally, we can observe that DSS technologies are well accepted by users working in professional fields, especially if they are designed to help in specific phases of the work. In accordance, our tool received positive evaluations at the overall score and, in particular at the scales that are most considered (i.e., “Perceived Usefulness” and “Perceived ease of use”). The SUS score was 72.5 (SD = 9.61), corresponding to a borderline level between “Marginal” and “Acceptable” according to the Acceptability ranges, and between the “Ok” and “Good” Adjective ratings. For this reason, enhancements are necessary. Finally, overall mean score at the section C of MARS was 3.38 (SD = 0.25), corresponding to the median value of the Likert scale, which corresponds to “satisfaction with few problems”; “moderate quality graphics aspects” and “average visual appeal”. It is evident that some graphics aspects are to be reviewed and modified.
Subjects’ comments noted during test session are relevant to deepen emerged issues and to understand which improvements are to be carried out. Small font used to indicate of appliances’ name and resident’s characteristics should be enlarged with attention to the color contrast; dwellers’ icons customization should be allowed. Subjects emphasized the need to make explicit clinical conditions of the dwellers, during the initial configuration phase. Logical links between dwellers and appliances choices must be explicitly stated. Other improvable graphics aspects are: Emphasizing appliances when the cursor hovers over them, and eliminating redundant icons from the menu.
7. Conclusions
In this work, the development of a Decision Support System (DSS) for the reconfiguration of a domestic environment is presented; while most of AAL solutions rely on complex systems and architectures, the DSS suggests a set of appliances to support residents affected by mild or moderate disabilities, thus enabling a simpler reconfiguration of living environments. The development process starts with the identification of specific residents, elderlies affected by impairments related to ageing and users affected by sensory or motor systems pathologies. To define the health condition of the residents, the International Classification of Functioning, Disability and Health (ICF) was selected as a standard tool able to ease communication among clinical and non-clinical stakeholders.
The DSS relies on a semantic application ontology, whose development is performed following the NeOn Methodology; the application ontology reuses ICF’s ontology and develops other parts from scratch. The result of this process is an application ontology that takes into account the residents’ health status and providing the means to describe the appliances to be placed within the reconfiguration process. Reasoning with the DSS allows to match residents with a set of appliances able to help them to cope with their impairments.
The DSS constitutes the base of the RecAAL application, which replicates the resident domestic environments in a 3D model; in this model a designer can select and place the appliances according to the results generated by reasoning process, then he can save the reconfiguration project.
Further works foresee the possibility to enhance some aspects of the DSS and the RecAAL application, by applying ML techniques for the automatic classification of appliances and kitchen aids.