Information Management for Telecaring Virtual Organizations › ws › files › 4377862 ›...

UvA-DARE is a service provided by the library of the University of Amsterdam (http://dare.uva.nl)

UvA-DARE (Digital Academic Repository)

Information management for telecaring virtual organizations

Guevara Masís, V.J.

Link to publication

Citation for published version (APA):Guevara Masís, V. J. (2007). Information management for telecaring virtual organizations.

General rightsIt is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s),other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons).

Disclaimer/Complaints regulationsIf you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, statingyour reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Askthe Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam,The Netherlands. You will be contacted as soon as possible.

Download date: 14 Jul 2020

https://dare.uva.nl/personal/pure/en/publications/information-management-for-telecaring-virtual-organizations(34589ca3-4fa4-4781-b366-7f6691c4a6c4).html

Information Management forTelecaring Virtual Organizations

The cover was designed by the author.

Copyright c© 2007 by Vıctor Guevara MasısAll rights reserved. No part of this publication may be reproduced or transmitted in any

form or by any means, electronic or mechanical, including photocopy, recording, or any

information storage and retrieval system, without written permission from the author.

658.4 Guevara Masıs, Vıctor JulioG939i Information Management for Telecaring Virtual

Organizations / Vıctor Julio Guevara Masıs.147 p. : 17 x 24 cmIncludes bibliographical references

ISBN 978-9977-12-976-1

1. Database Management. 2. Telecommunicationin medicine. 3 Mobile Agents (ComputerSoftware). I. Author II. Title.

Information Managementfor

Telecaring Virtual Organizations

ACADEMISCH PROEFSCHRIFT

ter verkrijging van de graad van doctoraan de Universiteit van Amsterdamop gezag van de Rector Magnificus

prof. dr. D.C. van den Boomten overstaan van een door het college voor promoties

ingestelde commissie,in het openbaar te verdedigen in de Aula der Universiteit

op vrijdag 19 oktober 2007, te 12:00 uur

door

Vıctor Julio Guevara Masıs

geboren te San Jose, Costa Rica.

Promotiecommissie

Promotor: Prof. dr. P. Adriaans

Co-promotor: Dr. H. Afsarmanesh

Overige leden: Prof. dr. L.M. Camarinha-MatosProf. dr. ir. F.C.A. GroenProf. dr. L.O. HertzbergerProf. dr. S.R. JonesProf. dr. B.R. Katzy

Faculteit der Natuurwetenschappen Wiskunde en Informatica

The research described in this thesis was partially supported by the European Com-mission under IST Project-27607 TeleCARE and the University of Amsterdam.

A mis padres, Luis y Haydee,

por ser mis amigos, mis confidentes,

pero sobre todo, mis maestros.

Contents

1 Introduction 11.1 Remote care for the elderly . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Telecaring framework . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 A base infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3 The emerging field’s challenges . . . . . . . . . . . . . . . . . . 51.1.4 Computer research challenges in telecaring . . . . . . . . . . . 6

1.2 Focus and scope of research . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 Research context . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Agent-based federated information management for telecaring 152.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Multi-agent systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Defining an agent . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2 Properties of agents . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3 Mobile agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4 Agent life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Information systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.1 Dimensions of information systems . . . . . . . . . . . . . . . . 252.3.2 Classification of information systems . . . . . . . . . . . . . . . 292.3.3 Federated information system . . . . . . . . . . . . . . . . . . . 30

2.4 Agent-based federated information system . . . . . . . . . . . . . . . . 322.4.1 Federated Information Management Server Agent . . . . . . . . 342.4.2 Agent Information Management System . . . . . . . . . . . . . 352.4.3 Information Access Manager . . . . . . . . . . . . . . . . . . . 362.4.4 Database repository . . . . . . . . . . . . . . . . . . . . . . . . 362.4.5 Mobile Information Retrieval Agent . . . . . . . . . . . . . . . 37

2.5 Federated query processing . . . . . . . . . . . . . . . . . . . . . . . . 372.5.1 Agent-based query processing . . . . . . . . . . . . . . . . . . . 382.5.2 Agent-based FQP components . . . . . . . . . . . . . . . . . . 392.5.3 Federated query language specification . . . . . . . . . . . . . . 41

i

ii CONTENTS

2.5.4 Federated query types . . . . . . . . . . . . . . . . . . . . . . . 442.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Ontology support for telecaring 493.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2.1 Definitions of ontology . . . . . . . . . . . . . . . . . . . . . . . 513.2.2 Ontology engineering definition . . . . . . . . . . . . . . . . . . 53

3.3 Ontology engineering in telecaring . . . . . . . . . . . . . . . . . . . . 563.3.1 Ontology design . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3.2 Ontology evolution . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.3 Data structure generation . . . . . . . . . . . . . . . . . . . . . 59

3.4 Automation of database schema generation . . . . . . . . . . . . . . . 613.4.1 From the object-oriented to the relational paradigm . . . . . . 613.4.2 Deployment of data structures . . . . . . . . . . . . . . . . . . 66

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 Agent-based service-oriented resource management for telecaring 694.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Telecaring resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.1 Agent-based resource management . . . . . . . . . . . . . . . . 714.3 Telecaring resource model . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.2 Advertisement and publishing . . . . . . . . . . . . . . . . . . . 754.3.3 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.3.4 Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.4 Collaboration among actors . . . . . . . . . . . . . . . . . . . . . . . . 804.4.1 Resource provider . . . . . . . . . . . . . . . . . . . . . . . . . 804.4.2 Resource broker . . . . . . . . . . . . . . . . . . . . . . . . . . 804.4.3 Resource requester . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.5 Agent-based resource brokerage . . . . . . . . . . . . . . . . . . . . . . 814.5.1 Catalogue repository . . . . . . . . . . . . . . . . . . . . . . . . 824.5.2 Brokerage functionality . . . . . . . . . . . . . . . . . . . . . . 824.5.3 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5 Tele-assistance platform and services of TeleCARE 855.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2 TeleCARE as a tele-assistance platform . . . . . . . . . . . . . . . . . 86

5.2.1 The TeleCARE multi-agent environment . . . . . . . . . . . . . 875.2.2 TeleCARE architecture . . . . . . . . . . . . . . . . . . . . . . 94

5.3 FIMA – Federated Information Management . . . . . . . . . . . . . . 1035.3.1 Object persistence . . . . . . . . . . . . . . . . . . . . . . . . . 1045.3.2 Log event management . . . . . . . . . . . . . . . . . . . . . . 1055.3.3 Federated query processing . . . . . . . . . . . . . . . . . . . . 106

CONTENTS iii

5.3.4 Structural design of internal subcomponents . . . . . . . . . . . 1085.4 DOSG – Dynamic Ontology-based data Structure Generation . . . . . 112

5.4.1 Relational database schema . . . . . . . . . . . . . . . . . . . . 1125.4.2 Java source code . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.4.4 Mapping definitions . . . . . . . . . . . . . . . . . . . . . . . . 1135.4.5 Structural design of internal subcomponents . . . . . . . . . . . 114

5.5 RCAM – Resource Catalogue Management . . . . . . . . . . . . . . . 1155.5.1 Resource description publishing . . . . . . . . . . . . . . . . . . 1155.5.2 Resource description discovery . . . . . . . . . . . . . . . . . . 1155.5.3 Resource access rights management . . . . . . . . . . . . . . . . 1165.5.4 Structural design of internal subcomponents . . . . . . . . . . . 116

5.6 Validation through TeleCARE Vertical Services . . . . . . . . . . . . . 1225.6.1 Virtual Community Support . . . . . . . . . . . . . . . . . . . 1225.6.2 Agenda Reminder . . . . . . . . . . . . . . . . . . . . . . . . . 1245.6.3 Life Status Monitoring . . . . . . . . . . . . . . . . . . . . . . . 125

5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6 Conclusion and future work 1276.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.2 Answers to the Research Questions . . . . . . . . . . . . . . . . . . . . 1276.3 Summary of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.4 Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Bibliography 133

Acknowledgements 145

Samenvatting 147

List of Abbreviations

5FP 5th Framework Programme.ACID Atomicity, Consistency, Isolation, and Durability.ACL Agent Communication Language.AIMS Agent Information Management System.API Application Programming Interface.ARMA Abstract Resource Manager Agent.CO-IM Cooperative Information Management.DAL TeleCARE Device Abstraction Level.DAML DARPA Agent Markup Language.DAML+OIL DAML Ontology Inference Layer.DBMS Database Management System.DDL Data Definition Language.DHCP Dynamic Host Configuration Protocol.DIMA TeleCARE Data Interface Mapping Access.DML Data Manipulation Language.DOSG Dynamic Ontology-based data Structure Generator.FDBS Federated Database System.FIMA Federated Information Management.FIMS Agent Federated Information Management Server Agent.FIPA Foundation for Intelligent Physical Agents.FK Foreign Key.FQP Federated Query Processing.GLIF GuideLine Interchange Format.GO Gene Ontology.GPS Global Positioning System.GUI Graphical User Interface.HL7 Health Level Seven.ICT Information and Communication Technologies.IG TeleCARE Interest Group.IPM TeleCARE Inter-Platform Mobility.IPSec IP Security Protocol.IST Information Society Technologies.JDO Java Data Objects.JNI Java Native Interface.

v

vi List of Abbreviations

MIRA Mobile Information Retrieval Agent.ODMG Object Data Management Group.OGSA Open Grid Services Architecture.OID Object Identifier.OKBC Open Knowledge Base Connectivity.OQL Object Query Language.OWL Web Ontology Language.OWL-S Semantic Markup for Web Services.PDA Personal Digital Assistant.PK Primary Key.RCAM Resource Catalogue Management.REMA REsource-Manager Agent.RMI Java Remote Method Invocation.RPC Remote Procedure Call.SDK Software Development Kit.SQL Structured Query Language.TAL TeleCARE Agent Locator.TLAD TeleCARE Agent Data.TLAID TeleCARE Logical Agent IDentifier.TLUD TeleCARE User Data.UI User Interface.UMTS Universal Mobile Telecommunications System.UPnP Universal Plug and Play.URL Uniform Resource Locator.UvA Universiteit van Amsterdam.VPN Virtual Private Network.WSDL Web Service Definition Language.WSDL-S Web Service Semantics.XML Extensible Markup Language.

Chapter 1

Introduction

There is a fast increase in the proportion of the elderly over the age of 60 to the totalpopulation in western countries. This is partially due to the general improvement inhealth care worldwide, by which the people have longer lives. In parallel to this fact,there is also a decrease in birth rate in several regions in the world. The proportionvariation in demography has resulted a number of tough challenges for governments,and has opened many opportunities for research as well as for investment by privatesector. By the middle of the 21st century, almost 40 percent of the European Union’spopulation will be older than 65 [1].

The population of elderly people represents a demographic force whose rapid in-crement in their proportion raises a simultaneous demand for new care and socialservices. The increasing demand for provision of new care services is becoming soprominent that it is projected to soon exceed what can be provided by the currentcare systems [2]. This creates an impact on a range of aspects, including social poli-cies, regional care networks, care provision, types of insurance, home-care systems,personal health systems, decision making systems for care providers, and ICT support.

1.1 Remote care for the elderly

The traditional approach to care provision has either resorted to supporting the elderlyat the house of a relative, or relocating them at specialized care centers. Thesesolutions however are gradually becoming far less feasible for the following reasons:

1. Shifting the burden of responsibility onto the relatives is becoming impractical,given the fact that more and more family members have to work to secure steadyincomes. Besides, with the rapid rise in the number of the elderly, relativelyfewer people are available to care for disabled and elderly in need of care.

2. Provision of enough care centers is costly and requires the relocation of the el-derly people often outside their home communities, in order to meet the growingneeds and to ensure that resources are distributed efficiently.

1

2 Chapter 1. Introduction

3. Many elderly people preserve enough robustness to stay at their own homes, asituation that is often preferable to them and better for their welfare.

After decades of delivering care in hospitals and care centers, the paradigm isshifting towards treating the elderly at the point of need, i.e. where the care is re-quired [3]. The relationship between elderly and the care providers is evolving fromface-to-face care to a broader, continuous, and remote care.

Although ICT definitely cannot provide the needed solution to all care problems ofthe elderly, it plays a fundamental role in the application of new remote and integratedservices for care professionals [4, 5]. For instance, progress in computer networks andubiquitous computing suggests the opportunity for more new care services, which canapply the remotely controlled hardware devices at elderly houses, and other customiz-able and adaptable software systems. Some advanced care services can support easyand ubiquitous access to heterogeneous data related to the elderly, comprehensivestatus monitoring, applying signal and image processing systems, proactive alert andalarm systems, context-aware reminding systems, and decision support systems thattogether can lead to significant benefits in the care sector for the elderly.

In several countries, some trial cases using ICT are now running to evaluate ifremote caring proves to be more effective and convenient for elderly and less costlyfor care providers [6–8]. A number of experiments have installed social alarm systems,mostly for people who live in rural areas. Such systems comprise a portable alarmtrigger and an alarm telephone that automatically dials a control center when thereis an emergency. Some other experiments attempt to provide advanced care servicesin care centers for the case of acute treatments (e.g. chronic diseases or terminalillnesses), and remote care services in the noncritical cases. In this way, the elderlywho, for different reasons, do not need to stay in a care center or in other specializedinstitutions, can receive care services in their own environment, possibly at home. It ischallenging however to properly distribute the care services, activities, and monitoringdevices in disparate geographical locations.

Although the idea of using new technologies, within different trial cases, to supportremote care provision for the elderly is not new and a number of focused initiativesare already underway, these initiatives cover specific areas and are carried out inde-pendently of each other. What is currently needed requires flexible means by whichtechnological advances can be linked together in a coordinated framework [9].

1.1.1 Telecaring framework

Figure 1.1 illustrates the distributed network envisaged for the telecaring framework,in which a variety of service providers and relatives of the elderly contribute to provideremote care assistance to a community of elderly. Since the assurance of the conditionand health of the elderly is essential, there is also a possibility to link delivery of lesssensitive primary care (clinical) services to this environment, for example to assisthealth professionals making a remote diagnosis [10]. The need for remote primaryhealth care as well as the liability of involved parties are subject to lengthy and opendebates which are outside the scope of this document.

1.1. Remote care for the elderly 3

ClinicalCenter

Healthcare/Hospital

Relatives(office)

Emergency(ambulance)

CareCenter

Virtual ShopSpecialist

doctor

PoliceStation

EntertainmentCenter

Elderly

People

Figure 1.1: Distributed scenario for a remote care for the elderly

A telecaring framework for elderly consists of a number of institutions such as carecenters, residential centers, health care organizations, social security institutions, etc.,and involves the cooperation of a variety of human actors, e.g. social assistants, careprofessionals, the elderly, and their relatives. If supported by computer networksand adequate supporting tools, the collaboration among the institutions may evolvetowards a long-term Virtual Organization (VO) [11, 12] and the various involved actorsbecome part of a Virtual Community (VC) [13, 14].

The number and variety of organizations involved in care of the elderly, such as carecenters, residential centers, health care institutions, hospitals, insurance companies,social security institutions, etc., can constitute a telecaring VO environment [15, 16],which is a promising way to facilitate a smooth interaction and collaboration amongthem. Through a VO, these organizations can collaborate and share resources andskills in an autonomous way, towards achieving specific common goals. To the outside,the VO represents a single entity with the behavior resulting from the collaborationof all member organizations. A large number of examples of VOs have being applied


to manufacturing [17], to service provision such as in the tourism industry [18], etc.Further to the organizations’ involvement in the telecaring VO, in another per-

spective, the care professionals, social care assistants, and other service providers, aswell as the elderly people and their relatives become part of a telecaring VC [16, 19].A VC provides human interaction based on computer networks, replacing the face-to-face communication with the virtual communication. VCs are being more andmore applied everyday to share knowledge, time, or experience among the associatedmembers of the community. VCs range from topical associations that help to keep intouch a group of individuals, to the professional VCs that provide consulting, allowcollaborative work, and help others to develop new areas of expertise [20].

1.1.2 A base infrastructure

Apart from setting up specific systems at remote locations to assist the elderly, remotecare requires a holistic design, and development of a supporting infrastructure for anadvanced telecaring framework. With different organizations participating in the VO,developing and providing different products and services at different locations, thereis a need for a base infrastructure to which all these developments can be pluggedand enabling their interoperability.

Clearly, the design of such an infrastructure is work should follow a detailed anal-ysis of its requirements, such as the one performed in [21]. The analysis report shalldetermine the requirements in terms of functionality for the elderly user, the care pro-fessional, and other actors in the environment. Based on the outcome of the analysisperformed in this area, the design of an overall infrastructure for a network-basedremote care support system for elderly faces the following key requirements.

• Given that the current elderly, on average, are particularly averse to and unfa-miliar with the potential of new and emerging information and communicationtechnologies, many difficulties arise in suggesting and encouraging take-up oftechnology by elderly. To facilitate the implantation of the telecaring system, anassessment of the ethical, socio-economic and organizational impacts of informa-tion society technologies on the elderly target group, as well as its implicationson the design of services by care professionals should be considered.

• A key functionality of the telecaring infrastructure is to comprise a platformand mechanisms supporting mobility of software, so that the service can beadapted specifically for the necessities of the elderly person at the point of need.Besides, it shall support connecting to a variety of devices, such as personalsensors, specialized PDAs, GPS apparatus, UMTS devices, etc., for differentremote services. The communication among the services involves either simpledata passing or complex exchange of real-world data (e.g. elderly’s personalinformation, diagnosis, sensored data, etc.).

• The telecaring infrastructure should allow authorized users to interface with thesystem. For example, personal care advisors should be able to access historical


data, and even suggest information to better supervise, prevent, or providetreatment at remote locations.

• The telecaring network includes sites which are geographically dispersed in aheterogeneous environment and have a high degree of autonomy. Therefore,the infrastructure making the infrastructure must be suitable for a platform-independent information management framework.

• Social institutions involved in remote care for the elderly require a secure net-worked environment to access distant monitoring services, because of the sen-sitive nature of the information exchanged in the care sector. Thus, the infras-tructure must support the secure transmissions among the system users.

• Assisting technologies should be evaluated, designed, adapted or developed,tested and integrated into the architecture of the telecaring infrastructure toguarantee the non-exclusion of elderly persons with perception deficits. Forexample, the needs of visually impaired and blind people are different, thus,typical graphical user interfaces (GUI) are completely insufficient and have tobe complemented or replaced by an audio user interface (AUI), and by a textualinterface for usage with a Braille display.

1.1.3 The emerging field’s challenges

A variety of needs for remote assistance have been so far observed and reported in theliterature [1, 22] that can be regarded as general guidelines for developing telecaringenviroments. The main suggestions include the following.

- The need to consider a high degree of security, privacy, and welfare of the elderlythrough the remote services targeted to help elderly and care professionals.

- The need to provide the best possible remote care to elderly in urban as well asrural areas under limited budget conditions.

- The need to improve the quality of life of the elderly, not only addressing pro-fessional care and supervision, but also their involvement in leisure and socialactivities and how to keep them from feeling lonely.

- The need to get the public authorities involved.

- The need to manage of huge amounts of care-related information and make itsecurely available and in a timely manner at the point of need.

- The need to respect the ethical and socio-organizational issues when developinga solution, with a balance between ensuring safety and privacy of the elderly.

- The need to preserve the independence of the elderly as much as possible.


1.1.4 Computer research challenges in telecaring

Development of an enabling base infrastructure as well as supporting services forremote telecaring with a generic architecture is not a straight forward “one-step”activity. Specially for the infrastructure, the conception, design, and building allneeded elements of such collaborative environment is an incremental and complexprocess. A process that involves many experts from a variety of disciplines whoshall work together, for a long period of time, with the general agreement to deliverintegrated set of services to the elderly that satisfies its requirements.

The requirements to take into account when developing base infrastructure fortelecaring differ based on their human or technological nature. On the human side,the needs focus on finding a solution to problems caused by aging, while on thetechnological side the requirements focus on how to organize and manage the servicesoffered to the elderly.

From the computer science point of view, proper support of a telecaring environ-ment needs the involvement of several areas, including: artificial intelligence, biomet-rics, databases, distributed computing, pervasive computing, transaction processing,human-machine interaction, among other areas. Furthermore, a telecaring environ-ment constitutes a number of components, including the hardware components (e.g.devices at home, computers at every site being the home of the elderly or at the carecenter, etc.) and software components (e.g. support services for the elderly and thesoftware infrastructure for services to run).

These issues need to be further clarified by future research in the field. It ispossible however to identify the following challenges.

Interoperability and knowledge sharing among different disciplines

The complexity and multidisciplinary nature of the telecaring framework demandinteraction, interoperability and knowledge sharing among the involved areas.

• Semantic and syntactic problems for integration and interoperation of care ser-vices, rendering independent designs and developments.

• Lack of proper terminology to optimize retrieval of information.

Adaptability of services to individual elderly

One of the well-recognized difficulties for the telecaring framework is that generalsolutions must be tailored and adapted to the individual’s needs and individual’senvironment. So far the developed solutions provide support only for the elderly withthe same specific needs, e.g. the panic button system for heart disease patients [23].Some required adaptations include the following:

• User-friendly interfaces for elderly. The interfaces however need to be cus-tomized to meet specific disabilities of the elderly, a key issue is to find theright balance between not being intrusive and monitoring daily activities of the


elderly. Furthermore these interfaces should support a large variety of users,who have different needs, and their distinct roles.

• Care services and their components should be able to adapt to specific environ-ments and elderly.

• Every elderly’s home in the network has different resources and characterization.The design of local and remote components (e.g. household devices and services)must adjust to these sites and adapt to characteristics found at each location.

• Unique certified credentials should be assigned to each component of a dis-tributed telecaring system. Interaction between components is performed onlyif allowed by the underlying identification and verification of the credentials, thusspecific authorization solutions should be adapted to verify the access rights.

• Telecaring services should be flexible enough to cope with the new market de-velopments, namely to facilitate the integration of future components.

Connecting and controlling devices through the network

Although a number of experiences of connecting devices (robots, video cameras, etc.)to a wide-area network for remote operation have been performed, some difficultiesstill remain as challenging issues:

• In domains such as telecaring, high levels of heterogeneity are expected in thesensorial and equipment richness of the remote places, which demands solutionsto guarantee the appropriate levels of flexibility and scalability.

• The emergence of mobile and ubiquitous computing raises the importance ofwireless connections where the actual connection to the network has to be re-duced to short periods, and its availability is not always guaranteed.

• General purpose wide-area networks such as Internet and wireless networksare characterized by long and variable time-delays and, in certain locations,suffer from low levels of availability, raising challenges in what concerns thereliability of the designed system. The dependence of telecaring services on thecharacteristics of the network should then be minimized as much as possible.

• The execution environments are potentially unstructured and uncertain whichmeans that it is difficult to cope with these environments by resorting to deter-ministically programmed services.

Infrastructure supporting telecaring network

Research into the remote care delivery needs to focus on building up a frameworkfor the elderly users, and their care professionals. An innovative approach is requiredwith a high degree of adaptability and flexibility for the design and development ofremote care services for the elderly. Important aspects to be considered for suchtelecaring infrastructure are the following:


• Service-oriented approach is needed for modeling, design, and development ofcare applications for the elderly.

• Since the telecaring framework involves a distributed network composed of het-erogeneous cooperating sites (e.g. service providers, homes, residences, etc.),every site requires a common layer through which to communicate and interop-erate with other sites in the network.

• Remote administration of care services and system components are needed toallow scalability in certain applications.

• A generic open and configurable infrastructure is needed for supporting plug-and-play of services. Furthermore, the infrastructure should be enable effectiveaccess to end-users of the equipments available at different places.

• From an exploitation point of view, service providers require techniques to rad-ically reduce the development time for complex services. When it comes to theindustry, rapid software development is crucial when developing and deployinga care service, since time to delivery can become the principal driver for success.

• Local and remote information management facilities are required to supportsecure data access to information generated by devices or sensors.

• The infrastructure has to guarantee the desired level of privacy of the membersand therefore provide mechanisms to ensure safe communications and flexibledefinition of visibility and access rights to the information and resources.

• Ideally, telecaring applications should have the ability to adjust their configura-tion and functionalities to fit new conditions. It should be possible to developdynamic components, having the new functionality, and deploy them for remoteexecution whenever needed, enabling real-time response with reduced depen-dency on network availability and its delays. For instance, mechanisms can beapplied to remotely update new functionality or replace the old functionalityat remote locations. As such, the communication between two nodes in thenetwork comprises two categories: (i) new functionality to send from one siteto another; and (ii) messages to send from a component in one site to anothercomponent in the second site.

• Granting access to the sensorial devices and other remote equipment, namelylocated in elderly homes, is required.

• A verifiable record of events on a site should be kept. Given the sensitivity ofthis application area,there must be a way to maintain log information generatedby the different components.

• Mapping legacy systems onto the planned infrastructure should be facilitated.

1.2. Focus and scope of research 9

Management and retrieval of data

A rich framework is required to cope with the needs for data brokerage, and retrievalof remote information. Some challenges to be considered here are the following:

• The software components have to able to adapt to a range of execution plat-forms, as systems are becoming increasingly heterogeneous.

• Mechanisms are required to allow transparent access to distributed informationaccording to the defined security and visibility rights rights.

• A way to provide adequate encapsulation and access control mechanisms tohandle diversity and autonomy is required.

• Data from different sources needs to be merged and integrated. It is necessaryto facilitate this, namely by employing common data definition, adapting (orconverting) information to different formats, or providing exchange methods.

• Mechanisms should provide support for knowledge extraction from data scat-tered on the network.

Technical requirements

Other technical requirements include the set-up of the communications and trans-mission of information, security and safety mechanisms, provision of access rightsto specific resources, the interaction between computational services (hardware andsoftware) and humans, and so on.

1.2 Focus and scope of research

The above challenges represent a new frontier for research, one to which this thesisintends to make a contribution. Covering all requirements for telecaring is clearlyoutside our scope, and we focus solely on providing a new perspective to informationmanagement of telecaring services. The aim is thus to develop an information man-agement that ensures the preservation of needed levels of autonomy and privacy, andallows care service interoperation by information sharing.

The overall goal of designing a configurable framework tele-supervision and tele-assistance for the elderly is raised in this thesis. This telecaring framework leads to anarchitecture that yields a horizontal infrastructure, harnessing the power and potentialof new and emerging information, communication and networking technologies, toserve as the base for gradual development of pluggable, adaptable and context-awarevertical services. The proposed approach addresses a number of characteristics tooptimize the administration and maintenance support of the telecaring system, withregards to the information sharing and coordination of care services.

The problem area of the thesis focuses on the conceptual approach to provide andimprove remote care for the elderly based on a flexible platform, with a clear em-phasis on the “information management” and less on the “communication” support.


Nevertheless, the thesis does not address all the challenges involved in supportinginformation management, rather it primarily focuses on the following main aspects.

• The need for proper distributed management of information, that ensures rele-vant information is ready and available when and where it is needed, allowingsecure and authorized access.

• The need to define meta-data (schemas) of the data structures handled by tele-caring services. The schemas define the structure of the information within adatabase repository; automating their creation clearly eases the development ofcare services and enables rapid prototyping.

• The requirement of enabling the composition of care services that access of re-mote sensors and devices, i.e. remote data sources, that eventually will improvethe quality and availability of care services.

• The need for support infrastructures that guarantee the privacy of the VOmembers and provide mechanisms to define visibility and access rights to theinformation and resources.

This thesis deals with the design of an information management system to sup-port the base infrastructure of a VO for telecaring of elderly people. Essentially, wesuggest establishing an agent-based federated information management focused on adynamic and open architecture, based on a combination of theoretical and empiricalwork. In terms of design and implementation, we embrace emerging technologies andparadigms, including (i) federated database mechanisms, which support secure in-formation visibility levels, information sharing over heterogeneous data sources, andevidently, federated query processing; (ii) multi-agent systems, including both sta-tionary and mobile agents; (iii) semantic conceptualizations, based on a developmentof an ontology methodology and automation of data structure generation, and (iv)service-oriented architectures, which offer a flexible modular development.

The result of this work contributes to meet the needs of the next generation ofuser-friendly, dependable, cost-effective, and interoperable services for the growingpopulation of the elderly.

1.3 Research methodology

The research methodology adopted in this work comprises a variety of theoretical,and a combination of non-empirical and empirical work [24]. These have been thedominating approaches in the domain of information systems [25]. The combina-tion seemed suitable for this work since the theoretical and non-empirical approachesprovided us with the formulation of the research goal while the empirical approachensured that our ideas are applicable in the industry. From the research context, weobtain the theoretical part of our research in order to formulate some preliminaryideas and results, in non-empirical research, focused on the design and construction

1.3. Research methodology 11

Results

Assessment

Results

Assessment

ResearchProblemDefinition

ResearchProblemDefinition

Validation of

Solution

Validation of

SolutionProposed

Approach

Proposed

ApproachLiterature

Review

Literature

Review

1 2 3 4 5

Study of telecare

domain and

formulation of

research goal

Literature

assessment in

related fields and,

seek for solutions

Design and

development of the

information

management system

and related tools

The proposed

solutions is validated

for implementability

and adequacy against

real life scenarios

Analysis of

research results

and possible

contributions

Figure 1.2: Research methodology

of the information management system. The laboratory and field experiments, usingreal scenario cases, are based on techniques applied to the empirical research.

An overview of the research phases is illustrated in Figure 1.2. Some of thesemethodology phases are repeated a number of times since their feedback influencesour research and some points are then reconsidered. The research methodology issummarized as follows:

1. Research problem definition. The initial step-in of our research methodologycomprises both the preliminary study of problems of the telecaring field, re-garding information management, and formulation of the preliminary researchgoal. It is motivated by the exploration of facilities and advanced mechanismsto tackle practical problems of information management in telecaring. This re-search aims to respond to the main research problem, found in Section 1.4, byanswering the six sets of research questions.

2. Literature review and related research. The second step is concerned with anextensive literature assessment to search for and investigate similar problems incorresponding telecaring domain and information systems.

3. Designing and enhancing the proposed approach. This step involves activitiesthat aim at the design of both the agent-based information management systemand the required supporting tools. The modeling of the information manage-ment components begins after the requirements analysis of the telecaring needs.We use the analysis of requirements described in [21] to ensure consistent, robustand implementable research ideas.

4. Validation of the proposed solution. The validation of the proposed approachis two-fold. First, the implementability of the suggested components is demon-strated by software development and programming of an experimental proto-type. The prototype system will support the information interoperability amongsub-systems while providing access to remote data from several nodes and sup-porting different types of queries, as stated in the requirements. Second, theexperimental prototype aims to validate the adequacy of the research work to


industrial cases. For this purpose, a number of care services for the elderly,focused on the tele-assistance, will be used as example.

5. Assessment and research results. After all iterations of the other phases theresearch methodology have been performed, the assessment of the results isperformed. It includes how the users benefit from the suggested functionalityand the analysis of the answers to the research questions.

1.3.1 Research context

The ideas for the work presented in this thesis are based on the literature, the author’sindustrial experience on information management, and the research and developmenton European and Dutch funded projects. In addition, the author participated indifferent research initiatives as a member of the Cooperative Information Management(CO-IM) Group [26] of the University of Amsterdam (UvA).

Due to the multi-disciplinary nature of the work, the spectrum of literature thatis relevant is very wide. We made use of a limited key literature references whose con-text and aspects have strong implications for the conceptions of our ideas, also takinginto account the constraints of time and scope. The key literature is then confinedto Federated Information Management, Collaborative Networked Environments, andService-Oriented Architectures,and the Agents Paradigm. Based on these studies,some results were developed, which include an approach for agent-based informationmanagement in a federation of sites, an approximation for an ontology-based sup-port in the telecaring domain, and the implementation of a service catalogue usingagents. Business and industrial case scenarios are considered to validate and refinethese preliminary results. The results obtained by this research are disseminated inpublications of international conferences and journals.

The IST 5FP TeleCARE project provides the main context for the research workpresented in this thesis. The TeleCARE project aimed at the design and devel-opment of a configurable framework solution that focuses on tele-supervision andtele-assistance for support of the elderly. The project is funded in part by the ISTprogram of the European Commission and it is complementary to other initiatives forthe integration of elderly in the society, while reducing their isolation. The TeleCAREproject investigates on an extendable infrastructure so different care developments forthe elderly may be easily plugged, enabling the interoperability in this sector. See [22]for more information.

1.4 Research questions

The work presented in this thesis concentrates on supporting the federated infor-mation management in a VO, particularly focused on telecaring, and using the agentparadigm. Specifically, the research goal for this thesis has been formulated as follows:

“The analysis, design and development of an agent-based federated infor-mation management system, and other generic and reusable solutions, to

1.5. Thesis outline 13

properly handle the information generated by heterogeneous sources, whichare specifically conceived to support telecaring services and related appli-cations for the elderly.”

To achieve our proposed research goal, we state six sets of questions that addressthe concept of federated information management as well as the agent-based mecha-nisms to support telecaring services. The set of research questions are the following:

RQ1 Is it possible to implement an information management system with agents?What is a suitable architecture for integrating agent-based solutions into infor-mation management processes? What are the relevant benefits from developingthis architecture for telecaring application services?

RQ2 Based on the current trends of agent technology, can we design a componentable to cope with local and remote care information while preserving autonomyof each location? How can this component support the information handlingand the query processing from both lower-level devices and high-level telecaringservices? Can we design a component that is easy to maintain and upgrade?

RQ3 How can we model different aspects of the information regarding the base plat-form and the telecaring services? Is it possible to provide a flexible and ex-tendible mechanism that is open for adding new entities or types of information?

RQ4 Can the functionality of care devices and telecaring applications be modeledin terms of agent interactions? What are the kinds of interactions involvedbetween those agents? How can any agent determine or find another agent (orfunctionality) in the collaborative network?

RQ5 Is it possible to illustrate, explore and partially validate the suggested approachon the basis of simple scenarios? Can we make field experiments and validatethe usability of a prototype?

RQ6 Is the proposed agent-based approach for federated information managementsuitable only for telecaring VOs? What are the minimum conditions of applica-bility for providing the same approach in another VO? In other words, can thesuggested solution be generalized?

1.5 Thesis outline

The rest of the thesis is structured as follows:

Chapter 2 presents the design used for developing the information managementsystem of a base infrastructure for telecaring based on the agent paradigm.

Chapter 3 addresses the generation of data structures within the telecaring network,using a generic framework based on ontology definitions.


Chapter 4 presents the agent-based design of the service-oriented architecture usedfor development and management of the telecaring services.

Chapter 5 validates the designed approach by implementing the components in thecontext of the TeleCARE project, with the use of real life scenarios and tele-caring applications. It further discusses the strengths and limitations of thefollowed approach.

Chapter 6 summarizes the feedback from the case studies and evaluates the overallresearch work presented in the thesis. In this chapter the answers to the researchquestions are evaluated, and we discuss the future directions for this work.

Chapter 2

Agent-based federatedinformation management fortelecaring

2.1 Introduction

Advanced care services for the elderly are needed both in rural and urban areas.Telecaring is a new paradigm that extends the availability of current care servicesto the point where they are needed. Telecaring becomes suitable for the care of theelderly by supporting their independent living, while enhancing the quality of dailyassistance. Clearly, most elderly prefer to stay at home rather than being relocatedto a care center, a residential centers, or another institution.

Telecaring enhances also the quality of care. Tele-assistance and tele-monitoringare possible at a continuous base at home, an environment without stress for theelderly. This approach reduces the necessary number of home visits by professionalcare-givers and minimizes the traveling of the elderly and their relatives to the spe-cialized care centers.

Integration of telecaring with other advanced care services provides a way to im-prove the general quality of life. To deal with this integration however new ways ofproviding assistance and care, recurring to technological support, must be found [21].Before all else, an infrastructure supporting these new services has to be establishedto provide a base framework for integrated care.

A considerable number of challenges are involved in designing a telecaring infras-tructure to deliver broader assistance and care to elderly, who are normally excludedfrom such support. On the other hand, the growing number of technologies althoughenabling the implementation of new services, it makes the design of such infrastruc-ture even tougher. New hardware and software appliances (sensorial devices, homeappliances, wireless devices, etc.) are being produced in isolation with lack of mech-anisms for interoperation among them. Advanced services that access and operate

15

16 Chapter 2. Agent-based federated information management for telecaring

remote care appliances usually require a number of functionalities found in severalproducts rather than on a single one. Additionally, the secure transfer, safety, avail-ability, and privacy of the information exchanged within the infrastructure should beassured while still allowing collaboration.

