Semantic and Dweller-Based Decision Support System for the Reconfiguration of Domestic Environments: RecAAL

Abstract

Researches in the field of ambient assisted living (AAL) have increased in the last ten years, and the paradigms of the smart home have widely spread. Smart homes must consider the health-related issues and the real needs deriving from the ageing of their dwellers. In the smart home, appliances are expected to provide support to the residents, especially when they are characterized by disabilities and/or impairments related to ageing. While most of the AAL solutions presented in literature rely on complex systems and architectures, residents affected by mild or moderate disabilities can take advantage of just a simpler reconfiguration of living environments, i.e., the replacement of certain appliances with others that are able to help them in coping with their limitations. This paper proposes a semantic-based decision support system (DSS), which relies on ontological models, to assist designers in domestic environments’ reconfiguration. The ontology leverages semantic representations of dwellers and domestic environments’ domains of knowledge to foster the adoption of appliances able to help the residents to live independently. The development process of the ontology is presented in detail together with the results deriving from reasoning processes. To ease the reconfiguration of domestic environments, a prototypical application taking advantage of the DSS is presented.

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 coping 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 helping 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 helping 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 coping 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 helping them in coping 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:

• A 72 year-old woman characterized by frailty (Silvia);
• A 69 year-old man characterized by a visual impairment due to ageing (Giovanni);

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. The list of Competency Questions (CQs).

Competency Questions—Group 1: Users and Their Health Condition

CQ1 —Who are the human end-users and beneficiaries of the DSS? The designer, Silvia and Giovanni —two users characterized by impairments. CQ2—Which are the dwellers who need to be modelled into the ontology? Silvia and Giovanni. CQ3—How are the dwellers identified? Through identity records for each resident. CQ4—Which are the identity records for the dwellers? Name, Surname, Address, telephone number, email, birthplace, Tax Identification number. CQ5—How is classified a dweller’s health condition? Using the domains and qualifiers from the International Classification of Functioning, Disability and Health (ICF).

Competency Questions—Group 2: Appliances of the House

CQ6—Which are the appliances involved in the use case? Environmental thermometer, air quality sensor, presence sensor, air quality sensor, luminance measurement sensor, oven, dishwasher, cooktop, refrigerator, microwave oven, washer. CQ7—How are the appliances identified? For each appliance the following information are compiled: Hardware version, mac address, software version, textual description of the appliance, name of the manufacturer, model of the smart object; in addition to these features, for each appliance a list of its programs is provided. CQ8—How are the appliances assessed to be suitable to cope with the impairments of specific types of users? Each appliance is categorized by a team of architect, designer and bioengineer on the basis of its features and programs into specific categories.

, 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), developing 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 helping 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 (“helpsCopingWith”), 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 “helpsCopingWith” 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), helpsCopingWith (?app, ?icf), SameAs (?icf, ?icf) -> suitableApplianceFor (?app, ?p)

This rule allows each appliance recognized as helping residents in coping 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. The results of the administered Technology Acceptance Model 2 (TAM2) questionnaire.

Item	Item Description	Mean	Standard Deviation
	Intention to use
1	Assuming I have access to the system, I intend to use it.	5.5	0.97
2	Given that I have access to the system, I predict that I would use it.	5	0.81
	Perceived usefulness
3	Using the system improves my performance in my job.	5.33	1.10
4	Using the system in my job increases my productivity.	5	1
5	Using the system enhances my effectiveness in my job.	5.17	1.06
6	I find the system to be useful in my job.	5.16	1.21
	Perceived ease of use
7	My interaction with the system is clear and understandable.	5.5	0.96
8	Interacting with the system does not require a lot of my mental effort.	6	0.81
9	I find the system to be easy to use.	5.83	1.07
10	I find it easy to get the system to do what I want it to do.	5.83	1.06
	Job relevance
11	In my job, usage of the system is important.	4.33	0.74
12	In my job, usage of the system is relevant.	5	1
	Output opportunity
13	The quality of the output I get from the system is high.	5.16	0.37
14	I have no problem with the quality of the system’s output.	4.66	1.10

).

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. The results of the administer Mobile App Rating Scale (MARS)_section C test.

