PIANI: An ontology-based platform for outdoor activity recognition and non-intrusive assistance to the elderly

Abstract

In this paper, we introduce a Platform for Non-Intrusive Assistance (named PIANI), as an assistance platform for elderly people able to do activities in outdoor environments without strict supervision. PIANI includes an ontology used to characterize outdoor activities of interest (activities to be observed). PIANI also defines a risk level of the activity that an elderly person is currently doing out of his home by comparing such activity to its characterization. In addition, the proposed platform uses the smartphone of the person in order to collect geographic and time information, which is used by PIANI to infer activity risk and send alert notifications based on semantic knowledge base. An experimental test was developed as a proof of concept about the utilization of PIANI to identify outdoors activities of elderly people, compute a level of risk and finally send non intrusive alert notification to the user.

Keywords

Ambient assisted living outdoor activity recognition ontologies

1 Introduction

The growth rate of the elderly population is rising in all countries around the world. This increment generates new economic and social scenarios, where aged people play a key role. Worldwide organisations manifest that in the year 2000, there were 605 million of elder people, and predict that this number will increase up to 2 billion in 2050 [1]. In order to face these emerging scenarios, organisations like [2, 4] and [5], have carried out efforts to improve the elderly people quality of life. Certainly, aged persons keep the desire of living an independent, comfortable and dignified life, performing recreational and daily activities in collaboration with their family and community.

The Active and Assisted Living Programme is an initiative in the European Union that aims to improve life conditions for elderly people by using information and communications technologies. They lead research projects to develop ambient assisted living (AAL) environments for elder people, especially to accomplish their daily activities. Certainly, assisted living environments implement solutions with technological tools for aged people to maintain an autonomous lifestyle and assist them in their daily activities simultaneously by developing intelligent products and services.

According to AAL, the provision of better quality of life for seniors having activities in indoor and outdoor environments are considered as open research areas. Indeed, internal assisted environments support users in their indoor activities at home or office. On the other hand, external assisted environments support users in their outdoor activities around their neighbourhood, for example, at a park, at a convenience store, or at a mall. Frequently, elders’ everyday activities extend beyond their home, and internal supporting technology is not always suitable for external environments. In these scenarios, external assisted environments provide support to the elderly and facilitate their interaction with the community, giving them more confidence to accomplish their external everyday activities.

Ontologies might be created using formal languages designed to represent a particular domain of knowledge, and they have been used in AAL systems to semantically represent the activities performed by elder people. Hence, the use of formal ontologies to represent such activities allows their recognition, which is an important step in most AAL systems.

The aim of this work is to assist elder people who live independently and perform daily activities outside their home. A Platform for Non-intrusive Assistance (PIANI) is proposed. PIANI supports elder people activities performed in external environments using an ontological approach. Specifically, PIANI uses the ONTO-AR ontology to identify external activities performed by elder people. In order to be lesser intrusive, PIANI will ask to the elderly person to characterize his outdoor activities of interest (to be observed). Then, PIANI uses such activity characterization to calculate the differences between a characterized activity and the current activity performed by the elderly person, hence, PIANI computes the risk of performing such activities and, finally, determines the response based on non-intrusive policies.

2 Related work

2.1 Ambient assisted living (AAL)

The importance of everyday life assisted by the environment has encouraged the implementation of various research and development work that assist the elderly in performing their activities outside the home. For example, you can currently find applications on Google Play such as GPS Tracking [9] and Motorola Alert [10], among others similar [11 –14]. GPS Tracking is an application that shows the locations of relatives or friends on a map, making it very useful to know where children are, and to monitor the location of elderly adults. Instead, the goal of Motorola Alert is to keep a caregiver informed about the times when the user enters or leaves pre-established places; for example, Motorola Alert sends a notification to the caregiver when the user leaves home, will notify when the user arrives at the mall, when he leaves the mall and also when he returns home. These applications are for generic use, i.e. they are not specialized for elder people assistance, although their utilization with the elderly is remarkably helpful.

Main contributions in AAL systems research are systems that delineate safe zones and routes so an elderly adult can perform any activity in that safe area [15, 16]. When the elderly adult leaves such areas, systems send notices to caregivers, who may be experts or relatives, to assist the user properly. Some AAL systems implement Neural or Bayesian networks. Neural networks are used in conjunction with ZigBee networks for indoor location systems with room-specific accuracy, i.e. the system can determine in what room the elderly adult is [18]. On the other hand, the system presented in [17] uses the variables of age, dementia level, climate, time in which the adult has been away from home and the time of the day, to model a Bayesian network in order to calculate the probability that the user is roaming the city. AAL systems e.g., [20, 21] have proposed ontologies as a tool for the recognition of activities. Knowing what activity the elderly adult carries out allows inferring if his/her behaviour is normal or if the activity implies some possibility of risk.