For the implementation of advanced and integrated care services, a number oforganizations, such as care centers, day centers, health care institutions, social securityinstitutions, etc. shall work in a coordinated and collaborative way, thus constitutinga kind of Virtual Organization (VO), which implies joint collaboration among healthcare professionals, social care assistants, elderly people, their relatives, etc. Thus, atelecaring support infrastructure plays a crucial role in assisting collaboration, whilekeeping autonomy and independence of the involved parties. Considering the level ofautonomy, independence, and physical distribution of each partner in such integratedcare system, a main difficulty is the provision of mechanisms for the organization,administration, and retrieval of shared information. These mechanisms are expectedto provide access to remote and heterogeneous data, while preserving the establishedaccess rights. Therefore, a suitable information system managing the data within theinfrastructure is required.

From the information management point of view, the design of an infrastructure fora VO devoted to advanced care services is similar to the one of a distributed databaseenvironment. In both cases, data are spread over several autonomous locations, localschemas covering only parts of the entire shared data set, and each site maintainingcertain degree of autonomy. As indicated in Table 2.1, the necessary infrastructurerequires, however, a more flexible information framework such as the one of federatedinformation systems [27, 28].

A federated information system is certainly not the only solution to all data man-agement related problems and requirements for the infrastructure. The research goalinvestigated in this thesis is that combining the information federation paradigm witha A Multi-Agent System (MAS) will offer great potential benefits to cope with the re-quirements of this distributed environment. Moving functionality to locations whereactions are required, for instance, enables real-time response, autonomy and conti-nuity of care service provision, while reducing the consequences of network delays,latencies, and limitations of network availability.

This chapter provides answers to the RQ2 introduced in Chapter 1. It aims at thedesign of an agent-based federated information management system that can supportadvanced care applications. Section 2.2 introduces the main concepts related to theagent and mobile agent paradigm. Section 2.3 regards to information systems andparticularly to the federated information systems. Section 2.4 describes the maincomponents of an information management system to support and facilitate the in-formation sharing in the distributed care environment. Section 2.5 focuses on thefederated query processing and provides details on the strategies to support remoteservices. Finally, Section 2.6 provides the conclusions of the chapter.

2.2. Multi-agent systems 17

Transparency The infrastructure requires masking from a VO partner institution the

differences, idiosyncrasies, and implementations of its underlying data

sources. This allows advanced care services to be written as if all the

data are in a single logical database, although, in fact, the data may

be stored in a heterogeneous collection of data sources.

Support

heterogeneity

The infrastructure must have the ability to accommodate a broad range

of data sources, without restriction of hardware, software, data model,

interface, or protocols.

High

degree of

functionality

The infrastructure must provide to the VO partner, not only homoge-

neous database access against all the data in the network, but also the

ability to exploit functions and data from remote data sources that the

local site may lack.

Extensibility The infrastructure should have the ability to add new data sources

dynamically in order to meet the changing needs of the care industry.

Openness It is important for the infrastructure to support the appropriate stan-

dards in order to ensure that the advanced care services can be extended

with standard-compliant components.

Autonomy Joining the collaboration should not compromise the autonomy of indi-

vidual data sources. Every VO partner autonomously establishes which

part of the local data is shareable, and existing applications should, as

far as possible, run unchanged (with data neither moved or modified).

Optimization of

remote queries

The infrastructure should provide means that’support query optimiza-

tion. When a query spans to multiple data sources, the VO partner

could make proper decisions about how to execute it, so that the query

is not costly in terms of resources or performance.

Table 2.1: Information management requirements for a telecaring infrastructure

2.2 Multi-agent systems

The research on Multi-Agent Systems is part of the area of distributed artificial intel-ligence. It concentrates on intelligent behavior among autonomous pieces of softwarecomponents, including their development, coordination, management, etc. It aims todefine and establish mechanisms that allow those components to structure and sharetheir capabilities and knowledge in order to reach their individual and common goals.A MAS can be defined as “a loosely-coupled network of problem solvers that worktogether to solve problems that are beyond their individual capabilities” [29].

2.2.1 Defining an agent

Although there is no general agreement on the definition of the term agent, since thereis an ongoing debate on it, many researchers generally consent that for a software pro-gram to be called an agent, it must exist in a dynamic and partially unpredictable


environment and must embody the notion of autonomy, among other characteris-tics [30–32]. A bare definition of an agent is to consider it as a software component,which can sense the environment in which it is existing, through sensors, and act uponit, over time, to achieve some goals. This aspect of acting can be proactive or reactiveand based on a set of rules. When machine learning mechanisms are employed, anagent can discover autonomously new rules. When enabling knowledge and reasoningmechanisms, it can be considered that the agent has intelligent behavior and is ableto decide for itself to satisfy its goals [33, 34].

The goals and objectives of the agents can be established either by a human useror by another agent. This leads respectively to an end-user perception or a systemperception of agent [35]. Table 2.2 presents a summary of agent characteristics basedon this notion and its dimensions.

Agent (End-user perspective)An agent is a computer program that assists people and acts on their behalf. Agents

function by allowing people to delegate work on them. The environment that provides

certain basic services and support for the life cycle of the agents is generally referred to as

agent platform. Such platforms provide a medium for communication and goal-oriented

collaboration among agents.

Agent (System perspective)An agent is an active entity, a software object that acts continuously in pursuit of estab-lished goals. There are various attributes associated to this concept of agent:

• Agents hold the following common attributes:- Reactive: able to sense changes and to react to them in a timely fashion- Goal-driven: to be proactive by taking initiatives to satisfy their design goals- Autonomous: to have control over their own actions- Temporally continuous: to continuously execute

• Agents may feature the following orthogonal properties:- Communicative: able to communicate and collaborate with other agents- Believable: to appear credible to the end-user- Mobile: to migrate from one environment to another

• Agents are capable of intelligent and autonomous action. Nevertheless, not allagents are intelligent. The notion of intelligence is here linked to four aspects:

- Reactive,- Goal-driven (proactive),- Learn, reason, and able to adapt in accordance with previous experiences- Social ability, able to interact with other agents (and possibly humans)

Table 2.2: Perspectives of agents


2.2.2 Properties of agents

The following paragraphs list several of the most relevant properties that are com-monly associated with agents [32, 33]. Clearly, since the properties vary according tothe definition of agent (and there is no general agreement of it), not all of them maybe found in every particular agent.

• Autonomy. Agents can operate under their own rules and goals without directinterference of others. They possess control over their own actions.

• Communicative. Agents are capable of interacting with other entities (agentsand humans) in order to satisfy their objectives. At the same time, agentsencompass the notion of machine-machine collaboration, where the negotiationand communication may be based on a semantic level, allowing agents to bettercoordinate their tasks and use of resources.

• Flexibility. Through learning, agents can cope with constant evolution. Theyhave the ability to self-adapt to changes in their environment, usually takinginto account previous experiences.

• Identity. Agents have usually a specific identity which enables them to con-tain a believable ‘personality’. Agents can be representatives of humans (ororganizations), or present themselves as autonomous entities to the user.

• Intelligence. Agents may exhibit some form of intelligence that allows themto learn in certain situations. This is manifested by the ability to adapt itsbehavior for better planning and decision-making. In addition, learning can beused by agents in several other dimensions, such as learning user preferences,negotiation strategies, adaptation processes, etc.

• Mobility. The agent paradigm can support mobility at different levels.

– User mobility refers to specific techniques to allow an agent to relocate auser profile within the network.

– Device mobility relates to connecting devices into different environments.Agents may help adapting these devices into diverse platforms.

– Code mobility is either characterized by weak mobility or strong mobility.

- Weak mobility indicates that the code of the agent is deployed onanother machine with an initial state. A Java applet or downloading anew version of software can be considered as examples of weak mobility.

- Strong mobility is depicted as the complete migration of both code andexecution state into another machine.

The mobility is however a property that not all agents possess. Some ofthem are stationary agents and exclusively bound to a specific location.Since mobility of code is relevant for remote delivery of services, it is furtheraddressed in the next section.


• Proactive. Besides responding to changes in the environment (as purely reactiveentities), agents also exhibit goal-oriented behavior. Thus, agents can take theinitiative during their operation and become goal-driven entities.

• Reactive. Agents are able to perceive ever changing environmental conditionsand respond to them in a timely fashion.

• Reusability. Agents can be applied to build new, and possibly, larger systems.Through composition of agents, developers are able to create complex systemsbased on functionality provided by smaller and cooperating agents.

2.2.3 Mobile agents

Agents whose predominant characteristic is the ability to migrate between platforms,and sites across a network, are generally classified as mobile agents. Mobile agents aredefined as pieces of computer software that are able to start a computation on a site,suspend the execution of the computation arbitrarily at some point, autonomouslymigrate from one computer to another in a network, and resume or continue theexecution on the destination computer [35–37].

Mobile agents have emerged as a paradigm for structuring distributed applicationsand are commonly considered by researchers as the evolution of traditional client-server paradigms [38, 39]. In the client-server model [40, 41], the roles and actions ofthe communication participants are fixed and well-defined. Generally speaking, user-interface functionality and front-end tools (forms, report writers, GUIs, etc.) arehandled by client systems, while the server systems, through back-end tools, manageaccess to data, devices, resources, or offer other processing services. Mobile agents arestand-alone, executable software, which are being sent to different computers (servers)to carry out specific computational tasks.

Client-server model

The client-server paradigm implies the subordination of clients to a server, i.e. clientsentities depend upon the server entity for the fulfillment of their goals. The interfacebetween a client and a server is maintained through a front-end, established by theclient application, a specific message passing protocols (like SQL for instance) for thecommunication link, and a back-end provided by the server application program.

Depending on the message passing protocol, clients must find the network addressand synchronization point with the server. This discovery process makes difficult theapplication development (too low level). Remote Procedure Call (RPC) architectures,such as the Java Remote Method Invocation (RMI), attempt to alleviate the devel-oper from the hassle of dealing with low level network details. Basically, a RPC clientrequests a service to be executed on a server as it would perform a local functioncall, as shown in Figure 2.1. Other more advanced client-server models, such as theCommon Object Request Broker Architecture (CORBA) [42], make the client-serverparadigm more accessible by adopting the object-oriented principles of object reuse,inheritance, encapsulation, and some other security and authentication facilities to


achieve a higher level of abstraction. Essentially, the separation of interface fromimplementation enables each server object to be defined as a proxy. Thus, the im-plementation of the server object is hidden from the rest of the system behind thisproxy, which acts as a broker or ambassador to the client.

Client Server

Front-end Back-end

RPC

service calls

Network

Figure 2.1: RPC client-server paradigm

A challenging problem with client-server architectures is the general assumptionof network and resource availability. If the server does not provide the exact servicethat the client requires or, it is not available, for example, then the client has toreconfigure itself to use a different server interface.

Another network concern involves the successive series of remote calls that may beneeded, from the client, to obtain a final result in a complex process. A concern thatgenerates several other inefficiencies: (a) network latency increase, (b) control databeing transmitted across the network, which might be costly and inefficient, especiallyfor large amounts of information, and (c) dependance on network availability.

There are some techniques and strategies to overcome some of the above problems.Employing the technique of subprograming, clients launch subprograms (weak migra-tion) at the remote site where the service is located [43], thus, avoiding some networklatencies. Weak migration, however, usually leads to objects that are no longer notreachable to the client. Additionally, subprograms cannot move subsequently to othersystems. Another technique to optimize data transfers is to take advantage of buffersto cache requests from clients, however, it increases the resources to be taken intoaccount as clients request different kinds of information. Thus, the reusability of thebuffer is minimized.

Mobile agent model

Mobile agents, based on strong migration, have emerged as a paradigm for structuringdistributed applications. The agent mobility is a topic of active research and its vari-ety of aspects are still under study, namely, communication between mobile entities,languages to express mobility, resource management, and security infrastructure formobile code, among others.

Mobile agents are not bound to the environment where they begin execution,


and are capable to travel actively (i.e. they can choose when to migrate). A mobileagent travels with its code and current state to the destination platform, where it isreconstructed and its execution resumed. Platforms however can also dispatch themobile agent, and it may happen that the agent does not know it has migrated.

In Figure 2.2, a mobile agent migrates from the original front-end site to the back-end site, where the resource resides. There, the mobile agent executes the service callsat local level, no longer depending on the network to fulfill its goal.

Client Server

Front-end Back-end

Service calls

AgentAgent

Mobile agent

Network

Agent migration

Figure 2.2: Mobile agent migration

Code mobility attributes

The strong mobility mechanism has significant attributes that are important for mo-bile agents [35, 38]. Although the mobile agent paradigm seems to be an interestingapproach by itself, the following attributes increase its potential for implementingdistributed applications in a computer network.

Network efficiency. Assuming that mobile agents are smaller than the raw data tobe transmitted, they are useful when it comes to reducing the flow of data inthe network. They can reduce the network load when, for example, very largevolumes of data are processed locally rather than transferred over the network,because of agent migration. Besides, an agent can preprocess data and thendecide over the final result to transmit. The reduction of network traffic is adecisive issue when considering low bandwidth connections.

From another perspective, if an agent moves across the network to the locationwhere resources reside, it can overcome network latencies. Networked systemsoften depend on communication protocols, security measures, or gateway sitesthat involve multiple interactions to perform a given activity. These interactionsinvolve significant latencies, which can be critical in real-time systems. Themobile agent, once dispatched from the original site, can interact locally withthe server resources avoiding some network overhead.

Autonomy of the sender. After being transferred, the mobile agent turns into anindependent process of the original site that launched it. It is not longer af-


fected if the sender site fails, and it can reconnect at a later time in order tofulfill its duty. In addition, the mobile agent may operate asynchronously andautonomously, so it does not require resources from the sender site.

Peer-to-peer agents. Peer-to-peer (P2P) networks are usually denoted by the re-sources available at the client sites that compose them rather than those foundat the server side. P2P networks are mainly used for sharing resources, comput-ing cycles, or as a platform for collaborative tasks. Mobile agents are consideredto be P2P components, in the sense that they can assume the role of a clientwhen interacting with a resource, however, when another mobile agent queriesit, then it becomes a server. This allows greater flexibility to reach the optimalconfiguration for solving a particular problem.

Robustness and fault-tolerance. The ability of mobile agents to react dynami-cally to unfavorable situations and events makes it easier to build robust andfault-tolerant distributed systems. If a platform is being shut down, for in-stance, all agents executing on that machine are warned and can be dispatchedto continue their operation on another platform.

2.2.4 Agent life cycle

The agent life cycle describes the different execution states of an agent and the eventsthat cause going from one state to another. The most prominent life cycle models arethe persistent process model, the task based model, and the event model.

Persistent process model

In the persistent process model (see Figure 2.3), the agent begins with a ‘start ’ state.The state becomes ‘running ’, when a persistent process is executed by the agent. The‘death’ state represents the stage when the process of the agent is terminated.

Resume

Frozen

Start Running Death

Suspend

Figure 2.3: Agent life cycle, the persistent process model

Before a mobile agent is transmitted from one environment to another, the agentexecution is first suspended. While the agent is suspended, its state remains as‘frozen’. Once the agent is sent to the target location and its execution resumes, thenits state becomes ‘running ’ again.


This kind of life cycle is simple and highly flexible. Other life cycle models arebuilt on top of this model [37, 44].

Task model

The task based model (see Figure 2.4) specifies a life cycle of an agent by describing anetwork of tasks and conditions. Each state of the agent is identified as a task, whilethe events leading to a change are identified as conditions. Similarly to the previousmodel, an agent begins with a ‘start ’ state. The current state becomes different,however, depending on the established set of conditions.

Condition 1

Task 2

Start Task 1 Death

Task 3

Conditio

n 2

Condition 3

Con

ditio

n 4

Con

ditio

n 5

Figure 2.4: Agent life cycle, the task model

Event model

In the event model, an agent basically responds to various events in form of movingrequests, communication requests, and cloning requests [35]. Figure 2.5 depicts themain stages of this model.

There are seven fundamental life cycle-related operations:

• Create. An agent is created within a valid environment and, upon creation, it isinitialized. During the initialization the thread of execution of the agent begins.

• Clone. This clone process produces another agent with similar capabilities andit is initialized.

• Dispose. When an agent fulfills its goals, it can be disposed. This processterminates execution and removes the agent from the execution environment.

• Dispatch. A mobile agent is removed from its current environment and for-warded to another remote site. At the target site, its execution can eithercontinue or begin anew.

2.3. Information systems 25

AgentAgent

Local

Storage

Create

Dispatch

Retract

Clone

Dispose

Deactivate Activate

Figure 2.5: Agent life cycle, the event model

• Retract. A mobile agent is removed from its remote environment and reintro-duced to its original environment.

• Deactivate. The execution of the agent is halted. The agent becomes dormant,i.e. its contents are transferred to secondary storage.

• Activate. When the sleep period of an agent expires, it is activated and itsexecution resumes.

2.3 Information systems

According to a rather loose definition [27], an information system grants access toinformation, based on data managed somehow and somewhere in the system. Arefined definition however states that an information system consists of a collectionof interrelated software programs, which access services or information coming frompossible diverse data sources.

Information is administered by a storage manager, which is responsible for the in-terface between the underlying data and the applications programs. The collection ofdata, including its storage manager, is usually referred to as a database [40]. Databasesare data sources that can be either centralized or geographically distributed, runningover different operating systems, and used for different purposes.

The literature has embodied a large amount of concepts and techniques for infor-mation systems. Table 2.3 presents a brief introduction to these principles.

2.3.1 Dimensions of information systems

Information systems are typically characterized by three dimensions: autonomy, het-erogeneity, and distribution.


Data

abstraction

Information systems provide to its users an abstract view of the data.

They hide certain details of how the data is stored and maintained by

using levels of abstraction, such as the physical level and logical level.

Data model The data model is the underlying structure of data. Data model mecha-

nisms refer to the collection of conceptual tools for describing data, data

relationships, data syntax, and data constraints. The overall design of a

database is called database schema.

Languages The database schemas are specified by a set of definitions, expressed

with a data definition language (DDL). The data manipulation language

(DML) enables users to access and manipulate information organized by

the appropriate schema. It provides basically operations for insertion,

deletion, and modification of data. A query language is the set of state-

ments used for retrieval of data in a database.

Transactions The management of transactions ensures that the information at the

data sources remain in a consistent state during both concurrent access

execution and in case of system malfunctions.

Administration The administration of information systems relates to the organization

of data sources, granting of authorization for data access, backup and

restoring activities, and other maintenance activities.

Data sources Responsible for interaction with the data stored in physical terms.

Table 2.3: Concepts corresponding to information management systems

Autonomy

Autonomy grants to a data source of the information systems to have its own con-trolled, separate and independently means of administering itself. The informationsystem provides access to the data, however, the owner of the information is the onein charge of controlling it.

The need to share data within the information system sometimes causes conflictsamong the autonomous sources, and these conflicts becomes a critical issue when theinformation system is based on multiple data sources [27]. According to [45, 46], thereare four main kinds of autonomy that can lead to conflicts as presented in Table 2.4.

Distribution

Distribution means that information is scattered and allocated among multiple datasources, while there is a communication link that allows the transfer of informationover a network. The physical location of the data sources is usually hidden, for in-stance by using approaches such as the client-server paradigm. Using RPC calls, forinstance, applications can be developed that ignore the physical location of compo-nents to a large degree.


Design Design autonomy refers to the independency of the design of a component

from the others. The sort of independence is related to issues such as the

universe of discourse, data model, naming concepts, the ontology used,

and so on. Since design autonomy embodies self-determination to change

the design, at any point in time, it causes troubles which are difficult to

handle within infrastructures of interoperable components.

Communication When a component can autonomously decide to which other systems it

will communicate, how the interaction will happen, or when it will occur,

then, it is assumed this component has communication autonomy.

Association Association autonomy refers to the ability of a component to decide on

the portion (or level) of functionality and resource (data, devices, etc.) to

share. Association autonomy is often considered as a mixture of design

and communication autonomy.

Execution Execution autonomy denotes the self reliance in execution and scheduling

of incoming requests. Thus, an external system is not able to enforce the

execution of the commands on a component with execution autonomy,

or even be informed of the order in which operations are executed.

Table 2.4: Types of autonomy

Heterogeneity

Heterogeneity results from a number of discrepancies in the systems, which may haveoccurred due to different reasons. For instance, particular requirements, such asa request for specific hardware or software, contribute to increase heterogeneity ofinformation systems. The understanding and modeling of the real-world conceptsand entities are also performed by different developers, having different points ofview and levels of expertise.

There are several different types of heterogeneity that have important conse-quences in the management of information. Both researchers and developers havebeen working on heterogeneity for many years, yielding many classifications, with dif-ferent spectrum, dimensions or level of detail for each type of heterogeneity [27, 46–48].Although, some of these classifications focus on the different degrees of interoperabil-ity, system, syntax, or structure in order to group the heterogeneity, the classificationpresented in [27] is particularly intuitive. In this work, the types of heterogeneity areclassified into syntactical, data model, and logical, including the semantic, syntactic,representational, schematic, and structural heterogeneity.

Syntactical heterogeneity. Syntactical heterogeneity comprises the technical het-erogeneity and the interface heterogeneity. The technical heterogeneity refers to thedistinctions on hardware platforms, operating systems, protocols, security procedures,etc. Interface heterogeneity exists if different components are accessible through dif-ferent access languages. This aspect does not concern technical issues, such as whether


a JDBC or a native interface is used, rather concerns restrictions of the possible ac-cess methods (e.g. no negation, no disjunctive conditions, only certain queries can beexpressed, etc.).

Data model heterogeneity. This type of heterogeneity is related to the diversityin data models and their different semantics for the concepts. A typical exampleis the difference between the relational model in contrast to object-oriented model.Under this type of heterogeneity it is possible to establish three different kinds of datasources, namely: structured, semi-structured, and unstructured.

• Structured sources have a predefined and fixed schema, where all information isdefined by a schema element. The schema establishes the format and type ofall data, and usually does not change frequently.

• Semi-structured sources have a structure that is not defined strictly into aschema. Each data item can have a tag or a label which holds its semantic defi-nition; the collection of tags can be represented as a potential evolving schema.The XML document is the typical example of semi-structured information.

• Unstructured sources have no structure at all. They do not have any shapeor pattern but they can have indexes in order to arrange and query the data.Textual documents are examples of unstructured data sources.

Logical heterogeneity. Logical heterogeneity refers to three heterogeneity types:semantic, schematic, and structural heterogeneity.

• Semantic heterogeneity pertains to the data and schema differences. There aredistinctions and conflicts in the semantics, even, in schemas using the samemodel, caused by the usage of homonyms (equal names that denote differentconcepts), synonyms (various names for the same concept), the understandingof a concept itself, among other reasons. The vagueness of the natural languagebecomes obvious when, for instance, the suggestion of a concept such as ‘name’can have multiple meanings like family name, nickname, former family name,artist name, etc.

A second kind of semantic heterogeneity exists if two source schemas refer to thesame object, but the corresponding set of attributes is not the same, having forexample different measurement units, data types, or even different structures.For instance, a medicine has a price attribute, which is represented with thecurrency data type, but non explicit if is Euro, Costarrican Colon or anothertype of currency.

• Schematic heterogeneity is the encoding of concepts at different elements of adata model. Figure 2.6 exemplifies one of such conflicts in the relational model;an ‘attribute name ↔ attribute value’ conflict; while the left table models asattribute names the disabilities a patient has, the right table models them asvalues of the attribute ‘Disability’.


XWolf

XVan Gogh

XSteinmetz

XReeves

XXKeller

XBeethoven

Orthopedic

impairment

Mental

disorderBlindnessDeafnessPerson

DeafnessKeller

Mental disorderWolf

Mental disorderVan Gogh

Orthopedic impairmentSteinmetz

Orthopedic impairmentReeves

BlindnessKeller

DeafnessBeethoven

DisabilityPerson

Figure 2.6: Example of schematic heterogeneity conflict

2.3.2 Classification of information systems

Based on the three dimensions, mentioned in Section 2.3.1, it is possible to derivefour broad classes of information systems: centralized, distributed, heterogeneous, andfederated. The following subsections sum up the key points of this classification.

Centralized information system

A centralized information system has a unique database whose management systemruns as one monolithic application on one computer. A single DBMS, used for struc-tured information, or non-database, used for semi-structured and unstructured infor-mation, running on a single computer are both centralized information systems.

Distributed information system

A distributed information system has multiple data sources, which are physicallydispersed yet connected through a communication network.

Heterogeneous information system

The heterogeneous information system consists of a collection of data sources whichdiffer in syntactical or logical aspects. The data components may have different phys-ical location, hardware, software, data model, semantics or communication support.

Federated information system

A federated information system embodies a group of separate and autonomous infor-mation systems, which are the participants of the federation. Data sources operateindependently, however, when they participate in a federation, they may renounce totheir autonomy to a certain degree, via agreements to share the infrastructure.

Due to the autonomous nature of the participants of a VO for telecaring, where asinformation sources are typically distributed among several geographical sites andtheir availability varies over the time, the federated information system becomes


highly relevant and applicable. Thus, the following section further addresses thistype of information systems.

2.3.3 Federated information system

The concept of federated information system is intrinsically related to the one ofFederated DataBase System (FDBS), which is defined as “a collection of cooperatingdatabase systems that are autonomous and possibly heterogeneous” [28]. Basically,a federated information system is constituted by independent information sourcesthat can, to a certain extent, be physically distributed and heterogeneous [49, 50]. Inaddition, each participant of the federation have the ability to associate or disassociateitself from the federation or, even, to participate in other federations [51, 52]. Afederated information system can be seen, in general, like a client server structurewith a three-tier architecture as shown in Figure 2.7.

Federation

layer

Data sources layerClient layer

…

Users and systems that

transparently access the data

from different sources

through the federation

Integration of heterogeneous

data sources by using

uniform languages, access schemas, communication

protocols, etc.

Each data source provides

local access to its own clients

yet can be participant of a

federation by offering broad

information services.

Figure 2.7: Federated information system as three-tier architecture

The client layer consists of users and applications, which take advantage of thefederation layer to access distributed information. The federation layer is composed ofsoftware components that provide transparent access and a uniform view of the datato the client users [17]. This uniform view involves usually a uniform access language,a uniform access schema, a uniform meta-data set, a uniform communication protocol,etc. The data source layer comprises the data sources, which are interfaced into thesystem by wrappers or mediators. The federated architecture can be extended withother layers [50, 53], for instance one dedicated to data source mediation, securityconcerns, or even a presentation layer.


Classification of federated information systems

Federated information systems are initially classified in two broad categories, eitherinto loose integration, where the local data sources have their own schemas, or intotight integration, where local data sources employ common schemas [54]. Accord-ing to [27, 55], however, these systems are better described by using a three cate-gory approach: loosely coupled information systems, federated database systems, andmediator-based information systems.

Loosely coupled information systems. These systems do not provide a federatedschema, but only a multi-database query language to access the federated datasources. Thus, clients have to locate, within the queries, the respective partic-ipant and the precise element in the schema of the participant. This approachis advantageous for the participants of the federation since they do not giveup the autonomy in order to be part of the federation. From another point ofview, it is more difficult to cope with interoperation given that no location andschema transparency is offered. Besides, most heterogeneity conflicts have to beresolved by the user or the applications, making them responsible for all dataintegration aspects.

Federated database system. A Federated DataBase System (FDBS) is built by aselective and partially controlled integration of data, creating federated schemasupon which database operations (i.e. query, updates, etc.) are performed [56,57]. FDBSs are tightly coupled information systems that offer full location andschema transparency to their users, in spite of the fact that there is no uniqueschema in the federation and that each database has no authority over another.Each participant has access to the data provided by other participants, however,the owner of the data is the solely responsible for control of its data. Still, to jointhe federation each participant may give up some autonomy, such as notificationof changes, access to logical metadata, or scheduling information for distributedtransaction management [50].

Mediator-based information systems. A mediator is a component that acts asa proxy between the user and the data source. In general, mediators are light-weight, flexible, and re-usable [55]. Mediator-based information systems aretightly coupled information systems with a federated schema, which is used toprovide integrated access to data of different components (semantic heterogene-ity), however, each mediator may have its own schema. By using mediators,the information system is able to cope with the flexibility required for systemevolution; they are usually plug-in software components and keep also communi-cation autonomy. Mediators hide technical and data model heterogeneity, thusthe access to the information sources is transparent for a federated user.

Federated query paradigm

The federated query paradigm relates to querying and processing data from federatedinformation sources [58, 59]. A federated query processing is designed to preserve


the autonomy of the component database systems and this requires some appropriatealgorithms to perform the evaluation tasks. If using mediators, each component has tofind combinations of queries against data sources that, when combined in a meaningfulway, together provide correct results to the query [27].

A federated query requires a query plan. This plan depends on the metadata es-tablished by the federated schema to access remotely-stored information. Apart fromthe query planning, in which optimization techniques may be used, other importantactivities include the execution of plan and the merging of results [60]. Based on thisactivities, it is possible to identify three key stages in the federated query processing:

• Query planning is the activity of establishing a suitable plan for executing re-mote queries for a given query against the federated schema.

• Plan execution is the task where the plan is executed. This task includes (i) op-timization activities to decide which query operations will be performed, whichcomponents will execute them and how they will do it, (ii) carry out the exe-cution of subqueries, (iii) the gathering of partial results, and (iv) possible postprocessing (data joins), if allowed.

• Results integration is the activity where the gathered data is homogenized byformatting the information, removing redundancy, identifying identical results,and resolving inconsistent data values.

2.4 Agent-based federated information system

This section focuses on the design of an agent-based component able to support alldata handling and data persistency required by an infrastructure for advanced tele-caring services. Using a MAS platform, with mobile agents, we seek to provide aninnovative and rich framework to tackle several difficulties found in traditional in-formation systems [61]. We explore here an integration of MAS with the federatedinformation system paradigm, focusing particularly on the federated query process-ing. We suggest to employ stationary agents for data brokerage activities, and mobileagents for retrieval of remote information. Furthermore, our proposal depicts strate-gies for executing the query processing at remote locations for a greater degree ofoptimization in terms of time performance and resources usability.

The analysis of information management requirements for a telecaring VO, foundin [21], has identified both the modeling and functionality required to be supportedlocally at each participant of the federation. Based on the analysis of these require-ments, we distinguish the main information integration and exchange needs, togetherwith the necessary interoperation among the sites. The information management sys-tem based on agents, generally speaking, acts as a flexible data mediator for federateddata sources. First of all, the agent-based components are designed to support ad-vanced care applications that may require a variety of data models, access physicallydistributed and heterogeneous data, and possess a variety of users and agents whoretrieve data with pre-defined visibility rights.

2.4. Agent-based federated information system 33

Let us introduce our design with the name “Federated Information MAnagement”(FIMA). FIMA is the main component that supports the management of informationat each site of the federated network [62]. It provides the infrastructure for flexibleprocessing of federated queries, data handling, and preservation of information privacythrough access rights management.

Figure 2.8 shows a high level overview of FIMA and its basic relationship withother components and elements within a telecaring site. These components, depend-ing on their role and functionality, are all designed as stationary or mobile agents.These agents (including mobile ones) have their own thread control, and communicateamong them through a proper Agent Communication Language (ACL).

Otherinternal

components

Device interface

FIMA

Agent Interface

Base service

Serv

ice

A

Serv

ice

B

Se

rvic

e C

Multi-Agent System

Legacy systems, devices, other external components

FIMAF I M A

Computer Node

Services and

other applications

Figure 2.8: Relationship between FIMA and other site elements

1. FIMA Interface. Agent that represents the FIMA component inside the node.It encapsulates, and protects, all methods from direct access, and provides trans-parent agent-based access to the repository, hiding database details.

2. Clients. They are the autonomous entities in the platform that request infor-mation management services to FIMA. Basically, they comprise advanced careservices, other applications, and the rest of the components of the site. Humanusers are also considered as clients, although they do not contact FIMA directlyrather they do it through a care service. All clients interact initially with theFIMA Interface.

3. Node. The node is the computer system where the FIMA component resides. Itprovides the environment for running all FIMA sub-components while it alsoprovides protection against malicious software. A MAS platform executes onthe node, providing the necessary context for valid agents.


4. Mobile Agent. The mobile agents are the mobile sub-component that are dis-patched from one site to another for information retrieval activities. Depicted inFigure 2.9, each mobile agent has as goal being in charge of execution of queriesand transfer of data.

Mobile

Agent

Mobile

Computer Node A Computer Node B

FIMA

Agent Interface

FIMAF I M A

FIMA

Agent Interface

FIMAF I M A

Figure 2.9: Interaction of a mobile agent with FIMA

5. Passport credentials A credential is the unique certified document that is usedto verify abilities and qualifications of an agent. This document is bound toan agent and attests the lifespan validity and is the basis to decide on theaccess rights of the agent within the federated network. Certified credentials areconceived as electronic passports. These passports are composed of two parts:an immutable part that contains information about the agent’s identity whocreated the agent, when that happened, and what is the purpose of the agent;and a variable part that states basically the itinerary followed by a mobile agent.

Now that we have introduced the basic elements of FIMA, we proceed with a closerlook into FIMA and identify the following sub-components, as shown in Figure 2.10.

z

- AIMS -Agent Information

Management System

FIM

S A

gen

t

- MIRA -Mobile Information

Retrieval Agent

DBMS

- IAMA -Information

Access Manager

FIMA

F I M S

M I R A

Clients

Figure 2.10: FIMA sub-components

2.4.1 Federated Information Management Server Agent

The Federated Information Management Server Agent (FIMS Agent) is the FIMAinterface, in each site, that manages all interactions between internal subcomponentsand the clients. FIMS Agent is designed as a static agent, supporting communication

2.4. Agent-based federated information system 35

mechanisms allowing it to cooperate with other agents. FIMS Agent interfaces infor-mation management functionalities with high-level ACL messages, hiding the internalprotocols and data handling involved in managing information.

2.4.2 Agent Information Management System

The Agent Information Management System (AIMS) is the sub-component in chargeof providing operations for management of the federated schema. The federatedschema is the grounding support to perform the federated query processing. Thethree main sub-components of AIMS are the (1) Access Rights Manager, the (2)Federated Query Processor, and (3) Federated Data Management Tools.

Access Rights Manager

Each partner of the federation has different privacy policies, user-based visibility lev-els, and access rights on their information. In fact, every site in the telecaring federa-tion is autonomous to decide which part of its local information should be available toeach member in the federation. The functionality of Access Rights Manager focuseson mechanisms for establishment of visibility levels and their validation.

The typical approach for ensuring access rights in federated information systems isbased either on the individual export schema definitions (on the local schema for everyremote “user”), or on the definition of a complete hierarchy of export schemas. Adifferent approach for FIMA, based on the passport credentials of the agent, is takenfor defining the visibility levels. Specifically, using the agent type and the user role,the Access Rights Manager provides access at different levels to the local information.Obviously, it is not enough to define the access rights to kept safe the information ofthe sites. It is also important to determine the credentials of an agent, at runtime, andto find out if this agent is allowed to execute, to access, and to retrieve information.

Federated Query Processor

The Federated Query Processor is designed to support the retrieval of all necessarydata from different remote sites. Through a single query request, issued by a useror by an autonomous agent, this component gathers all distributed information andpresents the results as if they are local.

The specific functionality supported by this component includes: query decompo-sition, sub-query processing, and result merging. These steps are further detailed andexplained in Section 2.5.

Federated Data Management tools

The tools for Federated Data Management provide the mechanisms for configuring theFIMA environment, the administration of the internal database repository, and themanipulation of the federated schema. These tools are designed to handle the requiredparameters for the proper execution and monitoring of the database repository.


In Chapter 3, we address the creation of the local database schemas making use ofontological definitions. In this context, an ontology-based tool generates the schema,however, the management of this schema is performed through AIMS.

2.4.3 Information Access Manager

The Information Access Manager (IAMA) is designed to provide object persistence atthe local site, by executing the proper operations on the local repository. It lets objectsfrom client agents to become persistent on a relational database. The IAMA designrelies strongly on a relational database, so it considers the usage of object-relationalmappings to allow the translation. These mappings describe the binding betweenthe objects from the client services and the information located at the relationalrepository. A data binding framework is also considered for transforming this objectrepresentation into other structures.

2.4.4 Database repository