Item	Mean	Standard Deviation
Layout: Is the arrangement and size of buttons/icons/menus/content on the screen appropriate or zoomable if needed?	3.16	0.75
Graphics: How high is the quality/resolution of graphics used for buttons/icons/menus/content?	3.33	0.51
Visual appeal: How good does the app look?	3.6	0.81

). 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.

6. Limitations of RecAAL’s DSS and Future Perspectives

The authors acknowledge that this work has some limitations and that further improvements are needed before the actual use of the described DSS and application.

6.1. Extending and Mapping the DSS Ontology

The possibility to rely on a referenced ontology of ICF eased the reuse of the whole standard classification for RecAAL’s DSS. However, in order for an ontology to be reused, it is important to define how it aligns with other models describing the same domains; this process is defined as ontology alignment (also known as ontology mapping or ontology matching). Mapping one ontology with another means that for each concept in the first ontology we try to find a corresponding concept that has the same or similar semantics in the second ontology [83]. Nevertheless, the creation of high-quality ontology mapping in an automatic way is still a challenge—and a cornerstone for the whole Semantic Web [84].

The ontology developed for the DSS (whose concepts and properties are here introduced by the namespace recAAL) can be mapped to other relevant ontologies, in order to foster its better interoperability and reusability. An ontology reused in many projects and developed within the framework of appliances’ energy-efficiency is SAREF. This model, developed with experts working in the appliance industry [66], was developed to foster interoperability among different devices. The concepts recAAL:Appliance and recAAL:Sensor can be semantically matched respectively with saref:Appliance and saref:Sensor, since they describe the same concept, as well as the respective subclasses representing specific categories of appliances or sensors (such as saref:WashingMachine, saref:SmokeSensor and saref:TemperatureSensor). Moreover, datatype properties used in the DSS’s ontology for appliances’ description (Section 4.3.1) can be aligned with the equivalent datatype properties modelled in SAREF (saref:hasDescription, saref:hasManufacturer, saref:hasName; etc.). MonErgy ontology [85] is another example of semantic model developed to provide a description of appliances and their energy ratings. This ontology classifies the monergy:ApplianceType in a set of subclasses, each of which corresponding to appliances’ types (monergy:MicrowaveOven, monergy:Oven, monergy:DishWasher, etc.). These classes can be semantically aligned with those modelled to classify DSS’s appliances (Section 4.3.1). Similarly, DomoML-env [86] (an ontology aimed at describing domestic devices to enhance their interoperability within a smart home) foresees a domoml-env:BuildingEquipment class that is detailed in domoml-env:HouseholdAppliance, which is further deepened into the subclasses domoml-env:WhiteGoods and domoml-env:BrownGoods; each appliance type is here represented as a concept, and can be semantically aligned with the classes modelled in the DSS’s otology. Moreover, some of DomoML-env’s properties modelled to describe appliances can be matched with the ones used in the DSS’s ontology. Device description is the aim of the FIPA Device Ontology Specification [87], a model aimed at fostering interoperability when communicating about devices and their capabilities. The class fipa:Device corresponds to recALL:Appliance ∪ recAAL:Sensor and therefore FIPA’s properties can be used to describe DSS’s devices. DSS’s Sensors (recAAL:Sensor) can be semantically matched with their equivalent concept in the Sensor-Observation-Sampling-Actuator ontology (SOSA), which is a core ontology reused in the W3C-endorsed SSN [67]. This ontology can also provide the means for the formal representation of actuators (sosa:Actuator) and for the description of the measurements performed by sensors, as well as the actuation provided by the actuators.

DSS’s ontology residents’ registry records (Section 4.2.1) can be aligned with the core properties of the Friend Of a Friend (FOAF) specification [88], a vocabulary widely-used for the description of networks of people.

Since the DSS’s aim is to suggest appliances for the reconfiguration of different domestic environments (not limited to the kitchen) an extension of the ontology should encompass also describing the appliances’ location; reconfiguration projects that tackles two or more rooms could benefit from a formal description of the environments. To this purpose, DogOnt [89] can provide the means to describe how a domestic environment is composed (including architectural elements and furniture) and the location of the various devices in the home.