2.2 Activity recognition based on ontology

Knowledge Representation (KR) is a fundamental area in Artificial Intelligence because KR methods record a domain knowledge in a computer-legible format. Automated reasoning processes use stored knowledge to infer more information or obtain new conclusions automatically [19]. Description Logics (DL) is a group of logic-based languages used to represent formally the terminological knowledge of an application domain. DL provides logical formalism for ontological languages. The World Wide Web Consortium (W3C) recommends the use of an ontology language based on DL, OWL (Web Ontology Language) [8].

The method for recognition of Activities of Daily Living (ADL) presented in [20] uses ontologies and several sensors positioned in a house (intelligent house) to discover and to monitor patterns of ADL. Sensors determine if the user opened or closed windows and doors, or if the user turned on or off various electronic equipment. For example, if the position sensor indicates that the user is in the dining room, the gas stove sensor is on (i.e. the stove is in use), and the time sensor indicates 15 minutes, the ontology jointly with the data provided by the sensors allow to infer that the user is cooking. The recognition of activities proposed in [21] is similar to the previous system, since sensors installed in the house and in various objects allow the system to identify the actions that the user performs. In addition, the ontology is used to infer the activity performed by the user based on the information provided by the sensors.

In this research work, PIANI is presented as a proposal to assist elderly people performing outdoor activities. PIANI aims to determine if the activity performed is safe or not. Table 1 presents differences and similarities of PIANI with existing systems and applications.

Table 1
Comparison of PIANI with existing systems and applications

System Outdoor User location Activity recognition Ontology based

App [9] yes yes no no

App [10] yes yes no no

App [14] yes yes no no

App [13] yes yes no no

App [11] yes yes no no

App [12] yes yes no no

Sys [15] yes yes no no

Sys [16] yes yes no no

Sys [17] yes no no no

Sys [18] no yes no no

Sys [20] no yes yes yes

Sys [21] no yes yes yes

PIANI yes yes yes yes

System	Outdoor	User location	Activity recognition	Ontology based
App [9]	yes	yes	no	no
App [10]	yes	yes	no	no
App [14]	yes	yes	no	no
App [13]	yes	yes	no	no
App [11]	yes	yes	no	no
App [12]	yes	yes	no	no
Sys [15]	yes	yes	no	no
Sys [16]	yes	yes	no	no
Sys [17]	yes	no	no	no
Sys [18]	no	yes	no	no
Sys [20]	no	yes	yes	yes
Sys [21]	no	yes	yes	yes
PIANI	yes	yes	yes	yes

3 Ontology-based platform for non-intrusive assistance

As previously stated, PIANI is a platform that provides to elderly adults a non-intrusive digital assistance for their daily activities outside home. In this work, an activity is an action or set of actions performed by an elderly person in a place, specified by their geographic location (latitude and longitude) U, a day of Week F, a starting hour of the day H and a duration D. In addition, PIANI classifies an activity as risky if the elderly adult does not do it habitually, that is, if the values of the variables U, F, H and D vary with respect to the routine of the elderly adult. In general, PIANI performs four processes:

Detect activity.

Identify Activity.

Determine activity risk

Select and execute non-intrusive action

3.1 Activity detection

In order to detect the different outdoor activities that a user performs, PIANI has to monitor when an activity starts, continues or finishes. Remember that, in order to be lesser intrusive, elderly adults register the sites where they perform their different activities of interest (to be observed) using the PIANI application installed in their smartphones; in Fig. 1, the stored sites appear with a mark and in red circles. Then, the application requests information from the available GPS satellites. After obtaining the latitude and longitude of the current location of the elderly adult, the application calculates whether this location is within any site that has previously been stored.

Fig. 1

General flow of information in PIANI.

PIANI considers that an activity starts when the elderly adult enters the area of one of the stored sites; it considers that the activity continues while the elderly adult remains inside the site; and the activity will finish when the elderly adult leaves the stored site’s area. Whether the activity starts, continues, or finishes, PIANI sends to the server the GPS data along with other user data.

3.2 Activity recognition

The server receives the data sent from the user’s mobile application and searches in the ONTO-AR ontology, through the Inference Engine, the activities that are similar to the current activity. That is, the Inference Engine filters the activities in ONTO-AR according to the values of the parameters U, F, H and D and creates a list of activities performed in site U, in day F, at H hours and/or lasting D minutes. From the activity list, server selects the activity with a greater number of matches in its parameters. If the server finds an activity that coincides in its four parameters, the identification of the activity is unequivocal. However, the less parameters coincide, the greater uncertainty will have PIANI, being able to identify several activities as correct. In these cases, the server weighs the parameters, giving the largest weight to the variable U, the second to F, the third to H and the lowest weight to D.