As mentioned, we consider a database repository based on a relational data model.The main reason is that most organizations in the care sector deploy applications onrelational database platforms [21]. The data is structured according to a relationalschema; and it is accessed through the SQL language. An additional middlewarelayer however is considered to compensate and overcome the limitations of the currentrelational database systems to support storage of objects.

Relational database management system

A Relational Database Management System (RDBMS) presents a view of data as acollection of rows and columns. All data are represented in tabular form. The rela-tional approach supports queries that involve several tables and some entries can beprograms, text, unstructured data in the form of binary large objects (BLOBs). Therelational model is currently the most accepted in practice for database systems sinceit provides enough robustness and maturity for the safety of the information stored.In other words, besides storing and retrieving information, RDBMS provides mecha-nisms that protect the data in case of system crashes or unauthorized access [40]. Infact, most relational databases are ACID compliant repositories [63]. ACID compli-ancy is used to test and validate the DBMS’s functionality, and indicates

• Atomicity, either all elements of a given transaction must commit successfully,or none do;

• Consistency, each transaction transforms the database from one valid state toanother valid state;

• Isolation, the effects of a transaction are not visible to other transactions in thesystem until it is complete; and

• Durability, once a transaction has been committed, all the effects are permanenteven if there is asystem failure.

2.5. Federated query processing 37

Database middleware

A database middleware facilitates the translation from tabular data to the object-oriented representation. The middleware component is an intermediary entity thatopens a database connection, handles the database properties, and is used to gatherinformation to create database objects. With this approach, it is possible to simplifythe exchange, persistence, and manipulation of object-oriented information.

2.4.5 Mobile Information Retrieval Agent

The Mobile Information Retrieval Agent (MIRA) performs the federated retrieval ofinformation from external sites, and its design is part of the Federated Query Proces-sor (included in AIMS). The decision to design the federated query mechanism as amobile agent guarantees the possibility of combining some intelligent decision makingfor information processing with the information retrieval tasks. Mobile agents mayhave planning, error diagnosis, and recovery capabilities. Each mobile agent, handlinga sub-query, are then able to recognize and self-adapt to diverse environments.

2.5 Federated query processing

The federated query processing, supported by FIMA, provides secure access to infor-mation distributed over heterogeneous and autonomous sites within the collaborativenetwork. The users of telecaring applications access the set of heterogeneous datasources through FIMA, which acts as a layer that offers a uniform way to access thedata distributed over the sites. The uniformity is reached with specific informationinteroperation strategy, based on sharable schema definitions, security mechanisms,a uniform query language and specific components that resolve technical differences(e.g. object-relational mechanisms, agent communication, etc.).

The processing of federated queries is a quite complex task, and it is briefly detailedas follows. First, the requester sends a query (which is in high-level format) to theFIMS Agent, which generates a specialized agent designed to handle this particularrequest. This new agent executes as a separate process and it frees FIMS Agent fromthe duty of carrying out the query. This new agent translates the original query intothe concrete internal structures of the stored data and a set of sub-queries. Thesesub-queries are one by one assigned to mobile agents with a proper itinerary. Afterthis step, these mobile agents are dispatched to the remote sites to accomplish theirmission, to perform the local query at remote sites, and to transmit the results backto the original site. Finally the gathered results are merged at the original site, inorder to be sent to the requester, as shown in Figure 2.11.

It should be noted that the main goal of the federated query processing in FIMAis to enable agents and end-users to query the authorized information, hiding theconcrete details about database connections, agents creation, their traveling amongsites of the network, and manipulation of the data.

In this section, the main aspects of the federated query processing are detailed,namely introducing the general strategy, following the internal steps, exploring the


Agent

creation

M I R A

M I R AM I R A

M I R A

F I M S

FIMS Agent generates an agent

to handle the query requestF Q P

F Q P

Sub-queries are assigned

to mobile agents traveling

to remote nodes

Once a mobile agents have

traveled, it performs a local query

F Q P

The remote results are sent back

to the original node

Once the results are received,

they are merged and given to

the requesterF Q P

Dispatching

Query evaluation

Gathering

of results

Revealing

results

Figure 2.11: Federated Query Processing

data structures, and suggesting an object query language. Furthermore, an innovativeapproach to handle the remote operation is introduced, by depicting a “range of dif-ferent kinds of federated queries” (see Section 2.5.4) that benefits from the FederatedQuery Processor and its stationary and mobile agents.

2.5.1 Agent-based query processing

The federated query processing of FIMA makes usage of both mobile and stationaryagents in order to perform the data retrieval. The mobile agents are used as themechanism to perform the sub-query and for result transmission between the remotesite(s), where information may be located, and the client site, where FIMA receivesthe request. Stationary agents provide proper processing of information, control ofthe status of the request, and verification of credentials of the requester.

The mobile agent paradigm provides a rich framework for information brokeragein networked environments [64], making it a good candidate for implementing theinformation management systems within a collaborative network. The use of agentsto retrieve information is relatively novel, and various approaches have considered toaccess remote databases with mobile agents. For instance, in [65], a DBMS-appletcreates and dispatches a mobile agent (or agents if necessary) that travels directly tothe remote database server. At the database server site, the mobile agent initiatesthe JDBC driver, connects to the database, and performs the query specified by therequester client. When the mobile agent completes its task, at the database server, itdispatches itself directly back to the client machine. The DBMS-applet then presentsthe results of the query to the user. In an alternative approach, employing only weakmigration, the user downloads a DBMS-applet in the client site, while a stationary


agent remains at the remote server. This stationary agent initiates the JDBC driver,handling the interface between the database and the clients, and communicates theresults to the DBMS-applet.

The query mechanism of FIMA differs from the above approaches in several as-pects. There is a specialization of stationary agents; namely, one provides a foundationfor local information retrieval and support for data visibility levels and access rightsverification, while another is in charge of query coordination and results processing.Another difference is that mobile agents, in FIMA, do not carry any code related todatabase connectivity, making them suitable for strong migration. Besides, these mo-bile agents do not need to return back to the point of origin, since they only transmitback the results, thus, not the entire agent returns to the requester.

2.5.2 Agent-based FQP components

The internal components and their tasks during the federated query processing ofFIMA are depicted in Figure 2.12

FQP instruction

(XML specification)

Query

execution FQP Agentcreation

F I M S

M I R A M I R A M I R A

M I R A

Requester

agent

FIMS Agent

Agent interface

FQP AgentQuery handling

M I R A

M I R A

M I R A

F Q P

MIR AgentsAccess to remote

information

Figure 2.12: Agents involved in FQP

- FIMS Agent: Federated Information Management Server Agent, acting asagent interface.

- FQP Agent: Federated Query Processor Agent, acting as the query supervisor.

- MIR Agent: Mobile Information Retrieval Agent (MIRA), acting as the mobilecomponent for the process.


FIMS Agent

As stated previously, the FIMS Agent manages the interface to access the information.It is continuously available and running, supporting several users. It then can fulfilrequests from numerous agents simultaneously, that may have different purposes otherthan just executing a single query.

Whenever FIMS Agent receives a request for a federated query, it generates an-other agent, the Federated Query Processor Agent (FQP Agent), which executes in adifferent execution thread. This mechanism provides modularity for query processing,since this new FQP Agent focuses on performing the query only while FIMS Agentmaintains its primary server operation. When the FIMS Agent summons the FQPAgent, it also includes the credentials of the requester into this new FQP Agent. Asa result, from that point on, all query operations are bound to that FQP Agent, i.e.it supervises the processing of a federated query, and thus the FIMS Agent is freedfrom the responsibility of the federated query execution.

FQP Agent

The FQP Agent has to accomplish several tasks, which are particularly needed in thecollaborative environment of a telecaring network. A number of techniques are usedto improve the performance of the query processing, for example: (1) special multi-thread processing, (2) simultaneous execution of several queries, and (3) reduction ofcommunication costs by reducing the size (i.e. content) of the mobile agents involvedduring the query execution. All these mechanisms focus on the internal operationsfor the processing of federated queries. These internal operations are grouped intoseveral task categories, which can be summarized in Table 2.5.

MIRA – Mobile Information Retrieval Agent

In Section 2.5, MIRAs are introduced as the mobile elements in the query processing.The management of MIRA agents is solely performed by the FQP Agent and it iscompletely transparent to the requester. Clearly, from the requester’s point of view,the proper execution of the query and its results is what really matters, and nothow the query mechanism is implemented. This transparency noticeably reducesthe complexity of the system, since the application designers and developers are notconcerned about internal details of the processing mechanism.

As part of the strategy to enforce the visibility levels and access rights on theinformation, FIMS Agent verifies the “credentials” of the requester with the AccessRights Manager before creating the FQP Agent. The FQP agent is created withthe credentials of the requester and, those credentials are used in turn to createauthorized MIRA agents. In general, this strategy is to validate the access rights tothe information for requesters, no matter if the requester is local or remote.


Query

translation

The query request that arrives in high-level format, which is first trans-

lated into concrete handling structures.

MIRA creation Depending on the federated query and on the targeted itinerary, appro-

priate (MIRAs) are created.

Query

decomposition

The original query is divided into a number of sub-queries according to

the number of target sites, and these sub-queries are assigned to the

corresponding MIRA agents.

MIRA

transmission

Each MIRA is sent to a remote site, carrying the corresponding sub-

query.

Query evaluation The MIRA agent performs the communication MIRA-to-FIMS Agent of

the remote site, in order to execute and retrieve the requested informa-

tion from that site.

Result

transmission

The MIRA transmits to the FQP Agent the information resulted from

the sub-query.

Information

merge

Once all results arrive from MIRA, the FQP Agent merges the sub-

results, and sends the final results to the requester.

Release of

resources

When the execution of the query completes, the requester can agree to

release resources generated by the FQP Agent, disposing all the MIRA

agents involved in the query evaluation as well as the FQP itself. Note

that disposing the FQP Agent at any stage of the query execution will

effectively close the processing of the federated query.

Table 2.5: Processing of federated queries

2.5.3 Federated query language specification

In terms of query language, our approach is to provide proper extensions for federatedaccess to a well-known language specification, rather than to reinvent the wheel anddesign a complete computational federated query language from scratch. Even whendesigning the necessary language extensions, there are certain issues that must beconsidered, in order to design a suitable language specification. As such, we considerthe following characteristics to set out the query specifications for FIMA.

Based on OQL. In essence, we design an extension of the Object Query Language(OQL) with notions of federated data access. OQL is a well-known object-oriented standard to query information, and it provides declarative access toobjects. OQL is the de facto standard to request objects from data repositoriesand relies on the object-oriented model of the Object Data Management Group(ODMG) [66]. In a nutshell, OQL represents object-oriented extension to SQL,using the known select-from-where clause, and it is designed specifically aroundthe functional needs to support an object-oriented architecture. Among themain differences between original OQL and traditional SQL, the most significantare highlighted below:


- OQL has the ability to support object referencing within tables. It ispossible to have objects nested within objects.

- Not all SQL keywords are supported within OQL.

- OQL has the ability to express mathematical computations.

Conformance with XML. The specification should be simple, very flexible textformat derived from XML. XML format is designed to meet the challenges forthe exchange of a wide variety of data. Conformity to XML format also meansfuture extensibility.

Target node plan. In a typical federated query, the requester describes only thecontext of the query. The requester however can also specify nodes or create anitinerary within the federated environment. For example, a service applicationcan send a query only to those sites that have subscribed to the service in aninternal directory.

Accessing method. The requester can define a special behavior for the agents inorder to exploit certain multi-tasking features or avoid system overhead.

Simplicity. The language must provide all the required information managementfeatures (language completeness), but at the same time must be kept as simpleand easy to use as possible. If some of the parameters are not specified, it shouldbe possible to establish a default behavior.

After taking into account the pre-established priorities associated with the FIMAdesign and objectives, and analyzing the above considerations, the extensions forquery language are expressed in accordance with the standard syntax of XML docu-ment. Figure 2.13 illustrates the XML syntax defined for a federated query request.

<?xml version="1.0" encoding="UTF-8" ?><fqp type="([PARALLEL | SERIAL | SEQUENTIAL])"

time-out="x" life-span="y"><query>Statement in OQL syntax </query><targetList>

<target>URL node 1</target><target>URL node 2</target>. . .<target>URL node n</target>

</targetList></fqp>

Figure 2.13: Federated query syntax for FIMA

The XML document only provides the XML representation, while Figure 2.14includes the definition of the XML Schema that clarifies how an XML document canbe used to represent federated query requests. Furthermore, Table 2.6 introduces


the semantics for each tag and facilitates reading and understanding of the structurespecified by this XML Schema. For example, the fqp tag contains three attributesand two tag elements: the query and the targetList. The attributes of fqp are usedto represent properties that influences the functionality in a specific query request.Namely, type specifies an access method for the query, time-out assigns the periodof time sufficient to accomplish the query, and the life-span defines the duration anagent may live before disposing itself. The query tag specifies the statement, in OQLsyntax, to be used for the query request, while the targetList tag is used to grouppossible target nodes that may participate in a federated query.

<?xml version="1.0" ?><xs:schema elementFormDefault="qualified"

targetNamespace="http://www.science.uva.nl/~telecare"xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="fqp" type="fqpType"/><xs:complexType name="fqpType"><xs:sequence><xs:element name="query" type="xs:string"

minOccurs="1" maxOccurs="1"/><xs:element name="targetList" minOccurs="0" maxOccurs="1">

<xs:complexType><xs:sequence>

<xs:element name="target" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>

</xs:sequence></xs:complexType>

</xs:element></xs:sequence><xs:attribute name="type" minOccurs="0" maxOccurs="1"><xs:simpleType>

<xs:restriction base="xs:string"><xs:enumeration value="parallel"/><xs:enumeration value="serial"/><xs:enumeration value="sequential"/>

</xs:restriction></xs:simpleType>

</xs:attribute><xs:attribute name="time-out" type="xs:positiveInteger"

minOccurs="0" maxOccurs="1" /><xs:attribute name="life-span" type="xs:positiveInteger"

minOccurs="0" maxOccurs="1" /></xs:complexType>

</xs:schema>

Figure 2.14: XML Schema representing the query specification

It is expected that an XML document defined with this specification is normallyincluded within each federated query request. Eventually, FIMS Agent will validateeach XML declaration against the XML Schema in order to accept only those well-formed and valid requests.


fqp The root tag encloses the federated query to be handled by every FIMA

component.

query This section encapsulates the OQL instruction to be executed and processed

by FIMA. The query is affected by three parameters.

type The requester can specify the access method to retrieve the information from

the remote sites. The access method is related to the query type, which can

be specified to reduce the communication cost, and blocking delays, etc.

time-out Time in seconds that controls the maximum period that agents have in order

to communicate with other agents.

life-span Time in seconds that controls the period that the agents will live before

disposing themselves.

targetList In this section the requester is able to specify the nodes where the informa-

tion is located. If not specified, only local information will be returned.

target This tag contains the physical address of the node, where the data source

is located.

Table 2.6: FIMA Query Specification

2.5.4 Federated query types

One of the most important and interesting aspects of the design of FIMA is to allowthe requester to select a query type that sets a different behavior to the underlyingagents. The advantage of using different types of access methods is that the useror requester can control the general application performance and overhead, thus, thefederated queries can be optimized for specific purposes.

Each one of the proposed techniques allows for information, which may resideoutside of the site, to be accessed under different ways. The following three querytypes are proposed for remote data access: (i) Parallel, where the performance inspeed is the key consideration; (ii) Serial, which targets the optimization of resourceusage; and (iii) Sequential for decisive user interactivity in controlling the informationprocessing overhead.

Parallel query type

The parallel query type exploits, in a transparent and parallelized way, the retrievalof information, independently of the number of sites to visit.

The design of the parallel query type involves a FQP Agent that summons differentMIRAs, one per remote site, as shown in Figure 2.15. The FQP Agent sends, atonce, all the mobile agents to the remote sites. When these agents arrive at theirdestinations they proceed to execute the (local) query. After retrieving the partialresults, each MIRA transmits the data back to the FQP Agent, which merges all theinformation to produce a final result. This final result is then given to the requester.

For tele-monitoring, which consists of gathering remote readings, diagnostic data,and other environmental conditions among the care sites, the parallel query type offers


Agent transmission

Partial results

Database

M I R AM I R A

M I R AM I R A

Node – 2

F I M SF I M S

Node – 3

F I M SF I M S

Requester’s Node

query

result

F Q P

FQP AgentQuery Processing

M I R AM I R A

Node – 1

F I M SF I M S

Requester

Agent

Figure 2.15: Parallel query type

a mechanism to transfer data to care experts (such as doctors, care consultants, etc.)as soon as possible, regardless of the location. The fast gathering of data may lead toan increase in the early diagnosis, assisting or prevention of problems. If care giversin an ambulance, for example, require the list of the elderly located in a certain street,they can submit a command in parallel like the one shown in Figure 2.16.

<?xml version="1.0" encoding="UTF-8" ?><fqp type="parallel">

<query>select a from Address awhere a.street = "Kruislaan" </query>

</fqp>

Figure 2.16: Example of a parallel query

Serial query type

The serial query type allows the query to be processed one site at a time (node-by-node). This reduces the amount of resources specially the communication and loadused while processing. The main disadvantage however is its associated low speeddue to the consecutive migration of code and sequential processing.

In Figure 2.17, the serial query type is illustrated. In contrast to the parallel type,the FQP Agent creates only one MIRA. This mobile agent is in charge of executingthe query request at all required sites, node-by-node. After the itinerary of the mobileagent is completed (i.e. no more sites to visit), it sends the results back to the FQPAgent, which in turns formats and forwards them to the requester.

As a potential application, let us consider that an elderly may move regularlyoutside his own home to residential centers, or viceversa. When this occurs, it is


Agent transmission

Partial results

Database

M I R AM I R A

M I R AM I R A

M I R AM I R A

Node – 1

F I M SF I M S

Node – 2

F I M SF I M S

Node – 3

F I M SF I M S

F Q P

Requester

Agent


query

Requester’s Node

result

Figure 2.17: Serial query type

difficult to locate the right location to gather the data. It must also be distinguished,whether the elderly lives in a residential center; a category including nursing homesand senior citizen residencies; or in a private residence, which comprises the cases ofelderly living in a private home; the elderly may live alone, with others (as a couple orwith family members), or in a mixture of these environments. Under this scenario, itis not certain to which site a monitoring query can be sent or where the information(regarding status monitoring) can be found. Using a serial query type, however,the user can establish an itinerary where to perform the query, avoiding possiblenetwork overhead. Figure 2.18 presents an example that gathers “medication” datafrom different sites in serial mode.

<?xml version="1.0" encoding="UTF-8" ?><fqp type="serial">

<query>select m from Medication mwhere m.PrescriptionDay = "06/06/2006"

</query><targetList>


</targetList></fqp>

Figure 2.18: Example of a serial query


Sequential query type

A sequential query type offers to the “requester” (being an intelligent decision-maker,i.e. a human or expert system) the ability to interact with the query processing, inorder to decide whether to stop the processing of the query when, for instance, theaim of the query is satisfied, or to continue.

Similar to the serial query type, the FQP Agent also creates only one MIRA, whichis in charge of performing the query node-by-node. The difference however is thateach time that a MIRA receives partial query results from a site, it sends them backto the FQP Agent. Then, the FQP Agent provides those results to the requester. Atthis stage, the requester is able to decide if the goal of the entire query is achievedor not. If is not yet achieved, the requester sends a signal to FQP Agent (and inturn to MIRA) to continue with the next site in the itinerary. Besides, this processfurther adds the advantage of cutting the processing time and usage of resources tothe minimum necessary. Figure 2.19 exemplifies a sequential query type.

Msg. Continue!

Partial results

Database

M I R AM I R A

M I R AM I R A

Node – 1

F I M SF I M S

Node – 2

F I M SF I M S

Node – 3

F I M SF I M S

F Q P

Agent transmission

Requester’s Node

Requester

Agent

query

result


M I R AM I R A

Figure 2.19: Sequential query type

A clear example of applying a sequential query type would be the routine processof checking the “event log” of sites that may have a faulty sensor and are associatedwith a specific care center. The approach is to execute a sequential query over possibleaffected sites, and check the responses as they are received. As such, those eventsthat may require a corrective action can be gradually identified and processed. Aserial query would not be useful as it would mean waiting for the entire search to endbefore obtaining information from any site, and a parallel query would overload thenetwork far too much for a routine process.

Another case of using sequential query type is when the requester is interactivelylooking for a piece of information, for instance, when an operator at the care centerrequires a phone number of an elderly’s relative. In this case, the operator launchesa sequential query over different sites where there may be data related to the phonenumber of the elderly’s relative. When the operator finds the phone number, the


sequential query can be immediately stopped. The example, in Figure 2.20, requests“relative” information in sequential mode.

<?xml version="1.0" encoding="UTF-8" ?><fqp type="sequential">

<query>select r from Person r, Person ewhere r.elderly = e.relative

and e.name = "Abraham"</query><targetList>


</targetList></fqp>

Figure 2.20: Example of a sequential query

2.6 Conclusion

This chapter suggests an architecture for an agent-based federated information sys-tem. Taking into account two paradigms, multi-agent systems and federated in-formation systems, it introduces an innovative system that tackles the informationinteroperability in a telecaring environment.

The FIMA architecture is proposed as an effective mechanism to develop a flexibleinfrastructure and to support a large variety of telecaring services that require a widevariety of data models. FIMA is designed as a multi-agent system, with a specificapproach towards the federated query processing. This federated query processingtransparently provides access to remote data from several sites, with the use of sta-tionary agents for coordination, mobile agents for remote data gathering and, querystrategies for query optimization.

The designed architecture provides ways to retrieve, store, and update physicallydistributed and heterogeneous data, while providing proper access rights definitionand validation. The architecture is not linked to any particular implementation ap-proach or concrete technology, making the contribution highly generic. As such, thedesigned components support a variety of application architectures, including client-server and agent-based systems.

Chapter 3

Ontology support fortelecaring

3.1 Introduction

The telecaring industry faces many challenges on its way to providing suitable inte-grated solutions for the ageing population. Manufacturing, social care, communica-tion, entertainment, software engineering, among others represent the main industriesthat need to collaborate towards joint opportunities supporting telecaring for the el-derly. This fact has lead to the emergence of a large number and variety of multi-sector Virtual Organizations (VOs), involving experts from different disciplines andorganizations needing to interact and integrate their approaches and system towardsreaching common goals [16].

While multidisciplinary collaboration for telecaring of the elderly con producemore suitable products, they create a number of inevitable complexities. These com-plexities are mostly due to the need for sharing and exchange of their entities as wellas the fact that their approaches and developments must be compatible and interop-erable, if not sharing the same infrastructure. The following list suggests a numberof difficulties faced by the experts.

• In each VO aiming at provision of telecaring services, the involved expertisehighly varies. Among other specialists, care professionals, appliance and sen-sor manufacturers, electrical engineers, automation experts, social workers, andcomputer scientists, need to collaborate in order to set up components and ser-vices for remote caring. Besides these main areas, other care-related experts(e.g. from areas of law, entertainment, finance, etc.) may need to take part inthe design and development of the VO’s products and services. Clearly, theterminology used in each of these areas is different. Sometimes having onlylittle in common, or even associating different semantics to the same concept;what makes the sharing, interaction, and interoperation among these expertsand their approaches a complex challenge.

49

50 Chapter 3. Ontology support for telecaring

• Each VO for telecaring has a life cycle, in which different experts may need to getinvolved at different times. This dynamic nature of VOs causes the collaborationamong experts to evolve at the different stages of the life cycle of the VO. Asa result, even if agreed by all involved experts to develop and use a commonterminology for the VO, it is still not possible to develop it a priori, or duringthe constitution of the VO, rather it needs to be gradually developed over time.

From the technical point of view, a telecaring environment contains several hard-ware and software components. In a general architecture for telecaring, as shown inFigure 3.1, these components are found at three different levels: (i) on the top level,care applications and services, (ii) at the middle level, the components that focus onthe base supporting functionalities, and (iii) at the lower level, external appliances(alarms systems, sensors, and other devices) from diverse sources.

BasePlatform Level

Services LevelCare providers

& relativesservices

SpecializedElderly

Interfaces

External Enabler LevelSafe Communication

InfrastructureDevice

Abstraction

E.g. online monitoring systems,external mobile alarms, etc.

E.g. platform administration, user management, information management, etc.

E.g. agenda reminders, fall detectionsystems, remote supervision, etc.

Figure 3.1: Three levels of telecaring architecture

Different experts in a telecaring VO are involved in design and development of dif-ferent parts of this architecture. Therefore it is needed to build a common understand-ing and shared terminology for a telecaring VO. Reaching this common terminologyan important issue for the success of the VO itself. Furthermore, the VO dynamismimposes the need to facilitate and automate this process as much as possible.

This chapter addresses the use of ontologies for the specification of the commonconcepts and terminology applied in a telecaring VO. It further considers how toengineer the ontology within a telecaring VO, what is needed to support the varietyof expertise involved in the VO as well as the need for evolution of the ontology duringdifferent stages of the VO’s life cycle.

A key purpose of this chapter is therefore to address the set of questions raisedunder RQ3 in Chapter 1. As such, the reader is exposed to the basic concepts ofontology in Section 3.2. Section 3.3 focuses on the proposed ontology engineeringprocess. Subsequently, Section 3.4 places a strong emphasis on the automatic gener-ation of database schemas and other data structures. Finally, Section 3.5 draws theconclusion of this chapter.

3.2. Ontologies 51

3.2 Ontologies

Initially used in philosophy, an ontology refers to the study of being or existence,seeking to describe the basic categories and relationships of being to define entitiesand types of entities within its framework. The concept is also linked to epistemology,to deal with the origins of human knowledge [67].

3.2.1 Definitions of ontology

One of the most common quoted definitions for ontology, in the context of our re-search, is given by Gruber [68] as “a formal explicit specification of a shared concep-tualization.” An ontology essentially defines the entities, their properties, and therelations among them, within a domain of disclosure. Ontologies support the processof conceptual modeling by providing a common collection of semantic information,involving a vocabulary with the set of terms used for modeling, a taxonomy, includ-ing some structure of the entities, and the semantic interpretation of the meaning ofterms and concepts.

Having the sharing of knowledge and information in mind, an ontology describesconcepts of a domain and their relationships, in terms that are understandable (andprocessable) for humans and software systems. Because of this, ontologies have re-cently received much attention due to the interest in both ‘Semantic Web’ and ‘Se-mantic Grid’ [69, 70]. Ontologies are widely used in applied areas where they facil-itate proper communication of software components, in particular, with multi-agentsystems [71]. Ontologies are also becoming one of the significant mechanisms fororganizations from different fields and disciplines to understand each other across aVO [72]. As such, one of the most relevant benefits of employing ontologies in tele-caring VOs is the agreement among field experts (manufacturers, sensor engineers,software engineers, researchers, social workers and other care professionals) to de-fine shared conceptualizations and terminology of the domain (or part of it) [73, 74].With such set of base concepts, human experts and agent systems shall share thesame world-view and the ability to understand the telecaring knowledge.

Different kinds of formal and explicit specifications however have appeared, whichare often referred to ontologies [75]. Although some of these representations mayrefer to identical domain areas or their goal may be the same (i.e. to define conceptsand their semantics), they may differ in complexity, formality and specification [76].Examples of these representations are glossaries, thesauri, data models, and databaseschemas, among others.

Categories

Since there are several ways to organize and structure a set of concepts, axioms, andtheir relationships, many categorizations for ontologies are therefore possible [77].Each category is generally based on the structure, purpose, design, or other charac-teristics of the ontologies. This section explores three main classifications, based onthe precision complexity, the usage, and the applicability of an ontology.


1. Precision complexity

One way to classify an ontology is related to its level of sophistication and tech-nical complexity [76, 78]. Table 3.1 shows a classification based on the precisioncomplexity, which refers to the ability to capture all (and only) the intendedmeaning of the area. According to this classification, the more an ontology hasto support automated tasks, the more formal and complex it will become. Inthe table, the most technically complex ontologies are found in the lower part.

Catalogue Itemized list of terms

Glossary Dictionary of terms and definitions

Taxonomy Terminology grouped by some principles or named

classification

Thesaurus Nomenclature with a classified list of synonyms

Database schema Group of structured entities and their relationships

(intended to store information)

Object-oriented model Model focused on the design of data structures

and their behavior (objects and classes)

Axiomatized theory Coherent group of general assumptions and rules

Table 3.1: Ontology classification according to precision complexity

2. Usage

Another categorization of ontologies is based on the ontology usage [79]. Theclassification focuses on outlining the distinction and purpose of the ontology.

• Application ontologies. They provide terminological services, at run time,for semantic purposes, in order to validate and check constraints betweenterms. They have limited expressiveness and high computational require-ments for runtime execution.

• Reference ontologies. They form a consensus about meaning of terms (ingeneral), specified during the design and development. Usually, they holdhigher expressiveness and have less computational requirements.

3. Applicability

The ontologies can also be categorized by three levels of applicability.

• General ontology. A general ontology provides broad definitions of com-mon concepts with a wide scope. The general definitions have a largeapplicability in several domains, and may be the foundation for the morespecific ontologies described below.

• Domain ontology. A domain ontology represents knowledge for a specificdomain (i.e. transport design, electron microscopy, biology, etc.), and it

3.2. Ontologies 53

is applicable for modeling and obtaining information from the domain. Itoffers a common vocabulary that serve domain applications, facilitatinginteroperability between services.

• Task ontology. A task ontology is the most specific type of ontology, sinceit defines terms and concepts of specific problem-solving procedures. Com-mon understanding at the level of task ontologies permits a high grade ofinteroperability but in hard to achieve due its restrictions to specific prob-lem solving methods. Task ontologies can also be domain-independentand remain valid in several domains. An example of a task ontology in thetelecaring domain is the OperOnt ontology [80], which describes contextualinformation for several agents to perform an activity.

Since it is possible to categorize the same ontology in different ways, a successfulevaluation and classification of an existing ontology model depends also on additionalfactors which are influenced by commitments and assumptions made during model-ing and conceptualization process. In addition to verifying the ontology properties,such as the underlying model, the representation language, the vocabulary, etc., it isalso relevant to evaluate these other commitments and assumptions. The evaluationmay however look into external features of the ontology, including its scope, history,purpose, modeling process, authors, the experience of the ontology engineers in theapplication domain, or best practices used during the ontology modeling.

3.2.2 Ontology engineering definition

The key elements of every ontology are the sets of concepts and their precise mean-ing. When building these sets, terms are selected with great care by the experts,to ensure that the most abstract foundational concepts are specified. The processof choosing and evaluating the vocabulary that is defined using formal techniques iscalled ontology engineering.

Ontology engineering is considered by researchers from a theoretical point of viewas well as from practical application studies [81, 82]. An analysis of the ontologyengineering process and its definition are provided in [83–85], while application studiesare described, for example, in [86, 87].

Purpose

Definition

Ontology

Modeling

Ontology

Evaluation

TargetOntology

Figure 3.2: Ontology design process

In a basic ontology engineering scenario, the ontology engineers address the for-mulation of a target ontology in stages, as shown in Figure 3.2. First, they need to


specify the potential purpose of the ontology. Then, with the related domain informa-tion, they model the terms and entities. Subsequently, every concept is additionallyassessed and evaluated to provide an initial ontology.

• Purpose definition. During this stage, ontology engineers conceive and specifythe purpose and goal of the ontology. Their decisions influence the level offormality and the precision of representation. In this stage, the mechanismsand tools for the modeling are usually established.

• Ontology modeling. Activities such as design and modeling of the ontology areperformed in this stage. The modeling of an ontology normally starts with theexamination of domain scenarios and then, based on its results, the identifica-tion of terms and concepts takes place. Then, for each of the identified terms,the semantic definition and its properties are specified. A modeling project be-gins with a minor model that is iteratively improved until it has approximatemappings between the modeled concepts and the real ones. From a software de-velopment point of view, the analysis and abstraction for the ontology is similarto the ones done during an object-oriented modeling, where the modelers haveto abstract the essential features and characteristics of the objects.

The modeling is considered as a troublesome stage since it deals with establish-ing a consensus among several ontology engineers who have different views andperspectives. The domain experts have to specify the concepts, processes andtheir behaviors, and may even have to integrate different schemas or represen-tations into a common model.

Although the resulting ontology should describe (and include) only those prop-erties that are necessary for modeling the entities in the field area, there is no“correct” method of how to design the ontology. The modeling process is ob-viously influenced by the ontology purpose and, of course, the experience andability of the involved ontology engineers.

• Ontology evaluation. During this stage, ontology engineers evaluate the targetontology against representative scenarios of the given domain. If the scenar-ios are correctly modeled without serious problems, then the ontology designprocess can be considered as completed; otherwise, the ontology must undergofurther re-design.

There are five main approaches concerned with the modeling, application, andinitial assessment of ontologies [88]. Namely inspirational, inductive, deductive, syn-thetic, and collaborative; or a combination of them, called hybrids, can be used as aguideline during the ontology design process. They are summarized in Table 3.2.

Ontology tool editors

During the ontology engineering process, the experts may define their particular modelusing an entity-definition facility. Generally referred to ontology tool editors, these

3.2. Ontologies 55

Inspirational The inspirational approach starts from a premise about why an ontology

is required. It is produced by a single expert, and the resulting ontology

reflects an individual view point of the given area.

Inductive When using an inductive approach, the basis for the ontology design is

related to study of specific cases within the domain. The ontology is con-

structed by observing, examining, and analyzing a few special scenario cases

in the domain. The resulting ontological characterization of the initial cases

is then applied to other cases of the domain.

Deductive This approach begins with the adoption of some general principles and their

application to develop an ontology applicable to a specific case.

Synthetic The basis for this approach is the synthesis of a set of existing ontologies.

Each ontology provides a partial characterization of the domain but none of

the ontologies is a real subset of another one. The concepts are synthesized

from these existing ontologies and then adopted in the new ontology. The

resulting ontology usually reflects a common viewpoint of the experts of the

initial ontologies.

Collaborative With the collaborative approach, several domain experts join efforts to de-

velop the ontology. The result reflects multiple viewpoints, experiences and

backgrounds. This approach requires a consensus-building mechanism, such

as a Delphi method, in order to structure the collaboration. The resulting

ontology is then accepted if the involved experts belong to different research

areas, implying a committed viewpoint from the represented areas.

Table 3.2: General approaches for ontology engineering

facilities provide the means by which experts (the users) can interact with their on-tology representation. With these ontology editors, ontology engineers design, andmay even deploy, the ontology for its use, for instance, in agent systems, semanticweb services, knowledge bases, etc.

Several tools exist that support ontology design, each of them with advantages anddisadvantages [89, 90]. Ontology engineers then decide on the suitable tool, balancingaspects such as the required ontology representation, estimated size, complexity, andthe level of required formality, besides their syntactical, semantic, and pragmaticfeatures. The following ontology editors are among the most widely adopted tools:

Ontolingua and Chimera. Ontolingua is a software build at Stanford Univer-sity [91] as an ontology development environment. It provides a suite of ontol-ogy authoring tools and a library of modular, reusable ontologies. The tools inOntolingua are oriented towards the authoring of ontologies by assembling andextending ontologies obtained from a library.

Chimaera [92] is a tool built on top of Ontolingua. It supports the processof achieving consensus by geographically distributed groups for a common andshared ontology. Interesting features of Chiamera are the ability to merge mul-


tiple ontologies and to diagnose individual or multiple ontologies. Chimaeraassists its users in diverse tasks, including loading knowledge bases in differentformats, reorganizing taxonomies, resolving name conflicts, editing terms, etc.

OILEd. OILEd is the outcome of an open-source project that started at the Uni-versity of Manchester [93]. OILEd is an ontology editor that allows the user tobuild ontologies using DAML+OIL [94] language. The development of large-scale ontologies is not part of its goal, i.e. the ontology migration, integration,versioning, argumentation, and other advanced manipulation activities, are notactively supported by OILEd. The objective of OILEd is to be a simple appli-cation, offering just enough functionality for building ontologies and checkingtheir consistency.

Protege. Protege was initially developed at Stanford University from the point ofview of the medical informatics domain [95]. It offers mechanisms for ontologyconstruction and domain knowledge acquisition. The functionality of Protegeis improved through the extendable modules. Due to its popularity, severalmodules (or plug-ins) are available and supported by a large research commu-nity. Examples of these plug-ins include those for merging ontologies, databaseimport and export, query, graphical visualization of ontology trees, interactionwith reasoners, etc.