6.2. Including More Personae

The two personae described in Section 3.2 were selected, taking into account the impact of the respective disabilities in the population. Silvia, the first person affected by frailty, represents one of the 962 million people aged over 60 years old in the world [90]. Frailty develops as a consequence of age-related decline, and nowadays afflicts half of the population aged 85 or more [91]; while evidences suggest that the incidence of this condition can affect also people aged 65–74 years old [92]. Giovanni, suffering from a visual impairment, is a person who represents a common situation in older groups of people. In fact, according to World Health Organization’s report “Universal Eye Health: A Global Action Plan 2014–2019” [93], 285 million people are affected by vision-related issues (39 million people are blind, with a complete impairment); visual impairments are more frequent among elderlies and the 65% of people affected by a moderate and severe impairment are older than 50 years of age.

Following the same methodology, described in Section 3.2 and Section 3.3, it is possible to sketch other personae, starting with the identification of ICF domains involved in the description of their impairments. Moreover, other personae with different health conditions, not enlisted in Section 3.2 can be modelled and described too, e.g., taking advantage of ICF core sets [94].

6.3. Using Machine Learning to Increase Ontology Population

A limit related to the current version of the DSS relies on its limited number of instances, in particular appliances, used for the proof of concepts. As described in Section 4, a group of experts worked to identify a certain number of appliances to be modelled into the application ontology. The group empirically selected a number of appliances and then classified it according to the benefits these can provide to particular categories of residents with impairments; the ontological population of appliances’ list can include both ADA and non-ADA compliant appliances, since the evaluation of the suitability of a device is performed by considering both its design features and programs. Such an empirical approach requires a lot of work to be carried out in order to:

• Identify the appliances on vendors’ and/or brands websites;
• Agree on appliances’ specifics to be evaluated and on the methodology to evaluate them;
• Manually classify them according to their specifics.

RecAAL’s DSS could therefore benefit from the application of Machine Learning (ML) techniques to populate the appliances’ ABox: Trying to automatically classify the appliances according to a set of appliances already classified by experts can, from the one hand, increase the number of individuals, while on the other hand can speed up application ontology’s population process.

Another application of ML techniques can concern the possibility to classify the appliances, not only as suitable for some specific impairments, but also to the severity of the impairments. In RecAAL, the selection of an appliance from the suggested list is performed by the designer together with the resident; by exploiting ML to further classify appliances according also to the magnitude of the impairments they can help coping with, the designer can potentially have a more limited—but more fitting—selection to choose from. This approach requires anyway clinical personnel to supervise the results generated from the automatic classification performed by ML techniques, since the complete automation of this classification process involves a sensitive domain—people with impairments everyday life and habits.

Additionally, the list of appliances could be flanked with a list of kitchen aids (such as cutting boards and tools for slicing foods designed for one-handed people, automatic and/or electric can openers, ergonomic peelers, etc.). These tools should undergo the same evaluation from a group of experts to be classified conveniently and may require the full extent of ICF “Body Structures” qualifiers to specify the type of disability the tools can mitigate; for this case, the DSS’s application ontology already provides the means to support this kind of body structures-related descriptions.

Finally, dwellers’ feedback regarding their experiences with the appliances selected and installed in their houses can constitute a validation means for experts’ group work, helping in better defining the classification methodology, illustrated in Section 4.3.2. Residents’ feedbacks can potentially be organized in a semantic knowledge base to be integrated to the original RecALL’s ontology.

6.4. Validation with Professionals

Regarding RecAAL’s validation, the protocol described in Section 6, needs to be administered to those professionals who could take some advantages from the application’s work: Interior designers, architects, smart home designers, caregivers, and vocational therapists could potentially be interested in knowing which appliances can be of some help for particular categories of dwellers. Moreover, to validate the approach of the empirical methodology, tests with both designers and residents with impairments need to be conducted. The preliminary tests described above highlighted that RecAAL can benefit from some enhancement in the graphical interface; appliances’ features need to be shown to application’s users, as well as an aggregate data regarding resident’s health condition.

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.