3.3 Risk definition

PIANI determines the activity risk by comparing the values of the four activity parameters, and compares a new variable: Preferred time T. This variable (T), also sent from the mobile device of the elderly adult, determines the schedule when an activity can be performed. For example, the user can define an activity that usually performs during the day, but never performs it at night, or vice versa. PIANI server compares the values of the variables U, F, H, D and T of the current activity with the values of the variables of the previously inferred activity, and obtains what variables differ and what are equal. The Inference Engine determines the activity risk according to the results obtained with the former comparison, and based on the ONTO-AR ontology definitions, decides if there is no risk, or if a low, medium or high risk is present. Finally, the PIANI’s Inference Engine updates its knowledge base (ONTO-AR) by setting the risk level of the current activity.

3.4 Assistance actions

The ONTO-AR ontology also defines system responses according to the risk level. Therefore, at the end of the previous process, the server uses the Inference Engine to search the action policies according to the risk level obtained. Lastly, the server sends selected response actions to the mobile device. The mobile application is responsible for performing the actions and continues waiting for another GPS reading to restart the three processes again.

4 PIANI architecture

Proposed platform architecture is composed by two main components, client and server; see Fig. 2. Client component locates the user via GPS, records points of interest and activities, determines when an activity is initiated or completed, and performs the response action, according to the information sent and received from the server. Server component contains predefined activities by the user; processes the semantic information of the activities, stored in an OWL file, to determine the risk level; and based on parameter values, selects the most appropriate non-intrusive policy to determine the action that PIANI should perform.

Fig. 2

PIANI architecture.

4.1 PIANI client

Client component is a mobile device with Android 4 or higher operating system, internet connection, wi-fi network, 3G or higher mobile system, and GPS sensor. It has four modules: GPS, Activity, Registry and Alert.

GPS Module obtains time and location data from the satellite: latitude and longitude of user current location, and time and date when information was obtained.

Activity Module assigns values to the attributes that characterize an activity: location, day of the week, time and duration. Additionally, this module determines whether an activity has initiated, finalized, or is in progress.

Registry Module locally records information required by the platform. During the user’s first sing in, this module asks the user for four types of data:

User’s personal data, such as name and phone number;

Information of the caregiver, i.e. the person who will be notified by the system in case of an emergency with user’s name and telephone number;

Points of interest data, i.e. locations where user performs his or her activities; recorded data includes the name of the location, a radio in meters (eligible between small, medium or large, corresponding 7, 20 and 50 meters), and the geographic position (latitude and longitude provided by the GPS module) of the current location; and

User activity data, such as the name of the activity, start and end times, days of the week and period of day (day or night) when activity is usually performed.

Alert Module waits for responses from the Inference Engine Module. When a response is received, it will perform the pertinent action selected from these options: a) if the activity has a low risk, notifies the user through a pop-up message; b) with an average risk, alerts the user with an alarm; and c) with a high risk, alerts the user and the caregiver.

4.2 PIANI server

From a technical point of view, PIANI’s server is an implementation of REST web services developed in Java and deployed in Apache Tomcat. This component has two modules: Knowledge Base and Inference Engine.

The Knowledge Base module stores in the server’s database the activity history with the information received from the Activity and the Registry Modules. Furthermore, it also manages the activity’s semantic information, users, caregivers and points of interest using an OWL ontology. The events of reading, writing, updating and deleting semantic information in the ontology are implemented through the OWL API library [23], which is a Java API for creating, manipulating and serializing OWL ontologies. Indeed, PIANI’s server allows to end-users retrieve all of their information just by sign in PIANI.

The Inference Engine Module receives information about the current activity from the Activity Module and asks the Base Knowledge Module for information on previously stored activities. The OWL inference engine employed is Pellet [24]: an OWL DL open source reasoner for Java. This engine compares the semantic information of the new activity with activity information provided by the Base of Knowledge Module. Classes, properties and values taken by each parameter of the ontology allow the Inference Engine Module to determine the level of risk. At the same time, ontology determines the action policy for caring to be performed, according to the level of activity risk, and send it to the Alert Module in order to be executed.

5 ONTO-AR ontology

PIANI uses the ONTO-AR ontology, and Fig. 3 shows its class diagram.

Fig. 3

Class Diagram of ONTO-AR.

5.1 ONTO-AR specification

Place class represents a location. Latitude and longitude attributes indicate a geographical location and must contain floating-point type values. It is optional that name attribute has some value. DaysOfTheWeek class represents a day of the week. Person class represents a person in the system, and contains String type attributes firstName and mobilePhoneNumber. In addition, String type attributes lastName and homePhoneNumber are optional.