SWOOP. SWOOP is an ontology editor, developed by the University of Maryland[96]. It considers a hypermedia-inspired ontology editor that employs a web-browser metaphor for its design and usage. It attempts to be more effective(in terms of acceptance) for the average ontology engineer by presenting a sim-pler, consistent, and familiar framework for dealing with the entities. BasicallySWOOP is meant for rapid and easy development of OWL ontologies [97].

Triple20. Triple20, developed by the University of Amsterdam, uses a formal tripledata model to manage ontologies [98]. Each triple represents a statement be-tween a subject, an object, and a predicate that denotes a relationship. Triple20provides a range of visualization primitives that interpret the triple repositoryat different level of abstraction, ranging from access via diagrams to dedicatedOWL views. In general, the ontology tool tries to handle anything that can beexpressed in triples.

3.3 Ontology engineering in telecaring

Available ontology engineering processes have already been applied in building ontolo-gies in many different collaborative areas [48], leading to a general increase of ontologymodels. As a result, comparable but heterogeneous definitions have appeared withinsimilar domains, making any particular ontology difficult to adopt [99].

In case of the telecaring domain, and due to the variety of expertise involved,the same problem occurs and, thus, more than one ontology model is considered fordeveloping tele-assistance application systems [80]. One way to solve the problem of

3.3. Ontology engineering in telecaring 57

multiple definitions is to identify the correspondences between different ontologies.This identification is performed by an activity called ontology matching which isvery similar to the database-related schema matching. Assuming that the ontologymatching generates an initial telecaring model, other difficulties arise: how can thecare applications cope with the ever-changing structures of the telecaring ontology?or, how do providers or service suppliers extend the context of their applicationswithout altering the common ontology?

With the aim of providing methods to improve the usability of available ontologiesin the context of telecaring application development, we investigated several method-ologies and application cases of ontology engineering in the field. As presented inFigure 3.3, we identify three main stages grouping the steps to define an ontology:(1) ontology design, involving general steps to gather and integrate different telecaring-related schemas into a basic and initial ontology; (2) ontology evolution, a stage thatconsiders the activities that help the ontology to remain valid in the domain; and (3)data structure generation, involving the steps followed by the ontology engineers tohave the common ontology refined and fitted for their data storage needs. All threestages consider a number of intermediate steps and sub-steps. The following sectionsfocus on an overall view of these intermediate steps.

Ontology

Ontology

Design

Ontology

Evolution

Data Structure

Generation

Domain

Application

• Deployment of database or

knowledge base structures

• Rendering of programming entities

• Ontology sustains the domain

application or service TelecareServices

1

2

3

• Identify diverse panel of participants

• Define ontology purpose and the

collaboration effort

• Initial concept integration

• Iteration until consensus is reached

• Extending ontological terms

• Refinement of concepts

Figure 3.3: Generic framework for ontology usage


3.3.1 Ontology design

Ontologies are mostly defined by the ontology engineers (or domain experts) who havethe knowledge of the domain area. Ontology design involves several activities such asestablishing the ontology requirements and purpose, discovering and understandingontological properties, and reaching agreements and consensus among the experts.A common ontology is the outcome of this stage. This common ontology then be-comes the enabling factor allowing coordination and interaction among the telecaringexperts, while it is also used by developers to build their telecaring applications.

The representation of common ontologies in areas related to telecaring, as sug-gested in Section 3.2.1, has different precision complexity [99]. Care-related conceptsare represented differently in these ontologies, and happen to be typically heteroge-neous in each ontology. Figure 3.4 shows samples of concepts, from two telecaring-related ontologies, having different points of structural and semantic heterogeneity.

-Name-Birthdate-Blood type-Weight (lbs)-Sex-. . .

Elderly

-Street-City-Province-Postal Code-Country

Address

1 1

lives

at

Ontology-A Ontology-B

-Last name-First name-Age-Weight (kgs)-Gender-. . .

Elderly

-First name-Last name-email address-Phone number

Relative

1 1..*

lives

with

-Street-City-State-Zip Code-Country

Address

1 1

lives

at

Figure 3.4: Sample fragments of telecaring ontologies

In this example, the concept for elderly in Ontology-A has a different perspectivethan the same concept in Ontology-B. In Ontology-A, for instance, the concept forelderly has a direct association with the address and its definition is also linked to care-related information such as blood type or weight. On the other hand, in Ontology-B,although elderly is associated with care-related information, this concept is indirectlyassociated to address. The concept relative bridges elderly with an address, but thisconcept is not expressed in Ontology-A. Table 3.3 lists a number of conflicts betweenthese ontologies.

Resolving the conflicts among ontologies is both time-consuming and error-prone,mainly because the task is performed manually. This raises the importance of aligningontologies and, particularly, the activities related to ontology-matching. Approachesfor semi-automatic ontology-matching attempt to resolve the conflicts relying on ba-sic dimensions of similarity: syntactic and semantic characteristics of the involvedontologies [48]. The ontology-matching algorithms take into account several as-pects [100, 101], including the number of classes, the taxonomical structure of anontology, or the use of a lexical database (such as WordNet [102]).

3.3. Ontology engineering in telecaring 59

Different labels for the same concepts Sex vs. Gender, or

Province vs. State, or

Postal Code vs. Zip Code

Same label for different concepts City where the elderly lives vs.

City where the relative lives

Structural differences Name vs. First Name and Last Name,

Relative concept in Ontology-B

Different units weight in lbs. vs. weight in kgs.

Table 3.3: Example of conflicts between two ontologies

3.3.2 Ontology evolution

Ontology evolution corresponds to the dynamic process of updating and adjustingthe original ontology. This process occurs when new requirements to extend or addnew definitions appear, and is performed by the ontology engineers. There are severalreasons to adjust to new requirements; some VO partners may need to conform theirproducts to new specifications, or need to share information with others outside ofthe VO, etc. According to [103], VOs are not inflexible collaborative structures withrigid frameworks, rather they are heterogeneous ensembles that continuously evolveover the time. On the other hand, a basic ontology often contains mistakes or doesnot meet entirely the needs of final users. The VO (or its goals) can also change,forcing the base ontology to adjust. New design or technical issues may also have tobe addressed in the ontology at a later stage.

Though most of the available ontology engineering methodologies mention theontology evolution as the continuous refinements of the base ontology, this stage canalso be interpreted as a kind of maintenance; namely corrective, adaptative, perfectiveor preventive maintenance [104].

Unfortunately for the ontology engineers, the current ontology tools do not provideenough support for ontology evolution [105]. Thus, the lack of support for conceptrefinements makes ontology evolution more troublesome and error-prone.

3.3.3 Data structure generation

The ontology is an abstract model that depicts the domain concepts and their de-pendencies without specifying any particular information about their representation.Ontologies enable conceptual modeling, however, the management of the information(i.e. storage, retrieval, querying, etc., of data instances) is typically outside the scopeof ontology modeling. Database schemas, knowledge models and other program struc-tures are, on the other hand, executable units required for an application environment.The activities that allow ontology engineers to transform an abstract ontology into aconcrete repository are considered part of the data structure generation.

Data structure generation is concerned with activities related to the mapping of theabstract ontology to the concrete physical repository, being a database or knowledge


base. It involves tasks that define program structures, technical diagrams, designsand other implementation details. The ontology engineers usually generate either aknowledge base or a database repository based on the ontology model, and then allowthe domain users (or domain applications) to employ portions, or all, of the facility.No direct process, however, exists to interpret an arbitrary (syntactic) representationof the ontology and create the schema for a database.

Ultimately, all access to retrieve information from any system is evaluated againstthe underlying physical data structures. The requesters are however aware of theontological definitions, thus, they may apply semantical search on the gathered data.In this context, ontology serves as initial step to process, to organize, to structure,and even semantically query information found in typical information systems.

Knowledge bases

One way of administering content is by using a knowledge base management system.In this way, the ontology provides the structural definitions while knowledge basessupport the data handling.

The main disadvantage of generating data structures into a knowledge base is thatthese systems currently have certain limitations as data repositories. Some of theselimitations include the low data consistency, weak typing, minimal security mecha-nisms, lack of transaction management, etc. Avoiding these limitations is crucial forthe telecaring domain since many parts of its information require the highest security,privacy and robustness available [21].

Database repository

Another way to address the content management is by using a database system. Thedata structure generation then aims to translate the ontology model into valid schemasfor database systems.

From another point of view, these systems can cope with most of the data require-ments for the telecaring applications. Databases provide a convenient and efficientenvironment to manage domain information, but are insufficient to provide semanticinformation. The database schemas, alone, are not expressive enough to describeboth structural information and the semantics of the entities, thus they do not createsufficient value for semantic reasoning.

The conversion of an ontology to a database schema is not straightforward. Thereare technical differences between models that are difficult to translate. Another prob-lem relates to data modeling, which is a task limited usually to database experts.They have skills and proficiency on database languages but lack the knowledge andexpertise of the application domain. Besides, the absence of facilitating or automaticsupport makes the data structure creation a time-consuming and error-prone processfor ontology engineers.

3.4. Automation of database schema generation 61

3.4 Automation of database schema generation

The purpose of automating the generation of database schemas is to provide a gentlelink from the ontology world, where experts produce the natural representation ofthe domain, to the database world, where efficient methods are used for storage andretrieval of persistent data. Figure 3.5 gives an overview of the aim of an automaticgenerator to map an ontology to a relational database schema.

Person

Photo

ElderlyAddress

Relative

Country

Street

Ontology

Database

Tables

Objects

Automatic Translation

Elderly

PK OID

LastName

FirstName

Weight (kg)

Birthdate

. . .

Photo

PK OID

Format

Size

Source

. . .

Relative

PK OID

LastName

FirstName

Residence

PhoneNumber

. . .

Address

PK OID

Street

PostalCode

Province

Country

Figure 3.5: Partial translation of an ontology to a relational schema

For the automatic generation to be successful, it requires surpassing a number ofchallenges. Since most of the ontology editor tools use an underlying object-orientedapproach to represent their models, one important challenge is the translation froman object-oriented ontology to a relational schema [106]. To ease the burden of suchtranslation, a series of transforming steps are required by the automatic generator.

3.4.1 From the object-oriented to the relational paradigm

While the object-oriented ontology supports definition of entities and concepts asobjects, described by their structure, semantic, and behavior, the relational databaseschema supports data definition with flat table-based structures.

Object-oriented models are based on the description of objects. The object is con-stituted by properties, also expressed as attributes or variables, and behavior, which


are methods or operations that control the properties. The act of enclosing the prop-erties and their behavior into an object is referred to encapsulation. A class is definedto specify a set of objects with similar characteristics. A class generally defines theproperties and the behavior common to all objects of a certain kind. Classes pro-vide the benefit of reusability, which is particularly useful for modeling inheritance.Inheritance allows subclasses to be specified in terms of other superclasses, and thusorganization of classes into a hierarchy. Apart from inheritance, there are severaltypes of relationships to define a connection between clases. Examples of relation-ships include associations, generalizations, dependencies, realizations, and transitions.Information from objects is generally accessed by traversing through the object’s rela-tionships. Basically, an object-oriented model identifies the main classes in a domainand contains a set of use case realizations that describe how the model is applied.

In a relational model, the data repository is established by a collection of tables. Atable is a flat record-structure comprised of a set of columns and an arbitrary numberof rows. Columns defines the attributes of the table and the rows represent instancesof the entity stored by the table; the intersection of a column and row is referred todata value. The set of columns that uniquely identify a row in each table is called theprimary key. Relationships are associations that occur between two or more tables. Aforeign key is a column attribute that relates a row in one table with a row in anothertable. Foreign keys are fundamental to the relational model because they enable tablesin the database to be related with each other. Hence, the information is accessed byperforming queries that join two (or more) tables. Most relational databases supportthe management of tables with SQL, a well-known database language.

When establishing the translation steps for an automatic generation, the rela-tional structures should be defined without weakening the structures specified in theobject-oriented ontology. The underlying structures of the paradigms, however, can-not be converted seamlessly without leading to a conflict between the models, whichis known as impedance mismatch [40, 107]. Although there are some fundamentaldifferences that automatic generation cannot overcome or translate, it is possible tomake intelligent tradeoffs to tackle several of the problems of impedance mismatch.

Mapping rules

The tradeoffs of dealing with this impedance mismatch include a number of mappingaspects, found in [108, 109]. These mappings refine the translation between the objectsand their relational counterparts. Table 3.4 lists some of the most important mappingconsiderations from an object-oriented model to a relational one, which are furtherdescribed in the following paragraphs.

Concepts. An object-oriented ontology describes complex concepts as a compositionof simple concepts. Concepts are modeled as classes. For example, a care centermay be characterized in terms of other classes such as roof, floors, foundation,walls, windows, bedrooms, and so on. A bedroom may in turn be composed ofwalls, ceiling, floor, windows, and doors. For the automatic generation, bothclasses and their properties are considered as “primitive” elements. There are


Classes Strong and weak entities (tables).

Object ID (OID) Primary key.

Properties Attributes forming table columns.

Inheritance One table per class hierarchy, or

One table per concrete class, or

Reference from the strong to the weak entity.

Relationships Depending on cardinality of the relationship and

how entities participate.

1:1 Relationship Foreign key constraint.

1:N Relationship Foreign key constraint, or

Relationship table.

N:M Relationship (Reification) Relationship table.

Constraints Depending on the supported relational model:

Uniqueness, Nullableness, default values, range of

values, enumeration, etc.

Behavior It is possible to generate behavioral rules as stored

procedures and triggers.

Semantics Textual descriptions of tables and columns, or ad-

ditional annotation tables.

Table 3.4: Mapping rules between an object-oriented model and a relational schema

strategies by which the automatic generation can translate a complex conceptinto a relational form.

• Mapping of classes. The strategy involves creating one table per class.Once a table is defined, the automatic generator can continue mappingspecific class properties. Only simply ontologies, however, will generate aone-to-one mapping of classes into tables. Relationships and inheritancemay affect the translation of the table.

• Mapping of properties. The properties of each class are translated intozero or more columns. While certain ontology definitions allow certainambiguity (e.g. using the abstract types), relational databases enforce astrong typing, which demands to specify the ‘data type’ for every column.In such cases, the automatic generator can specify a default data type forthe column, or decide not to create a column for the property.

• Object identifiers (OID). Each object instance has a special property knownas an object identifier (OID), which is used as a way of uniquely identifyinga particular object. OIDs do not depend on data from the object, and, assuch, they are often not considered during the modeling. In relationalterminology, the unique identifiers are known as key attributes. A primarykey (PK) is an attribute that uniquely identifies a record in a table.Therefore, an OID may be mapped into the primary key column(s) in a


table. The column name and data type assigned to the PK attribute maybe customized before the automatic translation by the generator interface.In general, OIDs make storing references to other objects in the databasesimpler but may cause technical problems. Referential integrity can beaffected if an object is deleted while other objects still have references toits OID. Ontology engineers thus should adopt a strategy for dealing withOIDs, and the way of assigning the OID values and the level of uniqueness(class, class hierarchy, or across all classes).

• Hierarchies. There are three well-known strategies for implementing in-heritance structures of object-oriented models into a relational database:

1. One table per entire class hierarchy. A complete class hierarchy canbe mapped into one table, by including all the properties of all classesas columns of this table. Clearly, this strategy wastes a lot of spaceand the table name should represent all classes in the hierarchy.

2. One table per concrete class. An automatic generator can include boththe attributes and the inherited attributes of the class into one table.This approach is perhaps the easiest way to implement but there areseveral important drawbacks regarding maintainability. For instance,if there is ontology evolution and ontology experts add another prop-erty to the superclass (or simply change its value) they need to replicatethe modification in all the subclasses as well.

3. One table per class using relationships. This strategy takes advantageof the OIDs to greatly simplify the translation process. To translatea class hierarchy, as shown in Figure 3.6, an automatic generator cancreate one table per class, with the attributes of that specific class,and establish a relationship among the tables of the subclass and thesuperclass. The relationship is maintained through the usage of theprimary key (PK) and the foreign keys (FK). From our point of view,this approach follows the original object-oriented model better thanthe other strategies.

Ontology Relational

SchemaPerson

PK OID

name

phoneNumber

Elderly

PK,FK1 OID

prescription

CareGiver

PK,FK1 OID

employee_ID

preferences

-name-phoneNumber

Person

-prescription

Person::Elderly

«inherits»

-employee_ID-preferences

Person::CareGiver

«inherits»

Au

tom

ati

c T

ran

sla

tio

n

Figure 3.6: Mapping the class hierarchies


Relationships. In contrast to the inheritance relationships, where a class “is a” sub-class of another, an association is a special kind of relation where two classes areconnected to each other as one being “part of” another. When two classes arelinked but they are normally viewed as independent classes, their relationship isconsidered as an association. The main challenge to map association relation-ships is related to the proper translation of the cardinality of the relationship.

• One-to-one relationships. By exploiting the use of the OIDs, an automaticgenerator can implement one-to-one relationships by including the OID ofone table into the other table (See Figure 3.7).

Ontology Relational Schema

Au

tom

ati

c T

ran

sla

tio

n

-name-phoneNumber-email address-birthdate-. . .

Elderly

-street-city-province-postalcode-country

Address

1 1

lives at

Elderly

PK OID

name

phoneNumber

email address

birthdate

. . .

Address

PK OID

FK1 elderly_OID

street

city

province

postalcode

country

1 has 1

Figure 3.7: Mapping one-to-one class relationships

• Many-to-many and one-to-many relationships. In order to implement amany-to-many relationship, the automatic generator can use a relationshiptable, as shown in Figure 3.8. The purpose of the relationship table isto provide the link between two or more tables. The relationship tablecontains, at least, the keys of the tables involved in the relationship.

Ontology Relational Schema

Au

tom

ati

c T

ran

sla

tio

n

-name-phoneNumber-email address-birthdate-. . .

Elderly

-description-type

Disability

0..* 0..1

afflicted

with

Elderly1

PK OID

name

phoneNumber

email address

birthdate

. . .

Disability1

PK OID

description

type

. . .

RL_afflicted_by

PK OID

FK1 Elderly_OID

FK2 Disability_OID

0..* 0..*

Figure 3.8: Mapping one-to-many and many-to-many relationships

The schema generator can either include the OID of one table into theother table, or use the strategy of creating a relationship table for handlingone-to-many relationships. The later option gives further flexibility to addmore columns or references in future.

Constraints and behavior. Optional constraints and behavior on classes and theirrelationships are a set of rules that determine the conditions under which a de-


pendent class may be inserted, updated or deleted. The rules deal also withthe restrictions the parent class imposes upon the dependent one. Simpler con-straints are related to integrity rules that define valid values that the attributescan assume. For example, some value constraints are maximum or minimumvalues for numeric types, default values, enumeration of strings, allowable valueranges, value uniqueness, whenever a value can be null or not, etc.

The rules in general can be mapped as extended referential integrity on the re-lational database, however, they may not be supported by all database systems.An alternative is to generate them in the form of stored procedures or triggers.

Semantics within the database repository. Some current database engines cansupport some level of semantics. For instance, if a RDBMS follows the ANSIstandard X3.135-199, it can store textual descriptions about the semantics ofdata structures (e.g. tables, columns, keys, etc.). Thus, if the ontology includestextual description of classes and attributes, then it is also possible for theautomatic generator to produce these semantics in the database repository.

Clearly, it is also possible to create a set of tables that contain the text descrip-tions. These tables have the semantics of the model although they are not partof the original model.

3.4.2 Deployment of data structures

Data structure generation is also concerned with the construction of source code. Ifthe automatic generator is flexible enough, it may be possible to consider it for thecreation of code related to the data structures in order to minimize the developmenteffort. It may be possible to describe the ontology in other terms and models, whichare suitable for data sharing with systems or users outside the VO.

Provision of Java source code

The generator may provide code in Java language for telecaring applications. Sincemost ontology systems and Java support object-oriented paradigm, the generation ofsource code is more straightforward than the generation of relational schemas.

Nevertheless, there are several issues that require attention or cannot be handledby the automatic generator, due to the technical incompatibilities. These incompati-bilities include features that are available in the ontology models, such as support tomultiple class inheritance, but are not supported directly by the Java environment.

Even some of the value constraints on attributes can be converted to Java prop-erties, but no constraints can be enforced unless specific code is also generated. Forinstance, it is difficult to map an enumeration of strings without generating specificvalidity code. On the other hand, when generating the Java source code, it is possibleto take advantage of some features offered by schema generator such as: (1) Javapackage definition, (2) on-line Java compilation, and (3) Java jar encapsulation.

3.5. Conclusion 67

Generation of XML Schema

Many organizations and enterprises use XML documents, as a format to exchangeinformation. XML documents are widely used to facilitate this exchange because theyare both human-readable and machine-readable. The extensibility of XML allows thecreation of generic models that integrate data from different sources.

XML Schema is a data structure definition language for XML documents [110].Due to the importance of XML in the telecaring sector, the XML Schema can be alsoproduced automatically using the ontology. The XML Schema supports the repre-sentation of the object-oriented paradigm better than the relational system. Similarto Java code generation, however, there are still several issues that cannot be at thisstage equivalently translated, including value constraints or multiple class inheritance.

3.5 Conclusion

It is now widely acknowledged that ontologies can make a significant contribution tothe design and implementation of information systems in the telecaring field.

This chapter reviewed fundamental issues in ontology design and demonstratespractical effectiveness by means of using the ontology to generate data structuresfor the domain. It explored further the automatic generation of relational databaseschema, which is especially important in the telecaring domain, since it allows theinformation to be managed in traditional -relationaldatabase systems.

An aspect that separates the presented approach from many other system develop-ment approaches is the application of ontologies. Application developers benefit notonly from understanding concepts but also from the data structures created from theontology. Ultimately, the development of telecaring services, using the ontology-basedsupport, avoids common development and maintenance problems.

The automatic and dynamic generation of data structures allows the applicationexperts and software developers to solely concentrate their efforts on the ontologymodeling, and not on syntactic definition of data. An automatic generator then freesthese developers and application experts from the burden of knowing the technicaldetails for developing the database structures, Java code, or XML Schema.

There are some limitations to our approach. First, further research is required toovercome problems associated to ontology evolution. A relational database focuseson a stable run-time system (efficiency, adaptability, fault-tolerance, etc.) and, thus,substantial alteration of the database schema is not well supported. The support ofevolution of ontologies and relational models is still an area of research.

The conversion between the ontology and the relational structures is not flawless.Solving the impedance mismatch problem for object-oriented models requires recog-nition of the difference in scale between object-oriented applications and relationaldatabase systems, and not only reliance on mapping rules. In particular, direct en-coding of the behavior of objects into the database (i.e. stored procedures) is notpossible without running into the impedance mismatch problem. A set of technicaldecisions, therefore, must be made on information that can be extracted from theontology and placed into the corresponding relational schema. Ontology engineers


should consider general recommendations, if they ultimately decide on an automaticgeneration. Simple suggestions include the following:

• the OID should not have any application meaning and be at least unique withina class hierarchy,

• it is also possible to map behavior of classes as stored procedures, however, wedistance ourselves from this approach since it reduces the application maintain-ability,

• if possible, to use one table per class using relationships to translate class hier-archies, and

• to establish a set of referential rules to handle class relationships.

Chapter 4

Agent-based service-orientedresource management fortelecaring

4.1 Introduction

Building advanced applications for tele-assistance and tele-monitoring, able to usenumerous devices, while they interoperate with other applications, is highly com-plex. Although a network enables connectivity among resources, it extremely difficultto achieve interaction among such variety of elements, since current communicationmechanisms of devices and applications have each evolved mostly in an independentand isolated way. This aspect leads for example to a poor reusability of resources,which becomes a serious bottleneck when considering the continuous development ofcare facilities and care services supporting independent living and care at home (e.g.the emerging domotics).

Several new interfaces to interact with sensors, monitoring devices, and other hard-ware (home appliances, environment controllers, etc.), and software components areneeded by developers of telecaring services, to facilitate the reuse of the functionalityof the resources. These interfaces shall hide aspects such as low-level protocols, wire-based or wireless communications, etc. If these interfaces are achieved and placed,e.g. in intelligent homes or local domotics networks, developers can build upon theirtelecaring applications on top of them easier.

Having in mind the scenario of different organizations developing different prod-ucts and services (in a variety of areas) for telecaring, there is a need for a commonplatform into which all these developments can be plugged so that reusability andinteroperability become possible. For this common platform, we suggest to applyan agent-based approach to handle telecaring resources, so that those responsible forproviding remote care can handle them as agents. A key purpose of this approach isintegrate telecaring resources in a plug-and-play manner.

69

70 Chapter 4. Agent-based service-oriented resource management for telecaring

Although it is possible to achieve some degree of interconnectivity between agents,the Multi-Agent Systems (MAS) technology has not so far completely resolve the prob-lem of managing resources that use incompatible frameworks. To solve this problem,our approach suggests to build loosely coupled, and dynamically bound, services basedon the functionality and characterization of the resource. This is represented in thischapter by a Service-Oriented Architecture (SOA), derived from a paradigm of self-contained and modular services. These services are accessible within the networkedenvironment and provide a set of functionalities (or operations) to different but spe-cific (authorized) users [111]. Some insights about how to deploy services, based ontheir descriptions, within the Virtual Organization (VO) environments, are presentedin [112]. Therefore, by using a SOA, we attempt to achieve proper interoperabilityby allowing “pluggable” developments, and reuse of them for the sake of telecaringapplications, all within a configurable agent-based environment.

This chapter addresses a possible solution to the set of questions under RQ4,introduced in Chapter 1. To accomplish this aim, Section 4.2 introduces the keyconcept of telecaring resource. Based on this concept, the service-oriented model thatapplies the agent paradigm is presented in Section 4.3. The Section 4.4 focuses on thedetails of the main actor involved in the suggested model, while Section 4.5 addressesthe key agent-based component handling the negotiation and brokerage of resources.Finally, Section 4.6 concludes this chapter.

4.2 Telecaring resources

A telecaring resource is basically a hardware or software component providing certainexternal functionality or information, that is made available through a VO network ofremote care. Personal care devices are important telecaring resources since they allowpersonal health monitoring, in the form of fixed portable prevention or measurementsystems (such as advanced sensors, transducers and PDAs). Devices, sensors, moni-toring apparatuses, and other pervasive hardware such as home appliances, environ-ment controllers, ubiquitous devices, etc., represent examples of hardware resources.Other possibilities include care monitoring components able to supervise, prevent, oreven treat elderly at the point of need, by means of software applications.

Consider the scenario of remote monitoring of a diabetic elderly. Telecaring devicesmeasure pressure, temperature, and humidity of the person. The measured dataare sent to the remote care center where they are analyzed by specific telecaringservices. We distinguish therefore two different kinds of telecaring resources: allhardware resources used for home domotics are categorized as devices, while thesoftware resources provided to users through the VO infrastructure are classified astelecaring services. Both devices and telecaring services have to be accessible toeveryone authorized, whenever and wherever they need them inside the VO.

4.3. Telecaring resource model 71

4.2.1 Agent-based resource management

An interface is needed for an application to interact with a telecaring resource. Wepropose an agent-based component as the entity that interacts, performs, and controlsall the actions on the resource, on behalf of the requester application. Thus, the detailsof the resource (its running code and its data) are hidden from the rest of the systembehind this agent, which acts as a proxy of the resource.

Although resources themselves, being devices or telecaring services, are not nec-essarily implemented as agents, every resource in our approach requires a REsource-Manager Agent (REMA) to communicate. This means that every telecaring resourcehas an agent-based interface, which allows the resource to interact with other agentsinside the VO, as shown in Figure 4.1

Resource

Manager D1

Resource

Manager D2

Resource

Manager Dn

Device D1 Device D2 Device Dn...

UPNP JINIDedicated

protocol

Resource Manager S1

Resource Manager Sk

Homogeneous

dealing of resources

TelecaringService S1

Telecaring Service Sk...

SOAPFIPA ACL

Figure 4.1: Dealing with heterogeneous resources in a homogeneous way

An advantage of introducing the REMA is the ability to encapsulate all resourcefunctionality. As such, a REMA for a telecaring device translates and hides the specificlow-level protocols, APIs, etc., of the device into common and generic agent interfacingprotocols. On the other hand, the REMA for a telecaring service interfaces thefunctionality offered by a telecaring application within the VO environment. Clearly,each REMA can be implemented to offer some or all functionality offered by thetelecaring resource, if its developer wishes to do so.

4.3 Telecaring resource model

The telecaring resource model facilitates the development of applications and increasesthe interoperation of services for telecaring of the elderly [113]. The architecturalconcept behind the telecaring resource model is the SOA paradigm [111, 114], inwhich a registry advertises descriptions of the services. This registry can be used to


search and select individual services to combine them in a high-level application [115].For example, the Open Grid Services Architecture (OGSA) represents an example ofapplying SOA principles to support the creation, maintenance, and application ofensembles of services (Grid services) maintained by VOs [116].

The telecaring resource model first assists developers by enabling them to choose,configure, and assemble their own telecaring services and care devices based on alreadyavailable resources. Second, any intelligent agent can select and investigate any device,or telecaring service, by using a set of functions or rules, eliminating the need forhuman beings to translate the conversation, fostering new interactions. This modelis meant for developing composite and workflow applications, which can orchestratethe runtime behavior of the resources involved according to a flow description.

We extended the SOA concept to provide agent-based access to the resource de-scriptions, and definitions of access rights to telecaring resources, by using the cre-dentials of the agents. The approach models the interactions between the telecaringresources and the involved actors. As shown in Figure 4.2, actors are the resourceprovider, resource broker and resource requester, while the basic resource activitytasks are description, advertisement, discovery and invocation and execution. Therest of this section focuses on the activities related to our model, while Section 4.4focuses on the collaboration among the participating actors.

ResourceBroker

Resource Catalogue

ResourceRequester

Execution

Advertisement /

Publishing

Resource + service information

Discovery

Invocation

+ Binding

Resource description

ResourceProvider

Figure 4.2: Service-oriented model

4.3.1 Description

Standard technologies to describe the resources are adopted to allow interactionsamong the actors. The usage of standards enables resource providers to implementand develop their resource description and internal functionality relying in interoper-ability.

Rather than creating another isolated set of service descriptions in the telecar-ing domain, we adopt specifications and standard protocols that are already well-known. These descriptions however must be expressive enough to allow the usageof resources in device-to-device, device-to-telecaring service, and telecaring service-to-telecaring service interoperability in a scalable multi-agent environment.


As illustrated in Figure 4.3, the description of a resource comprises provider-specific information, like the model name and number, serial number, manufacturername, URLs to vendor-specific web sites, etc. This description includes the internalfunctionalities supported by the resource, by listing the series of commands or actionsand how the resource service responds to those commands. Clearly, the parametersand arguments must be defined to properly invoke each action. The resource descrip-tion may also contain rules for protection and access rights, defining proper credentialsfor message integrity, message confidentiality, and message authentication.

Resource DescriptionResource Description

Provider specific informationProvider specific information

Security LayerSecurity Layer

Internal functionalityInternal functionality

Service description+ List of commands

+ Arguments

+ Parameters

+ Responses

+ . . .

+ Security parameters

Resource details+ Manufacturer name

+ URL vendor

+ . . .

+ Model name

+ Serial number

Figure 4.3: Resource description

The descriptions of telecaring resources provide documentation for developers toprogram properly their components. They learn the basics for communication, invo-cation, and exchange of messages with the resource. Those descriptions also raise theinterest of automating the process of accessing resources with intelligent agents, sinceless human intervention to establish a collaborative environment is needed.

Since there are two kinds of resources in the telecaring model, the selection fora resource description or standard for the design of the resource is two-fold. First,the search for standards describing protocols and schemas for “devices” and second,establishment of widely know standards to describe the “telecaring services”.

Device description

A device description specifies all valid properties, operations, and intermediate ex-pressions, for a target care device. The Universal Plug and Play (UPnP) DeviceArchitecture [117] is a standard that suits the telecaring resource model, since it pro-vides a reference to defining descriptions for home devices. It is intended for pervasivepeer-to-peer network connectivity of intelligent appliances, wireless devices, and anyother hardware component proposed by the UPnP Forum [118]. Its design goal is tobring easy-to-use, flexible, standard-based connectivity to ad-hoc networks whetherat home, in a small business, or in public places.

UPnP is an extension of the plug-and-play peripheral model. It is designed tosupport minimal configuration, transparent networking, and discovery for a range ofdevices from different vendors. It provides mechanisms for a device to dynamicallyjoin a domotic network, obtain an IP address, advertise its capabilities, and learnabout the presence and capabilities of other devices. It has been explicitly designed


for an environment where a Domain Name System (DNS) is employed as centralpoint, using the Dynamic Host Configuration Protocol (DHCP), while the devicesare attached and connected via Internet. The telecaring resource model, however,only applies the UPnP device description, since other communication infrastructurefunctionalities are adopted from the MAS paradigm.

Using UPnP, resource providers define a description per device. This descriptionis partitioned into two logical parts: a device that defines the physical and logical con-tainers, and one (or more) device-service that establishes all the capabilities exposedby the device.

Device. The description is based on the UPnP Device Template and derived fromstandard constructions in XML Schema. A device definition includes a devicetype identifier, the fixed elements in the description document, the requiredset of device-service definitions, and the hierarchy of devices and device-servicedefinitions. Figure 4.4 presents the XML syntax of the device description.

Device-service. Each device-service description corresponds to a Service ControlProtocol Declaration (SCPD), which comprises a list of commands and actionsthat the device-service responds to. Parameters and arguments for each com-mand are also specified by the SCPD, as well as a list of ‘exposed’ variables.The variables model the state of the service at run time, and are described interms of their data type, range, and event characteristics. Similar to the devicedescription, the SCPD is represented with XML syntax and based on the UPnPService Template. The UPnP Forum working committee produces this templatederiving XML standard constructions and extending it with human language.Figure 4.5 presents the XML syntax for device-service descriptions.

Telecaring service description

For the description of telecaring services, we consider the adoption of those usedfor Web Services. The Web Services Description Language (WSDL) [119] is the defacto standard Web Services description format. WSDL uses the XML format fordescribing services as a set of endpoints operating on messages, that contain eitherdocument-oriented or procedure-oriented information. The operations and messagesare described at a high level of abstraction, and then bound to a concrete networkprotocol and message format to define an endpoint. Currently, SOAP is used as thisconcrete network protocol [120], but agent languages are considered for the telecaringresource model. Related concrete endpoints are then combined into abstract end-points. WSDL defines a Web Service as an endpoint that operates on XML messages.

Table 4.1 describes each one of the XML elements of the WSDL document, whileFigure 4.6 shows an example of a WSDL document that represents a special case ofa service that spells numbers, called “NumberSpeller”.

WSDL is extensible to allow description of endpoints and their messages regard-less of what message formats or network protocols are used to communicate. Thisfact makes it ideal to be used in conjunction with agent mechanisms. Furthermore,the WSDL syntax allows both the messages and the operations on the messages to


<?xml version="1.0"?><root xmlns="urn:schemas-upnp-org:device-1-0">

<specVersion><major>1</major><minor>0</minor>

</specVersion><URLBase>base URL for all relative URLs </URLBase><device><deviceType>urn:schemas-upnp-org:device:deviceType :v</deviceType><friendlyName>short user-friendly title </friendlyName><manufacturer>manufacturer name </manufacturer><manufacturerURL>URL to manufacturer site </manufacturerURL><modelDescription>long user-friendly title </modelDescription><modelName>model name </modelName><modelNumber>model number </modelNumber><modelURL>URL to model site </modelURL><serialNumber>manufacturer's serial number </serialNumber><UDN>uuid:UUID</UDN><UPC>Universal Product Code </UPC><iconList><icon>

<mimetype>image/format </mimetype><width>horizontal pixels </width><height>vertical pixels </height><depth>color depth </depth><url>URL to icon </url>

</icon>XML to declare other icons, if any, go here

</iconList><serviceList><service>

<serviceType>urn:schemas-upnp-org:service:serviceType :v</serviceType><serviceId>urn:upnp-org:serviceId:serviceID </serviceId><SCPDURL>URL to service description </SCPDURL><controlURL>URL for control </controlURL><eventSubURL>URL for eventing </eventSubURL>

</service>Declarations for other services defined by a UPnP F orum working committee (if any) go hereDeclarations for other services added by UPnP vendo r (if any) go here

</serviceList><deviceList>

Description of embedded devices defined by a UPnP F orum working committee (if any) go hereDescription of embedded devices added by UPnP vendo r (if any) go here

</deviceList><presentationURL>URL for presentation </presentationURL>

</device></root>