User class represents to the user elderly adult, and Caregiver class represents to a caregiver; both are subclasses of Person class. User class inherits attributes from Person class and adds a Caregiver type attribute, attendedBy, which contains the caregiver information. Caregiver class also inherits attributes from Person class and adds User type attribute takeCareOf, which indicates who is the elderly adult attended, and String type attribute type, which can have two possible values: Relative or Physician, to indicate that the caregiver is an elderly adult relative or a medical doctor.

Activity class represents activities with four attributes that characterize PIANI’s activities: doneIn, a Place type attribute, indicates the location where the user performs the activity; doneOn, a DaysOfTheWeek type attribute, indicates the day of the week when the user performs the activity; itTook, an integer attribute, indicates the time in minutes the activity lasted; and performedAt, an integer type attribute, indicates the time when activity starts containing the amount of minutes between the start of the day and the current time. Additional attributes for activity class are: preferredTime, a String type attribute, indicates the period of day (Day or Night) when the activity is feasible; doneByUser, a User type attribute, indicates the user that performs the activity; name, a String type attribute, indicates the name of the activity; and riskLevel, a RiskLevel type attribute, indicates activity’s risk level.

RiskLevel class represents an activity risk level and it is mandatory that all its attributes contain a value. CaringActionPolicy type attribute named caringActionPolicy, indicates the action policy corresponding to a risk level; Boolean type attributes isItDoneOnDifferent, isItPerformedAtDifferent, isItTookDifferent and isItPreferredTimeDifferent, indicate if attributes location, time, duration and period of day have values that no correspond to usual activity of the elderly adult.

High, Medium and Low are RiskLevel subclasses and specify the type of risk level in an activity. CaringActionPolicy represents action policies to perform according to the risk level in an activity.

The CaringActionPolicy class represents the action policies to be performed according to the risk level of the activity. It is necessary that all its attributes contain a value. The RiskLevel type attribute isCaringActionPolicyOf indicates the risk level that corresponds to the application of the action policy; Boolean type attributes performPopUp, performRing, and performCall indicate whether or not to display a message, sound an alarm, and make a call, respectively.

Classes HighRiskPolicy, MediumRiskPolicy, and LowRiskPolicy are subclasses of CaringActionPolicy and represent the action policies applied when high, medium, and low risk is present, respectively.

5.2 Properties in ONTO-AR

Required properties for the ontology can be observed in Fig. 4. Data type properties are found in Fig. 3 as the attributes of the classes, whereas the object properties are the relationships between the classes.

Fig. 4

ONTO-AR’s object properties and data types.

5.3 Individuals in ONTO-AR

PIANI uses two types of individuals: those defined by the system and those defined by the user. Individuals defined by PIANI are those that are required to instantiate when the platform starts. These individuals (see Fig. 5) were created from the interface of [25] and generated a total of 21 individuals from 7 different classes.

Fig. 5

Individuals or instances defined by PIANI.

According to the risk level, a corresponding action policy will be performed. Three possible actions (popUp, alarm and emergency call) generate 3 individuals, one for each subclass of CaringActionPolicy as shown in Table 2.

Table 2

Individuals created from CaringActionPolicy superclass

Instance name	PopUp	Ringer	Call
LowRiskPolicy_1	yes	no	no
MediumRiskPolicy_1	yes	yes	no
HighRiskPolicy_1	yes	yes	yes

Regarding the days of the week, 7 individuals of DaysOfTheWeek class were created: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday and Sunday.

The risk of an activity is determined by the combination of variables that differ from the normal behavior of the elderly adult. For example, suppose that a user establishes as a normal or daily activity to go to the park on Saturdays at 10am (with preferred time in the morning) and with a duration of 60 minutes. Now suppose that the user goes to the park on a Saturday at 10am but stays there 90 minutes, that is, only the duration variable has an unusual value; Or for example, the user goes to the park on Saturday at 9am and remains 90 minutes; these abnormal behaviours involve different risks. Table 3 shows the different combinations to obtain the risk levels; for the former examples, the risks would be low and medium, respectively.

Table 3

PIANI’s instances for risk level policies. ✓ means that the value of the PIANI’s property matches current user activity and, therefore, the corresponding risk level. means that there is no match, thus increasing the risk level

Risk level	Weekday	Hour	Duration	Time
Low_1	✓	✓		✓
Low_2	✓		✓	✓
Medium_1	✓			✓
Medium_2		✓	✓	✓
Medium_3		✓		✓
Medium_4			✓	✓
High_1				✓
High_2	✓		✓
High_3	✓
High_4			✓
High_5