Figure 4.4: UPnP Device Template

be abstractly defined and, in this way, they can be mapped to multiple physicalimplementations [121].

4.3.2 Advertisement and publishing

Advertisement is a key operation of the resource model, since a provider can use thisoperation to inform interested parties, within a VO, of the existence of a specific ser-


<?xml version="1.0"?><scpd xmlns="urn:schemas-upnp-org:service-1-0"><specVersion>

<major>1</major><minor>0</minor>

</specVersion><actionList>

<action><name>actionName</name><argumentList>

<argument><name>formalParameterName</name><direction>in xor out</direction><retval /><relatedStateVariable>stateVariableName</relatedStateVariable>

</argument>Declarations for other arguments defined by UPnP Forum working committee (if any)go here

</argumentList></action>Declarations for other actions defined by UPnP Forum working committee (if any)go hereDeclarations for other actions added by UPnP vendor (if any) go here

</actionList><serviceStateTable>

<stateVariable sendEvents="yes"><name>variableName</name><dataType>variable data type</dataType><defaultValue>default value</defaultValue><allowedValueList>

<allowedValue>enumerated value</allowedValue>Other allowed values defined by UPnP Forum working committee (ifany) go here

</allowedValueList></stateVariable><stateVariable sendEvents="yes"><name>variableName</name><dataType>variable data type</dataType><defaultValue>default value</defaultValue><allowedValueRange>

<minimum>minimum value</minimum><maximum>maximum value</maximum><step>increment value</step>

</allowedValueRange></stateVariable>Declarations for other state variables defined by UPnP Forum working committee(if any) go hereDeclarations for other state variables added by UPnP vendor (if any) go here

</serviceStateTable></scpd>

Figure 4.5: UPnP Service Template

vice. In order to allow developers and other users to interact with a specific resource,the resource provider must publish the description of the resource to a resource bro-ker. The publishing refers to task of advertising the resource’s capabilities to thebroker. The broker structures the service information in a repository and exposes theinformation to all requesters.

To allow discovery services to deal naturally with dynamic service availability, the


definitions A definitions element at the root level contains all the other elements

in the WSDL document.

imports It points to the location of type definition and element declarations

contained in other files. Using imports enables developers to separate

different elements of a service definition into independent documents,

in a modular approach (using imports is not mandatory).

types It defines the data type definitions used to describe the parameters in

the messages exchanged, in the form of an XML Schema.

messages It defines abstract definitions of the data being transmitted. A message

consists of logical parts, each of which is associated with a definition

within some type system.

operations A operations element contains abstract definitions of actions supported

by the service, such as naming a method, message queue, or business

process that will accept and process the message.

port types A port types element has sets of abstract operations supported by one

or more endpoints. Port types defines the collection of operations for a

binding. Because it is abstract, a collection of operations can be mapped

to multiple transports through different bindings.

bindings It defines the physical protocol and data format that is used, and how

the port type is mapped onto a particular transport protocol.

ports A port establishes the address of a single endpoint, defined as a com-

bination of a binding and a network address. The port is the target

address of the service communication.

service A service is a collection of related endpoints encompassing the service

definitions in the document. Services map the binding to the port and

include any extendibility definitions.

Table 4.1: Elements of the WSDL Specification

advertisement must be periodically refreshed [116]. For instance, when a resource isremoved from the VO, it should first revoke its advertisement. The resource provider(or the resource itself) should send a proper announcement of the unavailability to theresource broker, in order to effectively declare that the resource is no longer available.

Access rights definition

The resource provider should establish proper access rights for the resource, togetherwith the advertisement, based on the credentials of the resource requesters [122].Then, if using agent paradigm, for example, the access rights for every telecaringresource are established through the type of the agent, user type, user id, and soforth, of or authorized users.


<?xml version="1.0" encoding="UTF-8" ?> <definitions name="NumberSpeller-interface"

targetNamespace="http://www.NumberSpeller.com/NumberSpeller-interface" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.NumberSpeller.com/NumberSpeller-interface" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<message name="InMessageRequest"><part name="numberToConvert" type="xsd:string" /> <part name="encodedlocale" type="xsd:string" />

</message><message name="OutMessageResponse"><part name="outMsgText" type="xsd:string" />

</message><portType name="NumberSpeller"><operation name="getSpelledForm"><input message="tns:InMessageRequest" /> <output message="tns:OutMessageResponse" />

</operation></portType><binding name="NumberSpellerBinding" type="tns:NumberSpeller"><soap:binding style="rpc"transport="http://schemas.xmlsoap.org/soap/http" />

<operation name="getSpelledForm"><soap:operation soapAction

soapAction="http://www.NumberSpeller.com/getSpelledForm" /><input>

<soap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:numberspeller" use="encoded" />

</input><output>

<soap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:numberspeller" use="encoded" />

</output></operation>

</binding><service name="NumberSpeller"><documentation>The NumberSpeller web service can be used to transforman integer number to a text string containing its spelled form (forexample, "1" is transformed to "one").

</documentation> <port name="NumberSpellerPort" binding="tns:NumberSpellerBinding"><soap:address location="http://www.service.org/numspell/ " /> <documentation>SOAP Port for the NumberSpeller service</documentation>

</port></service>

</definitions>

Figure 4.6: Example of WSDL description

4.3.3 Discovery

The discovery is the process of finding candidate resources and their respective ser-vices. It allows resource requesters to search for resources of interest on the networkedenvironment by submitting a specific search request to a resource broker. This mes-sage usually contains the type or the identifier for the target resource. The responsesfrom the resource broker are answer messages with the specification of the resource(or resources), identical to how it is advertised by the resource provider.


To retrieve a UPnP device description, the requester issues a query for the resourceusing the Simple Service Discovery Protocol (SSDP). SSDP enables applications, orresources, to learn of the existence of potential peer devices and the required informa-tion needed to establish connections to them. In response to a SSDP search, UPnPdevices return their description and optionally the binding headers (meant for invo-cation). The device and service descriptions may be retrieved at any point, since thedevice and service descriptions are static, i.e. the descriptions are available as long asthe device and its services are available in the central point of the site. On the otherhand, WSDL standard does not specify any mechanism to retrieve service descrip-tions. Although the discovery is then unrestricted to any tag or value, it is usuallyperformed on the port type tag, to find similar service descriptions in a WSDL repos-itory. A port type is a named set of abstract operations and the abstract messagesdefined within in the enclosing WSDL document. The search queries are commonlybased on XML query languages, and responses comprise the entire, or part of, theWSDL document.

During the resource discovery, the requester learns about the resource and un-derstand (or verify) the proper way to invoke the internal services. In the telecaringresource model, the requester is either a human user or an intelligent agent. There-fore, the discovery is performed using two different interfaces, namely: human-basedand agent-based.

Human-based discovery

The goal of human-based discovery is to increase the level of documentation andmatchmaking resource services. With the idea of developing new composite telecar-ing services, resource requester has the opportunity to examine multiple candidateresources to identify suitable resource functionality before making the actual decisionto use a particular resource.

To query the repository, a resource requester interacts with the resource brokerusing an appropriate Graphical User Interface (GUI). This GUI is the presentationlayer that can be seen as a program or as a web-based interface.

Agent-based discovery

It is possible to perform dynamic and autonomous interactions if an intelligent agent isperforming the resource discovery. In this case, the intelligent agent acts as a resourcerequester that attempts to discover a resource in the network. Using native discoveryprotocols to issue a query to the resource repository, the agent can get specific name,type, and invocation details of resources. If suitable resources are found, the agent isable to select one to interact with and proceed with its invocation.

4.3.4 Invocation

The invocation of the internal service of the resource comes after the resource dis-covery, when the requester learns about the resource capabilities through its specific


description. Through the invocation, the requester executes the actions and internalfunctionalities of the resource.

Within the telecaring resource model, to invoke a resource’s internal service, therequester executes an action by sending a suitable message to the REMA agent rep-resenting the resource. The REMA returns the results or errors messages from theexecuted action, if the requester has the proper authorization.

Access rights validation

Once a requester decides to interact with a specific resource, it communicates to therespective REMA. In this interaction, the credentials of the requester are transferredto the REMA. Using these credentials, REMA interacts with the resource broker inorder to assert whether the requester has permission to access the requested services.

4.4 Collaboration among actors

This section focuses on details of the three fundamental actors involved in the tele-caring resource model.

4.4.1 Resource provider

A resource provider builds specific services for a resource within the network. Eachresource provider must advertise and publish their resources and the internal servicesto the resource broker, so that the suggested functionality becomes available to thetelecaring community. Delegating the task of advertisement to the REMA is possible,which produces a resource that is self-configuring, adaptive to the VO environment.

Resource providers are free to implement their resources using any programminglanguage or based on any platform or system. Since the resource broker does notspecify or constrain the design of internal services running on the resources, a resourceprovider may use specific APIs that suit the needs and requirements of its customers.The resource provider has complete control over the user interface for the resource,however, all developed resources should implement an interface agent and describeformally its functionality. The idea is that every other agent in the network can havethe possibility to interact with it.

4.4.2 Resource broker

Through the resource broker, resource providers advertise and publish the function-ality of the resources. On the other hand, resource requesters obtain the necessaryinformation from the resource broker to bind and use suitable resources.

The resource broker holds internally a repository with the entries representingthe definition of a resource, its internal functionalities, and its access rights. Thesuggested broker supports human-based and agent-based discovery, thus it shouldhave a presentation layer that handles both ways of interfacing.

4.5. Agent-based resource brokerage 81

4.4.3 Resource requester

A resource requester needs to invoke internal services or functionality of a resourcelocated in the networked environment. The resource requester discover first the in-formation about resources using the resource broker, and from then on, it binds orexecutes the resource services through specific invocation mechanisms (i.e. the re-quester becomes a client of the resource).

A resource requester can either be a human user accessing the resource brokerthrough a special user interface (web browser, for example), or an agent that commu-nicates directly with the resource broker and the resource’s REMA.

4.5 Agent-based resource brokerage

The telecaring resource model proposes a REMA for each resource, which interfacesthe functionality of the resource to other agents. On the other hand, the ResourceCatalogue Management Agent (RCAM Agent) acts as the resource broker in themodel. RCAM Agent is basically a searchable repository of resource descriptions.

The design of RCAM Agent, however, follows a layered model considering bothagent-based paradigm and agent-based information management (described in Chap-ter 2). As shown in Figure 4.7, there are three main layers in RCAM Agent design: atthe bottom, the catalogue repository provides database storage; the brokerage func-tionality is provided by middleware subcomponents, and the presentation layer sup-ports client interfaces for devices and telecaring services.

Agent message handlerAgent message handler

Telecare servicesTelecare services

Serv

ice A

Serv

ice A

Device 1Device 1Devices and

Telecare Services

Multi-Agent System

RCAMAgent

R C A M

FIMS AgentFIMS Agent

F I M A

Telecare service

descriptions

Telecare service

descriptionsDevice

descriptions

Device

descriptionsAccess

Rights statements

AccessRights statements

Database Repository

Device 2Device 2

Presentation

Catalogue repository

Brokerage functionality

Figure 4.7: Resource broker agent


4.5.1 Catalogue repository

In order to develop the RCAM Agent, a detailed definition of the data structuresrepresenting the service interfaces and its corresponding data types, must be achieved.The proper data structures should follow two widely accepted standards: UPnP, fordevices, and WSDL, for telecaring services. Besides, the access rights managementshould also be modeled based on the authenticated credential of the agents. Sincethese standards are abstract (i.e. no concrete data structures are defined), several newdata structures and objects representing UPnP, WSDL, and credentials of agents arethen required.

Using the mechanisms suggested in Chapter 3, we design first an ontology repre-senting the abstract definitions, and then produce the corresponding database defini-tions for storing the catalogue instances.

The catalogue repository, however, is not designed to be directly used by browser ordata management applications. We look for manipulating and accessing the entitiesof the repository using FIMS Agent, which is designed to provide an agent-basedinterface to interact with the database.

4.5.2 Brokerage functionality

RCAM Agent provides agent-based mechanisms for resource brokerage by manipulat-ing catalogue data. RCAM Agent handles three types of catalogue entries representingthe (1) description of resources, (2) the description of the resource’s internal function-ality (internal services) and (3) the access rights to the resource, of every telecaringresource in the telecaring environment.

The initial set of supported operations of RCAM Agent (see Table 4.2) allowsadvertisement and discovery of resource services definitions, but also supports theestablishment of access rights on telecaring resources. The server side functionalitiesinclude commands such as get device list, get device information (for a given deviceidentifier), get telecaring service information (for a given service identifier), etc.

Advertisement andPublishing

Discovery Access Rights

SubscribeDevice() RequestDevice() ValidateAccess()

UnsubscribeDevice() RequestDeviceList()

RequestDeviceServices() PermitGroup()

PublishDeviceServices() RestrictGroup()

UnpublishDeviceServices() RequestTelecaringService()

RequestTelecaringServiceList() PermitUser()

SubscribeTelecaringService() RestrictUser()

UnsubscribeTelecaringService()

Table 4.2: Basic operations of RCAM Agent

4.6. Conclusion 83

4.5.3 Presentation

For the presentation layer, RCAM Agent provides two different interfaces: HUMAN-GUIis designed to support human-based clients, and AGENT-MESSAGES is conceived foragent-based interaction. Humans learn how to create composite services with the re-source descriptions while agents are meant to use these descriptions to create dynamicinteractions with the resources.

The HUMAN-GUI is used by service providers, developers, or care users to get gen-eral information of telecaring resources in the VO environment. As such, through anapplication GUI or a web portal, the users can browse service descriptions that areavailable at the network, see the service their actions or operations (including param-eters that are defined within a given resource), or even -for administrative purposes-use methods to define access rights right on specific functionality.

Furthermore, through the AGENT-MESSAGES, agents or other software based com-ponents are able to publish, remove, and modify access rights in the catalogue in-formation. The messages are designed entirely based on the brokerage functionalityoffered by the RCAM Agent. This means that the client agent only needs the high-level operations from RCAM Agent and understand UPnP and WSDL results.

4.6 Conclusion

The overall goal of our telecaring resource model is the provision of an infrastructuresupporting the management of resources applied to care service applications within aVO for telecaring. Our approach takes advantage of categorization of care resources,MAS technology, secure credentials, and well-known SOA protocols to support boththe current and future emerging telecaring resources. All together, they allow resourceproviders to implement and develop their resources relying interoperability.

A key point of the telecaring resource model is the RCAM Agent component, whichacts as an agent-based broker for resources. RCAM Agent helps publishing, adver-tising and even invoking the resource functionality, without being concerned aboutthe specific database structures or access mechanisms. RCAM Agent also maintainsvisibility and access rights to resources and their services, based on credentials of theagents. This supports both secure and private interactions and real-time invocationsof resources by agents or users; thus, providing a reliable development environment.

The following list summarizes the benefits and potential advantages of using ourtelecaring resource model.

- Reduced complexity by encapsulation. All sensorial devices and telecaring ser-vices are exposed as resource descriptions. Therefore, the proper description ofthe type of internal services that a resource provides is what really matters, andnot how they are implemented. Clearly, this reduces system complexity, as ap-plication designers and developers do not have to worry about implementationdetails of isolated resource services that they need to invoke.

- Interoperability. Any resource, being a device or a telecaring service, can in-teract with other resources. This is achieved through the resource definition


and usage of agent protocols for collaboration and negotiation. Apart from theestablishment of the REMAs, which is absolutely required for interoperability,the implementation of the resources are platform- and language-independent.Developers and resource providers do not need to change their development en-vironments in order to produce or consume other resources and become part ofthe collaborative environment, only create an agent-based interface.

- General reusability. From the point of view of the developer, and since theRCAM Agent can be queried in order to find current available resources, therelated descriptions of devices and telecaring services can in fact be re-used tosupport future resource developments.

- Resource composition. Composition is the way to define a new value-addedresource. Both design-time and run-time compositions require a precise anddetailed understanding of the involved resource services. Resource compositioncan produce advanced resource integration, ensuring that value is added overthe sum of the individual sub-resource services.

Furthermore, new interactions could be considered by developers. For instancelegacy resources or even applications can be exposed as resources, allowing in-teroperability between legacy resources and future resources.

- On-the-fly integration. Through agents, resources are able to support significanton-the-fly integration for real-time applications. First, each REMA is based onthe notion of building applications by publishing and discovering the resourceservices they handle. Second, RCAM Agent provides binding details to locatethe REMA of needed resources.

- Decreased deployment time. Resource providers using this model can providenew functionalities and new services without the investment and delays that atraditional development requires. They may develop new products by reusingand combining existing resources.

- Openness and extensibility. The openness of the suggested resource model issupported by its choice of standards and by the agent-based platform infras-tructure, which facilitates the gradual definitions and addition of new devicesand telecaring services to the VO environment.

- Increase of security. An important characteristic of the telecaring resourcemodel is the management of authorized access rights. These are verified againstcredentials of resource requester and support both security and privacy of end-users of telecaring applications, crucial in this domain. Resource providers candefine the access rights for their resources as well for internal services.

Chapter 5

Tele-assistance platform andservices of TeleCARE

5.1 Introduction

This chapter provides a detailed description of a platform for tele-assistance, identi-fying its main constituting elements and functionalities. As such, it mostly addressesthe set of research questions RQ5 and RQ6, introduced in Chapter 1, as well as pro-viding a test and validation scenario. The test and validation results, which have beenpublished in [15, 123–125], also give an overview of how the concepts, models, and ap-proaches presented in previous chapters are implemented. Moreover, they providesthe final achievements of this research.

Validating the research suggested through this thesis is not straight forward, asthere are no standard means for validating the models and approaches. Therefore,the means we applied here for confirming and testing the agent-based approach inthe three main aspects of our research in telecaring, namely: the federated informa-tion management system, the ontology-based methodology, and the service-orientedresource management, include:

1. Implementing and developing the initial ideas in a mobile agent platform.

2. Using a number of vertical telecaring services as test-bed to validate the tangibleusability of our results, in respect to an actual developed platform.

Our focus in this chapter is to primarily address the design and development ofan architecture used as a base platform for a Virtual Organization (VO) for telecar-ing. Clearly, our concern is solely on the description of software components thatrepresent the ideas expressed in the thesis, although other significant (agent-related)components are also described. The second focus is then on validating the telecaringplatform using a number of services coming from industrial cases in the telecaring do-main [19, 126, 127]. These industrial scenarios cover a variety of practical situationsthat are considered to identify the strengths and weaknesses of our approach.

85

86 Chapter 5. Tele-assistance platform and services of TeleCARE

The rest of the chapter is organized as follows. First, Section 5.2 gives an overviewof the TeleCARE project, addressing its main design characteristics and describing thegeneral architecture. Then, each of the three key components of our system contribut-ing to the telecaring platform are detailed in the subsequent sections. Namely, Section5.3 deals with the insights of the Federated Information MAnagement (FIMA) com-ponent, Section 5.4 provides the fundamental details of Dynamic Ontology-based dataStructure Generator (DOSG) component, and Section 5.5 presents the implementa-tion elements concerning the Resource CAtalogue Management (RCAM) component.Afterwards, Section 5.6 describes the validation and verification of the applicabilityof these components. Finally, Section 5.7 draws the conclusions of the chapter.

5.2 TeleCARE as a tele-assistance platform

An integrated care system for the elderly embodies several organizations, such ascare centers, residential centers, healthcare centers, social security institutions, whichcomprise the collaboration of various different people, e.g. care assistants, health-care professionals, social workers, elderly, their relatives, etc., and computer services.When supported by a network of computer systems and other computer tools, thecollaboration among all the care organizations and institutions may develop graduallyalong different stages of the life cycle of a telecaring Virtual Organization (VO), wherethe different human actors may even become part of a Virtual Community (VC).

Advances in computer networks and ubiquitous computing suggest the opportu-nity for more advanced care approaches including developing new services in the areaof telecaring, comprehensive status monitoring, and other forms of assistance such asagenda reminders, while creating the opportunity for the elderly to pursue daily lifeactivities and become involved in a (virtual) community. The innovation and conver-gence of computer networks, multi-media systems, safe communications, hypermediainterfaces, rich sensorial environments, intelligence of home appliances, and collabo-rative virtual environments represent an important enabling factor for the design anddevelopment of a virtual elderly support community for the elderly. In particular,a platform based on adaptive mobile agents combined with secure federated infor-mation management mechanisms provides a flexible infrastructure on top of whichspecialized and value-added care service are built.

In this context, the IST 5FP TeleCARE project developed an infrastructure, com-plete with support services that facilitate an independent lifestyle and improve thequality of life of the elderly and their relatives. The project had as main objectivesthe design and development of an integrated platform to be the base for VOs focusedon the provision of remote care for the elderly. The TeleCARE solution has to beseen as complementary to other initiatives regarding integration of elderly in the soci-ety. These initiatives are being carried out independently of one another, developingdifferent products and services. Project TeleCARE develops a common platform intowhich all these heterogenous developments can be plugged in such way that interoper-ability is possible, as shown in Figure 5.1. As such, the elderly and those responsiblefor providing their care can get the best out of available technologies.

5.2. TeleCARE as a tele-assistance platform 87

TeleCARE infrastructure

(Mobile agent framework and information services)

Future

applications

Vertical services: Specialized telecaring services

Resources: Communication and interfacing to external devices

Future

devices

Figure 5.1: TeleCARE infrastructure

An objective of the TeleCARE project is to leverage the potential use of themobile agents with federated information management into a flexible infrastructureto improve the quality of life, and care, for elderly people and their families. Theseagents will perform a large number of tasks regarding remote supervision, intelligentassistance, sensorial data collection, alarm notification, agenda assistance, virtualleisure activities, health monitoring, among other telecaring services.

5.2.1 The TeleCARE multi-agent environment

The TeleCARE platform is being developed on top of the Aglets Software Develop-ment Kit [128, 129], or Aglets SDK for short. Aglets SDK provides the basic Javaframework for inter-platform mobility and communication mechanisms for static andmobile agents. It has important and strong features, suitable for telacaring applica-tions. Among these features, it is possible to mention the following key ones:

• support for stationary and mobile agents,• support for local and remote inter-agent communication,• provision of an event driven model for programming mobile agents,• control over persistency and cloning functionalities,• basic security mechanisms for mobility and access of local resources, and• provides a reusable and extensible architecture.

In order to implement required functionalities for the TeleCARE project, however,the basic Aglets SDK mechanisms are extended with a set of strategies and modules.For instance, the aspect of security, which is critical in this domain, has to be improved


if the telecaring applications have to handle private and personal information. Thefollowing sections focus on the most important of these strategies and componentsemployed for developing the ideas expressed throughout the thesis.

TeleCARE agent

The Aglets SDK framework provides a base Java class, defined as Aglet class, fromwhich all (static or mobile) agents are derived. An agent derived from this baseclass is called an aglet. Aglets use an event driven model of mobile agents, that is,an aglet responds to events such as moving, cloning, and communication requests.Within TeleCARE project, a specialization and extension of the aglets with otheragent frameworks, including the Foundation for Intelligent Physical Agents (FIPA)specifications [130], is defined in order to provide robust methods for dispatching,deactivating and disposing the agent, communication, and persistency support [131].

TeleCAREAgent

Figure 5.2: TeleCARE agent and related classes

The TeleCARE agent is implemented into the TCAgent class and depicted inFigure 5.2. This class becomes the base agent class for both internal and user-definedagents in TeleCARE. The TCAgent class is the key class of the TeleCARE Applica-tion Program Interface (API). This class extends functionalities of the Aglet class,and defines methods for controlling its cycle of life. The class hierarchy of the Tele-CARE agents includes inherit properties from TCAgent class. A number of classexceptions are also defined to cope with unusual or unexpected system behavior.


TeleCARE passport

An important characteristic of all TeleCARE agents is related to their identificationand credentials, established through a TeleCARE passport. The structure of theTeleCARE passport is depicted in Figure 5.3. Essentially, the passport is the identitydocument of every TeleCARE agent and is the official “travel document” recognizedby all TeleCARE sites of the community. The passport is used for migration, control,access resources, and locating TeleCARE agents within the VO network. Passportand its credentials are also associated to each message sent by a TeleCARE agents.

TALPassport

The Agletsidentification

Platform where theAgent was created

TLAID

TLAID validity itinerary

agentID hostOrigin hostCurrent agentName agentType userRole userID

Platform where theagent is currently executing

Logical name ofthe agent, givenby the developer

The category ofthe agent: System

Resource, etc.

Category of the userwho created the agent:

Doctor, NurseRelative, Elderly, etc.

The identification of theuser who created theagent: Mary, Jose, etc.

Duration time of thePassport credentials

List of thevisited sites

domainNode

Domain node of the TeleCAREVirtual Organization whichthe source host belongs to

TeleCAREAgent Locator

TeleCARELogical Agent

Identifier

TeleCARE Agent Locator = TLAD + TLUD

Figure 5.3: The TeleCARE passport

In addition to traditional methodologies of passport for mobile agents [132, 133],which are focused primarily on low-level security aspects, such as migration control,the TeleCARE passport approach focuses also to provide mechanisms of definingpolicies to access the information and resources. This implies that if an agent requestsaccess to operate a TeleCARE resource, it must have a valid TeleCARE passport withvalid access rights to the services of the resource.

The main characteristics of TeleCARE passports include: (i) it is unique for ev-ery TeleCARE agent, (ii) compulsory for every TeleCARE agent, and (iii) partialinformation is assigned by the developers (origin, type, etc.), but cannot be modifiedprogrammatically by them. The passport is composed of the following fields:

TAL. The TeleCARE Agent Locator (TAL) is a computer-generated identifier usedto locate a TeleCARE agent within the multi-agent environment. With the


information obtained from any TAL, the system can find the location of anyagent, no matter where it is. The TAL comprises information related to theidentification of Aglets SDK, defined as AgentID (a string of 16 hexadecimalcharacters), the host where the agent has been created, and the host where theagent is currently executing.

TLAID. The TeleCARE Logical Agent IDentifier validates an agent at any host ofthe platform. Since, it is a high-level user-friendly identifier, it supports alsothe human search of an agent in the environment. The platform and servicedevelopers can identify any TeleCARE agent with the information provided bythe TLAID, given any parameter of its two substructures:

• TLAD. The TeleCARE Agent Data (TLAD) contains specific human-readable identification of the agent, namely its name and type.

• TLUD. The TeleCARE User Data (TLUD) is composed of human-readableidentification of the user who created the agent. It includes the role, theuser ID, and the domain node of the host.

Validity. The validity assigns the authorized time (duration) of the credentials.

Itinerary. The itinerary indicates the route of travel where the TeleCARE agenthad been executed. It contains the path to the hosting sites.

An example of how an agent is located by another agent is presented in Figure 5.4.In this case, a user looks for an agent but does not know its computer-generatedidentifier. With the help of the seeker agent (left), and using partial information ofthe TLAID, the user gets a set of TeleCARE agents from which he can choose theright one (right). The seeker agent is operated here by a human user, however, it canalso be controlled by another agent.

Finding other agents through TLAID

Passport information of a specific TeleCARE Agent

Figure 5.4: Finding an agent with a partial TLAID


Persistence of TeleCARE agents

The persistence of TeleCARE agents is an important element of the required reliabilityfor telecaring services. First of all, the service continuity should be assured for anysignificant activity that an agent is performing. Secondly, an interruption of anypart of a local system (including network operation) should not affect the overalldistributed system behavior. Besides, it is critical to preserve status information incase of a temporary node disruption. Eventually, the recovery process of servicesshould be as transparent and smooth as possible after a breakdown.

The persistency supported by TeleCARE agents is a mechanism that basically al-lows the agent platform to store information about the running activities and, when-ever a system failure take place, to resume them when the system is restored in astable manner. Each aglet has an internal method, called snapshot, that preservesinto a non-volatile storage an image of its status information. In the other hand, everyTeleCARE agent invokes the method tcSave from the TCAgent class, in order toinvoke the snapshot, including not only information of the execution status but alsoits passport when necessary.

The last valid image of the TeleCARE agent is restored from the non-volatilestorage and its execution is resumed, when the system overcomes the failure. InTeleCARE, the TCAgent class provides automatic support for the persistency duringcritical events of the life cycle of an agent: (i) at creation of an agent, (ii) after theagent arrival to a new location, and (iii) during the activation of an agent. TheTeleCARE approach, however, is flexible enough to allow developers to decide whento execute additional snapshots of their agents using the tcSave method.

Inter-agent communication

A simple mechanism for inter-agent communication is provided by Aglets SDK. It ishowever not sufficient for reliable communication for highly mobile agents [134], orwhen persistence mechanisms, such as those based on cloning are implemented, dueto the changes in the AgletID.

As result, the new TCMessage class is introduced by encapsulating the Messageclass of the Aglets SDK. This class is enhanced with the credentials of the sender,support for remote exceptions, and support for high structured message language.This TCMessage class allows the handling of additional message functionalities:

• Extended message exchange. This operation is based on the passport credentialsand the forwarding scheme found in [134], with the difference that the originalhost of the agent (where it was created) is also notified when the agent migratesfrom one location to another.

• Agent location transparency. As long as a TeleCARE agent knows some infor-mation from another agent, it can always communicate transparently. Withthe knowledge of some parameters of the TLAID, for instance, the target agent(receiver) can easily be reached without further effort to establish a commu-nication. The diagram illustrated in Figure 5.5, shows the process in which a


sender agent obtains the TAL of the receiver (with help from local and remoteAgent Registries (AR)) and uses this data to send the message.

Agent: TCAgent Local-AR Remote-AR

FIND_TAL

FIND_TAL

Check registry Check registry

Send response

Send response

location = localhost

TLAID < TLAD

<TLAID, location>

<TLAID, location>

Figure 5.5: Establishing contact with a TeleCARE agent

• Message certification and verification. Every outgoing message is endorsed,by encapsulating the passport of the sender agent into the message, beforebeing processed by the receiver agent. The verification process ensures that anymessage carries a valid passport, otherwise, the message is not handed out tothe receiver agent.

In addition, the receiver agent will also know which is the sender agent, dueto the fact that the passport of the sender agent is also associated with themessage. This is extremely useful in a situation when the sender agent sendsa request message to a resource agent, then the resource agent can verify theaccess rights of the sender agent, without great effort, before committing orperforming some action on the resource.

• Support FIPA ACL. For advanced communication, it is necessary to employ awell-structured language. The FIPA Agent Communication Language (FIPAACL) [135] is a well-known standard for inter-agent communication, which pro-vides negotiation mechanisms and a strong representation for structured mes-sages exchange between agents. An example of a FIPA ACL message is depictedin Figure 5.6, which indicates the corresponding ACL method for the definitionand extraction of each element of the message.

• Handling non-agent applications. Adequate manipulation of messages from non-agent application or systems is also supported. There are agent-based servicesthat require message exchanging with non-agent applications, thus, this mech-anism allows the agent to identifying such type of messages.

The TCAgent is the class that defines basic message handlers for each TeleCAREmessage. There are two types of TeleCARE messages: the TCMessage, which is based


(inform

:sender ( agent - identifier : name i):receiver ( set ( agent - identifier : name j)):content

(Line_quote(tc_customer,123),300):in-reply-to round - 4:language prolog:ontology tc - monitoring:protocol fipa - contract - net

)

setSender

setReceiver

setContent

setPerformative

getPerformative

setLanguage

getLanguage

setOntology

getOntology

getSender

getReceiver

getContent

Figure 5.6: Finding an agent through TLAID

on ordinary agent messages from Aglets SDK, and the ACLMessage, based on FIPAACL messages. The main methods for handling these messages are the following:

• boolean handleMessage(TCMessage msg). Operation that handles messagescoming from unreliable site locations or non-agents applications.

• boolean handleMessage(TCMessage msg, TCPassport passport). This op-eration takes care of messages and requests coming from trusted TeleCAREagents (i.e. TCMessage with valid passport).

• ACLMessage handleMessage(ACLMessage msg). This operation manipulateshigh-structured FIPA ACL messages coming from unreliable site locations ornon-agent applications.

• ACLMessage handleMessage(ACLMessage msg, TCPassport passport). Ithandles high-structured FIPA ACL messages (ACLMessage) coming from trustedTeleCARE agents with valid passport.

Agent Mobility

The Inter-Platform Mobility (IPM) is a special module that extends the Aglets SDKplatform with security mechanisms to support generalized mobility of TeleCAREagents. Although Aglets SDK supports basic agent mobility, it is necessary to includethe IPM to allow a registry control over the incoming and outgoing valid TeleCAREagents in a certain platform.

The processes of reception and registration of TeleCARE agents essentially acceptor refuse incoming mobile agents. An incoming mobile agent is accepted depend-ing on the validity of its passport. If the agent is accepted into the platform, thenit is registered as a legitimate agent; i.e. able to interact with other agents and re-quest available TeleCARE resources in the platform. Additionally, when an agent isaccepted (or rejected) both the origin and the sender platforms are notified, whichhelps to locate the mobile agent within the VO infrastructure.


Another aspect involved during the agent migration is the dispatch control. Thiscontrol is responsible for the operations of sending out a TeleCARE agent to itsdestination, while detecting whether the destination is a TeleCARE environment.

Besides all events regarding migration, TeleCARE agents are also registered in ahistorical log file. This log record allows the human operator to check the itineraryof the mobile agents and to examine which agents have arrived at the local platform.

From the operating point of view, the IPM module is a set of stationary agentsthat implements the mentioned functionalities:

• Agent Registry. Holds a record of each TeleCARE agent that is executing atthe platform in one site. The Agent Registry contains copies of the passportof each agent running locally. Besides, when an agent is created its passport isalso registered, so it can execute within the TeleCARE VO (i.e. allow requestaccess to TeleCARE resources at any node). When the mobile agent decides tomigrate, its passport is registered at the destination platform and its locationis updated at the local registry.

• Agent Reception Control. Depending on their credentials, agents are accepted orrefused. Thus, the Agent Reception Control behaves as a rule-based gatekeeperfor incoming agents that request to enter into the TeleCARE platform.

• Agent Exit Control. When an agent decides to migrate to another platform,its passport is inspected to verify if the agent has authorization to travel. TheAgent Exit Control also checks if the destination of the agent is available andis a valid TeleCARE platform.

Types of TeleCARE agents

There are two distinct types of TeleCARE agents, (i) the system agents that areresponsible for the functioning and management of the TeleCARE platform (includinginternal modules) and (ii) the application agents, which are all other agents thatare defined by the users or developers to perform any task or operation in order toconstruct the TeleCARE service applications. Table 5.1 presents all system agentswithin a TeleCARE VO.

The concepts, listed in Table 5.2, from the FIPA specifications can be mapped toTeleCARE elements. There is however no one-to-one mapping possible, and furtheralignments of interfaces and components are necessary.

5.2.2 TeleCARE architecture

The TeleCARE platform is a layered architecture for cooperation and federationamong different nodes of the telecare VO environment. The TeleCARE architec-ture benefits from the merger of a number of technologies and paradigms in orderto provide seamless support for future expansion. It is based on the integration offive different approaches: (i) multi-agent systems (ii), federated information systems,(iii) secure communications, (iv) ubiquitous computing devices, and (v) value-addedtelecaring services that are likely to be offered by the emerging intelligent applications.


Agent Registry This agent registers all agents currently running in the host

and all agents that are created in the host (including those

who migrated to other platforms).

Agent Exit Control Static agent in charge of handling outgoing mobile agents.

Agent Reception Control The agent that handles registration process for incoming mobile

agents.

Agent Platform Manager The agent is responsible for all administration tasks on the local

platform.

Domain Node Storer It keeps data of all platforms that belong to a defined VO.

Login Validator The agent confirms a user entry in the TeleCARE VO environ-

ment.

Login UI Agent with an adaptable user interface (UI) to log a user entry

into any platform of the TeleCARE VO. Figure 5.7 shows the

user interface for care center operators.

RCAM Agent It manages the catalogue of resources in a TeleCARE platform.

FIMS Agent Agent that supports the federated information management

processes.

Table 5.1: System agents of the TeleCARE platflorm

Initial login access to a TeleCARE platform

Specification of user name

and password information Establishment of userroles for this session

renata

renata

Figure 5.7: Suitable UI for login process at the care center

The architecture design of TeleCARE is composed of a three-layer platform asdepicted by Figure 5.8. At the lower level, External Enabler Layer provides all theabstraction and support for the external communication as well as the interface withexternal resources (data sources and devices). The Core MAS Platform Layer locatedin the middle is the key component of the architecture, which includes essential sup-port for the needs of static and mobile agents. Finally, the Vertical Services Layeris located on top of the architecture. The elements in this layer have a distributedimplementation over the TeleCARE network and they represent open components as