User-defined individuals (from Activity, Place, User and Caregiver classes) are created at PIANI’s runtime and the values of their attributes are explicitly assigned by the user through a mobile application (PIANI client) installed on the user’s smartphone.

6 Risk inference and action policy

Risk level inference is obtained by comparing the current activity with the activities that the elderly adult has previously defined.

Every 5 minutes, the GPS module will obtain new coordinates of elderly adult location, and this information will be used by the Activity module to obtain the values of place, day, hour and duration. The Server component, specifically the Inference Engine module, will receive these data and make a comparison with the information stored in the ontology.

The Inference Engine module, using the Pellet reasoner, uses the SPARQL query language to obtain the activities stored in the ontology that match the information provided by the Activity component. The queries are performed as in Fig. 6, repeating to select the activities filtering the time, duration and preferred time.

Fig. 6

SPARQL query to obtain user activities using a place and weekday as parameters.

After executing the queries, it is possible to know what variables of the current activity changed with respect to those selected in the ontology, and thanks to the SPARQL facilities, at the same time the actions to be performed are obtained (see Fig. 7). In summary, the process for obtaining the risk level and its respective actions is done with the following algorithm.

The Inference Engine receives the information of the activity that the user is currently performing.

Repeat the query of Fig. 6 for the variables: day, hour, duration and preferred time.

Filter the activities stored in the Knowledge Base.

Determine the activity most similar to the current activity.

Compare the current activity with the most similar activity, determine which variables (day, hour, duration and/or preferred time) change.

Perform the query of Fig. 7 with the values obtained in the previous step.

The combination of values will determine the level of risk.

The risk level will indicate what actions to take.

The server responds to the actions that the client must execute.

Fig. 7

SPARQL query to obtain the action to notify the user, whether to show him a popUp message, trigger the alarm or make a phone call to his caregiver.

7 Tests and results

The mobile application was installed on a smartphone Alcatel One Touch C7 7042A with Android 4.2.2, and Wi-Fi connection, 3G mobile data connection and GPS were activated.

The user provided the platform with different locations where activities are usually performed. Subsequently, the user established the activities performed in each location. As shown in Table 4, there were a total of 29 activities in 2 different places.

In this section, four case studies are presented, where PIANI is used to infer the risk of performing certain activities. These cases are classified in two types: Activities within the norm, i.e. those activities with normal values in the parameters of day, location, time and duration, that is, the activity matches with stored routine activity. Activities outside the norm, i.e. those where either place, hour, duration and the day of the week, do not match with stored values, and they represent unknown activities or activities that the user does not usually perform.

With the previous information, the user was asked to perform a series of controlled activities that were in and out of the norm, which are explained in the following subsections.

Table 4
ONTO-AR activities

ID Place Weekday Hour Duration Time

1 Home Monday 00:01 525 Night

2 Home Tuesday 00:01 525 Night

3 Home Wednesday 00:01 525 Night

4 Home Thursday 00:01 525 Night

5 Home Friday 00:01 525 Night

6 Home Monday 15:15 150 Day

7 Home Tuesday 15:15 150 Day

8 Home Wednesday 15:15 150 Day

9 Home Thursday 15:15 150 Day

10 Home Friday 15:15 150 Day

11 Home Monday 20:15 525 Night

12 Home Tuesday 20:15 525 Night

13 Home Wednesday 20:15 525 Night

14 Home Thursday 20:15 525 Night

15 Home Friday 20:15 525 Night

16 Home Saturday 00:01 525 Night

17 Library Monday 09:00 360 Day

18 Library Tuesday 09:00 360 Day

19 Library Wednesday 09:00 360 Day

20 Library Thursday 09:00 360 Day

21 Library Friday 09:00 360 Day

22 Library Saturday 09:00 240 Day

23 Library Monday 18:00 120 Day

24 Library Tuesday 18:00 120 Day

25 Library Wednesday 18:00 120 Day

26 Library Thursday 18:00 120 Day

27 Library Friday 18:00 120 Day

28 Home Saturday 13:15 645 Day

29 Home Sunday 00:01 1438 Night