FIPA Agent Platform Corresponds to the TeleCARE platform

FIPA Agent Corresponds to TeleCARE agent

FIPA Agent

Management System

Corresponds to the Agent Registry, in conjunction with some

characteristics of Platform Manager such as the services for

launching agents

FIPA Directory Facilitator Corresponds to RCAM Agent

FIPA Message

Transport Facility

Corresponds to the Agent Transport Protocol (for both inter-

agent communication and agent migration) of the aglets, in

conjunction with the Agent Reception Control, the Agent Exit

Control (for agent migration), and internal functionalities of

the TeleCARE agent (for inter-agent communication)

Table 5.2: Mapping FIPA concepts to TeleCARE elements

Core MAS Platform Layer

External Enabler Layer

Vertical Service Layer

Figure 5.8: TeleCARE layered architecture

a variety of value-added services are gradually added.In a nutshell, the core horizontal platform developed for TeleCARE provides the

MAS, mobility, safe agent communication, and the federated information services.The TeleCARE project further developed some vertical services on top of this plat-form, including status monitoring, as well as other forms of assistance such as agendareminders, entertainment services, time bank, and a few essential services supportingvirtual communities, web-accesses, and specialized user-interface for the elderly.


The External Enabler Layer (see Figure 5.9) supports the communication and inter-facing to the external devices. It includes the following two component levels:

Safe Communications Infrastructure. This component level provides secure andprotected network communications among TeleCARE platforms. The main el-


Safe Communication InfrastructureDevice Abstraction Level (DAL)


Figure 5.9: External Enabler Layer of TeleCARE

ements of this component are a firewall, a Virtual Private Network (VPN) anda strong authentication mechanism.

The implementation of a firewall is intended to isolate the TeleCARE networkfrom external access and to protect three aspects of fundamental importanceto any organization (and particularly this type of a network that communi-cates sensitive data): (i) the information stored in the platform, (ii) access totelecaring resources and (iii) intrusion-detection and management.

The adoption of VPN is based on the IP Security Protocol (IPSec), which aimsto fulfill multiple security objectives, both technical and strategic, includingcryptographic services. Essentially, the VPN is a combination of software andhardware that allows mobile agents, tele-workers and remote platforms to usean insecure public network, such as Internet, to establish a secure, private con-nection to other sites on the network.

Strong user authentication is an additional security measure within TeleCAREVO. The main objective is to provide a mechanism for users (with physicaldisabilities) to identify themselves to the system. A fingerprint mechanism sofar is used to grant clearance into care centers, while biometrics systems or SmartCards (specifically Java-Cards), are intended to be used and implemented at thehomes of the elderly.

Device Abstraction Level. The Device Abstraction Level (DAL) provides inter-faces to sensors, monitoring devices and other hardware (home appliances, en-vironment controllers, etc.). These interfaces represent the bridge to any intelli-gent home or local domotics network, hiding aspects such as low-level protocols,wire-based or wireless communications, etc. DAL hides and homogenizes thediversity of interface methods to the different devices and home appliances.

The DAL is based on the Telecaring resource model [117], described in Chap-ter 4, to manage intelligent devices or appliances, particularly within the homeenvironment. From the MAS platform side, the logical access to the devicesfunctionalities (i.e. remote service invocation) linked to DAL is established us-ing the Resource Manager Agents and coordinated by the Resource CatalogueManagement Agent, as described later in Section 5.5.



The Core MAS Platform Layer (see Figure 5.10) is the main component of the Tele-CARE basic platform. It supports the creation, launching, reception (authenticationand some rights verification), and execution of stationary and mobile agents as wellas their interactions. It also supports the storage and manipulation of data andinformation to be handled within TeleCARE. It provides a catalogue of all devicesand services supported in TeleCARE. Furthermore, an inference engine is included asintelligent agents are also envisaged for future advanced services.

Core MAS Platform LayerPlatform Manager

Basic Multi-Agent Platform

Resource Catalogue Management

Inter-platform mobility

Federated Information Management

Inter-agent Communication

Persistence

Support

Ontology

Management

System

Inference

Engine

Agent Exit

Control

Agent

Reception &Registration

Agent

FactoryResource

Managers

Federated Query

Processor

Ontology-based Data

Structure Generator

Device Registry Vertical Service Registry

Figure 5.10: Core MAS Platform Layer of TeleCARE

Basic Multi-Agent Platform The Basic Multi-Agent Platform is the engine ofthe Core MAS Platform Level. The Aglets SDK is the foundation to supportagent mobility, but it is extended and complemented with the following threeadditional modules:

• Persistence Support module provides basic recovery mechanisms in case ofplatform failure, as addressed in Section 5.2.1.

• Ontology Management System is used by software system developers anddomain experts to develop their knowledge base and the entities to be usedby their applications. Protege [95] is the Ontology Management System,which is developed by Stanford Medical Informatics Lab. It is designedoriginally for the medical care domain but it grew to become a general-purpose system for building knowledge bases in any domain. Protege isalready being used in TeleCARE-related domains such as clinical medicineand the biomedical sector, as well as in complex fields where the con-cepts need are modeled as a class hierarchy [136]. Examples of ontologiesdeveloped with Protege include: Health Level Seven (HL7) Data Types


and Top-Level Reference Information Model (RIM) classes, Biological Pro-cesses Ontology, Gene Ontology (GO), and GuideLine Interchange Format(GLIF) Ontology. Protege provides convenient mechanisms for conceptdefinition, problem-solving and decision-making required in the TeleCAREenvironment [106]. Besides, with the Protege knowledge model, based onthe Open Knowledge Base Connectivity (OKBC) protocol, applicationscan also be executed on top of this system.

Controlled vocabulary Simply listing a set of terms, being mnemonic names given to

classes and attributes.

Taxonomy for terms To arrange terms into a specific generalization-specialization

hierarchy, in order to better define attributes of these terms

and relationships between them.

Object-oriented schema For definition of a hierarchy of classes, and attributes and rela-

tionships of those classes, which includes semantic information

as well.

Table 5.3: Protege in TeleCARE

Protege is used in TeleCARE at several levels, as depicted in Table 5.2.In general, a TeleCARE ontology can describe constitute a collection ofconcepts and interconnections to describe the information units and datastructures within the domain. In particular, the semantic heterogeneityamong the shared information is resolved by mapping it into the TeleCAREcommon ontology (see Figure 5.11), that both humans and software agentscan understand and consult. Protege allows domain experts and developersto further reuse and extend this common ontology, thereby shortening thetime needed for development and application maintenance. Later, usinganother component the subsequent ontology is transparently translatedinto a proper data model.

• Inference Engine is based on a Prolog interpreter, called Kernel Pro-log [137], which is an open-source implementation of the commercial Java-based Prolog compiler Jinni [138]. Kernel Prolog is a lightweight Prolog-in-Java interpreter that allows Java applications to use knowledge bases.Kernel Prolog has some interesting characteristics that are valuable forTeleCARE environments [125], namely: (i) ISO-Prolog based, (ii) consoleand a GUI interfaces, (iii) Java APIs that allows its usage in Java applica-tions, (iv) multi-thread execution, (v) set of built-in useful operators, suchas reading file predicates, network predicates and database predicates, and(vi) applicable in intelligent distributed system.

Inter-Platform Mobility. The Inter-Platform Mobility component, as mentionedin Section 5.2.1, is an extension to Aglets SDK to support generalized mobilityof TeleCARE agents. It includes the Agent Reception and Registration sub-


-firstName : String-lastName : String

-gender : Symbol-birthdate : String-IDDocument : String-nationality : String-profession : String

-addressList : Address-nodeList : Node-telephoneList : Telephone-electronicAddressList : ElectronicAddress

Person

-addressText : String-postalCode : String

-city : String-state : String-country : String-addressType : Symbol

Address

-URL : String-logicalName : String-subscriptionDate : String

-physicalAddress : Address

Node

1..*

0..*

1..*

1..*

1..* 1

-person : Person-elderlyData : String-disabilityList : Disability-physician : Person

Elderly

1

1..*-relationKind : Symbol-elderlyPerson : Elderly-relative : Person

RelationType

-roleName : String-description : String

Role

1

1..*

1

1..*

1..*

1

-telephoneNumber : String-telephoneExtensionNumber : String-telephoneNumberType : Symbol

Telephone

-electronicAddressText : String-electronicAddressType : Symbol

ElectronicAddress

-person : Person-username : String-password : String

-subscriptionDate : String-roleList : Role-picture : Photo

User

1

0..*

1 0..*

1

1

1

1

-image : byte

Photo

1

1

-description : String-careToTake : String

Disability

1

0..*

Figure 5.11: TeleCARE Common Ontology

component (for verifying incoming mobile agents) and the Agent Exit Controlcomponent (for handling outgoing mobile agents).

Inter-Agent Communication. As expressed in Section 5.2.1, this extension to thebasic MAS platform supports communication and coordination of agents inde-pendently of their current location. It also integrates a high-structure languagewith FIPA ACL messages.

Platform Manager. This component is in charge of the specification and configura-tion activities of the platform at each TeleCARE site. These activities includetasks such as handling the login process, recovering from errors, monitoring


and supervising the status of the platform, defining new agents, defining usersand their roles, etc. The Platform Manager also comprises the following twosubcomponents:

• Agent Factory. It manages a library of TeleCARE agent templates thatease the development of new TeleCARE services. The Agent Factory isintended for users with software engineering skills, helping developers tobuild Agents. Basically, this subcomponent provides a set of TCAgentclasses for basic tasks in order to ensure that programmers without agentengineering experience to fasten the deployment of telecaring applications.

• Resource Manager. Each Resource Manager agent provides an abstractway of dealing with devices and appliances in TeleCARE. The ResourceManagers are responsible to provide access to the hardware resources andappliances when requested, for example, by upper level Vertical Servicesrunning in the TeleCARE platform. The Resource Manager are furtherexplained in Section 5.5.

Federated Information Management. This component supports the manage-ment of federated information at TeleCARE nodes, while preserving informa-tion privacy through access rights management. It provides the infrastructurefor: (i) flexible processing of federated queries and (ii) data structure genera-tion based on ontological definitions. This component is developed using JavaDatabase Connectivity (JDBC) in conjunction with free and open source soft-ware, namely the SAP DB [139] as relational database system and the Castoras data binding middleware [140]. See Section 5.3 for additional details.

Resource Catalogue Management. It manages the catalogue of resources, andregistering the service descriptions for all devices (Device Registry) and verticalservices (Vertical Service Registry) available at the site. It also provides func-tionality to handle the access rights to TeleCARE resources. More about thismodule can be found in Section 5.5.


Within the TeleCARE VO environment, the vertical services are developed in differentways. For instance, a monitoring service might involve a stationary agent in the carecenter, for interaction with a care giver, while a set of mobile agents can execute atthe home of the elderly. These last agents will negotiate with the Resource Managersin charge of monitoring local sensors, e.g. temperature sensor, presence sensor, inorder to carry out their mission, such as collect information from different sensorsand report back to the care center.

The negotiation can take place, via FIPA ACL messages, between mobile andstationary agents executing at any platform. As a TeleCARE message includes theextended agent and user identification, the agent receiving the message is able toverify the authorization and access rights of the sender.


As depicted in Figure 5.12, the Vertical Service Layer contains two types of ser-vices: a) Base Horizontal Services and b) Vertical Services.


Specialized interfaces Web Access

Living Status Monitoring

Multiplicity of information sources, bi-directional audio-video channels, controlled privacy levels

Entertainment

Ease sense of isolation, potential for new dimension of care services, diversity of user interface components

Future Services

Other future VC services, (chatters, messengers, emails, etc.)

Specialized interfaces for the elderly

Advanced interfaces for people with disabilities or not familiar with computers

Web Service AccessWeb-based mechanisms to interface with the TeleCARE environment

Time Bank

Automation of traditional time bank functionalities,integration in TeleCARE community, support active aging and community involvement.


Agenda Reminder

Memory assistance, flexible event management, increased care assistance


VC Support

Virtual Community Support

Management of the Virtual Community (VC) for the elderly environment within a TeleCARE VO.

Base Horizontal Services

Vertical Services

Figure 5.12: Vertical Service Layer of TeleCARE

Base Horizontal Services. This set of components include the following:

• Virtual Community Support. This component provides operations for cre-ation and operation of future services within the virtual communities de-signed for the elderly. Specifically, the management functionalities of theVC Support offer substantial help for the implementation of applicationsin the TeleCARE VO [19].

• Specialized interfaces for elderly. In the case of home sites, specializedinterfaces are required for elderly that are not familiar with the use ofcomputers. The ultimate goal is to build a user-friendly and invisible in-frastructure to be used by the elderly with special disabilities.

• Web Service Access. It allows web access to telecaring services. Thisfunctionality is particularly useful to relatives of elderly to have access tothe TeleCARE VO network from their working places, or locations wherethe installation of the TeleCARE platform is not possible. It facilitates alsothe interaction between the TeleCARE agents and Web-based programs.

Vertical Services. The following developments are vertical services:

• Living status monitoring. This vertical service represents an improvementover traditional “social alarm” systems [126]. It allows not only bi-lateral

5.3. FIMA – Federated Information Management 103

interactions with semi-automatic supervision functionalities, but also gath-ering of additional (urgent) information when it is needed or requested.The goal is to significantly increase the quality of life of the elderly andthe peace of mind of the relatives as well, by providing a robust assistance24 hours a day.

• Agenda reminder. The daily activities related to the welfare of the elderlyare easily scheduled in order to improve their quality of life and well being.This vertical service, through a number of TeleCARE agents, reminds theelderly of their activities [141]. These activities range from medicationalerts to exercise guidance, and it is even possible to create appointmentswith the care center.

• Time bank. The Time Bank service provides a mechanism for collaborativecommunity building and reinforcement, i.e. provides a way for people tocome together and help each other. The basic principle is that each memberearns credits by performing tasks to others, in turn the members thatrequest tasks spend credits. Each credit corresponds to one time unit,so for example, if some service takes one hour to be completed then therequester will consume one credit and the provider will receive one credit.In TeleCARE, the Time Bank concept leads to one virtual community.Members in this community include the elderly people, their relatives, andcare center personnel. There are agents associated to these members, whichperform the negotiation tasks of this vertical service [127].

• Entertainment. The Entertainment services are designed to ease the senseof isolation elderly feel and provide light entertaining applications to im-prove their sense of well being, contributing to the maintenance of a sociallife and also an active aging. A combination of games, music and educationprograms is offered among the leisure services.

5.3 FIMA – Federated Information Management

The Federated Information MAnagement (FIMA) component addresses the informa-tion interoperation among sites and considers the sharing and exchange of distributedinformation in a highly heterogeneous environment. This section presents its imple-mentation details, while the FIMA design can be found in Chapter 2.

From the point of view of the vertical service developer, FIMA allows specificinformation from each vertical service to be used in conjunction with other telecar-ing applications, or even manipulate the data in different ways. In addition, themanagement of data is distributed, which means data are updated and modified byapplications running at remote nodes.

FIMA at each node acts as the component in charge of creating, accessing, modi-fying and deleting the sharable information at the local repository of each TeleCAREplatform. Its internal repository is based on a solid relational database, that providesthe base functionality for data accuracy and data recovery. FIMA sub-components are


designed to support a wide range of telecaring applications that have complex datamodels, large numbers of users, and are implemented as software agents, while atthe same time it provides secure and authorized access to large volumes of physicallydistributed and heterogeneous data.

The key functionality of FIMA component of TeleCARE is divided in three areas:(i) object persistence, (ii) log event management, and (iii) federated query processing.

5.3.1 Object persistence

The TeleCARE platform and its development environment is based on Java. There-fore, it is evident that FIMA should support the storage of Java object properties,including class attributes and instance variables.

Supporting object persistence does not indicate only storing of the immediate class,it includes support for class relationships and class hierarchy (subclass-of or super-class-of). FIMA supports the object-oriented persistence over a relational database,regardless of its complexity. Essentially, objects with a single data model are expressedin simple tables, and those with more complex structure are expressed with referencesto values in other tables (using database foreign keys). This approach provides aflexible mechanism to handle the information items while offering the basic advantagesof a relational database, such as: recovery, security, transaction management, andconcurrency control, among others.

Clearly, since the underlying database system is relational, some additional con-siderations regarding complex classes and object identity, are important when definingthe class structure.

Complex classes

The support of complex classes is one important functionality of object persistence,and many telecaring services require manipulation of classes that may have complexinternal structures. Some objects from these complex classes may be part of smallersubclasses and have relationships with other objects. These complex classes, or partsof them, can also be shared with other vertical services or applications.

Object identity

In conventional RDBMS, entities are often identified by reference to certain attributesconstituting the primary key of those entities. When using objects, however, theapproach of allowing them to be identified only via their properties has some problems.For instance, the maintenance of consistency of the object associations results insignificant processing overhead when the key attribute of the object is modified.

In order to handle identification of objects, FIMA employs an Object ID (OID)for each instance in the repository. The implementation of this approach allowschanges to the properties of an object with no adverse effects. OIDs are generatedby the application system or by the database engine, depending on the choice of thedeveloper, are unique within a class definition. An OID stays with an object instancefor its entire lifetime.


5.3.2 Log event management

The log event management is the mechanism used for monitoring diverse occurrencesin each TeleCARE platform. The administrator can use the log records to view andmanage the total events of the system, security, and execution of vertical services. Thisservice starts automatically when the TeleCARE platform is started at the node, andthe log records are specified following the XML Schema of Figure 5.13.

<?xml version="1.0" ?><xs:schema elementFormDefault="qualified"

targetNamespace="http://www.uninova.pt/~telecare" xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:annotation><xs:documentation> XML Schema for TeleCARE log events </xs:documentation>

</xs:annotation><xs:element name="eventLog" type="eventLogType" /> <xs:complexType name="eventLogType"><xs:sequence><xs:element name="date" type="xs:date" minOccurs="1" maxOccurs="1"/> <xs:element name="time" type="xs:time" minOccurs="1" maxOccurs="1"/> <xs:element name="node" type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="category" minOccurs="1" maxOccurs="1">

<xs:simpleType><xs:restriction base="xs:integer">

<xs:pattern value="[1-3]"/></xs:restriction>

</xs:simpleType></xs:element><xs:element name="description"

type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="identification" type="xs:string" maxOccurs="1"/><xs:element name="source" type="xs:string" maxOccurs="1"/><xs:element name="eventCode" type="xs:integer" maxOccurs="1"/><xs:element name="type" type="xs:integer" maxOccurs="1">

<xs:simpleType><xs:restriction base="xs:integer">

<xs:pattern value="[5]"/></xs:restriction>

</xs:simpleType> </xs:element>

</xs:sequence></xs:complexType>

</xs:schema>

Figure 5.13: XML Schema for a log event

In the TeleCARE platform, an event is any significant occurrence during the exe-cution the system or in an application that requires a notification for the user. Anycomponent in the platform, including horizontal or vertical components, can itselfarchive event logs in the repository of FIMA. The specific information about thecontent of a log event is presented in Table 5.4.

For critical events such as full platform failure or an interrupted power supply, alog of these events can show important information. For many other events that donot require immediate attention, the FIMA component adds a log record to the logregistry to provide information without disturbing the usual on going work.


Date Day of occurrence of the event.

Time Timing of the occurrence of the event.

Node The exact name of the computer node where the log event occurred.

Category A classification of the event with three values:

1. for TeleCARE Platform component,

2. for Devices resource, and

3. for Vertical Services application.

Description Shows the specific event. This description helps the platform manager

or the support person to track down events in the platform.

Identification Text that specifies an identifier related to event, if any. For example,

the username or the agent identifier are to be stored here.

Source The software that logged the event. It can be an internal component of

the TeleCARE platform or a vertical service application.

Type A classification of the log according to five values:

1. for DEBUG,

2. for INFO,

3. for WARNING,

4. for ERROR, and

5. for FATAL.

Table 5.4: Content of a log event

5.3.3 Federated query processing

As conceived in Chapter 2, the federated query processing (FQP) supported by theFIMA component provides of secure access to information that is distributed over theTeleCARE network, while hiding details of this execution process to the requester.

The interoperation strategy for FQP is based on a shared schema definition, auniform query language and mobile agent components, which resolves some of thetechnical differences of each node. At the high level, processing of federated queriesstarts when a request for data comes from the vertical service application or end-users(requester). This query is then evaluated against the data and schema structures ateach platform, related to the query, using mobile agents.

Agent mechanisms

The FQP supported by FIMA uses both mobile and stationary agents in order toperform the retrieval tasks. On one hand, stationary agents provide proper processingof information, control of query status, coordination of the activity, and verification ofcredentials of the requester. On the other hand, mobile agents are the base mechanismto transmit sub-queries to remote node(s), where information is located, and to mergeresults for the client at the TeleCARE platform where the query is submitted.

The agent-base approach is loosely depicted in Figure 5.14. A requester agentsubmits a federated query to FIMA agent interface which in turn will create a coor-


dinator agent to handle the query. This coordinator agent will summon the mobileagents that will execute the query on the remote platforms. Once the federated queryis executed, the results are merged and given back to the requester.

M I R A

F I M S

F Q P

Requester agent

Agent creation

Agent message

Figure 5.14: Retrieving information with agents

Federated query types

Federated queries designed for FIMA can retrieve data from multiple distributedTeleCARE platforms, using three different techniques. These technique or strategiesare access methods introduced here as federated query types, and describes as follows:

• Parallel query type, by which the performance and high speed are achieved atthe cost of high network utilization.

• Serial query type, by which the focus is the optimization of resource usability.

• Sequential query type offering interactivity with the requester to control theinformation-processing and access overhead.

The advantage of providing three different types of query is that the requestercan choose among access methods to control the general performance and overheadof the query process. It is then possible to establish some degree of optimization andperformance in the TeleCARE environment.


5.3.4 Structural design of internal subcomponents

The main subcomponents of FIMA are developed as TeleCARE agents, allowing ver-tical service applications to benefit from agent mechanisms. The key modules relatedto the architecture of FIMA are illustrated in Figure 5.15, including the followingsubcomponents:

1. Database repository2. Federated Information Management Server Agent (FIMS Agent)3. Agent Information Management System (AIMS)4. Mobile Information Retrieval Agent (MIRA)5. Information Access Manager (IAMA)6. Data Interface Mapping Access (DIMA)

Other

internal

components

z

TeleCARE platform

Deviceabstraction layer

- DIMA -Data Interface Mapping Access

- AIMS -Agent Information

Management System

FIM

S A

ge

nt

- MIRA -Mobile Information

Retrieval Agent

Base Service

Se

rvic

e A

Se

rvic

e B

Se

rvic

e C

Vertical

Services Layer

Core MAS

Platform Layer


RDBMS

- IAMA -Information

Access Manager

FIMA

F I M S

M I R A

Figure 5.15: FIMA reference architecture

Database repository

SAP DB [139] is adopted as the database repository for the TeleCARE platform,mainly because it is an open source database comparable to those RDBMS used withinthe telecaring domain. In addition, Castor is used as middleware to compensate andovercome the limitations of the database system in supporting Java connectivity andXML. The latter approach, described below, provides a way to transfer data betweenXML documents and relational databases.


SAP DB provides a strong ACID-compliant [63] implementation with basic objectorientation on top of it. It supports open standards, including SQL for data definitionand manipulation language, and JDBC and ODBC for data access. SAP DB isplatform independent, with users deploying a wide range of applications on Unix aswell as Windows platforms.

Castor facilitates the integration of Java objects and XML documents with SQLrelational databases, in a unified Java model. This model enables Castor to simplifythe exchange and manipulation of information, while allowing object persistence in avariety of ways. In essence, Castor provides elements for Java development that allowobject manipulation for both relational databases and XML data binding.

FIMS Agent - Federated Information Management Server Agent

The advanced information management functionality of FIMA is provided by anagent interface identified as Federated Information Management Server Agent (FIMSAgent). FIMS Agent is a stationary TeleCARE agent and TeleCARE agent appli-cations can communicate with FIMS Agent through both FIPA ACL, for high-levelnegotiation, and the proprietary TeleCARE messages for high-speed data access. Therequests accepted by FIMS Agent are grouped into three categories: a) Local objectpersistence, b) Log event management, and c) Federated query processing.

Local object persistence. The local Java object persistence is supported by a setof atomic operations. When these operations are executed, they perform theproper command on the underlying Information Access Manager (IAMA) (seebelow), which in turn binds the information with the database repository. Ta-ble 5.5 lists the supported operations of this set.

StoreObject This operation inserts or updates an object in the local storage (where the

FIMS Agent resides). Depending on a specific parameter, OperationType,

the object will be stored in database or updated in the local repository.

ReadObject The read object operation reads an object of a specified Java class type

(given an OID) from the local database repository. Basically, this method is

equivalent to performing a query that returns a single object.

DeleteObject The delete object operation erases an object from persistent storage. During

the process of deletion, if a transaction is committed, the object is no longer

available.

Table 5.5: Local object persistence operations

Log event management. To facilitate the activity-logging and auditing of the plat-form, FIMS Agent provides log event management functionalities providing arecord of activities generated by other modules. All operations of Table 5.6focus on supporting the log records. All TeleCARE agents are allowed to storea log event in the local repository, thus proper log examinations are availableat each local node.


StoreLog

Event

This operation creates a log record in the local repository. Every log

record should follow the specification of the XML Schema as presented in

Figure 5.13. This operation, however, will update the values of date, time

and node, with the according date and time of the message submission and

where FIMS Agent is running.

ReadLog

Events

This operation reads the totality of the log events from the local log repos-

itory. The results are given as a XML document.

DeleteLog

Events

This operation erases all log events and their content from the local reposi-

tory.

Table 5.6: Log event management operations

Federated query processing. FIMS Agent does not work alone and it generatesan agent with the sole purpose of processing the federated queries to gatherresults from the distributed platforms. Each of the new query agents will runindependently of the other, allowing the execution and handling of multiplequeries in different thread processes. Actually, FIMS Agent only supports localquery processing, while it creates a special agent for federated queries. Theoperations supported in this set are listed in Table 5.7.

GetFQPAgent The operation constructs a special FQP Agent, with the partial credentials of

the requester agent (i.e. the identification from the passport are replicated).

This FQP Agent will process the federated query command.

QueryObjects This operation translates the Object Query Language (OQL) instructions

into actual relational statements (SQL), and executes the query against the

local repository. This operation is not intended to be used by vertical service

developers to gather federated information from remote nodes, instead, they

should submit only local OQL queries and employ its functionality.

Table 5.7: Query processing operations

AIMS - Agent Information Management System

The Agent Information Management System (AIMS) sub-component is a key ele-ment of FIMA since it is in charge of processing federated queries using the agentenvironment. It must support the cooperation among federated applications withinthe TeleCARE network. AIMS itself consists of three main sub-components: 1) ac-cess rights mechanisms; 2) federated query processor agent; and 3) federated datamanagement tools.

Access rights mechanisms. Access right mechanisms address the definition of ac-cess levels on local schemas to support the security of the information within a


TeleCARE platform. The information visibility is based on the type of the agentand username requesting data access. Thus, the vertical service developers es-tablish the access rights to handle the data according to those two parametersas they are specified in the passport of all valid agents.

Federated Query Processor Agent. To handle the federated queries that accessdata from multiple TeleCARE sites, AIMS uses the Federated Query Proces-sor Agent (FQP Agent). The FQP Agent supports several specific activities,namely the query decomposition, the sub-query processing, and the sub-query-results merging. As such, this component handles the general query processingprocedure and internal steps with proper data structures. When a target listis specified in the query by the requester, FQP Agent executes the query onlyin those specific locations. Table 5.8 presents the operations supported by theFQP Agent.

Execute This operation creates the mobile agents and sends them to their appropri-

ate destinations, the agents then perform the query on the remote node.

Depending of the type of query, this operation can be re-executed. For in-

stance, if the type is sequential then the operation is repeated to retrieve

the results from each destination. For parallel and serial query types this

operation should be executed only once.

HasMore This operation indicates if the query is still active (i.e. it has a possible

execution state). This kind of operation is particularly useful when the query

type is sequential, since it checks the validity of the query in all targeted

nodes.

Close This operation releases all the resources held by the FQP Agent and disposes

the agent itself.

Table 5.8: FQP Agent operations

Federated data management tools. This component provides mechanisms forconfiguring the FIMA environment, and for internal database management.Namely, FIMA Studio is a developing environment to support federated mech-anisms found in TeleCARE platform. It includes specific tools such as agentviewers, command line logging, an editor for configuration files, etc.

MIRA - Mobile Information Retrieval Agent

The Mobile Information Retrieval Agent (MIRA) performs the federated retrieval ofinformation from external sites to be submitted to the query processor.

IAMA - Information Access MAnager

The Information Access MAnager (IAMA) supports the Java object persistence lo-cally, by executing proper instructions on the local database repository. This compo-


nent also includes an XML data-binding framework that provides facilities for conver-sion between Java objects and XML structures. IAMA is built on top of Castor, andit comprises two main sub-components: (i) JDO Manager, and (ii) XML Manager.These two sub-components handle the repository access and the XML data bindingrespectively. The operations supported by the XML Manager are listed in Table 5.9.

Marshall Allows Java object serialization into XML documents. It is possible to em-

ploy a mapping file to establish a particular translation between the Java

classes and the XML structure.

Unmarshall This operation allows the de-serialization from the XML document to a

Java object. To unmarshall a Java class, it must contain proper methods

for accessing the attributes. A mapping definition can also establish a more

clear translation.

Table 5.9: XML binding operations

DIMA - Data Interface Mapping Access

The External Enabler Layer of the TeleCARE platform supports the managementof device resources in TeleCARE. Each Data Interface Mapping Access (DIMA) pro-vides a static adaptation to services of the External Enabler Layer, such as legacyinformation resource or data coming from sensor devices. As such, every DIMA is aspecialized device abstraction adaptor that interacts with the device information andorganizes it into a schema to store in FIMA.

5.4 DOSG – Dynamic Ontology-based data Struc-ture Generation

The Dynamic Ontology-based Schema Generator (DOSG) assists the TeleCARE ser-vice developers with the specification of the data structures and the definition ofrelationships among the entities they need. Service developers first formulate theirdefinitions using Protege as the Ontology Management System, which allows themto easily define their concepts and their inter-relationships. DOSG will then takethese ontology-based definitions, and automatically generates the necessary databaseschemas, Java related structures, object-relational mappings, and even deploy thesedata structure into a working TeleCARE node.

As such, DOSG provides an innovative approach to assist and support the auto-matic generation of needed objects in the database from a conceptual model.

5.4.1 Relational database schema

The DOSG tool translates an ontology definition from Protege system into relationaldata structures. These structures are provided in the form of a SQL commands

5.4. DOSG – Dynamic Ontology-based data Structure Generation 113

which are used to create the relational tables in the TeleCARE database repository.This approach frees service developers from the details of defining a database schemaduring their application development, but also lets them further customize databasetables with particular constraints. Currently, DOSG generates ANSI SQL statementsthat are accepted on SAP DB.

5.4.2 Java source code

The DOSG generation tool creates a set of Java classes that represent the objectmodel defined with Protege. Furthermore, DOSG is able to compile the ontology-generated source files and provide a Java package ready to use by the developers,thereby shortening the development time.

5.4.3 XML Schema

XML is the de facto standard format for data exchange among distributed applica-tion components for co-operating applications. The use of XML for information in-terchange among different sites or organizations suggests the need for common XMLSchemas to be defined. With the DOSG tool, the domain experts and applicationdevelopers can establish a shared XML Schema that describes the structure of defi-nitions from Protege projects.

5.4.4 Mapping definitions

In order to provide meaningful information about how to relate the Java objects witheither the relational schema or to XML Schema, DOSG generates mapping definitionsas well. There are two kinds of mappings that DOSG can generate as files, namely,(1) JDO mapping file, and (2) XML mapping file.

JDO mapping

The Java data object mapping provides a mechanism for binding the object modeldescribed by the Java code with the underlying relational model of the databaseschema. Essentially, the content of the file represents an object-to-relational mapping(O-R mapping). O-R mapping bridges the gap between an object model and a rela-tional model by specifying how the objects and their relationships should be accessedfrom the database tables.

XML mapping

Similar to JDO mappings, the XML mapping is a way to bind Java classes to the XMLspecifications provided in the XML Schema. If this mapping is used in conjunctionwith the marshalling and unmarshalling framework of FIMA, the developers can easilytranslate the information contained in Java instances into XML documents.



The main focus of DOSG is the transformation of ontologies, defined with Protege,into the underlying information management model of TeleCARE. Therefore designand architecture of DOSG are intrinsically linked to this ontology system.

DOSG as a Protege plug-in

The design of the Protege allows the addition of software components through smallextensions, which are defined as “plug-ins”. Taking advantage of this feature, DOSGis developed as an application contained within a Protege plug-in. The DOSG plug-in enables the modeling process and the actual generation of the data structuresseamlessly integrated ‘inside’ Protege tool.

Figure 5.16 shows a screenshot of Protege system and its DOSG plug-in. In thisfigure, it is possible to identify a general section for project configuration, anotherarea for the different types of generation, a deployment section (for TeleCARE), anda window for establishment of connection settings.

Figure 5.16: Screenshot of DOSG plug-in

5.5. RCAM – Resource Catalogue Management 115

5.5 RCAM – Resource Catalogue Management

The Resource CAtalogue Management (RCAM) acts as a resource broker in the Tele-CARE environment, and it provides a searchable repository of resource descriptions.Through the RCAM, device providers and vertical service developers can advertiseand publish the functionality of their resources. It also allows other developers ofvalue-added services or agents to search for appropriate resources. With this search,the requesters can look into the internal service details of the resources, and obtainthe necessary information to use them properly.

RCAM holds the registry of resource entries, representing the definition of re-sources, their internal functionality, and the access rights to the resources. Namely,for every resource in the TeleCARE environment, there is a catalogue entry represent-ing (1) the description of that resource, (2) the description of the resource’s internalfunctionality (also called “internal services” for the resource) and (3) the access rightsto the resource. Description of TeleCARE resources in RCAM are based on widelyaccepted standards. This strategy allows RCAM to support both the current andfuture emerging devices and vertical service developments.

Furthermore, RCAM can store information about the access rights to TeleCAREresources, based on the TeleCARE passport details and rights definitions. As such,access rights are established per user-role or user-id on every TeleCARE resource.

5.5.1 Resource description publishing

In order to allow developers and others to interact with a resource, the resourceprovider must publish the resource’s description and their capabilities in the RCAMcomponent of the node where the resource resides. Then, RCAM can expose thisinformation to the public (device providers and vertical service developers, and theother TeleCARE agents and users, etc.).

Similarly, when a resource is removed from a site or the network, its entry should berevoked from RCAM advertisement. To do so, the resource (or the resource provider)should send the request to remove the announcement of resource unavailability toRCAM, in order to effectively declaring that the resource will no longer be availablewithin the TeleCARE environment.

5.5.2 Resource description discovery

After a resource description is added in RCAM, this means that the functionalityof this resource is available for others to use. Before actually using a resource’sinternal services, the requester needs to first learn about the resource, understand,and verify the proper way to invoke the resource’s internal services. This process ofunderstanding and learning about resources is called “resource description discovery.”RCAM properly supports this discovery and requesters in search of resources of theirinterest in the TeleCARE environment.

A resource requester is either a human user or an intelligent TeleCARE agent.Therefore the discovery is performed using two different interfaces for these different


purposes, namely supporting users at the design-time and run-time. During thedesign-time discovery the requester is typically a human user who will interact with theresource registry in order to find out and gather knowledge of the available resourcesin the TeleCARE network. During the run-time discovery, the resource requester isan intelligent TeleCARE agent, which can have the proper code to run over specificresource types, allowing a dynamic tightly-coupled integration between the intelligentagent and the resource.

5.5.3 Resource access rights management

When a resource is added to the TeleCARE environment, RCAM also allows theresource provider to place proper access rights to the resource. RCAM’s access rightsmanagement establishes the protection of the resource, through permission rightsto the resource and its internal services, based on the users and their roles. Thismechanism is used to accommodate a wide variety of security models.

RCAM, however, does not enforce the security on the resources itself, rather itprovides information on who can access the resources, and how. Therefore, it providesan extensible mechanism, to set and reset access rights as well as further describe thecharacteristics of the credentials that are included with an agent message.


The TeleCARE platform is a common infrastructure that supports several hardwareand software resources. Sensors, monitoring apparatuses and other hardware (homeappliances, environment controllers, ubiquitous devices, etc.) represent examples ofTeleCARE devices. On the other hand, examples of TeleCARE vertical services aresoftware applications implemented on top of the TeleCARE platform focused on caresupport services for the elderly, known as well as value-added services.

In order to consistently handle the two kinds of resources, namely the Devicesand the Vertical Services, an agent-based interface is defined as Abstract ResourceManager Agent (ARMA). Each ARMA thus interfaces the resource while an agent-based broker coordinates their utilization. The broker is implemented as RCAMAgent, which generates a specific repository for each type of resources, including alsotheir access rights. Figure 5.17 presents the overall behavior of each ARMA duringthe service-oriented phases of resource publishing, discovery and invocation. Theinteractions between these components are described as follows:

1. Initial installation and setup configuration between the instance of the ARMA,represented as Resource Manager, and the device number 1.

2. After the Resource Manager is configured, it advertises the device to RCAMAgent by publishing the description of the device and its services.

3. Besides technical characteristics of the device, the Resource Manager establishesthe access rights of the device number 1, using again the RCAM Agent.

4. The Vertical Service k is a telecaring application that attempts to discover theresource characteristics, using RCAM Agent.




Vertical

Services Layer

Publishing and Discovery

Device interface(for device 1)

ARMAResource Manager

(for device 1)

Ve

rtica

lS

erv

ice

k

Ve

rtica

lS

erv

ice

p

. . .

ARMA

Device interface(for device n)

. . .

Ve

rtica

lS

erv

ice

n

. . .

1

2

3

4

5

Invocation

Device interface(for device 1)

ARMAResource Manager

(for device 1)

Ve

rtica

lS

erv

ice

k

Ve

rtica

lS

erv

ice

p

. . .

ARMA

Device interface(for device n)

. . .

Ve

rtica

lS

erv

ice

n

. . .

6

7

8

9 10

11

12

Figure 5.17: Interaction between ARMA instance and RCAM Agent

5. The RCAM Agent returns the required information.6. The Vertical Service k sends requests to the Resource Manager.7. A request of verification of access to the device is received by RCAM Agent

from the Resource Manager.8. Once the credentials of the Vertical Service k have been validated, RCAM

Agents send an affirmative notification to the Resource Manager.9. The Resource Manager then translates the invocation requests to corresponding

device using the actions and commands of device (it may not be UPnP).10. After executing the requests, the device returns corresponding results and even-

tual state device information to the Resource Manager.11. The Resource Manager sends the results of the requests to the Vertical Service

k (using FIPA ACL).12. Assuming that the Vertical Service p agent has subscribed to event notifications

(not shown in the figure), it receives a message from the Resource Manager withthe change of the state variables of the device.

Abstract Resource Manager Agents

The resource manager agents have the functionality of integrating devices into theTeleCARE platform. The main objective of each ARMA is to effortlessly deal withthe diversity of different type of resources and interfacing models. These models can,for example, be Jini, UPnP, JNI, or even a proprietary protocol. The goal is to keepdevelopers from learning the low level and specific details of each TeleCARE resourcesand their interfacing methodology.

The basic structure of the abstract resource manager agent is shown in Figure 5.18.


The structure is based on the UPnP Specification for device managers and on WSDLfor vertical service managers. The shaded blocks represent the areas where developersshould insert the Java code for the interaction with the device interfaces. Theseinterfaces are the low-level components of the manufacturer of the resource. Theother blocks are provided by ARMA skeleton, as properties common to all resources.The functionality of each block is the following:

ARMA skeleton

Authorization

Access

Resource Definition

State Variables Handling

Services & Actions

Event Implementation

Device Behavior

TeleCARE agent

(including passport)

Figure 5.18: ARMA block structure

• Authorization Access Block. This section is in charge of verifying the authoriza-tion access to the resource. It is based on the agent and user credentials locatedin the passport.

• Resource Definition Block. The developers specify or define the descriptions ofthe device and its services in this section. This block interacts with RCAM inorder to publish the device descriptions in the TeleCARE environment, so thatthe resource can be detected by the high-level services.

• State Variables Handling Block. Within this block, the service state variablesare handled. In order to manipulate these variables adequately, a set of methodsis available, as described in the UPnP recommended vocabulary. At runtime,the telecaring applications or other agents can query the ARMA to check forthe values of these state variables.

• Services and Actions Block. As stated by the UPnP specification, a device canprovide a set of services. Each service acts as a container for a set of actionswith specific input and output parameters. In this block the programmers caninsert their Java code to interact with the (native) resource interface code.

• Event Implementation Block. The ARMA provides this functionality for eachspecific instance of resource manager agents. Thus, the developers only definewhich state variables are “evented” in the Resource Definition Block. The ap-plication agents then subscribe to this service and, whenever a state variable


has its value changed (which be defined as an event), ACL messages are sent tothese application agents notifying about the change of the variable.

• Device Behavior Block. This block is necessary for those situations when theARMA needs to constantly interact with the device (such as a monitoring read-ing). Here, the developer can implement a control cycle for the resource, sendingcontrol commands to the device and performing changes on the state variablesusing the recommended vocabulary.

RCAM Agent

All descriptions for hardware and software resources used for home domotics areadministered in TeleCARE by RCAM Agent. The descriptions of hardware resourcesare handled by the Device Description Management, while the description of softwareresources are handled through the Vertical Services Description Management. Addi-tionally, using the Access Rights Management, the credentials of permitted access areestablished and liked to the resource descriptions.

Device Description Management. Devices are published and, later, discov-ered in the TeleCARE site using the device description management. With a properdescription, requesters can learn about device capabilities, and how to interact withits services. Table 5.10 lists the supported operations.

Subscribe

Device

This operation advertises the device definition, specified in UPnP format.

The definition is stored in the corresponding catalogue, where RCAM Agent

resides.

Unsubscribe

Device

This operation removes a given device definition from the resource catalogue,

using the unique device name (UDN).

Publish

Device

Services

This operation publishes into the resource catalogue the definition of an

internal services, in UPnP format.

Unpublish

Device

Services

This operation deletes the device service definition from the catalogue, spec-

ified with the SCPDURL of the UPnP definition (URL for device service

description).

Request

Device

The request device operation returns from resource catalogue the definition

of the device, specified by the unique device name (UDN).

Request

DeviceList

This operation returns a vector of UDNs of all devices described in the re-

source catalogue. This operation can also search for specific type of devices.

If no type is specified, RCAM Agent will return all the UDNs of the devices

where RCAM resides.

Request

Device

Services

This operation returns the device service definition, specified with SCPDURL

of the UPnP format (URL for device service description).

Table 5.10: Device description management operations


Vertical Service Description Management. The vertical service descriptionmanagement allows the requester to search for, view, and invoke TeleCARE verticalservices. The management operations handle descriptions based on the Web ServicesDefinition Language (WSDL). Table 5.11 shows the implemented operations.

Subscribe

Vertical

Service

This operation subscribes vertical service definition specified with WSDL

into the catalogue where the RCAM Agent resides.

Unsubscribe

Vertical

Service

This operation unsubscribes the vertical service information, specified in

WSDL, from the resource catalogue.

Request

Vertical

Service

This operation returns the vertical service definition in WSDL format, cor-

responding to the resource from the catalogue.

Request

Vertical

ServiceList

This operation returns a vector of Vertical Services from the resource cat-

alogue. This operation searches for specific port name of vertical services.

However, if no port name is specified, RCAM Agent will return all vertical

services at the site where RCAM resides.

Table 5.11: Vertical service description management operations

Access Rights Management. This management provides operations, listed onTable 5.12, to place the access rights on TeleCARE resources. RCAM Agent bindsuser information to every resource in order to establish the security, namely the user-role and user-id.

Validate

Access

This operation verifies the access rights authorization related to certain pass-

port credentials. If no permission for a specific resource is found in the

registry, the access will be denied.

Permit

Role

This operation defines the access and usage rights for users with a given

‘role’ and ‘domain’ for access of a resource. This operation allows users of

a given role to manage a resource object.

Restrict

Role

This operation restricts the access and usage of a resource to users of a

given ‘role’ from the specified ‘domain’.

Permit

User

This operation defines the rights for a specific users to access and use a

resource.

Restrict

User

This operation restricts a specific user from access and use a resource.

Table 5.12: Access rights management operations

Note however that Resource Manager Agents are the active elements that use thisinformation to grant access to the resource (and not RCAM Agent). Each resource


manager agent validates the authorization and access rights of the user in order toproperly secure the access to resources for each action request.

Although the RCAM component is a TeleCARE agent, thus supporting mostlyagent-based interaction (i.e. agent messaging), it also holds a GUI for human-basedinteraction and administration of resource descriptions and its access rights. The GUIdepicted in Figure 5.19 corresponds to the RCAM Administration Tool.

Figure 5.19: Screenshots of RCAM Administration Tool


5.6 Validation through TeleCARE Vertical Services

The clearest and most direct way to validate and verify the applicability of the fed-erated information management functionalities developed for the TeleCARE environ-ment, is to study how the development of emerging tele-assistance services benefitsfrom these functionalities. To illustrate this, one of TeleCARE’s basic services, Vir-tual Community Support, is used as an extended example, while two of TeleCARE’svertical services, Agenda Reminder and Living Status Monitoring, are used as briefexamples. The full description of each of the application services has been previouslyreported [19, 127, 141]. The key characteristics of each of these three services arebriefly described in this section, together with a table summarizing the contributionof the FIMA, DOSG and RCAM components in each situation.

5.6.1 Virtual Community Support

The Virtual Community Support (VC Support) is a base service that provides to itsfinal users (elderly) new approaches to socialize and improve their quality of life. Theparticipation in virtual communities is an important feature, playing a significant rolein recreating personal experiences that may be impossible otherwise. In TeleCARE,a virtual community offers elderly people the feeling of belonging and the facilityof communication. It also makes it possible for elderly people to contribute andcollaborate within a group.

The VC Support service provides the base mechanism for administration andevolution of TeleCARE virtual communities. As such, this tool provides basic func-tionalities to support the creation, operation, evolution and maintenance of virtualcommunities in the TeleCARE environment. VC Support uses the functionalities ofthe federated management of information offered in the TeleCARE network.

The data model of the VC Support base service is based on the TeleCARE Com-mon Ontology, extending particularly the user concept. The VC Support ontologymodels the entities and the relationships between them as well as the higher level oper-ations performed on these concepts. Figure 5.20 shows an initial diagram establishedwith Protege in terms of the VC Support model.

A VC service provider (care center, leisure site, etc.) can support any numberof virtual communities. From the information management point of view, a VirtualCommunity consists of a set of basic configuration attributes, registered members andgeneral interest groups. In every VC, the administrator can define several InterestGroups (IG) and designate Users (from the respective VC members) into these IGs.Furthermore, the VC administrator can assign moderators to the IG, which in turncan define one or more Message Boards (MB) for the interaction, discussion, andannouncements for the benefit of the members of the respective IG. The interactionin any VC is performed through Contributions. The contributions can contain thearticles or documents in the form of Attachments submitted by the VC member.

The modeled concepts, relationships and operations are automatically generatedinto proper structures by DOSG, a task that is not necessarily perceptible by the VCSupport client user. Figure 5.21 provides an extract of the actual SQL code generated

5.6. Validation through TeleCARE Vertical Services 123

-person : Person-username : String-password : String-subscriptionDate : String-roleList : Role-picture : Photo

User

-name : String-content : String

Attachment

-name : String-beginDate : String-endDate : String-keywords : String-qualifier : String-note : String-attachmentList : Attachment

Contribution

0..*

1

-name : String-beginDate : String-endDate : String-description : String-topic : String-styleSheet : String-attachmentLimit : Integer-contributionList : Contribution

MessageBoard

1..*1

-name : String-beginDate : String-endDate : String-description : String

-creator : String-memberList : User-moderatorList : User-messageBoardList : MessageBoard

InterestGroup

1..*

1

1..* 1

1..* 1

-name : String-beginDate : String-endDate : String-description : String-organization : String-mainContact : String-homePage : String-membershipCriteria : String-memberList : User-administratorList : User-interestGroupList : InterestGroup

VirtualCommunity

1..* 1

1..* 1

1..*

1

Figure 5.20: Ontology for Virtual Community Support

by that tool involving the message board and contribution entities. Evidently, theagent-based FIMA is employed for the information management of the VC Supportbase service, including storage for creation and operation of virtual communities,their members, and their contributions. Federated queries are applied to generatecommunity reports or search for specific contributions.

For instance, it is possible to establish the values and information of every VCfrom the GUI of VC Support, however, the data transfer is internally handled byFIMA. Figure 5.22 illustrates how IG moderator can define one or more messageboards for interaction and discussion, or for general announcements, for the benefit ofthe members of the respective IG. Clearly enough, the task of creation and submissionof contributions and attachments for the message board is the responsibility of thecommunity provider.

A summary of the significant characteristics of the usage of the information man-agement mechanisms for the VC Support service is shown in Table 5.13.


CREATE TABLE "VCS_CONTRIBUTION" ("OID" INTEGER NOT NULL,"ENDDATE" VARCHAR (255) ASCII,"NOTE" VARCHAR (255) ASCII,"KEYWORDS" VARCHAR (255) ASCII,"BEGINDATE" VARCHAR (255) ASCII,"QUALIFIER" VARCHAR (255) ASCII,"NAME" VARCHAR (255) ASCII NOT NULL,

PRIMARY KEY ("OID") );...CREATE TABLE "VCS_MESSAGEBOARD" (

"OID" INTEGER NOT NULL,"ENDDATE" VARCHAR (255) ASCII,"STYLESHEET" VARCHAR (255) ASCII,"BEGINDATE" VARCHAR (255) ASCII,"NAME" VARCHAR (255) ASCII NOT NULL,"TOPIC" VARCHAR (255) ASCII,"ATTACCHMETLIMIT" INTEGER,"DESCRIPTION" VARCHAR (255) ASCII,

PRIMARY KEY ("OID") );...CREATE TABLE "VCS_RL_MESSAGEBOARD_CONTRIBUTION" (

"OID" INTEGER NOT NULL DEFAULT SERIAL (1),"MESSAGEBOARD_OID" INTEGER,"CONTRIBUTION_OID" INTEGER,

PRIMARY KEY ("OID") );...ALTER TABLE "VCS_RL_MESSAGEBOARD_CONTRIBUTION“

FOREIGN KEY "FK_MESSAGEBOARD" ("MESSAGEBOARD_OID") REFERENCES "VCS_MESSAGEBOARD" ("OID") ON DELETE CASCADE;

ALTER TABLE "VCS_RL_MESSAGEBOARD_CONTRIBUTION" FOREIGN KEY "FK_CONTRIBUTION" ("CONTRIBUTION_OID") REFERENCES "VCS_CONTRIBUTION" ("OID") ON DELETE CASCADE;

...

Figure 5.21: Extract of output generation for VC Support

FIMA Handling information of Virtual Community, VC Member, Interest Group,

Message board and Contribution.

DOSG Concepts of the VC Support service are described with an ontology. DOSG

is used to construct the data structures at the Care Centre.

RCAM This base service interacts with RCAM in order to publish its functionalities

to support the creation, operation, evolution and maintenance of VCs.

Table 5.13: Information management for Virtual Community Support service

5.6.2 Agenda Reminder

The Agenda Reminder is a vertical service allowing the management of individualagendas for elderly people. It provides the necessary hardware and software for a carecenter to update agendas located at the home of the elderly and the other locations oftheir relatives (homes, offices, etc.). Forgetfulness is common in the elderly, causingthem to miss activities and meetings that could improve their physical and social

5.6. Validation through TeleCARE Vertical Services 125

Figure 5.22: Message board administration

well-being. The Agenda Service partially compensates for their loss of memory, byreminding them of the actions they could focus on.

Table 5.14 shows the key characteristics of the usage of the information manage-ment mechanisms in the Agenda Reminder service.

FIMA Handling information of Event, Proposal, Alarm and Event log. FQP Agents

are used to gather data contained in the remote nodes.

DOSG Concept definition for Proposal, Proposal Type, Event and Alert. DOSG

transformed the concepts into appropriate data structures. No code by

developers is required to define the structures into the database

RCAM This service registers and establishes proper access rights through RCAM,

when it is deploy on the location where the elderly resides.

Table 5.14: Information management for Agenda Reminder service

5.6.3 Life Status Monitoring

The Life Status Monitoring is a vertical service that proposes an innovative tele-assistance system for the elderly. The assistance is either requested manually, by theelderly through alarm buttons, hands-free communication devices, etc., or automati-cally, via the information generated by the medical equipment and hardware sensors.Moreover, the Life Status Monitoring service uses bi-directional information flows,together with complementary information sources (e.g. video cameras) in order to ac-


curately assess the characteristics and urgency of the situation to reduce the incidenceof unnecessary travel of care personnel.

Table 5.15 depicts the key characteristics of the usage of the information manage-ment mechanisms in the Life Status Monitoring service.

FIMA The information managed for this service relates to parameters describing

the normal life of the elderly. Reading and Event data originated from the

monitoring sensors is also managed by FIMA component. Federated queries

are applied to generate reports.

DOSG Concept definition for Parametrization, Response, Response type, Alerts and

Alert type. Translation of concepts into the primary data structures.

RCAM This service publishes its functionalities when it is deployed. Resource dis-

covery is used when this service searches for audio and video and monitoring

devices that are available at the home of the elderly. Access rights for

monitoring devices are assured for authorized users.

Table 5.15: Information management for Life Status Monitoring service

5.7 Conclusion

A federated information management approach offers suitable mechanisms to copewith the required flexibility, heterogeneity, autonomy, and privacy requirements forinformation handled within collaborative networks for care of the elderly. The com-bination of this approach with a mobile agent-based platform has proved to be aneffective approach to developing a flexible infrastructure supporting a large variety oftelecaring services.

The validation prototype system of TeleCARE supports information interoperabil-ity between agent-based systems, contributing to an open plug-and-play philosophyinvolving a resource variety of hardware devices and appliances, as well as vertical ser-vices. The federated query processing in TeleCARE transparently provides access toremote data from several nodes and supports different types of queries. The dynamicontology-based data structure generation facility offers system and service developersa new level of flexibility as they can focus on modeling their tasks at the ontologylevel using a user-friendly interface. Finally a modular approach is introduced forresources (devices and services) to be integrated in TeleCARE via the resource cata-logue management component, thus making it possible for resources to be discoveredand applied in the future service developments for this environment.

Chapter 6

Conclusion and future work

6.1 Introduction

This chapter concludes the thesis by summarizing results and contributions of theresearch work. We address the solutions given in the different chapters of this thesisto answer the research questions.

The chapter provides the evaluation of the research method, the selection of casestudies, the challenges in multi-disciplinary research, and the lessons learned from thiswork. Finally, a number of directions on how to continue this research are outlined.

6.2 Answers to the Research Questions

The main general objective, presented in Chapter 1, has been achieved, in general, byproposing an agent-based approach to support the federated information managementin telecaring Virtual Organization (VO) environments. This has been implemented inthe TeleCARE project and validated using different case studies. The results indicatedthat the approach can be used to support research and industrial needs to keep theelderly healthy and socially integrated.

In order to be able to support an agent-based information management systemfor telecaring VOs, a good understanding of the design of a such system is required.Thus, a comprehensive set of questions is proposed in the first chapter of this thesisand their detailed solutions are found in the subsequent chapters. A summary of theanswers is found below.

RQ1 The answers to RQ1 are defined in the context of a federated information systemapproach. The combination of this approach with an agent-based platform hasproved to be an effective way to develop a flexible infrastructure supporting alarge variety of services.

The design and implementation of a Federated Information MAnagement(FIMA) component demonstrates that it is possible to benefit from an agent-

127

128 Chapter 6. Conclusion and future work

based paradigm to handle a wide variety of data models, while its validationwith industrial cases shows clearly its value in the telecaring domain.

The agent-based model of the federated information system is proposed in [124].

RQ2 The answers to RQ2 provide means of describing a federated query process-ing as an agent-based model. The federated information management systemoffers suitable mechanisms to cope with the required heterogeneity, autonomy,and privacy requirements for information handled within VOs. The agent-basedparadigm offers facilities to wrap both lower-level devices and high-level telecar-ing services, and then store their information. This information is retrieved andaccessed from (several) remote sites by using the federated query processing.This kind of processing supports large numbers of users and agents accessingand retrieving data, while providing visibility rights to physically distributedand heterogeneous data.

The designed system does not require any centralization, it supports flexibilityand extensibility required for the future of the telecaring VO.

A description of the federated information management system is defined in [123]and extended with agent-based federated query processing in [62].

RQ3 The answers to RQ3 go beyond defining just a data model for the platformcomponents or vertical services, rather are closer to establishing a shared under-standing among the people in the telecaring field. Although there are differentaspects involved in the modeling of the information regarding the base platformand the telecaring services, an ontology can be used to define the concepts withsome level of detail and structure.

To reach the suitable ontology for a particular telecaring service, however, thedeveloper is required to follow some steps. These steps include the ontologydesign, the ontology evolution, and the data structure generation. In general,an ontology comprises a set of concepts and relationships that both people andsoftware can use to represent the application area for which the ontology isdesigned. This thesis does not address the issues governing the definition of theontology itself, but rather focuses on the generation of data structures basedon the ontology. It is through an automatic generation of physical databases,program structures, and other implementation details, that developers can focuson modeling proper concepts and not on creating technical definitions.

Parts of the basic elements for a methodology to build a base ontology modelfor telecaring services and other applications is found in [48]. The insights of thedata structure generation can be found in [106], while its application in otherscientific areas can be found in [142].

RQ4 The answers to RQ4 are obtained by wrapping lower-level devices and high-level telecaring services with plug-and-play agents. The functionality of all theseagents is different and, thus, some description about the operations supportedby them is required.

6.3. Summary of results 129

Using a Service-Oriented Architecture (SOA), together with widely acceptedstandards for device services and software services, agents can search, discoverand invoke autonomously for the telecaring resource they require. With anagent-based broker, device and vertical service providers can advertise and pub-lish the functionality of their resources in a telecaring VO environment. Otherdevelopers or value-added services can interact with this broker to search forappropriate resources, and then obtain the necessary description to invoke theresource operations properly.

Since privacy and security is a main concern in telecaring, the access rights tothe resource are also considered. These access rights are based on agent anduser credentials, allowing flexible and extensible strategy to support both thecurrent and future emerging developments.

The high-level description of the SOA design is presented in [113], while [124]shows how its agent-based approach fits in a telecaring platform.

RQ5 To answer to RQ5 is not easy since scenarios to verify the applicability of theagent-based and federated information management functionalities are not sim-ple. The ideas presented in this thesis are applied only to the area of telecaringof the elderly in the context of the European funded project TeleCARE. Be-sides, the description of the validation only focuses on part of industrial servicesof the project, namely, one base service, Virtual Community Support, and twovertical services, Agenda Reminder and Living Status Monitoring. These casesare complex but served well as field experiments to validate the prototype.

A complete description of Virtual Community Support the base service can befound in [19]. The evaluation and validation criteria are shown in [124].

RQ6 The answers to RQ6 are provided as results and contributions of the agent-based approach to information management that are applicable to differentVOs. The approach and a large portion of the results of the thesis are genericenough to apply to most other service-oriented VOs.

The ideas focus on the design of a generic, open, and flexible architecture,after considering the heterogeneity, autonomy and physical distribution of theinvolved organizations, and actors in the telecaring domain. The design ofan appropriate generic architecture provides an infrastructure to support thebasic functionalities, on top of which dedicated value-added services can bedefined. The applicability in other VOs however depends highly on the paradigmsupported by those VOs, namely, agent-based mechanisms, ontology, federatedinformation systems, etc.

6.3 Summary of results

The idea of using new technologies to support care provision for the elderly is not newand there are many initiatives already underway. A number of research projects, in avariety of areas, address technological solutions to improve the care services, in order

130 Chapter 6. Conclusion and future work

to reduce costs. For instance, some experiments are using “social alarm” systems whenthere is an emergency situation, namely for the case of people living in remote places.These systems usually comprise a portable alarm trigger, an automatic telephone call,and an alarm control to relatives or care center. These solutions however becomeunsuitable for the following reasons:

• Responsibility to (working) relatives is impractical.• Provision of one-way line to care centers is costly and also difficult to assess the

level of emergency of the situation.• Elderly may not be aware of location of their homes.

More recent works are focused on mobile social alarm systems or monitoring sys-tems based on a diversity of sensors and other devices, aiming at bringing healthcareto the patient. For instance, the MobiHealth [143] system allows patients to be mobilewhilst undergoing health monitoring; the patient wears a lightweight monitoring sys-tem which is customized to their individual health needs and can wirelessly transmitinformation to their physician.

The opportunity for more advanced care approaches including comprehensive sta-tus monitoring, forms of assistance such as agenda reminders, and opportunities to getthe elderly involved in a community are now available. With different organizationsdeveloping different products and services, however, there is a need for a commonplatform into which all these developments may be plugged so that interoperability ispossible. The project TeleCARE developed this platform, a common infrastructureso that the community of the elderly and those responsible for providing care andassistance can get the best out of the care technologies.

The federated information system of the TeleCARE infrastructure, provided byFIMA, properly supports the information-sharing and exchange among the nodes ofthe TeleCARE network by means of stationary and mobile agents, while supportingthe node autonomy, the information visibility levels, and access rights for exchangedinformation. The Federated Query Processing supported by FIMA has been designedto retrieve remote information, while hiding the processing details, including querydecomposition, distribution of queries to remote nodes, secure access, and merging ofresults. Furthermore, it incorporates features allowing the possibility to launch threedifferent types of federated queries, allowing requesters to optimize their queries.

The data access performed by FIMA uses an object data model, which is gener-ated by the DOSG component. This object data model supports both human andagent interpretation, and it is based on the ontological definitions provided by Tele-CARE service developers. DOSG provides mechanisms for the developer to exchangeinformation based on XML format, making the interoperability more flexible.

The TeleCARE platform includes configurable infrastructure supporting the man-agement of resources specific applied to care service applications. Based on the tele-caring resource model, resources are described with well-known SOA protocols andsecured with agent credentials. Acting as an agent-based resource broker, the RCAMAgent component provides the required negotiation functionality in the platform.

In order to evaluate the platform results, several vertical services were implementedwith the purpose of simulating real situations in the domain of care for the elderly.

6.4. Next steps 131

This thesis addressed the applicability and validation of all functionality providedby FIMA, DOSG and RCAM, through their usage in two vertical services, AgendaReminder and Living Status Monitoring, and the base service Virtual CommunitySupport. The concept of virtual community serves as basis for the other services.

The work presented in this thesis has been published in international conferencesand journals. This provided valuable feedback while, at the same time, it also helpedto disseminate the contributions to the scientific field. Clearly, there are inconsis-tencies between the content of the papers and this thesis. It is often difficult toestablish the right focus for the paper, while keeping them self-contained, due to themulti-disciplinary nature of the conferences and publishers.

We can conclude that the design and implementation of information managementfor telecaring expressed in this thesis satisfies all the information management require-ments that are identified within the context of Chapter 1. Moreover, all componentsprovide a solid platform that simplifies the deployment and execution of services forelderly users, while it can be extended in order to address future services or can evendeployed in a different VO.

6.4 Next steps

There are a number of future research directions related to certain aspects of the workpresented in this dissertation.

Ontology integration. Ontology integration involves general strategies for gener-ating a common ontology from different conceptualizations. Resolving conflictsis an activity performed manually by the domain experts. Thus, using an agent-based model to support and enhance the negotiation and to partially support theontology formation could reduce the ontology creation time while minimizingthe resources that are used in the ontology creation.

Ontology and database evolution. The development of a domain ontology is acollaborative process, which nowadays is being held at different locations. Fur-ther improvement of the ontology, the version control, and evolution bring tolight the challenges to update the database schema as well. A reliable frame-work which keeps compatibility between ontology-database versions must beconsidered in future research.

Semantic services. With an increasing number of competing services in a network,it is crucial that developers and agents are supported in selecting appropriateservices that cover their needs, otherwise, the usefulness of the services willstay questionable. To benefit fully from future complex service offerings, andto handle the increasing variety of telecaring applications, research into ad-vanced techniques for profiling and semantically-enriched service descriptions isrequired. Motivated by the emerging Web Service paradigm and its proposedimplementation and language standards (e.g. OWL-S or WSDL-S), researchactivities can prepare the mechanisms to support a wide range of services.

Bibliography 133

Bibliography

[1] Commission of the European Communities, “e-Health - making healthcare better foreuropean citizens: An action plan for a european e-Health area,” Tech. Rep. COM(2004) 356 final / SEC(2004)539, COM, Brussels, April 2004.

[2] Health Care Task Force, “Can we have it all? balancing access, quality, and cost inhealth care,” tech. rep., Vermont Business Roundtable, Vermont, USA, January 1999.www.vtroundtable.org.

[3] European Commission, “Final report 3rd framework programme telematics systemsfor health care (AIM) 1991-1994,” Tech. Rep. Volume 1, European Commission, Di-rectorate General XIII, Telecommunications, Information Market and Exploitation ofResearch. Directorate C: Telematics Applications (networks and services), Brussels,Belgium, September 1996. http://www.ehto.org/aim/ M. Sosa-Iudicissa (Editor).

[4] M. J. Field, Telemedicine: A Guide to Assessing Telecommunications in Health Care.National Academies Press, October 1996.

[5] NHS Executive, “Information for health: an information strategy for the modern NHS1998-2005.” Leeds: NHS Executive, 1998.

[6] I. Bante, “MobiHealth: new mobile services in healthcare.” Ducth Pavilion@ist2004,November 2004. http://www.ctit.utwente.nl, University of Twente, CTIT.

[7] TELEMEDICARE, “Telematic support for patient focused distant care.” IST-1999-10754 Project, 2002. http://www.telemedicare.net/.

[8] Ksyos, “TeleDermatology ’safe transmula communications’.” Dutch Pavilion@IST2004, November 2004. http://www.ksyos.org.

[9] L. M. Camarinha-Matos and H. Afsarmanesh, “Infrastructures for collaborative net-works - an application in elderly care,” in SAINT ’05: Proceedings of the 2005 Sympo-sium on Applications and the Internet (SAINT ’05), (Washington, DC, USA), pp. 94–101, IEEE Computer Society, 2005.

[10] World Health Organization, “A Health Telematics Policy in support of WHO’sHealth-for-All Strategy for Global Health Development,” tech. rep., Report of theWHO Group Consultation on Health Telematics 1997 Dec 11-16, 1998. PublicationWHO/DGO/98.1 1998.

[11] L. M. Camarinha-Matos and H. Afsarmanesh, “The virtual enterprise concept,” inInfrastructures for Virtual Enterprises (L. M. Camarinha-Matos and H. Afsarmanesh,eds.), pp. 3–14, Dordrecht, The Netherlands: Kluwer Academic Publishers, 1999.

[12] R. Butlje and J. van Wijk, “Taxonomy of virtual organizations, based on definitions,characteristics and typology,” Virtual-Organization.net, vol. Newsletter Vol. 2, No. 3 ,p. http://www.virtualorganization.net/, 1998.

[13] H. Rheingold, The virtual community: Homesteading on the electronic frontier. Read-ing, Massachusetts: Addison-Wesley, 1993.

134 Bibliography

[14] L. M. Camarinha-Matos and H. Afsarmanesh, “Virtual communities and elderly sup-port,” in MIV ’01 - Advances in Automation, Multimedia and Video Systems, andModern Compuuter Science (V. Kluev, C. D’Attellis, and N. E. Mastorakis, eds.),pp. 279–284, WSES, 2001.

[15] L. M. Camarinha-Matos and H. Afsarmanesh, “A multi-agent based infrastructure tosupport virtual communities in elderly care,” International Journal of Networking andVirtual Organizations, vol. 2, no. 3, pp. 246–266, 2004.

[16] L. M. Camarinha-Matos and H. Afsarmanesh, “Design of a virtual community in-frastructure for elderly care,” in Proceedings of the 3rd IFIP Working Conference onInfrastructures for Virtual Enterprises (PRO-VE 2002), (Sesimbra, Portugal), KluwerAcademic Publishers, 2002.

[17] C. Garita, H. Afsarmanesh, and L. Hertzberger, “The PRODNET federated infor-mation management approach for Virtual Enterprise support,” Journal of IntelligentManufacturing, vol. 12, pp. 151–170, 2001.

[18] C. Garita, E. C. Kaletas, H. Afsarmanesh, and L. O. Hertzberger, “A service interfacedefinitions catalogue for virtual enterprises in tourism,” in Proceedings of the IFIPTC5/WG5.3 Fifth IFIP/IEEE International Conference on Information Technologyfor Balanced Automation Systems in Manufacturing and Services (BASYS ’02), (De-venter, The Netherlands), pp. 97–108, Kluwer, B.V., 2002.

[19] H. Afsarmanesh, V. Guevara-Masıs, and L. O. Hertzberger, “Virtual community sup-port in TeleCARE,” in Proceedings of the 4th IFIP working conference on Virtual En-terprises PRO-VE ’03, Processes and Foundations for Virtual Organisations, (Lugano,Switzerland), pp. 211–220, Kluwer Academic Publishers, 2003.

[20] B. R. Katzy and G. Sung, “Building virtual professional communities,” in Proceedingsof the IFIP TC5/WG5.5 Third Working Conference on Infrastructures for VirtualEnterprises (PRO-VE ’02), Sesimbra, Portugal, Kluwer, B.V., 2002.

[21] TeleCARE Consortium, “Final report on user requirements,” Tech. Rep. D1.3, NavarraChamber of Commerce and Industry-UPD, June 2002. Compiled by A. Pascual.

[22] TeleCARE, “A multi-agent tele-supervision system for elderly care.” Internet Refer-ence, 2007. http://www.uninova.pt/~telecare.

[23] TeleCARE Consortium, “A definition of different typologies of end users,” Tech. Rep.D1.1, Navarra Chamber of Commerce and Industry-UPD, June 2002. Compiled by A.Pascual.

[24] C. Sørensen, “This is not an article - just some food for thoughts on how to writeone,” technical report - 121, London School of Economics & Political Science, 2002.http://is.lse.ac.uk/staff/sorensen/downloads/not/notart.pdf.

[25] R. D. Galliers, “Choosing appropriate information systems research approaches: Arevised taxonomy,” in Information Systems Research: Contemporary Approaches andEmergent Traditions (H. Nissen, H. Klien, and R. Hirschheim, eds.), pp. pp. 327–345,Elsevier Science Publishers (North Holland), 1991.

Bibliography 135

[26] CO-IM Group, “Co-operative Information Management Group.” Internet Reference,2007. http://www.science.uva.nl/CO-IM/.

[27] S. Busse, R.-D. Kutsche, U. Leser, and H. Weber, “Federated information sys-tems: Concepts, terminology and architectures,” Tech. Rep. Forschungsberichte desFachbereichs Informatik 99-9, Computergestutzte InformationssystemeCIS, TechnischeUniversitat Berlin, 1999.

[28] A. P. Sheth and J. A. Larson, “Federated database systems for managing distributed,heterogeneous, and autonomous databases,” ACM Computing Surveys, vol. 22, no. 3,pp. 183–236, 1990. ISSN: 0360-0300.

[29] N. R. Jennings, “Coordination techniques for distributed articial intelligence,” in Foun-dations of Distributed Articial Intelligence (O’Hare and N. R. Jennings, eds.), pp. 187–210, Wiley, 1996.

[30] Y. Shoham, “Agent-oriented programming,” Artificial Intelligence, vol. 60, pp. 51–92,March 1993.

[31] M. Wooldridge, “Intelligent agents: The key concepts,” in Proceedings of the 9thECCAI-ACAI/EASSS 2001, AEMAS 2001, HoloMAS 2001 on Multi-Agent-Systemsand Applications II-Selected Revised Papers, vol. 2322 of Lecture Notes in ArtificialIntelligence, (London, UK), pp. 3–43, Springer-Verlag, 2002.

[32] J. P. Muller, B. Bauer, and M. Berger, “Software agents for electronic business:Opportunities and challenges,” in Multi-Agent-Systems and Applications II : 9thECCAI-ACAI/EASSS 2001, AEMAS 2001, HoloMAS 2001. Selected Revised Papers(V. Marık, O. Stepankova, K. H., and M. Luck, eds.), vol. 2322 / 2002 of LectureNotes in Computer Science, pp. 61–106, Springer-Verlag GmbH, January 2002. ISSN:0302-9743.