ID	Place	Weekday	Hour	Duration	Time
1	Home	Monday	00:01	525	Night
2	Home	Tuesday	00:01	525	Night
3	Home	Wednesday	00:01	525	Night
4	Home	Thursday	00:01	525	Night
5	Home	Friday	00:01	525	Night
6	Home	Monday	15:15	150	Day
7	Home	Tuesday	15:15	150	Day
8	Home	Wednesday	15:15	150	Day
9	Home	Thursday	15:15	150	Day
10	Home	Friday	15:15	150	Day
11	Home	Monday	20:15	525	Night
12	Home	Tuesday	20:15	525	Night
13	Home	Wednesday	20:15	525	Night
14	Home	Thursday	20:15	525	Night
15	Home	Friday	20:15	525	Night
16	Home	Saturday	00:01	525	Night
17	Library	Monday	09:00	360	Day
18	Library	Tuesday	09:00	360	Day
19	Library	Wednesday	09:00	360	Day
20	Library	Thursday	09:00	360	Day
21	Library	Friday	09:00	360	Day
22	Library	Saturday	09:00	240	Day
23	Library	Monday	18:00	120	Day
24	Library	Tuesday	18:00	120	Day
25	Library	Wednesday	18:00	120	Day
26	Library	Thursday	18:00	120	Day
27	Library	Friday	18:00	120	Day
28	Home	Saturday	13:15	645	Day
29	Home	Sunday	00:01	1438	Night

7.1 Scenario 1: Activities within the norm (or usual activities)

The user was requested to perform 5 activities on Thursday normally (activities with IDs 4, 9, 14, 20, and 26, see Table 4). The first test was to perform activity with ID 4.

Results presented in Table 5 show that at all times the platform correctly inferred that the activity being performed was ID 4, and that all time at which it took place (from 00:01 to 08:45) there was no risk and no action was taken (Fig. 8). Similar results were obtained after performing activities with ID 20, ID 9, ID 26, and ID 14; results presented in Tables 6 –9, respectively, show that the platform correctly inferred the activity and did not detect some risk (Fig. 8).

Table 5
Results obtained from test 1 scenario 1

Duration PopUp Ringer Call Inferred activity

5-525 false false false 4

Duration	PopUp	Ringer	Call	Inferred activity
5-525	false	false	false	4

Table 6

Results obtained from test 2 scenario 1

Duration	PopUp	Ringer	Call	Inferred activity
5-360	false	false	false	20

Table 7

Results obtained from test 3 scenario 1

Duration	PopUp	Ringer	Call	Inferred activity
5-150	false	false	false	9

Table 8

Results obtained from test 4 scenario 1

Duration	PopUp	Ringer	Call	Inferred activity
5-120	false	false	false	26

Table 9

Results obtained from test 5 scenario 1

Duration	PopUp	Ringer	Call	Inferred activity
5-220	false	false	false	14

Fig. 8

PIANI User interface corresponding to a no-risk activity. PIANI takes no action.

7.2 Scenario 2: time and duration out of the norm

In this scenario, the user was requested to perform 2 activities usually performed on Friday (activities with ID 5 and ID 21, see Table 4) but modifying the duration and/or the start time, and consequently the system would have an activity that, actually, does not exist. For the first test, the user took 60 minutes more doing the activity ID 5 than normally it takes, i.e. activity lasted 585 minutes instead of 525. Table 10 shows that within the first 525 minutes the activity was considered as normal (Fig. 8), but at minute 530 a low risk was detected, so the user was notified with a message on his smartphone (Fig. 9).

Table 10
Results obtained from test 1 scenario 2

Duration PopUp Ringer Call Inferred activity

5-525 false false false 5

530 true false false 5

Duration	PopUp	Ringer	Call	Inferred activity
5-525	false	false	false	5
530	true	false	false	5

Fig. 9

PIANI user interface for an activity with low risk. Policy states that a pop up message should be presented asking if the user is fine.

Since in the previous test, the activity lasted more than usual, as second test, activity ID 21 began at 10:00 A.M. and its duration increased by one hour, that is, the activity lasted 420 Minutes in total. In this case, PIANI determined that activities ID 21 and ID 27 are similar when the duration is between 5 and 175 minutes and when the duration is exactly 420 minutes, see Table 11. In the same Table 11, the reader can observe that risk level of the activity was considered low from its beginning (Fig. 9) and such risk level was maintained until the activity duration reached 415 minutes. However, when the activity duration reached 420 minutes, its risk level increased to medium (Fig. 10).

Table 11

Results obtained from test 2 scenario 2

Duration	PopUp	Ringer	Call	Inferred activity
5-175	true	false	false	21, 27
180-415	true	false	false	21
420	true	true	false	21, 27

Fig. 10

PIANI user interface for an activity with medium risk. PIANI policy set a pop up text along with a sound alarm stopping until the user answers.

The last test case for this scenario consisted in asking the user being present at ‘HOME’ location, at 5:15 p.m. and remain there for 405 minutes. The inference engine determined that the activity performed was ID 10, having a low risk level from the beginning (Fig. 9), but after the minute 210, the risk level increased to medium level (Fig. 10), see Table 12.

Table 12

Results obtained from test 3 scenario 2