[33] A. I. Wang, R. Conradi, and C. Liu, “A multi-agent architecture for cooperative soft-ware engineering,” in The Eleventh International Conference on Software Engineeringand Knowledge Engineering (SEKE’99), (Kaiserslautern, Germany), pp. 1–22, June1999.

[34] M. Wooldridge and P. Ciancarini, “Agent-oriented software engineering: The state ofthe art,” Agent-Oriented Software Engineering, pp. Springer–Verlag, 2001.

[35] D. Lange and M. Oshima, Programming and deploying Java mobile agents with aglets.Addison-Wesley, 1998.

[36] F. Baude, D. Caromel, F. Huet, and J. Vayssiere, “Communicating mobile ac-tive objects in java,” in Proceedings of HPCN Europe 2000 (R. W. Marian Bubak,Hamideh Afsarmanesh and B. Hetrzberger, eds.), vol. 1823 of LNCS, pp. 633–643,Springer, May 2000.

[37] S. Green, L. Hurst, B. Nangle, P. Cunningham, F. Somers, and R. Evans, “Softwareagents: A review,” Tech. Rep. TCS-CS-1997-06, Trinity College Dublin, BroadcomEireann Research Ltd., Dublin, Ireland, 1997.

136 Bibliography

[38] D. Chess, C. Harrison, and A. Kershenbaum, “Mobile Agents: Are They a GoodIdea?,” Tech. Rep. RC 19887 (December 21, 1994 - Declassified March 16, 1995), IBMResearch Division, Yorktown Heights, New York, 1994.

[39] L. Y. Deng, T. K. Shih, T.-S. Huang, C.-H. Huang, R.-X. Chen, and Y.-L. Chang,“Universal access for roaming user via mobile agent technology,” International Journalof Tamkang Journal of Science and Engineering, vol. 5, pp. 175 – 186, September 2002.

[40] A. Silberschatz, H. Korth, and S. Sudarshan, Database system concepts. Mc Graw Hill,4th ed., 2002.

[41] P. E. Renaud, Introduction to client/server systems: a practical guide for systemsprofessionals. New York, NY, USA: John Wiley & Sons, Inc., 1993.

[42] Object Management Group, “CORBA – Common Object Request Broker Architec-ture.” Internet Reference, 2007. http://www.omg.org/.

[43] A. D. Stoyenko, “SUPRA-RPC: SUbprogram PaRAmeters in remote procedure calls,”Software–Practice & Experience, vol. 24, no. 1, pp. 27–49, 1994.

[44] J. White, “Telescript technology: The foundation of the electronic marketplace,” whitepaper, General Magic Inc, 1994.

[45] M. T. Ozsu and P. Valduriez, Principles of distributed database systems (2nd ed.).Upper Saddle River, NJ, USA: Prentice-Hall, Inc., second ed., 1999.

[46] A. P. Sheth, Changing Focus on Interoperability in Information Systems: from System,Syntax, Structure to Semantics, vol. Interoperating Geographic Information Systemsof Kluwer International Series in Engineering & Computer Science, ch. 2, pp. 5–29. Boston, USA: Kluwer Academic Publishers, February 1999. Goodchild M. F.,Egenhofer, M. J., Fegeas, R., Koffman, C. A. (eds.).

[47] J. Hammer and D. McLeod, “An approach to resolving semantic heterogeneity in afederation of autonomous, heterogeneous database systems,” Journal for Intelligentand Cooperative Information Systems, vol. 2, no. 1, pp. 51–83, 1993.

[48] V. Guevara-Masıs, O. Unal, E. C. Kaletas, H. Afsarmanesh, and L. O. Hertzberger,“Using ontologies for collaborative information management: Some challenges &ideas,” in Advances in Information Systems: Third International Conference, AD-VIS 2004 (T. Yakhno, ed.), vol. 3261 / 2004 of Computer Science, (Izmir, Turkey),p. 107, Springer-Verlag GmbH, 2004. ISSN: 0302-9743.

[49] H. Afsarmanesh and L. M. Camarinha-Matos, “Federated information management forcooperative virtual organizations,” in DEXA (A. Hameurlain and A. M. Tjoa, eds.),vol. 1308 of Lecture Notes in Computer Science, pp. 561–572, Springer, 1997.

[50] S. Busse, R.-D. Kutsche, and U. Leser, “Strategies for the conceptual design of feder-ated information systems,” in EFIS, pp. 23–32, 2000.

[51] H. Afsarmanesh, M. Wiegijk, L. O. Hertzberger, F. J. Negreiros-Gomes, A. Provedel,R. C. Martins, and E. Salles, “A federated cooperation architecture for expert systemsinvolved in layout optimization,” in Proceedings of IEEE/ECLA/IFIP InternationalConference on Architecture and Design Methods for Balanced Automation SystemsBASYS 95, (Vitoria, Brazil), pp. 287–300, 1995.

Bibliography 137

[52] H. Afsarmanesh, C. Garita, Y. Ugur, A. Frenkel, and L. O. Hertzberger, “Federatedinformation management requirements for virtual enterprises,” in Infrastructures forVirtual Enterprises - Networking Industrial Enterprises (L. M. Camarinha-Matos andH. Afsarmanesh, eds.), pp. 36–48, Kluwer Academic Publishers, 1999.

[53] H. Afsarmanesh, A. Benabdelkader, E. C. Kaletas, C. Garita, and L. O. Hertzberger,“Toward a multi-layer architecture for scientific virtual laboratories,” in HPCN Europe(M. Bubak, H. Afsarmanesh, R. Williams, and L. O. Hertzberger, eds.), vol. 1823 ofLecture Notes in Computer Science, pp. 163–176, Springer, 2000.

[54] D. Bell and J. Grimson, Distributed Database Systems. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1992.

[55] G. Wiederhold and M. R. Genesereth, “The conceptual basis for mediation services,”IEEE Expert: Intelligent Systems and Their Applications, vol. 12, no. 5, pp. 38–47,1997. ISSN: 0885-9000.

[56] D. Heimbigner and D. McLeod, “A federated architecture for information manage-ment,” ACM Transactions on Information Systems (TOIS), vol. 3, no. 3, pp. 253–278,1985.

[57] H. Afsarmanesh, F. Tuijnman, M. Wiedijk, and L. Hertzberger, “Distributed schemamanagement in a cooperation network of autonomous agents,” in Proceedings of the4th IEEE International Conference on Database and Expert Systems Applications -DEXA’93 (V. Marik, J. Lazansky, and R. Wagner, eds.), vol. 720 of Lecture Notes inComputer Science, (Prague, Czech Republic), pp. 565–576, Springer, 1993.

[58] C. Garita, H. Afsarmanesh, Y. Ugur, and L. Hertzberger, “Federated query processingfor distributed process coordination in virtual enterprises,” in Proceedings of the 4thIEEE/IFIP International Conference on Information Technology for Balance Automa-tion Systems in Production and Transportation (BASYS’2000), (Berlin, Germany),2000. Accepted.

[59] E.-P. Lim and J. Srivastava, “Query optimization and processing in federated databasesystems,” in CIKM ’93: Proceedings of the second international conference on Infor-mation and knowledge management, (New York, NY, USA), pp. 720–722, ACM Press,1993.

[60] V. Josifovski, P. Schwarz, L. Haas, and E. Lin, “Garlic: a new flavor of federatedquery processing for DB2,” in SIGMOD ’02: Proceedings of the 2002 ACM SIGMODinternational conference on Management of data, (New York, NY, USA), pp. 524–532,ACM Press, 2002.

[61] J. R. Chen, S. R. Wolfe, and S. D. Wragg, “A distributed multi-agent system forcollaborative information management and sharing,” in CIKM ’00: Proceedings of theninth international conference on Information and knowledge management, pp. 382–388, ACM Press, 2000.

[62] V. Guevara-Masıs, H. Afsarmanesh, and L. O. Hertzberger, “An agent-based federatedinformation system for telecare environments,” in Proceedings of the InternationalSpecial Topic Conference on Information Technology in Biomedicine (ITAB 2006),(Ioannina, Greece), IEEE Engineering in Medicine and Biology Society, 2006.

138 Bibliography

[63] J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques. San Mateo,CA, USA: Morgan Kaufmann Publishers, Inc., 1993.

[64] A. I. Wang, C. Liu, and R. Conradi, “A multi-agent architecture for cooperative soft-ware engineering,” in International Conference on Software Engineering and Knowl-edge Engineering (SEKE’99), (Kaiserslautern, Germany), pp. 1 – 22, 1999.

[65] S. Papastavrou, G. Samaras, and E. Pitoura, “Mobile agents for WWW distributeddatabase access,” in ICDE, pp. 228–237, 1999.

[66] R. Cattell, D. K. Barry, M. Berler, and e. al., The object data standard: ODMG 3.0.San Francisco, USA: Academic Press, 2000.

[67] M. Raubal, “Ontology and epistemology for agent-based wayfinding simulation,” In-ternational Journal of Geographical Information Science, vol. 15, no. 7, pp. 653–665,2001.

[68] T. R. Gruber, “A translation approach to portable ontologies,” Knowledge Acquisition,vol. 5(2), pp. 199–220, 1993. See also: Gruber, T.R.: A Translation Approach toPortable Ontology Specifications. Knowledge Systems Laboratory Technical ReportKSL 92-71, Computer Science Department, Stanford University. Stanford 1993 (revisedversion).

[69] S. Decker, S. Melnik, F. van Harmelen, D. Fensel, M. C. A. Klein, J. Broekstra,M. Erdmann, and I. Horrocks, “The semantic web: The roles of XML and RDF,”IEEE Internet Computing, vol. 4, no. 5, pp. 63–74, 2000.

[70] F. Tao, L. Chen, N. Shadbolt, G. Pound, and S. Cox, “Towards the Semantic Grid:Putting Knowledge to Work in Design Optimisation,” Journal of Universal ComputerScience, vol. 9, pp. 551–562, June 2003.

[71] M. N. Huhns and M. P. Singh, “Ontologies for agents,” IEEE Internet Computing,vol. 1, no. 6, pp. 81–83, 1997.

[72] P. Mika, V. Iosif, Y. Sure, and H. Akkermans, “Ontology-based content managementin a virtual organization,” in Handbook on Ontologies (S. Staab and R. Studer, eds.),International Handbooks on Information Systems, pp. 455–476, Springer, 2004.

[73] D. Pisanelli, ed., Ontologies in Medicine, vol. 102 of Studies In Health Technology andInformatics. Amsterdam, The Netherlands: IOS Press, May 2004.

[74] M. Becker, C. Heine, R. Herrler, and K. Krempels, “OntHoS - an Ontology for HospitalScenarios,” Tech. Rep. No. 300, Julius-Maximilians Universitat Wurzburg, Institut furInformatik, September 2002.

[75] M. Gruninger and J. Lee, “Ontology: applications and design,” Communications ofthe ACM, vol. 45, pp. 39–41, Feb. 2002.

[76] N. Guarino, “Formal ontology, conceptual analysis and knowledge representation,”International Journal of Human and Computer Studies, vol. 43(5/6), pp. 625–640,1995.

[77] IEEE, “The IEEE Standard Upper Ontology Working Group (P1600.1).” InternetReference, 2007. http://suo.ieee.org/.

Bibliography 139

[78] A. Gangemi, “Some design patterns for domain ontology building and analy-sis.” Presentation, Manchester, January 2007. Institute for Cognitive Science andTechnologies (ISTC-CNR), Trento-Roma, Italy, http://www.loa-cnr.it/Tutorials/OntologyDesignPatterns.zip.

[79] N. Guarino, “Ontology-driven conceptual modelling.” The 21st International Confer-ence on Conceptual Modeling - ER 2002, October 7 - 11 2002. Institute for CognitiveScience and Technologies (ISTC-CNR), Trento-Roma, Italy, http://www.loa-cnr.it/Tutorials/GuarinoERTutorialPart1.pdf.

[80] M. I. Bagues, J. Bermudez, A. Illarramendi, A. Tablado, and A. Goni, “Using ontolo-gies in the development of an innovating system for elderly people tele-assistance,”in On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE(R. Meersman, Z. Tari, and D. C. Schmidt, eds.), vol. 2888 of Lecture Notes in Com-puter Science, (Catania, Sicily, Italy), pp. 889 – 905, Springer-Verlag GmbH, 2003.

[81] N. Guarino, “Understanding, building, and using ontologies,” International Journal ofHuman and Computer Studies, vol. 46, pp. 293–310, 1997.

[82] Y. Sure, S. Staab, and R. Studer, “Methodology for development and employment ofontology based knowledge management applications,” SIGMOD Record, vol. 31, no. 4,pp. 18–23, 2002.

[83] V. Devedzic, “Understanding ontological engineering,” Commun. ACM, vol. 45, no. 4,pp. 136–144, 2002.

[84] R. Mizoguchi and M. Ikeda, “Towards ontology engineering,” Tech. Rep. AI-TR-96-1, Institute of Scientific and Industrial Research, Osaka University, Osaka University,Japan, 1996. See also R. Mizoguchi, Towards Ontology Engineering, J. Jpn. Soc. forArtificial intelligence, Vol. 13,No. 1, pp. 9-10, 1998.

[85] M. Uschold, M. King, S. Moralee, and Y. Zorgios, “The enterprise ontology,” Knowl.Eng. Rev., vol. 13, no. 1, pp. 31–89, 1998.

[86] S. Semy, K. Hetherington-Young, and S. Frey, “Ontology engineering: An applica-tion perspective,” in Wissensmanagement (K.-D. Althoff, A. Dengel, R. Bergmann,M. Nick, and T. Roth-Berghofer, eds.), pp. 499–504, DFKI, Kaiserslautern, 2005.

[87] G. W.E., H. Eriksson, R. Fergerson, G. H., T. S.W., and M. M., “Knowledge modellingat the millenium (the design and evolution of protege-2000),” in Proceedings of the12th workshop on knowledge acquisition, modeling and management (KAW’99), (Banff,Canada), October 16 - 21, 1999.

[88] C. W. Holsapple and K. D. Joshi, “A collaborative approach to ontology design,”Commun. ACM, vol. 45, no. 2, pp. 42–47, 2002.

[89] M. Denny, “Ontology building: A survey of editing tools.” Internet Reference,November 2002. http://www.xml.com/pub/a/2002/11/06/ontologies.html. See also:Denny, M.:Ontology Tools Survey, Revisited., http://www.xml.com/pub/a/2004/07/14/onto.html, July 2004.

140 Bibliography

[90] OntoWeb Consortium, “A survey on ontology tools,” Tech. Rep. Deliverable 1.3, On-toWeb Ontology-based information exchange for knowledge management and elec-tronic commerce. IST-2000-29243., 2002. http://www.aifb.uni-karlsruhe.de/WBS/

ysu/publications/OntoWeb_Del_1-3.pdf.

[91] Stanford University, “Ontolingua.” Software, 2007. http://www.ksl.stanford.edu/

software/ontolingua/.

[92] Stanford University, “Chimaera.” Software, 2007. http://www.ksl.stanford.edu/

software/ontolingua/.

[93] University of Manchester, “OilEd.” Software, 2007. http://oiled.man.ac.uk/.

[94] DAML Program, “DARPA Agent Markup Language - DAML.” Internet Reference,2007. http://www.daml.org/.

[95] Stanford Medical Informatics, “The protege project.” Internet Reference, 2007. http://protege.stanford.edu/.

[96] MINDSWAP Group, “SWOOP - a hypermedia-based featherweight OWL ontologyeditor.” Software, 2005. http://www.mindswap.org/2004/SWOOP/.

[97] W3C Consortium, “Web Ontology Language (OWL).” Internet Reference, 2004. http://www.w3.org/2004/OWL/.

[98] University of Amsterdam, “Triple20.” Software, 2007. http://www.swi-prolog.org/

packages/Triple20/.

[99] N. Noy and S. Tu, “Developing medical informatics ontologies using Protege.” InternetReference, 2007. http://protege.stanford.edu/amia2003/index.html.

[100] E. Rahm and P. A. Bernstein, “A survey of approaches to automatic schema matching,”VLDB Journal, vol. 10, no. 4, pp. 334–350, 2001.

[101] A. Maedche and S. Staab, “Measuring similarity between ontologies,” in EKAW’02: Proceedings of the 13th International Conference on Knowledge Engineering andKnowledge Management. Ontologies and the Semantic Web, (London, UK), pp. 251–263, Springer-Verlag, 2002.

[102] Princeton University, “WordNet: An electronic lexical database.” Internet Reference,2007. http://wordnet.princeton.edu/.

[103] S. A. Petersen and M. Divitini, “Using agents to support the selection of virtual enter-prise teams,” in AOIS@AAMAS (P. Giorgini, Y. Lesperance, G. Wagner, and E. S. K.Yu, eds.), vol. 59 of CEUR Workshop Proceedings, CEUR-WS.org, 2002.

[104] L. Stojanovic, A. Maedche, B. Motik, and N. Stojanovic, “User-driven ontologyevolution management,” in 13th European Conference on Knowledge Engineeringand Knowledge Management EKAW (A. Gomez-Perez and V. R. Benjamins, eds.),vol. 2473 of Lecture Notes in Computer Science, (Siguenza, Spain), pp. 285–300,Springer, 2002.

Bibliography 141

[105] L. Stojanovic and B. Motik, “Ontology evolution within ontology editors,” inOntoWeb-SIG3 Workshop at the 13th International Conference on Knowledge En-gineering and Knowledge Management EKAW 2002 (J. Angele and Y. Sure, eds.),(Siguenza, Spain), pp. 53–62, 2002.

[106] V. Guevara-Masıs, H. Afsarmanesh, and L. O. Hertzberger, “Ontology-based auto-matic data structure generation for collaborative networks,” in Virtual Enterprisesand Collaborative Networks, IFIP 18th World Computer Congress, TC5 / WG5.5 - 5thWorking Conference on Virtual Enterprises (L. M. Camarinha-Matos, ed.), (Toulouse,France), pp. 163–174, Kluwer, August 2004.

[107] C. J. Date and H. Darwen, Databases, Types and the Relational Model, 3/E. Addison-Wesley, 2006.

[108] S. W. Ambler, “Mapping objects to relational databases.” White paper, October 2000.

[109] M. Blaha, W. Premerlani, and H. Shen, “Converting OO models into RDBMS schema,”IEEE Softw., vol. 11, no. 3, pp. 28–39, 1994.

[110] W3C Consortium, “XML Schema.” Internet Reference, 2007. http://www.w3.org/

XML/Schema.

[111] J. O’Sullivan, D. Edmond, and A. T. Hofstede, “What’s in a service? towards accuratedescription of non-functional service properties,” Distributed and Parallel Databases,vol. 12, pp. 117–133, 2002. Kluwer Academic Publishers.

[112] J. Yang, W. V. d. Heuvel, and M. Papazoglou, “Service deployment for virtual enter-prises,” in Workshop on Information Technology for Virtual Enterprises, (Queensland,Australia), IEEE Computer Society, 2001.

[113] V. Guevara-Masıs, H. Afsarmanesh, and L. O. Hertzberger, “Service-oriented archi-tecture of TeleCARE,” in On the Move to Meaningful Internet Systems 2004: OTM2004 Workshops: OTM Confederated International Workshops and Posters, GADA,JTRES, MIOS, WORM, WOSE, PhDS, and INTEROP 2004 (R. Meersman, Z. Tari,and A. Corsaro, eds.), vol. 3292 of Lecture Notes in Computer Science, (Agia Napa,Cyprus), p. 14, Springer-Verlag Heidelberg, 2004.

[114] A. Tsalgatidou and T. Pilioura, “An overview of standards and related technologyin web services,” International Journal of Distributed and Parallel Databases, vol. 12,pp. 135–162, 2002.

[115] D. Kuebler and W. Eibach, “Metering and accounting for web services.” InternetReference, 2001. http://www-106.ibm.com/developerworks/library/ws-maws/.

[116] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke, “The physiology of the grid: Anopen grid services architecture for distributed systems integration,” 2002.

[117] UPnP Forum, “UPnP Device Architecture.” Internet Reference, 2000. http://www.

upnp.org/download/UPnPDA10_20000613.htm.

[118] UPnP Forum, “Universal Plug and Play (UPnP).” Internet Reference, 2007. http:

//www.upnp.org/.

142 Bibliography

[119] W3C Consortium, “Web Services Description Language (WSDL).” Internet Reference,2007. http://www.w3.org/TR/wsdl.

[120] Y. Shohoud, Real World XML Web Services: For VB and VB .NET Developers. Ad-dison Wesley Professional, 2003.

[121] Cape Clear Software, WSDL Editor User’s Guide. Cape Clear Software, 2003. http:

//www.capescience.com/downloads/wsdleditor/index.shtml.

[122] L. Camarinha-Matos and H. Afsarmanesh, “TeleCARE: Collaborative virtual elderlycare support communities,” The Journal on Information Technology in Healthcare,vol. 2, no. 2, pp. 73–86, 2004. Publisher: Health Technology Press.

[123] H. Afsarmanesh, V. Guevara-Masıs, and L. O. Hertzberger, “Federated managementof information for TeleCARE,” in Camarinha-Matos [144], pp. 49–62. In conjunctionwith ICEIS 2004.

[124] H. Afsarmanesh, V. Guevara-Masıs, and L. O. Hertzberger, “Management of federatedinformation in tele-assistance environments,” The Journal on Information Technologyin Healthcare, vol. 2, no. 2, pp. 87–108, 2004. Publisher: Health Technology Press.

[125] L. M. Camarinha-Matos, W. J. Vieira, and O. Castolo, “A mobile agents approachto virtual laboratories and remote supervision,” Journal of Intelligent and RoboticSystems, vol. 35, pp. 1–22, 2002.

[126] J. M. Aguilar, J. Cantos, G. Exposito, and P. Gomez, “The improvement of the qualityof life for elderly and relatives through two tele-assistance services: the TeleCARE ap-proach,” in 1st International Workshop on Tele-Care and Collaborative Virtual Com-munities in Elderly Care - (TELECARE 2004) (L. M. Camarinha-Matos, ed.), (Porto,Portugal), pp. 73–85, INSTICC PRESS, 2004.

[127] O. Castolo, F. Ferrada, and L. M. Camarinha-Matos, “TeleCARE time bank: A virtualcommunity supported by mobile agents,” in Camarinha-Matos [144], pp. 13–26. Inconjunction with ICEIS 2004.

[128] IBM Tokyo Research Laboratory, “Aglets workbench.” Internet Reference, 2007. http://www.trl.ibm.com/aglets/.

[129] Aglets.org, “Aglets.” Internet Reference, 2007. http://aglets.sourceforge.net/.

[130] FIPA, “Foundation for Intelligent Physical Agents,” January 2007. http://www.fipa.org/.

[131] L. M. Camarinha-Matos, O. Castolo, and J. Rosas, “A multi-agent based platformfor virtual communities in elderly care,” in 9th IEEE International Conference onEmerging Technologies and Factory Automation - ETFA-2003, (Lisbon, Portugal),2003.

[132] V. Varadharajan and D. Foster, “A security architecture for mobile agent based ap-plications,” World Wide Web, vol. 6, no. 1, pp. 93–122, 2003.

[133] S.-U. Guan, T. Wang, and S.-H. Ong, “Migration control for mobile agents based onpassport and visa,” Future Gener. Comput. Syst., vol. 19, no. 2, pp. 173–186, 2003.

Bibliography 143

[134] A. L. Murphy and G. P. Picco, “Reliable communication for highly mobile agents,”in First International Symposium on Agent Systems and Applications (ASA’99)/ThirdInternational Symposium on Mobile Agents (MA’99), (Palm Springs, CA, USA), 1999.

[135] FIPA, FIPA ACL Message Structure Specification. FIPA, 2001.

[136] N. F. Noy, M. Sintek, S. Decker, M. Crubezy, R. W. Fergerson, and M. A. Musen, “Cre-ating semantic web contents with protege-2000,” IEEE Intelligent Systems, no. 16(2),pp. 60–71, 2001. IEEE Educational Activities Department, Piscataway, NJ, USA.

[137] BinNet Corp., “Kernel Prolog.” Internet Reference, January 2007. http://www.

binnetcorp.com/OpenCode/kernelprolog.html.

[138] BinNet Corp., “Java INference Engine and Networked Interactor (JINNI).” InternetReference, January 2007. http://www.binnetcorp.com/Jinni/.

[139] SAP AG, “SAP DB.” Internet Reference, 2005. http://www.sapdb.org/.

[140] ExoLab Group, “Castor.” Internet Reference, 2007. http://www.castor.org/.

[141] J. M. Aguilar, J. Cantos, G. Exposito, and P. J. Gomez, “Tele-assistance services toimprove the quality of life for elderly patients and their relatives: The TeleCARE ap-proach,” The Journal on Information Technology in Healthcare, vol. 2, no. 2, pp. 109–117, 2004. Publisher: Health Technology Press.

[142] V. Guevara-Masıs, H. Yakali, A. Belloum, C. de Laat, and L. O. Hertzberger, “Im-proving automatic data structure generation for e-science applications,” in Proceedingsof the Second International Conference on Collaborative Computing: Networking, Ap-plications and Worksharing (CollaborateCom 2006), (Atlanta, USA), IEEE ComputerSociety, November 2006.

[143] MobiHealth Consortium, “Mobihealth.” Internet Reference, 2007. http://www.

mobihealth.org/.

[144] L. M. Camarinha-Matos, ed., Tele-Care and Collaborative Virtual Communities inElderly Care, Proceedings of the 1st International Workshop on Tele-Care and Collab-orative Virtual Communities in Elderly Care, TELECARE 2004, (Porto, Portugal),INSTICC Press, April 2004. In conjunction with ICEIS 2004.

Acknowledgements

This thesis grants me ‘Phinally Done’, however, it is not the result of only my work. Clearly,there were people who, with their help, support and friendship, made it also possible.

First of all, I would like to thank my promotor Pieter Adriaans and my co-promotorHamideh Afsarmanesh. On one hand, it was Pieter who guided me in the last part of myresearch, while giving me his support on my work. On the other hand, Hamideh’s efforts,supervision and feedback on the drafts of this dissertation certainly improved its quality. Ireally appreciate all their interest and confidence they have placed on my research.

Clearly, I want to express gratitude to the rest of my evaluation committee. I highlyappreciate their time, thoughts, and dedication on the promotion activities. Special thanksgo to Bob Hertzberger. After my Master’s, I looked for performing advanced research oninformation management. This became possible once Bob arranged my position at the UvA.

Furthermore, I am thankful to all the people involved in the TeleCARE project, specially,to Luis M. Camarinha-Matos. The ideas presented in this thesis were, in one way or another,influence by his work. Of course, I appreciate all the working and development time I sharedwith Ana Ines Oliveira, Filipa Ferrada, Octavio Gonzalez, Antonio del Cura, GuillermoExposito, Jose Marıa Aguilar and Javier Canto.

Many thanks should go to both paranymphs: Ronald de Wolf and Olman Castro. Ronaldhas been willing to assist and correct me where my skills in English, Dutch, French..., let’ssay, in languages let me down. I can correct him in Spanish, at least, for the moment! Iappreciate that Ronald was always been there, eager to exchange ideas, or to offer me afriendly hand. Olman, instead, provided me with humor and fun at distance. I did enjoy allthe time we spent in the past, but I am sure we will have more laughs in future.

From the UvA, I have to thank a lot more people. In the group, thanks to formermembers: Cesar Garita, who gave me wise guidance and support in the early part, AnneFrenkel, whose quality of spirit encourage me; Djamel Abtroun, for the headaches with thecode :); Ammar Benabdelkader, for teaching me how to get lost in town; and Ersin Kaletas,for his sense of comradely. Now, I wish luck to Simon Msanjila and Ekaterina Ermilova.Thanks to Ersin (again), I met the members of the Turkish gang, Basak Kaletas, HakanYakali, Ozgul Unal and Cagkan Erbas, who made my life more enjoyable at the coffee times.I am sorry for the lack of tildes in your names. ;-) I would also like to extend my gratitudeto Adam Belloum, who assisted me wisely in the latest stages of my research.

Furthermore, I thank the people from the administration area. In particular, AmandaCollins, Saskia Heijboer, Erik Hitipeuw, Frans Hondeman, Virginie Mes, Jacqueline van derVelde, Edwin van der Vlist, and more recently Alexis Salin, deserve much of my gratitude forall their patience, attention and assistance to my organization matters and requests. I amalso specially grateful to Jacqueline for her friendship during this time. By the way, whichmovie are we seeing this weekend?

Thanks also to other colleagues Frans Verster, Aristeides Diplaros, and Nikos Massiosfor all the after-hours. I appreciate also Silvia Olabarriaga and Ruud Veldhuis for theircaipirinhas on new year’s eve. I thank the members of the CSP Lab and SNE group for theirspirit of comradely and fellowship, including my officemates: Adianto Wibisono, Dmitry

146 Acknowledgements

Vasunin, Vladimir Korkhov, Zhiming Zhao; and others in the building: Evghenii Gaburov,Frank Terpstra, Mark Thompson, Piter de Boer, Simon Polstra, Thomas Bernard, and YvesFomekong. Thanks for your company and I think we will be meeting sometime in future.

In addition to the people from the UvA, I extend my appreciation to those who mademy stay in The Netherlands more gratifying and interesting. I want to thank first SonjaFaberesk for literally offering me a place in her home. I appreciate all my time in her housebut also her comments and advice, which made me stronger like the king of Tonga.

Much of my appreciation also goes to the family Bakker-Torrentes in Friesland. Together,Jan and Leticia, deserve my recognition for their kindness, understanding, and enthusiasm.I would like to thank Aant de Jong and Lilian Bakker for their friendship and hospitality,but also because my electrical knowledge has improved a lot since I met them. The gratitudeextends to Baudina Bakker, who offered me joy and drinks in “La Tica.” That also countsfor Eelko Bakker, Mainor Bakker, Fressy Bakker, Douwe de Jong, and cheerful KlariskaLeegstra. Noflike krystdagen en seine yn it nije jier!

When not working, I spent some time wandering, biking around the city, watching films,or finding interesting cafes. It is wonderful to have buddies who are willing to join you in thoseendeavors. As such, I thank Silke Heumann, for all those shared dinners at home; CornelieRenckens, for being there when I needed her the most; Tarlach McGonagle, for his singularpoint of view and stories along the canals; Alex Ter Beek, for cheering me up with his forwardattitude; Jurjen Meeuwissen, for organizing my time on Tuesdays; Demetrio Munoz, for histrue Latin spirit for going out to dance salsa; this last word reminded me of Jose Melendez,who I appreciate for all the nightlife together; Zaire Gonzalez, for keeping the costarricanhospitality in Utrecht alive; Eefje Stam, for all her stories, chats, and party time; MaryPtacin, for being a wonderful guest who can take care of herself in the neighborhood; Roosvan Grieken, for providing me with some side inspiration; Julie Visser, for her positivism andour discussions about daily life; Jan Westering and Jonne Janssen, for the talks and drinksat ’t Sluisje; Monica Saez, for her fellowship and bringing me to the indoor football; SaraMunoz and Marco Calvo, for the lovely time eating “chifrijo” in Delf; Marcela Chavarria, forproviding me a huge shelter in Maastricht; and Marieke Wilkins, for becoming my travelingpartner and friend. Thank you all for making my life a bit easier (or harder!).

Many more should be thanked for their moral support or for creating a friendly environ-ment. Unfortunately, I can only name a few, for instance, Maaike Timmers, Bregje Prent,Lieke Wiggers, Sanne van der Kooij, who I met through Roos and Julie; Ronnie Quintero,Andrea Meneses, Nader Mirzadeh, Pieter de Han, Spyros Tsekouras, Yanina Sanchez, EijiShinkai, Juliana Potulic, Lara Mazurski, and more recently Marlijn Lelieveld.

Sporting also contributed to this thesis. The football on Tuesdays always cheered up mymood so I thank everyone there but, in particular, Alessia Amore, Fabrizio Ribaudo, FrancoDoro, Janelle Brown, Mauro de Pra, and Vladica Bocokic. I also like to thank “the drinkingclub with a running problem”, the Amsterdam Hash House Harriers, including the hardcoresingers Postman Prat, Missing Link, Paparassi, Five Pack, and Excremental Earnings. Thistime, the punishment is on-on me!

From Costa Rica, I appreciate the people who gave me advice and support when makingthe decision to come to The Netherlands. I appreciate the words, from Marta Alencar andGabriela Marin, which inspired me to make the decision. Ricardo Madrigal is, however, themain person who deserves extra credit. He is always concern with more important mattersrather than work, amusement or trivialities. His counseling always helped me to focus myideas. I thank also Sergio Calderon, Angie Sanchez, Cristian Rodrıguez, and “los Barboza”(Roberto, Melissa and Yorly) for bringing some costarrican joy to Amsterdam. My gratituderegards also to Mabel Rojas for her comprehension, patience and love; it is unfortunate thatmaking our own choices does not always go along with whom we associate with.

At last, but not least, I thank enormously my family. My parent’s support and confidencegave me the strength to finish this dissertation. While my sister, Renata, and my brother,Luiser, always provided me with the motivation to keep going on. Thank you!

If I am forgetting someone here, please excuse my lack of focus at this point! :-)

Samenvatting

Informatie Management voor Virtuele Telecaring Organisaties∗

Een raamwerk voor telecare (zorg op afstand) voor ouderen bestaat uit een aantal instellin-gen, zoals zorgcentra, woonruimte voor ouderen, instellingen voor gezondheidszorg, voorsociale zekerheid, enz. Het behelst de samenwerking tussen vele menselijke actoren, zoalssociaal werkers, professionals uit de zorg, de ouderen zelf, en de mensen in hun omgeving.Wanneer het ondersteund wordt door computer netwerken en andere adequate middelen,kan samenwerking tussen de instellingen evolueren tot een Virtuele Organisatie (VO), en desamenwerking tussen de actoren kan evolueren tot een Virtuele Gemeenschap (VG).

Hoewel het gebruik van geavanceerde technologieen ter ondersteuning van telecare nietnieuw is, en een aantal initiatieven al in ontwikkeling is, behandelen deze meestal alleenspecifieke gebieden, en worden deze onafhankelijk van elkaar uitgevoerd. Wat nu nodig is, iseen generieke, flexibele infrastructuur via welke nieuwe technologieen aan elkaar gekoppeldkunnen worden op een gecoordineerde manier.

Dit proefschrift behandelt het ontwerp van een informatie management systeem ter on-dersteuning van de basis infrastructuur van een VO voor telecare voor ouderen. De be-langrijkste doelen van dit proefschrift zijn: de analyse, ontwerp en ontwikkeling van eenagent-gebaseerd gefedereerd informatie management systeem and gerelateerde generieke enherbruikbare oplossingen die nodig zijn voor de basis infrastructuur van VO’s en VG’s, terondersteuning van de benodigde uitwisseling van de informatie die gegenereerd of behandeldwordt door de verschillende bronnen. Meer specifiek willen we ondersteuning bieden voortelecare diensten en gerelateerde applicaties voor ouderen.

Het ontwerp en de implementatie van het systeem dat in dit proefschrift gepresenteerdwordt, past geavanceerde opkomende methodes, technologieen en paradigma’s toe, metname (i) gefedereerde database mechanismes ter ondersteuning van beveiligde informatie-zichtbaarheid niveau’s, het delen van informatie uit verschillende bronnen, en gefedereerdeverwerking van queries; (ii) multi-agent systemen, met zowel statische als mobiele agents;(iii) semantische conceptualiseringen, gebaseerd op een ontologie die ook gebruikt wordt alsde basis voor het automatisch genereren van database schema’s en andere data structuren;en (iv) service-georienteerde architectuur die flexibele en modulaire ontwikkeling toestaat.

De resultaten van dit proefschrift zijn empirisch gevalideerd door de implementatie van decomponenten in de context van het 5FP-IST TeleCARE project, met gebruik van scenario’suit het bedrijfsleven voor telecare toepassingen. Het resultaat van dit werk draagt bij aande volgende generatie van gebruiksvriendelijke, betrouwbare, kosten-effectieve, en onderlingsamenwerkende diensten voor de groeiende populatie van ouderen.

∗Vertaling door Ronald de Wolf

Information Management for Telecaring Virtual Organizations › ws › files › 4377862 ›...

Documents

Transcript of Information Management for Telecaring Virtual Organizations › ws › files › 4377862 ›...