Duration	PopUp	Ringer	Call	Inferred activity
5-205	true	false	false	10
210-405	true	true	false	10

7.3 Scenario 3: Day of the week out of the norm

The purpose of this scenario is to evaluate the activity inference when activities are performed on a non-habitual day. Therefore, the user was requested to perform activities with IDs 4, 9, 14, 20, and 26 (see Table 4) on Saturday, and the rest of the activity parameters will not have changes. Performing activity ID 4 on Saturday coincides with activity ID 16. PIANI identified activity ID 16 and did not consider it risky (Fig. 8), see Table 13.

Table 13
Results obtained from test 1 scenario 3

Duration PopUp Ringer Call Inferred activity

5-525 false false false 16

Duration	PopUp	Ringer	Call	Inferred activity
5-525	false	false	false	16

As a second test, the activity ID 20 was performed. PIANI found in the ontology that there is an activity like ID 20 but on Saturday, that is the activity ID 22. The difference between these activities is the duration (ID 20 lasts 120 minutes longer than ID 22) and this was identified by PIANI, since the activity was considered safe for the first 240 minutes (Fig. 8), but after that, it was considered as a low risk activity (Fig. 9), see Table 14.

Table 14

Resuls obtained from test 2 scenario 3

Duration	PopUp	Ringer	Call	Inferred activity
5-240	false	false	false	22
245-360	true	false	false	22

For the third test in this scenario, the user performed Activity ID 9. The first 145 minutes the system inferred that the activity was ID 28 with a low risk level (Fig. 9); however, at the end of the activity, in minute 150, the system found that the activity could be ID 6, ID 7, ID 8, ID 9, or ID 10, and since the day of the week is non-habitual, the alarm went on because the activity risk was identified as medium (Fig. 10), see Table 15.

Table 15

Results obtained from test 3 scenario 3

Duration	PopUp	Ringer	Call	Inferred activity
5-145	true	false	false	28
150	true	true	false	6, 7, 8, 9, 10

The fourth and fifth tests (Tables 16 and 17, respectively) have similar results to those obtained in Test 3, that is, during the activity, PIANI found the most similar activity, and when the activity ended, PIANI managed to identify that the activity is one that already exists but is being performed on a different day.

Table 16

Results obtained from test 4 scenario 3

Duration	PopUp	Ringer	Call	Inferred activity
5-115	true	false	false	22
120	true	true	false	23, 24, 25, 26,
				27

Table 17

Results obtained from test 5 scenario 3

Duration	PopUp	Ringer	Call	Inferred activity
5-215	true	false	false	16
220	true	true	false	11, 12, 13, 14,
				15

7.4 Scenario 4. Activity out of the norm

The goal of test scenario number 4 is to evaluate the inference of activities that are completely different from those the user usually performs. Thus, the user was asked to go to ’Library’ location at 10:00 on Sunday and remain there for 420 minutes. Since it is an unknown activity, the platform was unable to identify this activity within those stored in the ontology, and assigned a medium risk level from the beginning (Fig. 10), see Table 18. At the end of the activity, PIANI made an emergency call and notified the user as the risk was promoted to high level (Fig. 11).

Table 18
Results from test 1 scenario 4

Duration PopUp Ringer Call Inferred activity

5-175 true true false 17-27

180-295 true true false 17-22

300-415 true true false 17-20

420 true true true 17-27

Duration	PopUp	Ringer	Call	Inferred activity
5-175	true	true	false	17-27
180-295	true	true	false	17-22
300-415	true	true	false	17-20
420	true	true	true	17-27

Fig. 11

PIANI’s user interface for a high risk activity. A pop up message, sound alarm, and phone call to the caregiver are triggered.

8 Conclusion

A Platform for Non-Intrusive Assistance (PIANI) has been developed with an ontological approach, which allows inferring the risk level of activities performed by elderly adults in their daily tasks. The use of the ontologies facilitated the identification of the activities and the inference of their risk, thanks to the semantics provided to our characterization of activity, risk, and related concepts. PIANI acted as expected in all test cases. Results obtained in the different tests of each of the 4 scenarios show that, PIANI satisfactorily identifies activity performed according to the norm, i.e. if the day of the week, time, duration and preferred time have values congruent to the normal routine of the elderly adult. Also, if the values of the four variables that characterize our definition of activity change (compared to stored values) PIANI finds in the ontology more than one possible activity. This result is explained by the fact that PIANI, using SPARQL statements, searches in the ontology for the most similar activity to the one currently being performed, and if it does not find an activity with four matching values, it will search for those activities with three matching values, etc. Naturally, the less values coincide, the greater the number of activities PIANI will encounter.

As future work, a study will develop an evaluation of PIANI’s inference engine performance as the number of users increases. Although the structure of our proposed ontology (classes, individuals and properties) is neither complicated nor numerous, we must ensure that an increment in number of users does not increase processing time and, consequently, time response by the server.

References

World Health Organization. Ageing and life-course. Facts about ageing. http://www.who.int/ageing/about/ facts/en/ (2014, accessed: 30 March 2017).

United Nations. Proyecto de declaracion de los derechos del adulto mayor. http://www.un.org/swaa2002/coverage/parlamentoS.htm (2002, accessed: 21 July 2017).

Comision Nacional de Derechos Humanos. Derechos de los Adultos Mayores. http://www.cndh.org.mx (2012, accessed: 21 July 2017).

AAL PROGRAMME ACTIVE AND ASSISTED LIVING PROGRAMME. ICT for ageing well. http://www.aal-europe.eu/our-projects/ (2016, accessed: 18 February 2017).

World Health Organization. Mental health and older adults. http://www.who.int/mediacentre/factsheets/fs381/en/ (2015, accessed: 18 February 2017).

World Health Organization. Ageing and life course. About ageing and life course. http://www.who.int/ageing/about/ageing_life_course/en/ (2012, accessed: 30 March 2017).

Hong

, Vincenzo

, Ning

, Chris

, Promises and Challenges of Ambient Assisted Living Systems, In: Sixth International Conference on Information Technology: New Generations, Las Vegas, NV, (2009), 1201–1207.

W3C. OWL Web Ontology Language Overview. https://www.w3.org/TR/owl-features/ (2004, accessed: 25 January 2017).

Family Safety Production. Seguimiento GPS. https://play.google.com/store/apps/details?id=com.fsp.android.c (Accessed: 15 January 2017).

10.

Motorola Mobility. Alerta Motorola. https://play.google.com/store/apps/details?id=com.motorola.bodyguard&hl=es_419 (Accessed: 4 May 2017).

11.

KidControl Dev. GPS Localizador familiar. https://play.google.com/store/apps/details?id=ru.kidcontrol.gpstracker (Accessed: 18 Feb 2017).

12.

Friend Locator Inc. Localizador de familia. https://play.google.com/store/apps/details?id=mg.locations.share (Accessed: 18 Feb 2017).

13.

FAMILO. Localizador Familiar & Chat. https://play.google.com/store/apps/details?id=net.familo.android (Accessed: 18 Feb 2017).

14.

Carrot Rocket Family Locator GeoZilla. https://play.google.com/store/apps/details?id=com.carrotrocket.geozilla (Accessed: 18 Feb 2017).

15.

Jose

, Fernando

H. B.G.

, Amaia

, Alday

and J. L. Teleassistance outdoor system for the elderly based on Android devices, In: 13th IEEE International Symposium on Signal Processing and Information Technology, Athens, (2013), pp. 9–14.

16.

Sergio

, Telmo

and Filipe

, Mobile web server for elderly people monitoring, In: IEEE International Symposium on Consumer Electronics, Vilamoura, (2008), pp. 1–4.

17.

Frank

, Justin

and Gary

, iWander: An Android application for dementia patients. In: Annual International Conference of the IEEE Engineering in Medicine and Biology Society., Buenos Aires, (2010), pp. 3875–3878.

18.

Ruben

, Alvaro

, Roberto

, Alejandro

, Victorian

and Angel

, Indoor Localization Based on Neural Networks for Non-dedicated ZigBee Networks in AAL, In: 10th International Work-Conference on Artificial Neural Networks, Salamanca, Spain, (2009), pp. 1113–1120.

19.

Stuart

, Peter

, John

, Jitendra

and Douglas

, Artificial Intelligence: A Modern Approach. Prentice-Hall, Inc., 3rd edition, December (2009).

20.

Ihn

, An ontology-based approach to ADL recognition in smart homes, Future Generation Computer Systems33 (2014), 32–41.

21.

Liming

and Chris

, Ontology-based activity recognition in intelligent pervasive environments, International Journal of Web Information Systems5 (2009), 410–430.

22.

Melchor

, Plataforma Inteligente para la Asistencia No-Intrusiva de Personas de la Tercera Edad que Realizan Actividades en Ambientes Externos, Tech. rep., Universidad Autónoma de Yucatán, Facultad de Matemáticas. (2015).

23.

OWL API. The OWL API. http://owlapi.sourceforge.net/ (accessed: 18 September 2017).

24.

Pellet. Pellet: An Open Source OWL DL reasoner for Java. http://clarkparsia.com/pellet/ (accessed: 18 September 2017).

25.

Protégé. A free, open-source ontology editor and framework for building intelligent systems. http://protege.stanford.edu/ (accessed: 24 March 2017).