6 ... The endless cycle of idea and action, Endless invention, endless experiment, Brings knowledge of motion, but not of stillness; Knowledge of speech, but not of silence; Knowledge of words, and ignorance of the Word. All our knowledge brings us nearer to our ignorance, All our ignorance brings us nearer to death, But nearness to death no nearer to GOD. Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? T.S. Eliot, The Rock

7 Abstract Mobile network technologies are representative of a paradigm shift from classical desktop applications to highly-distributed nomadic systems. Mobile technologies make it possible to deliver information anywhere at anytime, and provide nomadic users with up-to-date information ready for decisionmaking processes. Nevertheless, the management of structured information (i.e. knowledge) for delivery to mobile users poses several challenges. Besides the limited computational capabilities of mobile devices, mobile systems face specific problems that cannot be solved by traditional knowledge management methodologies and tools, and thus require creative new solutions. Knowledge Mobilization is an innovative approach that integrates contributions from several areas such as Knowledge Engineering, Distributed Artificial Intelligence, Soft Computing, and the Semantic Web, to develop effective knowledge-intensive mobile applications. In this doctoral thesis we explore possible computational solutions for problems of knowledge distribution and information overload in Knowledge Mobilization systems. More precisely, we describe a new architecture for Knowledge Mobilization systems (based on the multi-agent paradigm) and an innovative context-aware knowledge representation model (which relies on Description Logics ontologies). Both elements provide support for effectively delivering knowledge obtained from large, heterogeneous information sources to nomadic users. The architecture and knowledge representation model were used to design and implement a Knowledge Mobilization system in the domain of Healthcare. The system creates and distributes to nomadic doctors summaries of the clinical histoiii

26 List of Figures 2.1 Knowledge Mobilization related research areas Components of a mobile Knowledge-Based Systems Society Diagram of the KMob architecture Society Diagram of the agent roles Protocol Sequence Diagram of the roles Consumer and Provider Schema of a CDS ontology CDS Tab plug-in in Protégé IDE Structure of the database of the Hospital Clínico San Cecilio Schema of the IASO context, domain, and significance ontologies Architecture of the IASO system Implementation of the IASO prototype Input form of the IASO prototype Output form of the IASO prototype B.1 Semantic Web layers B.2 Web Services protocols xxii

27 List of Tables 3.1 AML primitives Complexity of reasoning with TBoxes in basic DLs A.1 Syntax and semantics of concepts and roles in ALC A.2 Constructors for some extensions of ALC A.3 Axioms for some extensions of ALC A.4 Complexity of reasoning different DLs w.r.t. general TBoxes A.5 Syntax and semantics of concepts and roles in f ALC B.1 OWL class descriptions and axioms B.2 OWL property axioms xxiii

28 CHAPTER 1 Introduction 1.1 Antecedents Knowledge Engineering is the subarea of Artificial Intelligence that studies how to represent both the concrete and abstract aspects of an application domain in a model that can be used by an automatic procedure to solve a complex problem. Knowledge Engineering is based on classical fields such as Ontology, which studies how the entities of a domain are classified, and Logic, which studies formal languages and inference rules for representation models [238]. The formal models studied by Knowledge Engineering are the core support of Intelligent Systems. An agent that handles more knowledge is more intelligent, and consequently, able to better resolve problems. A Knowledge Based System (KBS) is a software system that manages and applies represented knowledge to solve complex decision problems [89]. KBSs provide support for decision-making processes, and supply the right person with the right information at the right time [151]. Although this definition is still valid, current KBSs face new challenges. Nowadays, it is assumed that the right person may be located just about 24

29 1.1. Antecedents 25 anywhere, and that the right time is any moment at all. In the most extreme case, this means that KBSs must provide support for mobility. This signifies that they must be remotely accessible by means of a mobile device and a wireless communication network. Likewise, thanks to the Internet, users are now able to access to large quantities of useful information that was previously unavailable. Hence, the right information is obtained by integrating data retrieved from several sources, which may be large and distributed, as well as having different formats and semantics. Modern KBSs are expected to provide nomadic with support through the use of mobile technologies and the incorporation of all available information sources. This allows the implementation of new functionalities, but also poses significant challenges to developers. Most of these difficulties stem from the computational limitations of mobile devices, e.g. reduced screen size, unreliability and limited bandwidth of mobile communication networks, battery duration, and the heterogeneity of development platforms and devices. Some of these difficulties can be solved by improving mobile technology. For instance, recent mobile networks guarantee Mb/s transfer speeds. Nevertheless, other problems are intrinsic to mobile KBSs, and though they may gradually lessen as technology evolves, they still require computational solutions. Knowledge must be retrieved from large, distributed and heterogeneous information sources, and must be delivered to the mobile devices of decision makers. Mobile systems must be context-aware. That means that they must adapt their behavior to the user s environment, and must avoid information overload (i.e. overwhelming users with more data than they can digest). This requires representation models and software architectures that can extract, represent, integrate, and present this knowledge properly. One of the focuses of Distributed Artificial Intelligence has always been the development of intelligent distributed systems. Distributed Artificial Intelligence proposes computational paradigms and technologies for the design and implementation of distributed KBSs. For instance, the multi-agent paradigm, or more recently, Web-based technologies, have defined organi-

30 1.1. Antecedents 26 zational patterns, communication protocols, and technologies to implement these systems. Furthermore, Distributed Artificial Intelligence has incorporated contributions from Mobile Computing (and vice versa), thus giving rise to Ambient Intelligence. New knowledge representation and acquisition models are necessary to integrate distributed, heterogeneous information sources since more traditional techniques have shown themselves to be incapable of accomplishing this task. In this sense, one of the goals of Knowledge Engineering is to create knowledge models and methods that support the integration of information. For this reason, ontologies (a knowledge representation formalism that promotes the integration and re-use of previous knowledge) have become increasingly popular in recent years. As often stated, the most complete (as well as heterogeneous) information source is the Web. Therefore, Web resources must be incorporated into KBSs. The Semantic Web is a recent initiative that aims at automatically searching, retrieving, and integrating Web information by endowing Web contents with semantics. The Semantic Web uses premises from Knowledge Engineering, since document metadata is represented by means of formal ontologies. Despite such contributions, mobility and information integration problems in KBSs have not as yet been satisfactorily resolved. At the present time, mobile communication technologies are in a state of constant evolution. Although this is an exciting and dynamic situation, it also means that it is extremely difficult to establish a lasting implementation framework. The design of a knowledge-intensive mobile application is currently more of an art than a science, since well-established software engineering methodologies for desktop systems are not directly applicable to mobile ones. What is urgently needed are new software design guidelines such as architectural patterns. Regarding knowledge models, there are very few formalisms that solve knowledge delivery requirements in intelligent mobile systems. Ontologies are a promising approach, and Semantic Web proposals can be used to handle representation issues. However, this is a new research field that

31 1.2. Objectives 27 needs to be further developed. Knowledge Mobilization is a proposal that combines some of the approaches mentioned above (Distributed Artificial Intelligence, Ontologies, Semantic Web) with Soft Computing contributions (mainly Fuzzy Logic) in order to offer integral solutions for the difficulties that arise in mobile KBSs. Knowledge Mobilization provides a common framework, both from a conceptual as well as a practical perspective, for the development of mobile intelligent systems. This research is on Knowledge Mobilization, and also pertains to Knowledge Engineering and Distributed Artificial Intelligence. With a view to dealing with the problems inherent in Knowledge Mobilization (limitations of mobile devices, integration of heterogeneous sources, context-awareness, information overload, etc.), we studied the architectures and models required to manage and distribute the knowledge obtained from large, heterogeneous information sources to nomadic users. The remainder of this thesis gives a detailed description of our research and the results obtained. We discuss the rationale underlying our proposals, as well as their advantages over previous work. 1.2 Objectives The general objective of this research work was to find computational solutions for the problems of knowledge distribution and information overload in Knowledge Mobilization systems. More precisely, we focus on the study and creation of software architectures and formal representation models capable of overcoming these difficulties. Such architectures and models must be able to support the effective delivery of the knowledge obtained from large and heterogeneous information sources to nomadic users. Accordingly, the objectives of the thesis are the following:

32 1.2. Objectives To review and analyze the state of the art in Knowledge Mobilization and related research areas. a) To examine the problems inherent in Knowledge Mobilization and related research areas; b) To analyze the benefits provided by Knowledge Mobilization systems in different application domains; c) To review relevant contributions from areas such as Mobile Computing, Distributed Artificial Intelligence, Ubiquitous Computing, the Semantic Web, and Soft Computing. 2. To propose an abstract architecture to support the design of Knowledge Mobilization systems. a) To provide an overview of the structure of a general Knowledge Mobilization system; b) To facilitate the development process of Knowledge Mobilization Systems by providing the developer with a global and customizable schema that can be specialized to meet the requirements of each concrete application; c) To discover which technologies are most suitable for the implementation of a Knowledge Mobilization system in each specific scenario, and how they should be integrated to achieve optimal results. 3. To create a context-aware knowledge representation model for Knowledge Mobilization. 4. To develop a proof-of-concept Knowledge Mobilization system that demonstrates the validity of our research.

33 1.3. Methodology Methodology Constructivism is a methodology that solves problems by creating models, methods, diagrams, plans, organizations, etc. [135]. It is mostly used in Design Sciences. Design Sciences are applied sciences that have both a descriptive component (i.e. they can describe reality) and a prospective component (i.e. they can change reality) [188]. For example, if target B must be achieved and the current situation is A, Design Sciences study which artifact X needs to be designed and built in order to evolve from A to B. In the same regard, [125] explains the differences between constructive, nomothetic, and idiographic methods. The objective of constructive methods is the creation of new artifacts, in contrast to idiographic and nomothetic methods, which study real phenomena, and social relations and behaviors, respectively. Information Systems (and by extension, Knowledge-Based Systems) are Design Sciences [126, 169]. Therefore, research in Information Systems consists of creating meta-artifacts that are useful for the development of concrete artifacts [127]: languages, models, methods, frameworks, software packages, environments, etc. This aspect is highlighted in [114], which distinguishes between routine design and research. Research must inevitably try to solve new problems ( wicked problems ) and/or apply innovative procedures, whereas routine design uses well-established practices and techniques to solve known problems. This author describes seven features that are present in most Design Science research work, namely, artifact design, relevance of the problem, evaluation of the design, contributions of the research, rigor of the research, design as a search process, and communication of the results. In [193], an schema to achieve rigor in the research process is proposed. This procedure consists of the following steps: (i) elaboration of a conceptual framework; (ii) description of the architecture of the system; (iii) analysis and design of the system; (iv) implementation of a prototype; (v) observation and evaluation of the solution. This approach is known as Development as a Research Method because it reproduces the steps of a development process.

34 1.3. Methodology 30 Information Systems is a Design Science, but it is also a Behavioral Science since it studies the behavior and utility of existing systems [114]. Generally speaking, because of its multidisciplinary nature, Information Systems research also presupposes studying the state of the art in related fields. Our research follows the principles of constructive methodology. We targeted a general problem, in this case, Knowledge Mobilization, and we created meta-artifacts, namely, an architecture and representation model capable of facilitating the development of Knowledge Mobilization systems. The validity of the meta-artifacts was shown by implementing a software prototype that provides a solution for a specific Knowledge Mobilization problem (Nomadic Healthcare). We also provided other supporting tools, such as the API and the visual tool to manage and create ontologies within the framework of our knowledge representation model. The structure of our research study follows the iterative process proposed in [193]. First, we describe the conceptual framework of Knowledge Mobilization, i.e. the nature of Knowledge Mobilization and the properties of Knowledge Mobilization systems. Then, we present a general architecture of Knowledge Mobilization systems. The architecture is described in terms of a semi-formal language, which facilitates its interpretation and reutilization by different developers. Additionally, we created a second meta-artifact, namely, a model to represent knowledge in Knowledge Mobilization systems. Interestingly enough, reasoning with this model proved to be complete. This was possible since it is expressed in a formal language. The design of the resulting software prototype is based on the architecture, and relies on the knowledge model. This prototype satisfactorily solves a crucial Knowledge Mobilization problem. Consequently, it validates both the architecture and the model created, and shows that the results obtained in this research can be extended to other application domains.

35 1.4. Thesis structure Thesis structure Throughout the description of our research, we clearly distinguish between original contributions, i.e. new proposals formulated in this thesis, and the contributions of others in related disciplines. Chapters 2 to 5 present the original contributions of this thesis, namely, a review of Knowledge Mobilization, an abstract architecture for Knowledge Mobilization Systems, a context-aware knowledge representation model, and the implementation of a Knowledge Mobilization application. Appendices A and B presents an overview, respectively, of related topics such as knowledge representation with Description Logics ontologies and the Semantic Web. Chapter 2 offers a panorama of Knowledge Mobilization and the problems that it targets. We give a pragmatic definition of Knowledge Mobilization and study the features that Knowledge Mobilization systems should offer. In order to illustrate the benefits of Knowledge Mobilization, we provide three examples of Knowledge Mobilization use cases. Additionally, we review other research areas and related contributions that offer integral solutions for intelligent mobile systems development. Chapter 3 presents our proposal for a new architecture for Knowledge Mobilization systems. The chapter studies how the entities participating in Knowledge Mobilization systems should be organized in order to achieve the effective delivery of knowledge retrieved from large information sources. Accordingly, we introduce an abstract architecture for Knowledge Mobilization systems, consisting of entities, dependencies, and communication schemas between distributed components. This architecture is general and can be adapted to different application domains. It is expressed in the semi-formal language AML, a language for the specification of agent-based systems. Moreover, in this chapter we recommend various technologies that can be applied to implement different adaptations of this architecture. Chapter 4 describes our proposal of a context-aware knowledge representation model for Knowledge Mobilization. This model is a design pattern

36 1.4. Thesis structure 32 for the creation of OWL significance ontologies, i.e. ontologies that specify which information from the domain ought to be considered in each use scenario. The model solves the problem of information overload by creating a knowledge base that explicitly connects context descriptions with the domain expressions significant in each context. The formal description of the pattern is presented in this chapter as well as a reasoning algorithm to infer relevant knowledge. We demonstrate that the reasoning algorithm is complete, and we also study other features of the model (complexity, modularity, etc.). Furthermore, in order to facilitate the creation and use of significance-aware ontologies, a visual tool and a Java API were implemented. In the last part of this chapter, we describe an extension of the design pattern, which contemplates the creation of fuzzy significance ontologies. Fuzzy significance ontologies improve the crisp approach by allowing the representation of imprecise contexts and domains, and the quantification of the importance of relevance relations. Chapter 5 presents the design and implementation of IASO, a Knowledge Mobilization system that solves the Nomadic Healthcare use case studied in Chapter 2. Thus, IASO provides mobile doctors with summaries of clinical histories, whose contents depend on the situation of the patient who is being attended. The design of IASO is based on the architecture described in Chapter 3, whereas the knowledge base that supports the system was created with the design pattern explained in Chapter 4. IASO shows that the results of our research led to the development of a successful Knowledge Mobilization system. The last chapter summarizes the new proposals presented and highlights their contributions to Knowledge Mobilization. We analyze the results of this work in accordance with the objectives established in this introductory chapter. Finally, the thesis concludes with plans for future research work.

37 CHAPTER 2 Knowledge Mobilization In this chapter, Knowledge Mobilization is defined in detail on the basis of earlier contributions in the literature. This chapter also provides a pragmatic description of the problems faced by Knowledge Mobilization as well as the characteristic features of Knowledge Mobilization systems. Given the close relation between Knowledge Mobilization and other areas of Information Systems and Artificial Intelligence, relevant technologies, methodologies and paradigms that are used to support Knowledge Mobilization are overviewed. Finally, some integral approaches to the development of Intelligent Mobile and Ubiquitous Knowledge-Based Systems are studied. 2.1 Definition Knowledge Mobilization (KMob 1 ) comprises all the efforts aimed to take advantage of the features provided by new mobile networks and devices in order to improve Knowledge Management (KM) procedures. KMob research faces certain problems which tend to arise when classical Knowledge-Based 1 From this point on we will note Knowledge Mobilization as KMob, in contrast with Knowledge Management, which is usually shortened as KM. This abbreviation if firstly proposed in this work. 33

38 2.1. Definition 34 Systems (KBSs) are applied in current organizations, and proposes mobile technologies to overcome them. As a result, KMob is closely related to other topics such as Knowledge Engineering, Artificial Intelligence and Mobile Computing. This notion of KMob appeared for the first time in [138]. In this work, Keen and Mackintosh present KMob as one of the three dimensions of modern companies (besides logistics and customer relationship) which can be improved by using mobile technologies. The mobilization of knowledge consists of making knowledge available for real-time use in a form which is adapted to the context of use and to the needs and cognitive profile of the user. In other words, KMob should furnish managers with suitable knowledge in order to support them in decision-making processes, wherever they are located. Accordingly, KMob would provide the means to accomplish requirements of current organizations resulting from information immediacy and user mobility needs. The authors make the following distinction between: (i) conveniences, namely, new features which are truly useful for the companies; (ii) freedoms, or new services which change the structure of everyday life. In this sense, KMob is regarded as being a paradigm shift from traditional supply-center KM conveniences to KMob demand-driven freedoms. By providing (better) support to (better) KM practices and systems, KMob would help to diminish KM failure, which is a frequent issue caused by both people (employees do not share or update knowledge) and software (systems do not represent or distribute knowledge accurately). Carlsson follows this approach and stresses that KMob systems must be intended to identify, delimit, and provide solutions to fulfill current KBS requirements [61]. The author defines four main tasks to be solved by KMob: creation of knowledge, activation of latent knowledge, retrieval of hidden knowledge, and delivery of knowledge. Paraphrasing F. Braudel 2, this will 2 Fernand Braudel is one of the most important historians in 20th century. He is the author of Civilization and Capitalism: 15th-18th Century, a broad study of the economy in the pre-industrial era which analyzes the impact of economic events on everyday social behavior.

39 2.1. Definition 35 result in mobile value services and applications that will expand the limits of the possible in the structures of everyday life. Recalling the definition of KBS in the introductory chapter to provide the right information to the right people in the right time, in such a way that it is useful in the decision-making process [151], it should be noted that KMob shares with traditional KBSs time, place, and person requirements. The main contribution of KMob is that it is particularly concerned about the complex environments where decisions are made in current organizations, and proposes mobile technologies as a valuable tool to cope with them. Besides, as mentioned, real time, context, and a priori information are important to discriminate which information is significant to the user. In addition, Carlsson points out a plethora of theories and technologies, most of them from Intelligent Systems and Soft Computing areas, which could be used to carry out each one of these KMob tasks: Semantic Web, Ontologies and Fuzzy Logic for building knowledge; Multicriteria Optimization, Evolutionary Computing and Simulation for activating latent knowledge; Data and Text Mining and Text Summarization for finding hidden knowledge; and Multi-Agent Systems for effective delivery of knowledge to ubiquitous users. Our approximation is based on the proposal by Carlsson, concentrating on further studies on the computational difficulties that the implementation of KMob poses. From a pragmatic point of view, we believe that KMob addresses the challenge of building Knowledge Mobilization Systems, which are: Ubiquitous. KMob systems offer services that can be accessed from anywhere, at anytime, and using any device, particularly mobile ones, which have limited computing capabilities. Proactive. KMob systems are expected to discover what information is needed by the users and to act consequently.

40 2.1. Definition 36 Declarative. KMob systems transform users questions, which may be expressed in natural language, to queries that the resolving subsystem can understand. Context-aware. KMob systems take into account information about users context and incorporate it to the decision process. Context knowledge may be used to adapt system behavior automatically depending on the current scenario and the ongoing activity. Integrative. Several and heterogeneous information sources, technologies and devices are meant to participate in KMob systems. Concise. KMob systems must summarize gathered data and tailor it to user needs and device capabilities. Finally, since KMob systems are intended to be a key tool to manage knowledge inside organizations, they must comply with common requirements of corporative software, such as reliability, extensibility, security, easy maintenance, etc. We must point out that though these three definitions state KMob applications as targeted to assist expert decision, its contributions are suitable to be extended to less specialized areas. KMob also provides a proper support for developing services which offer advices or suggestions to mobile users facing non-critical tasks. For instance, let us imagine a shopping guide software which schedules in the customer s mobile phone a shopping spree to the local boutiques according to his location and preferences. Accuracy of results is (probably) not as vital as it would be in a corporate KBS, but needs of interoperation, integration of information sources, summarization of results, or use of context data may be even harder to resolve.

41 2.2. KMob and Ubiquitous Computing KMob and Ubiquitous Computing KMob is inevitably related to Ubiquitous Computing (UC) and, to some extent, KMob can be regarded as a particular paradigm in this area. UC, often named alternatively Pervasive Computing (PC), was introduced in 1991 by Weiser, who envisioned a world where a multitude of computational objects (software and hardware: sensors, actuators, communication networks, portable devices, etc.), which are part of the ambience, communicate and interact with each other in order to carry out different jobs to help humans in daily activities [258]. Nowadays, UC systems obtain data from remote tiny sensors, transmit information using wireless communications, retrieve information from the Web, use Internet protocols, etc., aimed at automating tasks in different everyday life situations. UC is regarded as the result of the evolution of Distributed Computing [226]. From early personal networks to current high-scale massive internets, problems have arisen (e.g. reliability, interoperability, or security) and solutions have been developed (e.g. routing algorithms, standard protocols, or encryption techniques) with a view to making remote communication a freedom, using the terminology of Keen and Mackintosh. A major step in this progress was the advent of mobile systems, which allowed voice and data networks to be accessed from anywhere at anytime. Mobile Computing poses new challenges to Distributed Computing, both hardware and software, while it also offers new opportunities: ubiquitous access to data, wireless communication, use of portable devices, etc. Relying on Distributed and Mobile Computing, several UC subareas and related topics have been developed, each with its own particular focus. For instance, Smart Rooms [204], a combination of Domotics and Image Recognition to support an inhabitant s activities with computational facilities, are defined similarly to UC. Computationally-enhanced environments are also studied in Ambient Intelligence, which claims that Artificial Intelligence techniques are the key to building effective pervasive applications [214]. UC overlaps considerably with Embedded Computing [260]. Embedded devices

42 2.3. Use cases 38 are simple specific-purpose controllers, which are encapsulated inside the larger machinery that they manage. When devices are expected to be carried by the users, ideally indistinguishable from their clothes, systems are usually included in Wearable Computing [220]. KMob, in turn, can be regarded as the UC subarea interested in delivering refined information (i.e., knowledge) to specialized nomadic users. It shares with the aforementioned ones several issues to be resolved, e.g. mobile networking, information delivery to nomadic users, integration of devices, context-awareness, adaptive behavior, transparency, and scalability. Artificial Intelligence theories and techniques are expected to play a key role, a principle which is shared with Ambient Intelligence. On the other hand, KMob has specific challenges that require particular solutions, namely, knowledge acquisition, representation, and presentation. KMob involves providing users with more elaborated information than general pervasive applications, which usually manage lower-level data collected from environmental sensors. As a result, an expressive formalism must be used. In addition, since devices with limited computational capabilities are used, representation formalisms must generate tractable knowledge bases. Likewise, person to machine interaction is more frequent in KMob, since more critical decisions must be made based on the available information. Thus, interfacing with the user is a priority. 2.3 Use cases In this section, we present three scenarios that exemplify the kinds of applications that can best take advantage of KMob proposals. We follow the schema of the W3C Semantic Web Activity 3, which describes use cases for Semantic Web technologies. In this context, a use case is an example of a prototype system which, event though it is not currently being used by an organization, demonstrates the benefits of applying Semantic Web tools. In this section, our use cases show the possibilities of KMob technologies. The 3

43 2.3. Use cases 39 first is the Nomadic Healthcare use case, which is exemplified in Chapter 4, and implemented in the application described in Chapter 5. Nomadic Healthcare use case The problem. Dr. Greg is a physician who needs to consult the clinical data of a patient in order to prescribe the best treatment. If the healthcare service occurs inside the hospital, Dr. Greg will be allowed to access the Hospital Information System (HIS) and to retrieve all of the patient s Electronic Health Records (EHRs). Since he has enough time and knowledge, he will be able to rule out all the useless pieces of information and will only obtain those that he is interested in. In the event that Dr. Greg is in an emergency-assistance ambulance unit, and he is caring for a patient injured in a car accident, it will be helpful to be able to access some data about the patient s clinical history. For instance, data concerning the patient s adverse drug events (ADEs) may have been recorded. Nevertheless it is improbable that the doctor will be able to access HIS data from outside the hospital (much less by using a portable device such as that available in emergency healthcare units). Even if it were possible, the doctor would not have enough time to review all the stored electronic records. The solution. In such a situation, a brief report including those pieces of the patient s clinical data which ought to be considered would be very valuable. The clinical procedure to be carried out would determine which data should be part of this summary. For example, if the patient is unconscious and has a hemorrhagic laceration, information regarding whether he has an allergy to procaine (an anesthetic drug which reduces bleeding but is also often badly metabolized and triggers allergic reactions) should be taken into account, among other things. Thus, some kind of rule asserting that data about previous anesthetic drug reactions ought to be considered when the patient has a penetrating wound should be created in the knowledge base of the system. Following recommendations for clinical and ADE guidelines,

44 2.3. Use cases 40 other similar rules can be included in the knowledge base in order to support the creation of context-dependant EHR summaries. Assigning a priority to these links among patient states and registers of the HIS would also be desirable. For example, allergic reactions to anesthetic drugs are more important than blood-borne diseases and should be presented firstly to the doctor since avoiding an anaphylactic shock is a major priority, and medical protocols prevent the doctor from being in contact with patient s blood. Ranking the relevance relations would allow system responses to be sorted by precedence and a threshold to be fixed to filter information. Benefits of using KMob contributions. This example present various of the characteristic features of KMob systems (as they have been defined in this chapter). For instance, the system must be context-aware, i.e. it needs to detect which is the situation of the patient and behave accordingly. Likewise, the eventual Nomadic Healthcare system must be concise, since doctors are provided with summaries only including significant information about the patient. Necessarily, the system will integrate different technologies (mobile platforms, communication protocols, etc.) and information sources (the HIS, the vocabulary to describe patient situations, etc.). All these tasks can be faced by applying KMob technologies and tools. Portable Tourism Guide The problem. Travelling to a strange city is often an unnerving experience, whether the trip is for business or pleasure. If the traveller wants to know how to get from the airport to his hotel, he has to check the timetables and prices of the airport buses, trains and taxis, calculate the estimated time and cost of the trip, and decide which means of transportation is best for him. A similar situation occurs when the traveler decides to go sightseeing and visit one of the tourist spots in the city. He must retrieve information from different providers, and then make his choice accordingly. Moreover, the traveler may be interested in checking out the opinions

45 2.3. Use cases 41 of other people who have visited the city. Webs offering reviews of movies, restaurants, cinemas, hotels, companies, etc. have proliferated over the past years. Providing the user with this information in addition to the official data is very advantageous, especially if he is visiting a city that he is unfamiliar with. None of these tasks is easily carried out by a mobile device operating with current technologies. All this information is probably available on the Web and can be accessed, but it is difficult to integrate the different information sources. Furthermore, it does not make sense to present a huge volume of data to the user because he will not have the energy or the time to read pages and pages of results on his mobile device. The solution. A possible solution to this problem is the publication of all the data in a format that can be automatically processed. This enables a software agent to collect and integrate information, which is subsequently delivered to users in a proper format. The information received is then filtered according to the user profile, which includes previous actions, preferences, location, etc. It would be also interesting to implement the means to automatically update this profile. For example, if the user changes location, the profile should be changed without the user having to explicitly specify his new geographic position. Moreover, the profile could be learnt as the user utilizes the system. For instance, if the user frequently consults sports results, the profile should be adapted so that it takes this preference into account. Currently, there are various research initiatives aimed at describing published information with well-defined metadata. Actually, this is the objective of the Semantic Web, which can be applied to building advanced mobile systems. In our example, the information pertaining to public transportation, places, and users reviews should be published in the RDF language so that an automatic agent can automatically extract, integrate and consult the semantically-enriched data. Additionally, the user profile should be expressed in a logic-based language such as OWL. Thus, user preferences and available information could be matched, and only relevant information retrieved.

46 2.3. Use cases 42 Benefits of using KMob contributions. The Semantic Web, which is one of enabling technologies of KMob, offers a framework for the formal description of information published in the Web. Resources with a well-defined meaning can be better located, integrated, and delivered. Soft Computing and Machine Learning techniques can be applied to adapt the behavior of applications without user intervention. KMob, as an integral approach, establishes how these technologies can be combined to develop an effective mobile application. Ubiquitous Security Guard The problem. Security in large installations is controlled by teams of guards that patrol the surveillance area. Guards can either be walking the beat or watching the cameras installed in the secured area. The guards can communicate by using radio transmitters. Usually, when a security alarm is triggered, guards follow a predefined protocol for each possible risk situation. Mobile technology allow security systems to be improved by implementing software that provides guards with data, which may include any kind of multimedia content, independently of the location of the user. Moreover, mobile communications and devices can be used to better coordinate the response against a security alarm. Another benefit of mobile technologies is that they can be combined with intelligent procedures in such a way that the signals captured by ubiquitous devices (sensors, cameras, or other devices carried by the guards) can be interpreted, and a suitable plan can be automatically scheduled in real time. Such an Ubiquitous Security Guard application must integrate different communication technologies, but even more important, it must rely on a sound knowledge model to detect security threats and generate reaction plans, as well as a suitable mechanism to coordinate the distributed components of the system. These components are both computational (sensors, cameras, etc.) and human (guards).

47 2.4. Methods, technologies and tools 43 The solution. The software entities participating in the Ubiquitous Security Guard application must have a high degree of autonomy. At the same time, they must cooperate and coordinate their actions in order to react to and effectively deal with security threats. The design of such system can be based on the multi-agent paradigm, which establishes a framework for the design and implementation of distributed intelligent systems. Additionally, the knowledge of the system can be represented if the form of ontologies. Maps of the secured area can be tagged with semantic metadata, which allow agents to precisely state the location of an object or an event. Likewise, ontologies that describe possible risk situations could be created. These knowledge models would be used by the reasoning procedures to deduce the protocol to be activated in a given situation, and to create a plan to deal with the incident. Benefits of using KMob contributions. KMob proposes multi-agent systems to achieve effective intercommunication and interoperation between entities in a distributed system. In the same regard, ontologies are applied in KMob as a suitable formalism to create a language, understandable by a wide range of different agents. Moreover, KMob provides a framework that decouples the design and the implementation of an intelligent mobile system. Thus, the structure and behavior of the entities of the system can be abstractly described as participants of a KMob application, and then implemented using a suitable technology. 2.4 Methods, technologies and tools In the previous section we have described three use cases that illustrate some of the benefits which KMob afford to nomadic knowledge workers. Now we shall point out some recent technologies which are crucial to the development of KMob systems. As is well known, there are currently development platforms that allow ad hoc mobile solutions for concrete applications to be implemented, covering:

48 2.4. Methods, technologies and tools 44 (i) software running on mobile devices (e.g. J2ME,.NET Compact Framework, Symbian OS programming toolkits); (ii) server logic (J2EE,.NET); (iii) communications (WAP, HTTP, SOAP/Web Services, etc). These technologies are the framework supporting development of mobile services. Building a KMob application from scratch with these technologies can be rewarding, but also frustrating and (even more important) costly, especially when maintenance is required or when there are new demands to fulfill. Participation of new devices, update of technologies, change of user roles, or need of incorporating new interaction patterns pose a great challenge to people in charge of the system because some parts of the system (if not all of it) will have to be redesigned and redeveloped from the basis. Therefore we consider that a unified, extensible, and adaptable computational architecture for KMob applications must be defined. This architecture must identify the components of a KMob system, the relations between them, and the actions they can perform. Such an architecture would allow KMob systems to be described in terms of abstract modules and operations. This avoids the specification of the low-level aspects of mobilization, both hardware (which devices will be used) and software (which technologies will be applied to implement the system). The architecture will be conveniently implemented using different technologies depending on the system size, purpose and restrictions. Our proposal of an architecture and an associated supporting framework is extensively discussed in Chapter 3. The following sections review some of the existing methods, technologies and tools in different areas which KMob applications will rely on. Figure 2.1 shows our vision of KMob and related topics. It depicts the research areas and technologies that we consider to be appropriate to make data develop into knowledge ready for mobilization in different application domains. Interestingly enough, we propose relying on Intelligent Systems (IS) solutions to meet the challenges of KMob challenges, in line with Carlsson s (as well as other UC researchers [253, 257]) view. We focus on three main (non-disjoint) contributions of IS: Knowledge Representation (see Appendix A), Intelligent agents, and Soft Computing. Besides IS, other tech-

49 2.4. Methods, technologies and tools 45 nologies can be used: mobile devices and networks, database and data warehouse systems, middlewares, etc. In this figure, four main layers are distinguished: data, information, knowledge and applications. This organization reflects a distinction usually stated in Information Systems theory which mirrors the process of rough data becoming useful knowledge [1]: data are syntactic patterns with no associated meaning, which are used in the initial step of a decision-making process; information is the result of interpreting data and providing it with meaning; knowledge is learned information which is conducive to inferring new knowledge to be used in decision-making. In the case of the doctor in the emergency ambulance service consulting the HIS (Section 2.3), the patients EHRs can be considered data, since they have little meaning; EHRs merely store figures, strings and perhaps images with the values of different healthcare parameters. If semantics are added to these parameters, they can be considered information; an ontology can be used to state that blood pressure is a clinical sign, or that anemia is a blood disorder. This ontology can be further enriched to have relate profiles, diseases and EHRs; it thus becomes knowledge useful for decision-making. For example, the ontology can tell us that anemia occurs when the hemoglobin level is below 13.0 g/dl, and that it is commonplace to have anemia after radio and chemotherapy treatments have been carried out. Next we discuss relevant research related to topics mentioned in Figure 2.1.

51 2.4. Methods, technologies and tools 47 Data Wireless broadband communication technologies and portable computational devices have emerged to become the enabling technology of new mobile services, such as those provided by KMob. On the one hand, third-generation cell technologies (3G) are being currently deployed in the market, still dominated by GSM (2G), and new services, such as videoconference or MBMS (Multimedia Broadcast Multicast Services), are now being offered thanks to higher transfer speeds (up to 2Mbits/s versus 144Kbits/s) and more reliable connections. Regardless of these advantages, dissemination of 3G technologies has not been as fast and rewarding as expected. However new extensions to them are being introduced, namely, the 3.5G and 4G. Poole provides a comprehensive introduction to cellular communications, describing issues, solutions, and standards in [207]. Wireless network technologies are seen to complement or to build on current third-generation mobile technologies. In recent years, Bluetooth (for short-range ad hoc connections, i.e. WPANs) and Wi-Fi (for local IP-based networks, i.e. WLANs) have become the means to communicate small and mid-sized systems [153]. In fact, voice-over-ip (VoIP) services, which allow voice communications to be performed throughout IP networks, are regarded as a considerable threat to carrier operators, since they eliminate subscribers dependence on cell infrastructure (at least within the last mile of the loop). Possibilities will be extended with the advent of WiMax, a successor of Wi- Fi which promises wider covertures and higher transfer speeds (up to 70 Mbits/s and 110 km, in the best of cases and not simultaneously). Both cell and WLAN/WPAN technologies will be fully interoperable in the near future (Mobile IP and IPv6 share this aim). The result will be that all significant data communication will work on IP protocols, which is usually known as an all-ip development. On the other hand, as a result of technology convergence mainly handheld devices (PDAs), cell phones, and laptop computers, mobile devices

52 2.4. Methods, technologies and tools 48 have evolved from simple voice-transmission terminals to smart computation gadgets equipped with 3G, Wi-Fi, GPS, video recorder, etc. which are able to fulfill complex tasks, such as browsing the Internet, ing, running business software, etc. This trend will predictably continue in the near future [194], in consonance with the impressive penetration rates of these technologies. As a matter of fact, consultant firm Strategy Analytics estimates in its report for the last three months of 2007 that 332 million cellphones were shipped worldwide [174], an increment of 13% year-over-year, with strong demand in emerging markets like Africa, India and China, whereas Informa Telecoms & Media forecasts that 121 million converged devices will be sold by 2012 [128]. Software programmers can make the most of mobile technologies by using development platforms and APIs adapted to the flavor of the target device operating system. Currently, there are two main branches of mobile devices, differentiated by the operating system used: Symbian-based (mostly owned by Nokia, and the most widespread) and Windows Mobile-based (developed by Microsoft, and included since 2006 in Palm Treo Series). Each has its own programming platforms. An alternative is to use J2ME (Java2 Mobile Edition), which can be run on different OS. J2ME defines a set of profiles and configurations to adapt software to device capabilities, as well as additional pluggable interfaces for new specifications (JSRs). Other minority development frameworks worth mentioning are those intended for Linux-based mobile devices: Maemo, for Nokia N770 and above; Android SDK, for Google s Android OS (not included in any device to this date); or Qtopia, provided by Trolltech (recently bought by Nokia) and used in some Motorola and Panasonic cell phones. It is also possible to develop software for (more) closed platforms like iphone OS (non-web applications are officially supported only since February 2008) and RIM Blackberry (which provides a Java Development Kit). Finally, web development is an alternative to ensure portability: mobile phones can access the Web and invoke applications running on remote servers using HTTP. These applications can be enriched with recent web programming technologies such as AJAX or Flash,

53 2.4. Methods, technologies and tools 49 which can be interpreted by most of current mobile browsers. Recently, platforms which split the execution of web applications between the client and the server have been proposed, namely, the Rich Internet Applications (RIAs) (e.g. Microsoft Silverlight and Adobe AIR). Additional sensor systems may be involved in KMob applications. In this sense, there are two that have become increasingly popular in the last decade: GPS (Global Positioning System) and RFID (RadioFrecuency IDentification). GPS technology allows users to calculate the absolute position on Earth (latitude, longitude) of a GPS receiver by the interpolation of the signals transmitted from four (or more) satellites. RFID, in turn, is based on remote read and writing of tags storing identification data, a simple mechanism which may be used to track tagged objects during their lifetime. These can be used beside other environmental sensor in context-aware systems, i.e. systems that acquire, deliver, and process environment data in order to apply it to subsequently customize system behavior to the users ambience. In order to deal with this wide range of technologies and facilitate mobile application development, middlewares have been developed. In general, middlewares are programs which enable interoperation between application and system software. In our case, a KMob middleware is a set of (software) high-level primitives which cope with low-level aspects of mobilization (software and hardware) and embodies a reference framework for developers, whose objective is to hide device and communication details as much as possible, especially from users. There are middleware platforms at different abstraction levels, ranging from standards aimed at interconnecting distributed components of a system (syntactic interoperability) to complex software able to automatically locate, invoke and coordinate system nodes (semantic interoperability). Some of the more interesting technologies currently used are: (i) RPC protocols, for remote procedure calling over TCP/IP; (ii) CORBA and its sucessor ICE, two specifications for remote procedure calling in object-oriented architectures; (iii) Jini, a Java technology for federated systems; (iv) SOAP, which together with WSDL and UDDI is the standard to implement Web Services, allowing

54 2.4. Methods, technologies and tools 50 remote procedures to be requested through elaborated HTTP calls; (v) REST paradigm, which promotes the access to remote resources using ad hoc simple XML and HTTP messages. More abstract middlewares usually rely on these technologies, and these are described in Section 2.5. Mobile Web is a related initiative: since it strives to make possible surfing the whole web using mobile devices, it is also suitable to allow interchange of information (via Web protocols) and the remote running of applications (via Web Services) in mobile systems without having to be concerned about all the details of the underlying technologies. Information Since applications (and, consequently, supporting middlewares) are expected to manage different and heterogeneous data sources, different data models must be used to endorse semantics to data. Among others, the information layer ought to consider multimedia (images, sounds, video streams), context data and user profiles, apart from general domain information. Therefore, formal theories to represent sparse and heterogeneous information are required in KMob. This has been a long-established issue in Knowledge Engineering that nowadays is being tackled by using ontologies. Ontologies are a knowledge representation formalism which offer interesting features such as the standardization, sharing and reutilization of knowledge [64]. They are thus suitable for representing knowledge in KMob applications. Appendix A includes a detailed study of ontologies and the ontology language OWL. The role of context knowledge in intelligent mobile systems is worth mentioning, since it may be used to automatically customize responses according to user circumstances and preferences [158], leading to the UC aspiration of a semi-invisible computer [258]. Summarization, as a form of personalization, is an especially desirable feature in KMob applications, where presentation of large volumes of data on mobile devices is critical and may result in information overload.

55 2.4. Methods, technologies and tools 51 Accordingly, knowledge models can be roughly classified as applicationspecific or context-related, depending on the role that they play in a KMob application. The application-specific knowledge base contains expert information about the specific problem to be dealt with by KMob systems, whereas context knowledge is used to specify under which conditions subsets of the latter ought to be considered. Chapter 4 describes how context and specificdomain knowledge can be represented by using ontologies, and proposes a design pattern to create and reason with context-aware ontologies. By information integration and retrieval, we mean that information could be automatically integrated and conveniently stored in a data warehouse to perform further knowledge discovery processes. Information may be tagged with terms of an ontology, which is known as ontological annotation, or alternatively, it may be used to build a new ontology, which is known as ontology learning. Both processes can be performed automatically with proper machine learning techniques (maybe based on Soft Computing and Fuzzy Logic). It should be highlighted that the representation primitives of ontologies are crisp, that is, they are logic-based constructors which evaluate either to true or false. For instance, regarding concept inclusion the basic inference procedure in DLs, it can only be stated that a concept is or is not subsumed by another one. This can be a serious shortcoming when imprecise information must be represented in a knowledge base, something far from unusual in several domains. For that reason, extending ontologies (and consequently ontology languages) to handle imprecise and vague knowledge in KMob applications is a very promising research line. Fuzzy ontologies are an extension of classical ontologies that allow such knowledge to be represented [225]. Fuzzy extensions of DL also support enhanced information retrieval processes, for instance (partial) matching of user preferences against service capabilities or result rating based on different criterions. Such tasks would be difficult to implement using a crisp representation formalism. In this work (see Chapter 4), we propose a fuzzy extension to rank significance relations

56 2.4. Methods, technologies and tools 52 in context-aware ontologies. This approach is based on previous studies on reducing reasoning within Fuzzy DLs to reasoning within Crisp DLs in order to make possible the use of currently available inference engines [39, 41] (see Appendix A. Knowledge Built upon the information management layer, IS technologies dig into information stores to extract valuable knowledge from less elaborated data. Furthermore, intelligent appliances can be used to deliver useful knowledge to ubiquitous users, providing them wherever they are with information generated at any point of the system using any device to make effective KMob. Agents are one of the abstractions that have been most frequently used to describe and implement proactive intercommunication among modules in intelligent distributed systems. The Multi-Agent Systems (MAS) paradigm proposes a scenario where independent, goal-directed, and environment-aware units (the agents) become coordinated (by collaborating or competing) to accomplish complex tasks [259]. Adaptive learning may be applied to dynamically adjust agent behavior. In KMob, agents collect and distribute information across the distributed modules of the system. Some advantages of MAS are a solid conceptual grounding (they can be depicted using welldefined abstract entities and operations), encapsulation of their components (which hides agent policies and promotes scalability), communication facilities (high-level protocols are used), and parallel execution (resulting in better performance and robustness) [244]. From a practical perspective, the MAS paradigm eases system development as standards and frameworks to build them have been proposed. For instance, FIPA describes an extensive standard ranging from system architecture (FIPA Abstract Architecture) to agent communication (ACL, Agent Communication Language) [208]. Related approaches are KQML (Knowledge Query Manipulation Language) [93], a communication language, and MASIF [179], a collection of standards for agent interoperability. There are

57 2.4. Methods, technologies and tools 53 also development platforms which implements these standard, e.g. JADE [23] (FIPA-compliant), JatLITE [129] (KQML- and FIPA-compliant) or Grasshopper [19] (MASIF- and FIPA-compliant). Extreme decoupling of processing modules is driving MAS towards peer-to-peer systems (P2P), i.e. highly distributed systems where central coordinators are reduced to the minimum. Our vision of a KMob middleware is not very far away from these MAS platforms, although it should be located on a high abstraction level. In our opinion, developers should concentrate on knowledge management rather than on data communication details. Nevertheless, these platforms can provide a sound framework from which richer tools can be built, above all if we bear in mind that MAS research has faced mobility problems in preceding years. In the literature, MAS mobility has usually referred to the capacity of running agents to be transferred from one computer to other [68, 6], but the explosion of mobile computing has led to an increased focus on agents executing on mobile devices. As a result, some platforms as JADE-LEAP allow the deployment of agent software in J2ME-enabled mobile phones [25]. MAS are strongly related to Service Oriented Architectures (SOAs). SOAs, implemented with Web Services [75], have been used respectively as an alternative or a complement to other paradigms like MAS, and to other transport protocols like CORBA/ICE or RPC. Recently, the OSGi platform has been presented as a complement or a replacement for Web Services. OSGi is a Java-based framework which provides support to create communicative services that can be executed in different computational environments, including mobile devices [5]. However, understanding between pure agents platforms and services (whatever they are implemented) must be explicitly achieved, since different communication technologies are used. Ontologies, employed as intermediate terminologies, are expected to play a key role in solving this issue [112]. The Semantic Web is proposed, in addition to MAS, as the key technology for knowledge building in KMob. The Semantic Web (SW) is defined as an extension of the current web where resources are described using logic-based languages in order to allow automatic processing [27]. The aim of SW is

58 2.4. Methods, technologies and tools 54 to overcome certain drawbacks of the current Web by providing mechanisms for the automation of document processing and the simplification of effective information recovery processes. Relying on metadata annotating resources, software agents are expected to search, locate, discover, or link documents better than today s lexical-search engines. Accordingly, SW researchers are very interested in formalisms for creating metadata to be associated to Web resources. Hence, ontologies play a fundamental role, since they are the main representation formalism in the core of the layered architecture of the SW. The SW has contributed to Knowledge Engineering with languages (such as the standard Ontology Web Language OWL [176]); methodologies (for instance, METHONTOLOGY [71]); tools (parsers, editors, reasoners, APIs) [76]; or domain-specific large-scale ontologies (e.g. UMLS ontology [45]) (see Appendix A). These make up a suitable framework for building not only SW applications, but distributed KBS of any kind. Semantic Web Activity 4 within the World Wide Consortium (W3C) congregates several groups that are making a great effort to develop standards for the SW. Fully-fledged semantic web pages are still far away from being common in the world outside research labs, but some of their contributions are valuable and stable enough to be incorporated in KMob systems. For our purpose, resources in KMob systems can be given semantics by using ontologies, and can be managed with Semantic Web technologies. A survey of work which shares this objective is presented in Ranganathan et al. [217]. This also presents some challenges which can be addressed using SW technologies, like the automatic coordination of actors in mobile interaction. Masuoka et al. tackle this problem, and suggests attaching descriptions to services in order to discover, communicate, and integrate customers and providers in pervasive environments [173]. More recently, Lassila also has underlined this difficulty, and has proposed the use of OWL ontologies to represent policies (roughly, contexts) and Semantic Web Services (an in-progress specification from the W3C) to achieve serendipitous device coalitions [157] (Semantic 4

59 2.4. Methods, technologies and tools 55 Web Services are studied in [43]). Examples of implementations that use Semantic Web technologies and agents to ensure interoperability in contextaware pervasive environments are given in Chen, Finin, and Joshi [66], who define an ontology (SOUPA, Standard Ontology for Ubiquitous and Pervasive Applications) for representing agent BDIs (beliefs, desires and intentions), user profiles, time, etc. and Soldatos et al. [236], who create a semantic directory of entities. Applications Applications are implemented on top of the enabling technologies of KMob, and will be supported by a KMob framework. As far as possible, these applications must keep the user unaware of the underlying complexity. Intuitive and user-friendly interfaces must be provided (the more adapted to user context, the better). There are various methodologies for improving multimodal/mobile user interface design [164], and more are expected to be investigated [187], given the fact that new input and output procedures (e.g. auditory, tactile, or motion-based) are being offered by mobile devices. Thus, best practices and proper techniques should be considered in order to make the use of KMob systems easier and to reduce the number of interaction problems and the length of the learning period. Usability methodologies allow the evaluation of user experiences, and anticipate the conditions of the interaction in future scenarios. Regarding application domains, as presented in Section 2.3, health care applications are one of the most interesting domains where KMob can be applied since both the technical challenges and the social implications are relevant. KMob can be applied to decentralized and personalized health services, care of the disabled, hazardous drug control, food traceability, logistics, etc. Chapter 5 presents a system that provides nomadic physicians with summaries of a patient s previous diseases that directly affect diagnosis. It also provides advice regarding further clinical tests to be carried out.

60 2.5. Related work Related work In the previous section we discussed various contributions pertaining to different areas of Information Technology that will participate in KMob applications, remarking some useful references about each subject. In this section we describe integral approaches to the problem of knowledge management and delivery in mobile systems, that is, we review architectures, frameworks, platforms, APIs, etc. that are intended to support ubiquitous intelligent systems by integrating some of the aforementioned technologies. These range from pure UC applications to others closer to our vision of KMob, according to the differences remarked in Section 2.2. Most works in the literature on pervasive systems tackle the problem of representing context information, which is one of the main objectives of UC and KMob. A fundamental contribution in that area is the Context Toolkit [80], a framework for rapid prototyping of context-aware applications. Apart from the framework (both conceptual and practical), a general definition of context and categories of context are examined in that paper. Tradeoffs of this approach are examined by Hong and Landay [115], who propose a higher-level infrastructure is suggested. Similar ideas are explained in [111], which gives a description of a hardware implementation of a context-aware system for smart rooms based on CORBA communication. Several projects tackling the problem of contextawareness in smart rooms were unveiled in the early 2000s: Interactive Workspaces (at Stanford University) [132, 206], EasyLiving (Microsoft) [55], Aura (Carnegie Mellon) [98], Cooltown (HP) [145], BlueSpace (IBM) [156], and Oxygen (MIT) [78] are some examples. All these seminal works concentrate essentially on providing software platforms and on developing physical implementations of enhanced environments where a considerable amount of different and heterogeneous devices must be coordinated. In addition, Yau et al. propose RCMS (Reconfigurable Context-Sensitive Middleware) [261], a middleware which provides development and runtime support for applications that require context-awareness and spontaneous ad hoc communica-

61 2.5. Related work 57 tion. As mentioned in Section 2.4, ontologies are being intensively used for specific-domain and context knowledge representation. They can be encoded in OWL or in other languages. Gaia, a middleware for mobile applications promoting the use of ontologies in the description of context predicates, is presented in [216]. In this platform, components are modeled as agents; the are communicated with CORBA; and their context is represented with DAML+OIL (a predecessor of OWL). Gaia has been extended to incorporate fuzzy, probabilistic and Bayesian formalisms to process uncertain facts about general context data [215]. In the same way, the Context Mediated Framework defines a platform based on a fuzzy model to pre-process inputs from crisp environmental sensors [149, 168]. These works are more oriented to classical UC than KMob. In spite of the fact that they provide rich mechanisms to represent context knowledge (mostly acquired from sensors), domain information is not expected to be as complex as in knowledge-intensive KMob applications. Gu, Pung, and Zhang follow a similar approach to Gaia in SOCAM (Service- Oriented Context-Aware Middleware), although they use OWL and consider that a SOA is more suitable to communicate modules in that kind of systems [106]. Other works which use SOAs are [163], [212] and [144]. The first defines a middleware for Ambient Intelligence implemented with Web Services called WSAMI; the second establishes a similar architecture relying on MAS paradigm and OSGi; and the third proposes another middleware for UC applications based on SOA and Web Services with OWL ontologies being the means to manage context knowledge. In contrast to these contributions, the OWL Services Framework (OWL-SF) proposes a REST architecture and a supporting framework based on OWL for context representation and reasoning, and OMG Super Distributed Objects for sensor management, which provide support for UC intelligent applications [182]. CoBrA (Context Broker Architecture) is another infrastructure which also represents context using a RDF/OWL ontology [67], based on SOUPA [66]. A more specific proposal using ontologies is described in [154], where a rec-

62 2.5. Related work 58 ommender system for mobile users is developed on a multi-agent platform. Some of these platforms (Context Toolkit, Context Mediated Framework, Co- BrA, and SOCAM) are reviewed in [233], where the STU21 framework, a proposal by the authors, is also described. It is interesting to mention the work in [7], which presents a fuzzy methodology to measure partial equivalences between situations (expressed using OWL ontologies) and to determine suitable action rules to be fired in pervasive applications. Regarding multi-agent platforms, we have cited JADE (Java Agent DEvelopment), a framework for implementing FIPA-compliant multi-agent systems based on a peer to peer communication architecture [23]. JADE platform was adapted to mobile devices with the LEAP (Light Extensible Agent Platform) extension [25]. JADE/LEAP provides a functional but overly general infrastructure for working with high-level semantics and context information. Thus, it is not generally used directly when implementing such distributed KBSs. Instead, new middlewares have been built over JADE/LEAP primitives. For example, that is the underlying technology of the approaches by Khedr and Karmouch [139] and Soldatos et al. [235]. The first proposes an infrastructure for developing context-aware applications (ACAI, Agent-based Context Aware Infrastructure) based on OWL ontologies for representing context and agents (implemented in JADE) for coordination and communication within the system. The second also defines a new middleware for pervasive and context-aware which relies on JADE, but concentrates more on system implementation and evaluation rather than establishing a model of the infrastructure. Nevertheless, a formal description of these authors middleware has been recently sketched in the CHIL Reference Model Architecture for Multi-modal Perceptual Systems [251]. Agents are also used to communicate components in the ECORA (Extensible Context Oriented Reasoning Architecture) framework [198], which uses the ELVIN4 framework instead of JADE. This work claims to resolve issues resulting from the use of logic and sensor-based formalisms in context representation by providing the so called Context Spaces model, based on state-space models. Addition-

63 2.6. Towards Knowledge Mobilization 59 ally, this approach includes ad hoc mechanisms to facilitate reasoning with uncertain contexts. The rise of both SW and MAS technologies has favored the appearance on the horizon of recent infrastructures built from a combination of them, which is very close to our view of KMob. For instance, the proposal by Lassila and Khushraj, which will be implemented in the SwapMe (Semantic Web Application Platform for the Mobile Ecosystem) project at Nokia Research and MIT, also aims to combine the best elements from a wide range of different fields (MAS, SW, mobile computing, etc.) to implement effective smart mobile systems [9, 158]. Also interesting is that fact that CoBrA, though more oriented to Ambient Intelligence, heavily relies on MAS and SW as well as underlying data communication technologies [67]. Finally, we should like to mention the PLIMM (Product Line enabled Intelligent Mobile Middleware) middleware [263], which uses ontologies to represent knowledge in the system and, more specifically, context. This middleware deploys BDI (belief, desire, intention) agents able to reason with OWL on a supporting platform, which can either be a SOA (compliant to OSGi standard [5]) or Jadex [205]. 2.6 Towards Knowledge Mobilization The numerous approaches to the development of intelligent mobile systems seem to indicate that the implementation of a KMob system is not an easy task, and can be carried out from many different perspectives. Various new and often immature technologies need to be integrated in order to achieve communication between mobile entities. Nevertheless, this is not the greatest problem that developers have to face. As explained in Chapter 1, successful KMob systems require new methodologies, architectures and knowledge models. The research work reviewed in the previous section is largely aimed at satisfying these requirements, either partially or completely. Although these contributions are valuable, most of them are excessively focused on

64 2.6. Towards Knowledge Mobilization 60 the integration of technologies. Instead of coming to grips with the most crucial problem of a knowledge-intensive system, which is the representation of knowledge, this work limits itself to establishing communication, between mobile peers, and has nothing to say about achieving understanding. Such work targets less specialized applications that do not require elaborated knowledge to be managed. For this reason, our research makes a detailed study of the problems that arise when refined knowledge, retrieved from large and heterogeneous information sources, has to be provided to decision-makers. Obviously, we take into account related research, but at the same time explore new ways to offer support for Kmob systems that must deal with complex problems. Thus, we propose a software architecture and a context-dependent knowledge representation model that solve information distribution and overload problems in KMob systems. The representation formalism is explained in Chapter 4, whereas the software architecture is described in the next section.

65 CHAPTER 3 An Architecture for Knowledge Mobilization This chapter presents a proposal for a new abstract architecture for KMob systems. The chapter begins by exploring the rationale behind this proposal and the features that a KMob architecture should have. It then goes on to provide an introduction to software agent-based architectures. The main content of the chapter is the description of our architecture, which uses the semi-formal language AML. Since the architecture can be implemented by using different technologies, we also offer a description of alternative development frameworks. 3.1 Rationale In the previous chapter, we presented various frameworks, standards, specifications, etc. for building KMob systems. These technologies were classified in terms of three abstraction levels, namely, data, information, and knowledge, according to the degree of refinement of the managed values (Figure 2.1). The implementation of a KMob system might be started from scratch, and rely on (a selection of) these tools. Although such a straightforward 61

66 3.1. Rationale 62 approach to the problem could be time-saving in the short term, it would probably turn out to be expensive in the long run. The reason for this is that software maintenance, support, and extension costs often soar if the system is very complex, and if incompatible, immature, or undocumented technologies are used. Since this is a likely scenario in KMob, it is crucial to rigorously follow the recommendations of Software Engineering. The software life cycle 1 selected should pay special attention to the design stage, when the developers identify the global structure of the future system. The schema describing the system organization is called its architecture, and its design is one important factor that affects the success of the system. In this chapter, we propose a general architecture for KMob systems that can be adapted to different application domains. This reference architecture semi-formally defines a set of abstractions that are the building blocks of a KMob system. These abstractions are not very specific, and must be adapted to particular applications. Therefore, this proposal may be regarded as more of a meta-architecture, i.e., a description of the possible architectures, rather than an architecture, as the term is commonly used. Lower-level solutions regarding system implementation (programming languages and APIs, communication protocols, etc.) are not dealt with in the architecture, and the specific details must be decided by the designer. The utility of such an architecture is inversely proportional to the experience of the system designer. Since KMob is a new perspective on corporate systems, this issue is especially relevant. Actually, mobile systems development as a whole poses several challenges to IT professionals, mainly due to the fact that long-established software engineering methodologies for desktop applications are no longer valid [224]. Therefore, a design artifact for mobile systems like this one is a very valuable contribution to the field, since 1 The software development cycle consists of a sequence of stages that go from the informal specification of requirements to the deployment and maintenance of the final product. Each stage has associated techniques, procedures, and tools. Software life cycle processes in Software Engineering (e.g. iterative, waterfall, agile, or extreme programming) define alternative methodologies for each of these stages.

67 3.1. Rationale 63 it saves time and money during the development process. The following objectives must be achieved by the architecture. Most of them correspond to non-functional requirements of KMob systems, which are requirements that are not related to what the system has to, but rather to how it is done. Unfortunately, these features are not orthogonal and are often in conflict with each other. First, the architecture must be adaptable to a variety of situations, namely, different domains, interaction patterns between elements, and technologies. The communication schema may range from untethered asynchronous message queues to highly-demanding real-time synchronous processing, and the architecture must be able to reflect these situations. Managing different configurations can be achieved by decoupling actors, actions, resources, and communication channels as much as possible. Two other features that a KMob architecture must provide are extensibility and robustness. Extensibility may be required in diverse dimensions, for instance, in the number and type of system users or in the amount of resources available. A robust system guarantees that it will be operative most of the time. The more critical the task to be resolved, the greater the effort that must be made to build a reliable system. Given that system failure may be triggered by many uncontrollable facts, obtaining a robust system is usually expensive. Security is a very important property that deserves a special comment. Security entails user authentication, integrity of the data, and encryption of the communications among other tasks. KMob systems must be secure, but our architecture does not tackle this matter in depth because a complete study of it is outside the scope of this work. As widely pointed out in the literature [123, 166], security in mobile systems and applications is an extremely complex issue that transversely affects the layers of a mobile infrastructure. Nevertheless, security mechanisms can be easily incorporated in our architecture. Given these requirements, we propose an architecture based on the multi-

68 3.2. Agent-based architectures 64 agent paradigm. The reason is that the multi-agent paradigm has proved to be capable of supporting the development of distributed systems in several domains with different communication schemas [244]. Moreover, multiagent systems are scalable, adaptable to different requirements, and robust. The multi-agent paradigm provides the theoretical foundations for both describing and implementing distributed systems. We will use the agent paradigm for describing the architecture of KMob systems. The components of the architecture will be modelled as agents. However, the developers will be free to choose any implementation framework for the architecture, not only multi-agent platforms. For instance, Web Services can be used to implement the architecture when the communication schema of the application is of the client-server type. In the next section, we study multi-agents architectures as a metaphor for designing KMob systems (Section 3.2). Before presenting our KMob architecture in greater detail (which is done in Section 3.3), we provide a brief introduction to agent-based architectures as well as the modeling language AML (Section 3.2). Finally, we describe three combinations of technologies that can be applied to implement the architecture in three applications domains (Section 3.4). 3.2 Agent-based architectures Architectural patterns Software architectures have been studied in Software Engineering for some time now, but only recently they have been acknowledged as important artifacts in the development process. This is mainly due to the evolution of monolithic software systems as distributed networks of computational resources. The recently adopted ISO standard IEC/DIS (formerly IEEE Std ) states than an architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its com-

69 3.2. Agent-based architectures 65 ponents, their relationships to each other and the environment, and the principles governing its design and evolution [124]. Basically, a software architecture abstractly specifies (i.e. unnecessary details are not presented) the structure of a system (i.e. the distribution and the responsibilities of the elements), the communication between the components (i.e. the flow of information), and other additional requirements (i.e. technical, quality, or business oriented) [104]. The architecture of a software product can be described from various perspectives, which produce different views of the system. Commonly used views are the functional/logical view (focus on structure), the concurrency/process view (focus on communication), the development view (focus on software modules), and the physical/deployment view (focus on implementation). Documenting a software architecture has always been something of a headache for IT managers. Revising or sharing a specification is often rather difficult. For this reason, semi-formal methods for modeling software systems have been proposed, such as UML (Unified Modeling Language) [69, 86]. An architecture is said to comply with an architectural pattern when it has the typical features of the pattern. There are several predefined architectural patterns that have obtained considerable success in specific application domains. These best patterns have been verified and studied in great detail. Thus, if a problem fits a certain pattern, design and development can be guided by the pattern specification. Three widely used patterns for distributed systems are client-server, service-oriented, and agent-based architectures. The client-server pattern is one the most frequently used architectures in distributed computing. In its basic form, it suggests a simple intercommunication schema between two clearly-distinguished entities: clients and servers. Clients are programs that perform minimal processing and require few computational resources. Clients delegate most of the tasks to servers, which run on more powerful platforms, and are responsible for satisfying client requests. Workload can be balanced between clients and servers in

70 3.2. Agent-based architectures 66 such a way that clients may need servers only to carry out certain complex tasks such as database management. The evolution from simple (thin) to complex (fat) clients has given raise to Service Oriented architectures (SOAs), which, to some extent, may be considered an enhancement of the client-server paradigm. Functionalities in a SOA are provided by services, which are stateless facilities that can be accessed remotely. Services are usually implemented with Web Services, a standard from the World Wide Web Consortium (see Section B.5). Web Services also separate clients and servers, which have very different roles in the architecture. Nevertheless, in some situations a client may become a server (and vice versa), in such a way that each component of the architecture can alternatively request and provide information. This pattern is known as Peer-to-peer (P2P), and depicts a scenario where groups of loosely-coupled equally responsible entities communicate directly to accomplish an objective. Peers showing a certain degree of autonomy and awareness can be regarded as agents, in the classical sense of the term [203]. The multi-agent paradigm depicts a scenario where the agents, which are autonomous, proactive, and context-aware computational entities, communicate to achieve a goal [259]. A multi-agent architecture is a description of a system in terms of agents capabilities, organization, and interactions [91]. Multi-agent theory proposes different kind of agents, system structures and collaboration policies, which should be adapted to the problem to be faced [172]. Multiagent software engineering techniques [28, 29] can be used to develop a multi-agent system. Very few general architectures tackling the specific problems of mobile applications have been created, and most are adaptations of the client-server pattern. Not surprisingly, this is a natural way of structuring mobile systems, given the computational limitations of mobile devices. Thus, several research studies focusing on the adaptation of the client-server architecture to mobile environments have been published [131, 159].

71 3.2. Agent-based architectures 67 Though these approaches consider participation of both thin and fat clients, intelligent applications require more diverse interaction patterns. As a result, other architectures have been proposed in the context of Intelligent Systems. Most of them have an associated implementation framework, such as those mentioned in Section 2.5. These ad hoc architectures are usually inspired on existing paradigms from pure client-server to multi-agent, and are tailored to meet specific needs. Our contribution in [77] provides an abstract architecture for intelligent mobile systems that overcomes some of the issues of related approaches. This architecture relies on the service-oriented and the multi-agent paradigms. Services are modelled as agents, and a convenient multi-agent architecture is proposed. With this architecture, the choice of implementation technologies is left to the developer, who can use agent and non-agent platforms. As a matter of fact, the paper showcases the PDA 2 (Psychological Disorders Assistant for PDA), a mobile knowledge-based system to retrieve information about psychological disorders. PDA 2 is designed as a multi-agent system, but is implemented as a Web application. The client, equipped with a portable device, consults the server by using a Web browser. In Section 3.3, an improvement on the architecture in [77] is presented in detail. The new architecture, also based on the multi-agent paradigm, is described using AML, a software specification language for agent-based systems. An overview of AML is provided in the next section. The Agent Modeling Language The Agent Modeling Language (AML) is a semi-formal visual language for specifying, modeling, and documenting systems in terms of concepts from MAS theory [256]. AML defines a set of elements and restrictions that the software designer can combine to graphically depict the structure, relations, and procedures in an agent-based system. Similar approaches to AML have been proposed. The survey in [63] compares AML with other agent-modeling languages, such as Gaia, AUML, Mes-

72 3.2. Agent-based architectures 68 sage, Tropos, MAS-ML, and AOR. AML is less academical and more practical than the other languages. As a result, it is more applicable to real problems. We have decided to use it because it is more flexible, and is better supported by existing visual design tools. available documentation than other proposals. It also has the advantage of having more Furthermore, AML has solid underpinnings, since it is based on the Unified Modeling Language (UML) [69, 86]. UML defines entities (with an associated graphical notation) that represent elements of the application domain, such as actors, resources, procedures, etc. These entities are included in UML diagrams corresponding to different views of the system architecture. UML representations are simple enough to be understood by both developers and clients so that feedback can be directly provided. Nevertheless, in order to interpret all the details of a software design, more knowledge regarding language particularities is required. The formal semantics of UML entities and diagrams are stated in the UML metamodel. AML is defined as a layer on top of the UML metamodel, extending it with new primitives consistent with UML entities. The most important AML primitives are the following: (i) entities, which are social and autonomous elements with a behavior and a structure; (ii) relationships or associations between entities; (iii) behaviors, defined as procedures performed by entities; (iv) execution environments or platforms where entity implementations are deployed; (v) ontological elements or components of a knowledge model. Table 3.1 summarizes the AML constructors employed to specify our architecture, and shows their graphical representation. Next, a brief description of each is provided 2. AgentType. This is the type assigned to AML agents. In AML, an agent is any autonomous entity that passively or proactively interacts with the environment, independently of its implementation. 2 Since it is out of the scope of this dissertation to provide a complete overview of AML, we refer the reader to the AML specification for further details on the language [63].

74 3.2. Agent-based architectures 70 ResourceType. Resources are passive entities with associated properties that are accessible inside the system. External resources in AML are defined as UML Actors. EnvironmentType. Environments are the logical or physical surroundings where entities exist. The environment type defines a set of properties for defining which entities live in the environment (agents, resources, etc.) and some of their features (rules, laws, policies, etc.). In the same way as resources, external environments in AML are defined as UML Actors. EntityRoleType. Generally speaking, a role denotes a set of features and capabilities that an entity may decide to acquire. ServiceSpecication. This class is used to describe accessible services in the system. Such services are defined by their protocols (entry points that a service offers) and behaviors (activities that the service performs). BehaviorFragment. Behavior fragments (partially) describe the dynamics of an activity performed by an entity to achieve a goal. SocialAssociation. A social association is a bidirectional property denoting a relationship between two socialized entities. PlayAssociation. A play association is a bidirectional property denoting that a behaviored entity can acquire a role. ServiceProvision. Service provision stands for a dependence relation between the provider entity and the provided service. ServiceUsage. Service usage stands for a dependence relation between the user entity and the service used. ExecutionEnvironment. An execution environment models the physical platform where entity implementations run. It is interesting to note that new execution environments can be defined by specialization of the basic

75 3.2. Agent-based architectures 71 ExecutionEnvironment. Thus, implementations with different frameworks (including non-agent technologies) can be described with AML. Ontology. Ontology is the basic primitive to specify a knowledge base in AML. Ontologies are used in agent systems in several scenarios: to define a common language for agent understanding, to describe the features of a service, to build the knowledge models supporting a knowledge-based system, etc. Other ontological constructors are OntologyClass and OntologyUtility. Context. Context is a primitive to describe the properties of the section of an AML model that is to be considered in a particular situation. These situations can be specified with UML constraints or states. AML specifications are organized in diagrams, which are extensions of the standard UML diagrams. In our specification, the following diagrams are used: Society Diagram. A society diagram presents a general view of the architecture of the multi-agent system. Entities (agents, resources, environments, and organization units) and relationships (social associations, play associations) are depicted in these diagrams. This diagram is a specialization of UML Class Diagram. Entity Diagram. Entity diagrams are used to present in detail the structure of an entity: features, behaviors, ports, roles played, services provided and requested, etc. This diagram is a specialization of the UML Composite Structure Diagram. Protocol Sequence and Protocol Communication Diagrams. These are two different kinds of diagram that are used to specify communication acts between entities. They are specializations of the UML Sequence and Communication Diagrams, respectively. MAS Deployment Diagram. These diagrams specify how the multi-agent system is deployed on the execution platform. This diagram is a specialization of the UML Deployment Diagram.

76 3.3 Architecture description 3.3. Architecture description 72 In this section, our abstract architecture for KMob systems is presented. The full specification can be downloaded from ~jgomez/thesis/. This architecture is based on the proposal in [77], which is extended to be adaptable to different KMob application domains. The new architecture is described using the AML language. Foundations The architecture for mobile Knowledge-Based Systems in [77] has three main components, namely, clients, service servers, and ontology servers (Figure 3.1). This naive architecture reflects the following idea. Clients request services, which are provided by servers. Servers solve client requests, sometimes by consulting other services, and returns an answer to the clients. Communication between clients and servers is performed throughout the network infrastructure by using a suitable communication protocol. The servers of the architecture implement the services provided by the system, i.e. they offer an access point to the functionalities of the application. These functionalities can be large database querying, real-time data supply, reasoning with a knowledge base, or any kind of expert decision support. Given that knowledge management is crucial in Knowledge-Based Systems, we distinguish a special service provider, namely the ontology server. This ontology server is responsible for the management of the global knowledge base of the system, as well as the incorporation of other information sources, which may be external data repositories. The clients are expected to run on mobile devices, such as cell phones and PDAs. If the mobile device has very limited computational capabilities, it will be forced to delegate most of the processing to the servers. Alternatively, it may happen that a client runs on a more powerful device (which, in the best case, may be a desktop device), and is able to perform heavier processing.

78 3.3. Architecture description 74 In this case, the client can carry out more tasks, and even handle a local knowledge base. Therefore, depending on the features of the device, there will be clients with different degrees of intelligence: intelligence alludes to the ability of the client to solve queries with its own knowledge. We have extended this architecture to better represent this variety of client abilities, which occurs in KMob systems. The extended architecture for KMob is described in the remainder of this section. As explained below, we have completely decoupled agents and roles. Entities of the previous architecture are modelled as agents in the new architecture description. Thus, clients and servers are now agents (KMob Agents). The actions that an agent can perform have been separated from the agent description, and are represented now as roles. Thus, a role is a set of methods that an agent can execute (KMob Roles). The difference between agents running on mobile and desktop devices is represented by defining two subtypes of agentsm namely, Desktop Agents and Nomadic Agents. The execution environment determines the features and requirements of an agent because data processing and transmission are limited in mobile devices, and they are used in dynamic situations. Nomadic and Desktop Agents can acquire different roles. We consider that both agents running on mobile and desktop devices can eventually perform as knowledge requesters and providers. Obviously, in a P2P application, every agent will be both requester and provider, whereas in a pure clientserver system, mobile clients will only be requesters and desktop servers will be mainly providers. The advantage of the architecture is that it can be adapted to these different scenarios. Starting from these primitive elements, other entities and roles have been defined. For instance, the former ontology server would be a Desktop Agent with connections to Local and External Knowledge Models that acquires the Provider role. Next, the new agents and roles are described.

79 3.3. Architecture description 75 General structure An overview of the architecture for KMob systems, in AML notation, is shown in Figure 3.2. KMob Agents are the basic elements of the architecture. They encapsulate all the processing associated with nomadic and static entities. Two kinds of agents are distinguished: (i) Nomadic Agents, which run on mobile devices; (ii) Desktop Agents, which run on application servers. Agents may be deployed in a public, private, or mixed network, which should support communication between them. Basic KMob Agents can be specialized in concrete applications by organizing them into subclasses with additional properties. Each agent, nomadic or desktop, manages a Local Knowledge Model. The richer the local model, the more intelligent the agent, since it will be capable of better resolving a greater number of problems. When an agent is not able to answer a question with its own knowledge, it requires the services of other agents or the contents of External Knowledge Sources. Services are offered by both Nomadic and Desktop Agents, although Desktop Agents usually provide more complex services. Integration of internal and external knowledge can either be performed on the fly, i.e. as necessary for satisfying a service request, or off-line, i.e. by creating a warehouse with a permanent mapping between internal and external knowledge. When agents interact directly as a result of a service request, or indirectly, because they share their resources or their objectives, Social Relations are established among them. Social Relations may range from implicit associations resulting from the functioning of the system to explicit connections with a well-defined structure.

81 3.3. Architecture description 77 Architecture components Agent roles The basic roles that can be adopted in the KMob architecture are Consumer, Provider, Directory, Facilitator, Integrator, and Broker (Figure 3.3). Some or all of these roles can participate in a KMob application. More interaction patterns that might be considered are those specific of the application to be implemented. Consumer and Provider roles are self-explanatory. An agent becomes a consumer when it requests a Service. The petition is processed and eventually resolved by the Provider. In order to supply a suitable answer to the Consumer, the Provider may turn to a second Provider (for instance, an External Knowledge Model) and play the role of a Consumer (Figure 3.4). In the basic situation, a Consumer s requests are processed on-demand synchronously, although in some cases asynchronous communication may be preferred. A different situation occurs when a Provider decides to proactively supply information to a Consumer. In other words, the communication act is not started by the Consumer entity. It is the Provider who sends an information package to a Consumer, who can accept or reject it. A Directory is a special kind of Provider that resolves queries asking about the features of the services in the system. An agent playing the Directory role can be consulted, for instance, if there is a service with a given name available (in the simplest case), or if there is a service that can fulfill a specific task. To have an effective directory, services must be registered before being offered to consumers. Service-oriented and multi-agent platforms usually provide mechanisms for elemental directories; e.g., the UDDI Web Services protocol is intended to create and consult a service directory. More recently, formal languages such as OWL-S have been proposed to attach semantics to service descriptions in order to automate location, integration, and invocation. These approaches, which are commented in Section B, can be used in the directories of the architecture. In simple applications, agents offering di-

84 3.4. Frameworks and technologies 80 rectory services will not be necessary since every agent can have a predefined list of services. Facilitator is the role acquired by the agents that provide Mediation Services between entities that cannot communicate directly. This issue may arise in several circumstances; e.g., incompatibility between agents (different communication protocols or languages/ontologies are used), or security (the Facilitator is a gateway between the secured and the private network). Implementing a Facilitator role may be a difficult task, since mediation can be extraordinarily complex in some applications. Integrators are the specialized Facilitators responsible for combining local and external knowledge sources, i.e. mediating between local and external knowledge providers. Ideally, integrators should allow owned and external knowledge to be accessed together transparently in such a way that consumers are unaware of the origin of the information. A Broker is a role that offers both facilitation and directory services. Brokers are expected to perform several complex tasks to satisfy a request: location of services, matching of consumer preferences and provider capabilities, mediation, etc. This kind of role is frequent in applications with several providers and thin clients, who delegate most of the processing to the broker entity. Brokers are also responsible for guaranteeing quality of service in highly-demanding systems. 3.4 Frameworks and technologies The architecture in Figure 3.2 depicts the basic components in a KMob system, but it does not state how they should be implemented. In this section, we describe three combinations of technologies (i.e., frameworks) that can be used to implement KMob systems 3. These technologies are multi-agent 3 Since processing in the nodes may be disparate, and will probably include knowledge management tasks, ontology tools, such as management APIs or inference engines, are generally used. These technologies are described in Appendix B.

85 3.4. Frameworks and technologies 81 platforms, tuplespaces, and Web-based protocols. Each framework is suitable for a particular instantiation of the architecture. The architecture can be directly implemented using multi-agent platform, such as JADE. The multi-agent technology is especially recommended in applications with independent components that require complex coordination policies. Nevertheless, it is known that multi-agent platforms require a considerable amount of computational resources to run properly. Therefore, the multi-agent framework should be used only when the application requires all the features of a multi-agent platform. In other cases, communication is the main issue of the KMob system. Accordingly, developers should use technologies that promote effective communication between distributed components. This is a feature provided by tuplespaces, which are the second framework suggested in this section. On the other hand, in some applications communication is not the main problem, but rather the processing that must be carried out in certain components of the system. In these situations, a good choice is to implement a client-server application using Web technologies, such as HTTP-based interaction or Web Services. Multi-agent technologies The client-server and the tuplespace frameworks, described below, are simplifications of the more general communication schema supported by the architecture. Nevertheless, in some scenarios it is not possible to be absolutely certain of the structure of the conversations between consumers and providers. Moreover, entities act as a consumer or a provider depending on their needs and capabilities. Ultimately, in these situations communication may take place among equally gifted entities, corresponding to a peer-to-peer schema. This is the case of the Ubiquitous Security Guarding application (Section 2.3). The guards are provided with mobile devices which continuously

86 3.4. Frameworks and technologies 82 send and receive information about the state of the areas under surveillance, both on demand and proactively. For instance, a guard can request the video signal currently captured by a camera. He can also receive a notification stating that an alert has been triggered in a sector, and automatically, the proper signal is displayed automatically on his device screen. Other links could be established between the guards in such a way that they are able to transparently communicate among themselves as well as with other nodes of the system. An agent platform is a natural approximation to implement such a system. Entities exhibit a high degree of autonomy and, at the same time, there are social dependencies between them, which are one of the most notable features of multi-agent systems. Our architecture can be almost directly implemented using one of the MAS platforms presented in Section 2.4. In fact, certain contributions aim to automatically generate a programming code from AML specifications automatically [150]. Among these platforms, we propose the JADE/LEAP middleware as a suitable framework to implement the KMob architecture in that kind of application. JADE (Java Agent DEvelopment Framework) is an open-source middleware oriented to the development of distributed multi-agent applications based on peer-to-peer communication [23, 22]. JADE offers three utilities to developers: (i) an API for agent programming; (ii) a runtime where agents are executed; (iii) a graphical tool to administer running agents. JADE agents are implemented with the JADE API, which includes Java classes to manage agents, behaviors and messages, and Jave methods to send and receive messages. JADE agents are loaded into the runtime, which manages agent lifecycle and message passing. Agent state can be modified with the graphical tool, which provides an interface to check the runtime status. JADE avoids dealing with low-level localization and communication mechanisms, and different transport protocol may be used (e.g. SOAP). JADE is compliant with the specification of the IEEE standards committee

87 3.4. Frameworks and technologies 83 FIPA 4 (Foundation for Intelligent Physical Agents) [94]. The FIPA standard, intended to promote the interoperation of heterogeneous agents and the services that they can represent, is divided into five categories: agent communication, agent transport, agent management, abstract architecture, and applications. The agent communication category is the most important of the five since it defines the Agent Communication Language (ACL), a language designed to achieve understanding between diverse agents. JADE is extended with the LEAP add-on [25], a set of additional libraries that allow JADE agent containers to run on mobile devices, such as PDAs (implementing the CDC profile of J2ME) and cell phones (CLDC profile of J2ME). A LEAP container can be executed in a stand-alone or split mode. This split mode is targeted to devices with limited computational capabilities, and thus it is the most suitable to be used in the KMob Multi-agent framework. The main drawback of LEAP, and consequently, of JADE, is that their formality makes them rather inefficient. Therefore, they are used only when all their features are required. Tuplespace technologies Another scenario is one with several clients, also with computational limitations, but who need to share part of their knowledge. This is the case of the KMob scenario Portable Tourism Guide (Section 2.3): information about sightseeing spots is still accessible to all of the numerous tourist community as a whole, but each tourist is able to introduce new data (tags, reviews, plans, etc.) in the system. Since little processing can be carried out by the clients, they must delegate heavy knowledge management tasks to a server. However, the knowledge base should be, at least to a certain extent, shared among the clients. A suitable solution to these issues is that of tuplespaces. A tuplespace is a knowledge repository composed of n-tuples that can be accessed remotely and concurrently (a n-tuple is an ordered sequence of n items). Tuplespaces 4

88 3.4. Frameworks and technologies 84 were firstly proposed by Gelernter in the context of generative communication, a paradigm for asynchronous exchange of information in distributed systems [99]. Tuplespaces act as mediators in generative communication systems. In order to communicate an entity A and an entity B, A stores a tuple in the tuplespace and B reads it. Generative communication was supported by the programming language Linda, which defines three basic operations to access a tuplespace: out(tuple pattern), to write in the tuplespace; in(tuple pattern), to read and erase a tuple from the tuplespace; and read(tuple pattern), analogous to in but without deleting the tuple. When a query operation fails, the calling procedure is blocked until a suitable tuple is available. In this manner, asynchronous communication is implemented from synchronous read-and-write operations. Tuplespaces and Linda are similar to blackboard architectures defined by the multi-agent paradigm. The objective of both is to provide a central knowledge repository that can be accessed by thin clients using simple operations. More recently, other initiatives have taken a similar approach to Linda. For example, JavaSpaces are a Java technology included in Jini for implementing tuplespaces that can be distributed over the nodes of a network [31]. Tuplespaces also have received attention from researchers seeking a simple mechanism to implement interoperable mobile systems [184]. On the other hand, tuplespaces can be easily adapted to support Semantic Web applications, given the fact that the basic primitive of RDF language is the triple, i.e. the 3-tuples. In that regard, RDF-based Semantic Web Spaces [189, 255], OWL-based stuples [140], and WSMF-based Triple Space Computing (TSC) [152], have been proposed to accomplish Semantic Web coordination by using tuplespaces. Incorporation of a tuplespace in our KMob architecture is quite straightforward. A Tuplespace role can be defined by the specialization of Facilitator. An entity acquiring the Tuplespace role provides a Tuplespace Service, which is a specific Mediation Service offering Linda-like operations. Read and write messages will be sent to the tuplespace entity using, for example, SOAP or RESTful messages. The tuplespace can be implemented by adapting one of

89 3.4. Frameworks and technologies 85 the previously mentioned contributions, or by creating a specific solution e.g., a Linda API wrapping a Sesame RDF repository [54]. Client-server technologies The simplest scenario is that involving a pure client-server interaction pattern. Clients are not able to execute complicated procedures. As a result, queries are totally pre-programmed and processed almost completely in the server. Adding a new functionality implies implementing a new service. Communications are one-to-one, with a client asking for a service, and a service replying to a client. In this case, the Consumer and Provider agents are clearly identifiable, and the communication schema is totally predefined. The Nomadic Healthcare use case (Section 2.3) is a good match for the client-server schema. Doctor Greg, equipped with a mobile device requires information from a centralized server where the bulk data is stored. The client application, running on the doctor s mobile device, carries out very little processing. It is only used to acquire the clinical description of the patient, and to display the results retrieved from the HIS. The server application accepts client requests and translates them to the HIS, acting as a gateway between them. The client may additionally include some knowledge in his local model to work out simple or previously solved queries. The greater or lesser complexity of the reasoning will naturally depend on the mobile device capabilities. Client-server communication between a mobile device and an application server can be implemented by using various technologies. The lowest-level communication issues are handled by means of a wireless or cellular communication technology, e.g. Wi-Fi or UMTS (Section 2.4). Nevertheless, the developer can remain relatively unconcerned about the data communication layer, since middleware systems or, alternatively, Web technologies are available. We consider that a Web-based implementation is appropriate for the Nomadic Healthcare system, and in general, for client-server KMob systems.

90 3.4. Frameworks and technologies 86 Web applications are systems accessible throughout the Internet using the HTTP protocol. Server logic can be implemented with J2EE [133] or.net [65], two current development platforms for corporative systems. Web applications are usually structured in two or three tiers, decoupling the backend storage (e.g. databases) and the presentation layer. The interface of a web application can be oriented to human users or automatic procedures. For human users, HTML pages with a suitable format are created in the server and sent to the client; for automatic procedures, there is an entry point managed by a callback procedure, i.e. a Web Service, enabled to accept XML requests. Since both J2EE and.net platforms supports HTML generation and Web Services, either can be selected. We focus on J2EE because it is multi-platform and its specifications are open. However, all considerations can be easily extended to.net. Human-readable web interfaces with J2EE can be created by using different technologies. For instance, servlets and JSPs (Java Server Pages) are server components that dynamically generate HTML content [183, 262]. These components are deployed in a special web server, such as Tomcat 5. Servlets and JSPs have been recently complemented with JSF (Java Server Faces), which simplifies the creation of HTML interfaces in Java Server applications. Interaction between clients and servers with these technologies is described as click and wait. In other words, the contents are downloaded from the server and presented to the client after a link in the document is clicked. This behavior is problematic in certain scenarios since user experience is downgraded when communication latency is high. The user is idle while he is waiting for the document to be transmitted, whereas the network is idle while the user is reading the document. Ajax is a recent technology aimed at overcoming these problems [72]. Ajax defines a set of recommendations for the implementation of web applications in order to accomplish: (i) partial execution on the web browser (with Javascript); (ii) asynchronous message sending (with the XMLHttp- Request object); (iii) presentation of new contents by modifying only the 5

91 3.4. Frameworks and technologies 87 sections of the document that have changed (with the Document Object Model). These properties are very interesting in KMob applications because richer clients could be implemented in Ajax-enabled mobile web browsers (e.g. Opera Mobile 6 ). New steps towards a better balance of the processing load are RIAs (Rich Internet Applications). RIAs are a set of competing platforms that split execution between web servers and clients. To date, these platforms are in an embryonic state though they will be incorporated in commercial mobile phones in the near future, e.g. Silverlight in Windows Mobile 6 and Nokia S60 Series. Alternatively, Web Services can be used. Web Services are used in machineto-machine communications, i.e. communication acts where human participation is reduced. Web Services have succeeded as means to implement corporative distributed systems. J2EE and.net platforms offers extensive support for them. An alternative approach is the REST model (REpresentational State Transfer), which proposes a simpler architecture based on ad hoc XML request-response messages and APIs. This model is preferred when the power and the formality of the Web Services protocol stack are not required. The client-server framework was used to develop the prototype of the IASO system, which is one of the contributions of this thesis. IASO clients, equipped with mobile devices able to browse the web, can access IASO HTTP servers, which provide the query-resolving services. The IASO system is described in Chapter 5. 6

92 CHAPTER 4 A Context-Dependent Knowledge Representation Model for Knowledge Mobilization This chapter proposes a solution for the problem of information overload in KMob systems based on using knowledge about the context of the user: a novel design pattern aimed to develop OWL ontologies explicitly representing which information from the application domain is significant in a given situation. We begin the chapter by introducing the incidence of information overload in KMob and some work related to our proposal. Then, we present the formal specification of the ontology design pattern, and describe the knowledge base that results from its application. The following section examines the properties of the pattern, including modularity of the resulting ontology. A complete algorithm to infer significant knowledge from the description of a context is also presented and discussed. Next, a software application which supports the creation of ontologies using this pattern is described. Finally, as an improvement to this pattern, we propose extending it by using fuzzy Description Logics, which allow the management of imprecise context and domain knowledge as well as the ranking of significance relations. 88

93 4.1. Rationale Rationale Two main features of current enterprise information systems are connectivity and massiveness. Storages populated with Gbytes or even Tbytes of data are available across corporate networks, and allow users to access to complete, precise, and up-to-date information. The situation becomes more complicated when the Internet is considered because of the huge amount of valuable data that can be harvested from it. Corporative KBSs are expected to incorporate these several and probably heterogeneous information sources to provide valuable advice to decision makers. As a result, functional KBSs usually manage so many resources when it comes to solving most requests that it is common for users, who access large-scale systems, to receive excessive information. Excessive means that either the time to filter it manually is extremely long or that simply it cannot be processed. In the literature this state is designated by the term information overload. It has also been called data smog [231], analysis paralysis [240], or information fatigue syndrome [196]. Information overload is described as a situation in which a user is provided with more data than he can digest, either because sifting through the information received would take too much time or simply because interesting facts cannot be separated from irrelevant data with the knowledge available [83, 85]. This results in unproductive decision processes and knowledge management failure. Solving information overload poses a great challenge for KBS, who must find the means to support the summarizing and customizing of information collected from massive, heterogeneous, and distributed sources depending on user needs. This objective can be achieved by adding metadata to information sources in order to delegate filtering tasks to automatic procedures [87]. Though few scientific studies have specifically addressed information overload issues in mobile systems (as argued in [4]), such issues are crucially important, and have been identified as a key factor for the acceptance of (knowledge-intensive) mobile services (as pointed out in [24]). Any KBS is expected to carry out tasks in consonance with user needs, and consequently,

94 4.1. Rationale 90 to present only significant data. However, this requirement clearly becomes even more critical in KMob. On the one hand, the scenario where a nomadic user requests system answers is completely different from the scenario where the user is stationary. KMob has to be able to handle dynamical decision processes. Such processes must often take place in real time and at the actual work site, where circumstances are extremely changeable, whereas classical support systems are usually exploited in more controlled situations. Therefore, the user cannot be completely focused on the device, and must not be required to search at length for the desired information. On the other hand, despite the fact that the computational power of mobile devices has continued to increase and the fact that wireless technologies provide Mb/s transfer speeds, device dimensions remain small. This is mandatory because of weight and battery life constraints. Reduced screens and adapted input interfaces make it difficult to cope with large datasets, but make it very easy to downgrade user experience. This means that succinctness is essential. Thus, it naturally follows that mobile users cannot be overwhelmed with all the available data of the system nor can they be expected to manually review these results. On the contrary, it is crucial to provide nomadic users with data summaries that include only the most relevant fraction of the information generated. Consequently, the KMob architecture described in Chapter 3 must offer reasoning services able to compute summaries automatically. These services must rely on suitable knowledge bases that represent what is significant. We strongly believe that what is significant (or relevant) depends on certain factors other than the query to be resolved. Such factors include user environment, preferences, previous actions, etc. All of these variables, referring to various circumstances of the query 1, embody what can be regarded as the context of the query. According to Dey and Abowd, context is any information (either implicit or explicit) that can be used to character- 1 Although he was certainly not considering mobile knowledge-based systems, Spanish philosopher Ortega y Gasset ( ) summarized this idea in his maxim I am myself and my circumstances (Meditaciones del Quijote, 1914).

95 4.1. Rationale 91 ize the situation of an entity [79]. More details on context representation in UC are included in Section 4.2. Consequently, a context-aware system must include two kinds of knowledge in its supporting knowledge bases, which are ontologies in KMob: (i) knowledge specific of the domain of the application; (ii) knowledge describing contextual situations. The significance of a piece of domain-specific information in a given context is represented by a relation between an ontological description of the situation and an ontological definition of the domain knowledge. Having a scenario description and a domain-specific expression connected with this type of significance relation means that this domain information must be considered because it is important in that situation. In this chapter, we describe an innovative proposal of a design pattern aimed at representing in OWL ontologies this notion of context-dependent significance. The Context-Domain Significance (CDS, read as Kodos) pattern defines a set of rules to build a new ontology where context descriptions and domain expressions are connected through constrained relations. The main reasoning task within a CDS ontology is to retrieve the pieces of domainspecific knowledge that are significant in a given context. This task can be carried out with a corresponding algorithm. A CDS ontology permits the description of which domain information is interesting in a scenario, but it does not measure how important the information is. This is very convenient in certain applications. Accordingly, we have developed an extension of the CDS design pattern which, relying on Fuzzy Description Logics, allows significance relations to be ranked. The extended pattern creates a fuzzy ontology where contexts descriptions, domain-specific knowledge expressions, and significance relations may be imprecise. This also makes it possible to rank the importance of a significance relation.

96 4.2. Related work Related work Ontology design patterns are simple recipes which help ontologists to capture and represent aspects of the application domain. In this section, we review some contributions on ontology design patterns that are related to our proposal. Since our design pattern is aimed at creating context-aware ontologies, two additional topics are addressed as well: context representation and contextualization of ontologies. In general, contextualization of ontologies consists in determining how additional knowledge influences the interpretation of an ontology (consistency, validity, partitioning, etc.). From this perspective, contextualization is related to context representation: context representation deals with environmental data management, whereas contextualization studies deal with how these context models affect the satisfiability of domain models. In this section, we discuss the literature on representation of context by means of ontologies in UC. Ontology design patterns Design patterns are concise guidelines which identify common design problems, and suggest how to resolve them. Patterns have been recognized as a valuable tool since the very beginning of design sciences from architecture [3] to software developmente [96]. Analysis and design patterns are important meta-artifacts that support the design process of software systems, as stressed in [126]. Acquiring, reusing, representing and eliciting knowledge to build an ontology is frequently an exhausting, time-consuming and frustrating experience even when collaborative experts, proper tools, and sound methodologies are used. Consequently, simple recipes which enable ontologists to better capture aspects of their application domain are greatly appreciated. Ontology design patterns are the extension of software design patterns. Their objective is to describe, more or less formally, recurrent modeling scenarios as well as to provide guidelines for correctly incorporating this knowledge

97 4.2. Related work 93 into ontologies. By correctly, we mean obtaining accurate, transparent, and reasonable representations [252]. Since the earliest work on the Semantic Web, ontology design patterns have been acknowledged as important contributions, which permit developers to save time when coping with the knowledge acquisition bottleneck. Templates to build knowledge bases have been proposed in several papers, some of which are specific for a concrete application domain (e.g. [219]), some of which are more general and (even) language-independent (e.g. [239]). The task force Ontology Engineering and Patterns [195] was created inside the W3C Semantic Web Best Practices and Deployment Working Group in order to elaborate best practices and patterns for OWL. The work of this task force was partially inspired by [191], a classical ontology-development guide which includes tips on how to build ontologies properly. Research studies [252, 97, 38] provide a useful introduction to the use of design patterns during the ontology lifecycle. In the first study, Svátek analyzes several ontologies publicly available at Semantic Web repositories, and briefly presents some examples of patterns targeted at solving common representation mistakes. In the second paper, Gangemi describes the differences between software and ontology design patterns from a Semantic Web perspective, remarking that greater formality is required in the presentation of the CODePs (Conceptual Ontology Design Patterns), and provides some examples. In the third study, Blomqvist and Sandkuhl set out a classification of the patterns used in ontology development, and establish that ontology design patterns are those applied to create certain sections of the models. More recent contributions from these authors have proposed techniques for the automatic selection of suitable patterns to support ontology development [36, 37]. Context representation in UC Broadly speaking, context is any information (implicit or explicit) that can be used to characterize the situation of an entity [79]. More specifically, context

98 4.2. Related work 94 is usually considered a mix of geo-spatial data, ambient sensor inputs, user profiles (preferences, intentions, etc.), and service descriptions [229]. Accordingly, context awareness is commonly defined as the ability to acquire, represent, and process environmental information in order to automatically adapt the behaviour of an application to user activity. Context-Aware Computing entails two activities: (i) interpreting the current user situation; (ii) using contextual knowledge to improve the performance of the system, for instance, helping to filter and tailor system responses. Context representation has been considered to play a key role in UC [258, 226], as explained in Section 2.4. The previously mentioned Context Toolkit is one of the first systematic approaches towards a generic framework for context-aware systems [80]. We use ontologies as the conceptual model to represent context knowledge in KMob. Not surprisingly, ontologies have been proposed as a design tool for modeling context in current pervasive systems since they offer several advantages over other formalisms: reusability, sharing, reasoning, standardization, supporting tools, etc. [57, 248]. In fact, significant progress was initially made in representing situational knowledge by means of formal theories, thanks to Levesque (inter alia) [162], one of the fathers of Description Logics. In the same regard, Situational Computing is claimed to be an extension of Context-Aware Computing which considers series of situations and past actions in the adjustment of system responses. Recent proposals on UC which use ontologies, written in OWL or in one of its predecessors, are cited in Section 2.5 [7, 149, 66, 106, 139, 154, 158, 182, 263]. Contextualization of ontologies Most of the work on contextualization concerns non-monotonicity in knowledge bases, in other words, reasoning with models which are satisfiable or not depending on the available knowledge [180]. Some early approaches

99 4.2. Related work 95 to the use of contexts in real Expert and Knowledge-Based Systems are described in [53]. For our purposes, contextualization is important because it determines how a knowledge base is interpreted depending on a concrete model, namely, the context knowledge model. Interestingly enough, Description Logics and, extensively, ontologies, include a feature that makes them pretty much a monotonic formalism [49]. This feature is the open world assumption (see Section A.4). Some of the extensions proposed to allow non-monotonicity in ontology languages are the following: epistemic queries [136], default reasoning [148], circumscription [46], belief revision [95], and integration with logic Programming [181]. Other research works are focused on contextualization in the Semantic Web, and extending OWL with new operators to explicitly allow contextualization. For instance, Guha, McCool, and Fikes [107] examine seminal contributions on contexts and microtheories in Artificial Intelligence, and use some of these ideas to solve context-dependent aggregation problems in the Semantic Web. These authors use an ontology to define contexts which model implicit knowledge with a view to interpreting the right semantics of data sources. Essentially, a context associated to a source means that these data are true in that context. Similarly, Bouquet et al. propose C-OWL [50], an extension of OWL to define mappings (via bridge rules) between locally-interpreted and globallyvalid ontologies. Multi-viewpoint reasoning in [249] is a related approach which resembles to a certain extent our idea of significance. However, it concentrates on the conditional interpretation of a model (i.e. how to classify an ontology depending on the viewpoint submodel), whereas we focus on the relevance of the model (i.e. in which circumstances a submodel should be considered). In the same regard, a review of different perspectives on the implementation of context-sensitivity is presented in [109]: C-OWL, ɛ-connections, Bayesian networks, probabilistic and possibilistic logics, etc. This work also cites context-based selection functions, which are very similar to our pro-

100 4.3. Definition 96 posal. These functions retrieve the submodel K K that ought to be considered when performing some task. This report is a deliverable of the NeOn project, an on-going initiative that targets, among other problems, the handling of contexts with certain degree of uncertainty [211]. 4.3 Definition The Context-Domain Significance (CDS) design pattern is our proposal to represent relevance depending on context in KMob applications. The CDS pattern constructively states a set of rules to develop a new OWL ontology, the significance or CDS ontology. This ontology explicitly relates context descriptions, created by using a context vocabulary, with domain-specific expressions, which represent knowledge specific of the application domain. Given a CDS ontology, it is possible to infer which domain knowledge ought to be considered in a given situation by performing various subsumption tests. The CDS ontology is the instantiation of the rules stated in the CDS pattern. Following [38], the formulation of the pattern in Description Logics notation can be interpreted as the semantic definition of the pattern, whereas the final OWL encoding is the syntactic expression of the pattern. We refer the reader to Appendix A for a review of ontology-related topics and Description Logics (DLs), upon which the remainder of this chapter is based. To illustrate the definition of the CDS pattern, in this section we use the case study of Nomadic Healthcare presented in Section 2.3. We partially describe the ontology that supports a KMob system which delivers summaries of patients electronic health records to a mobile doctor. The content of these summaries depends on the clinical situation of the patient who is being treated and is selected automatically.

101 4.3. Definition 97 Formulation A CDS ontology is built from two basic subontologies, one representing domain-specific knowledge and another defining a vocabulary to describe context situations. These two subontologies may be related or even included in a more general ontology, but for the sake simplicity, we will operate on the assumption that they are disjoint. Both context and domain ontology should exist before applying the CDS pattern. The domain-specific ontology contains the knowledge required to solve the concrete problem that the system is facing. In the KMob system for Nomadic Healthcare, this would be an ontology that abstractly represents which records are managed by the Hospital Information System, and which values have been stored for a patient. This ontology can be built by adapting some of the current proposals for a standard to represent the semantics of the contents of an HIS [84]. For instance, an OWL translation of openehr could be adapted to our requirements (see Section 5.2). Example 4.1 A domain-specific ontology in Nomadic Healthcare.. Concepts of the domain ontology may be Patient, EHR (Electronic Health Record 2 ), HDR (Health Data Register), and HDRDrugIntolerance (Health Data Register of Drug Intolerance). Roles of this ontology can be related- ToPatient, from Patient to EHR, and composedof, from EHR to HDR. Instances of this ontology are the actual values of patients electronic health records. This is an excerpt of the (simplified) ontology in DL syntax. It reflects that patient juan has related an EHR with a HDR stating that he has been diagnosed as having allergic reactions to Procaine. Moreover, other additional concepts describing different pieces of data stored in the HIS are defined. InformationUnit 2 An Electronic Health Record (EHR) is defined by the Health Information Management Systems Society s (HIMSS) as a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, and radiology reports [185].

102 4.3. Definition 98 Specialty Patient HDR InformationUnit EHR composedof.hdr EHR relatedtopatient.patient HDRDrugIntolerance HDR HDRProcaineIntolerance HDRDrugIntollerance HDRPenicillinIntolerance HDRDrugIntollerance HDRCoagulationDisorder HDR HDRBloodPressureDisorder HDR (jgomez : Patient) (jgomezehr1 : EHR) ((jgomezehr1, juan) : relatedtopatient) (positiveprocaine : HDRProcaineIntollerance) ((jgomezehr1, positiveprocaine) : composedof ) New concept definitions built from elements of the domain-specific ontology are called complex domains. Definition 1. Let K D = T D, R D, A D be a domain-specific ontology. A complex domain D j is a concept such as S(D j ) S(K D ). The context ontology contains knowledge suitable for the representation of circumstances or surroundings in which the domain knowledge is used. The context ontology can be regarded as a formal vocabulary or terminology to depict these situations. In the example, the context ontology contains terms describing the clinical situation of a patient (e.g. if he is unconscious; if he has a wound and where it is located; if his situation is serious; etc.). Thus, this is a medical ontology which can be built by specializing a general medical ontology, e.g. Galen [221].

103 4.3. Definition 99 Example 4.2 Context ontology in Nomadic Healthcare. Concepts of the domain ontology for Nomadic Healthcare are Unconsciousness, Laceration, or IntensityQualifier. An important role is has- Intensity, which is used to express the degree of severity of a pathological process. The following is an excerpt of the domain ontology. As can be observed, the knowledge base states some equivalences with the base ontology Galen. Unconsciousness galen:disorderofconsciousness Hemorrhage galen:haemorrhagingprocess IrregularPenetrationWound galen:laceration High IntensityQualifier New concept definitions built from elements of the context ontology are called complex contexts. Definition 2. Let K C = T C, R C, A C be a context ontology. A complex context C i is a concept such as S(C i ) S(K C ). It is important to notice that D j and C i are not part of the domain and the context ontology. Actually, they are defined in the CDS ontology (K S ), which is a new ontology where C i, D j, and links between them are defined. These links, called σ- connections (connections representing significance), state that the domainspecific knowledge D j should be considered in situation C i. A σ-connection concept is a new concept representing a σ-connection, and is defined with existential restrictions on the complex context and the complex domain that it links (via properties R c and R d ). When there is no possibility of confusion, we use the term σ-connection instead of σ-connection concept. Definition 3. Let K D and K C be, respectively, the domain and context ontologies, C i a complex context, and D j a complex domain. The significance or CDS

104 4.3. Definition 100 ontology that relates the set of pairs (C i, D j ) (i.e., states that D j is interesting when C i occurs) is a consistent ontology K S = T S, R S, A S such that T S (nonexclusively) includes definitions for the concepts P, C, D, C i, D j, P i, j, which satisfy: 1. P, C, D are the superclasses σ-connection concept, complex Context and complex Domain : P i, j P, C i C, D j D 2. R c is the bridge property linking σ-connections and complex contexts: P R c.c 3. R d is the bridge property linking σ-connections and complex domains: P R d.d 4. P i, j is the σ-connection linking the complex context C i and the complex domain D j : P i, j R c.c i R d.d j Figure 4.1 depicts the structure of a simple CDS ontology. It can be observed that K C and K D are imported by K S. Since C i and D j are built from concepts defined in K C and K D, respectively, these two ontologies must be incorporated into K S to preserve their semantics. The consequences of this fact are discussed in Section 4.3. Next, we present an example of a CDS ontology. Example 4.3 A significance ontology for Nomadic Healthcare. The CDS ontology K S in this example must reflect which information from the HIS ought to be considered when treating a patient in a specific clinical situation. Let us suppose that hasclinicalfact and haselectronic- Register are the bridge properties R c and R d. Then, complex contexts C i, complex domains D j, and σ-connections between them can be defined as follows.

106 4.3. Definition 102 When the patient is unconscious, with an extremely serious hemorrhage, and has a penetrating wound, it is necessary to check registers for blood pressure disorders, drug intolerances, and coagulation disorders. C 3 Unconsciousness (Hemorrhage hasintensity.high) PenetrationWound D 3 HDRBloodPressureDisorder HDRDrugIntollerance HDRCoagulationDisorder P 3,3 hasclinicalfact.c 3 haselectronicregister.d 3 It can be observed that C 3 C 2 C 1 and D 1 D 3, D 2 D 3. Properties Inclusion of σ-connections Proposition 1. Let K S be a CDS ontology, where C i and C i complex contexts defined in T S, and D j are D j complex domains defined in T S. The ontology K S satisfies the following property: C i C i D j D j P i, j P i,j This proposition reflects the intuition that if a context and a domain are connected through a σ-connection, more general (i.e. subsuming) contexts and domains will be connected through a more general σ-connection. Proof. The proof is practically immediate from the fourth condition in Definition 3. Let us examine it in greater with more detail.

107 4.3. Definition 103 From the semantics of the full existential quantifier 3, given any model I of K, x ( R.C 1 ) I ( y I (x, y) R I y C I ). Using this expression 1 and the definition of the interpretation of a GCI (C D C I D I ), we obtain: y C I y D I ( y I (x, y) R I y C I ) x ( R.D) I. Therefore, given an ontology K = C D and any model I of K, ( R.C) I ( R.D) I is true, or in other words, C D R.C R.D. This result is also valid for the significance ontology K S, and can be expressed in terms of R c and R d : C i C i ( R c.c i ) I ( R c.c i ) I and D j D j ( R d.d j ) I ( R d.d j ) I. The application of the property of common sets A 1 A 2 B 1 B 2 A 1 B 1 A 2 B 2 and the definition of the interpretation of a GCI give the following: ( R c.c i ) I ( R d.d j ) I ( R c.c i ) I ( R d.d j ) I ( R c.c i ) ( R d.d j ) ( R c.c i ) ( R d.d j ). This finally gives: ( R c.c i ) ( R d.d j ) P i, j P i,j ( R c.c i ) ( R d.d j ). In general, the reciprocal is not true. This formulation of the pattern allows a consistent significance ontology to be created with P i, j P i,j, but C i C i and/or D j D j. As this can be useful in some applications, further requirements in the pattern can be stated to ensure this property. Definition 4. A hierarchical significance ontology is a CDS ontology K S which additionally satisfies: P i,j P i,j C i C i D j D j This property means that in a hierarchical relevance ontology, if we define a σ-connection subsumed by another σ-connection (P i, j P i, j ), the context and the domain thus linked (C i, D j ) are subclasses of the context and domain (C i, D j ) related by the super σ-connection. The procedure used to prove if a CDS ontology is hierarchical is straightforward: for each pair of σ-connections, subsumption between the linked context and domain must be checked. When developing a new CDS ontology, this test can be performed for every new profile with a view to: (i) 3 See Section A.3 for a detailed explanation on the semantics of DL constructs and axioms

108 4.3. Definition 104 detecting possible contradictions with Definition 4; (ii) displaying advice for the ontologist; (iii) adding suitable axioms. Alternatively, it is also possible to add further restrictions to our definition of significance ontology which force the resulting CDS ontology to be hierarchical. Proposition 2. The following additional restrictions are sufficient to ensure that a significance ontology is hierarchical: 1. R c and R d are functional 2. R c and R d are functional 3. A complex context is involved in a σ-connection: C i R c.p i, j 4. A complex domain is involved in a σ-connection: D j R d.p i,j Proof. The conditions can be proved to be sufficient by contradiction. Let us assume a significance ontology K S satisfying Proposition 2, a model I of K S and an instance c such as c C I i and c / C I i. Because to restriction 3 (and 2), there is (only) one p P I such as i, j (c, p) R I (p, c) R I. c c By hypothesis, P i, j P i,j, so p PI. By definition, P i, j i,j R c.c i R d.d j, which implies that (p, c ) R I, where c c C I. i Therefore, we have (p, c) R I and (p, c ) R I. Due to restriction 1, c c R c is functional, so necessarily c = c. Consequently, c C I, which is a i contradiction of the initial assumption. No individual satisfying c C i and c / C i can exist and, as a result, C i C i. The counterpart for D j D j is immediate. Modularity The CDS pattern promotes ontology modularization since it clearly separates the context, domain, and significance models. Nevertheless, the significance

109 4.3. Definition 105 ontology K S must completely import K C and K D. This is necessary because K S contains the definitions of complex contexts C i and domains D j, which are built by relying on the concepts of K C and K D, respectively. Moreover, partial inclusion is not allowed by the import directive of OWL. Arbitrary definitions of C i and D j in K S may lead to undesired inferences in K C and K D. For instance, for two concepts A and B defined in K C, the following situation is possible: C 1 A C 2 B C 2 C 1 = B A The axiom B A, which may not be asserted in K C, is obtained as a result of the definitions of C 1 and C 2. This is not a desirable inference because the significance ontology is not expected to change the meaning of the context and domain ontologies, which are external models, and possibly managed by other organizations. In the remainder of this section, we focus on the context ontology K C. The following considerations can be directly extended to K D. Undesired inferences frequently appear in ontology reutilization. This must be avoided, and ontologies should be safe to reuse. The basic idea underlying the safe reuse of ontologies is that the importing ontology must not add new knowledge that changes the meaning of the concepts defined in the imported ontology. In our case, the definitions of the complex contexts C i must not imply new axioms that modify the semantics of the concepts in K C. This property is formalized in [73, 74] by applying the notion of conservative extension of a TBox, which is defined in [101]. Given two TBoxes T and T, T T is a conservative extension of T if, for every axiom α with S(α) S(T ) we have T T = α iff T = α. In our case, for the significance ontology to be safe, K S K C must be a conservative extension of K C. The authors improve this approach and study safety without taking into

110 4.3. Definition 106 account the whole imported ontology, but rather only the imported symbols (i.e. the external signature). Thus, an ontology K is safe for a signature S (w.r.t. the DL in which K is expressed) if for every ontology K with S(K) S(K ) S, K K is a conservative extension of K. In [74], it is proved that detecting if an ontology K is a safe extension of a submodel K (with K K) is 2NEXPTIME for ALCIQ, and undecidable for ALCIQO. Consequently, this task is also undecidable for OWL DL. However, sufficient conditions are stated to guarantee that the union of the importing ontology and the imported ontology is a safe extension of the imported ontology. These conditions, which guarantee syntactic locality, are syntactic restrictions on the possible axioms involving imported symbols. As proved in the paper, syntactic locality implies locality, and locality implies safety. In our case, we must assure the syntactic locality of C i and D j definitions, which will result in the significance ontology K S being safe. Recently, an methodology for ontology reuse based on these results has been proposed [130]. To avoid undesired collateral effects on the imported ontologies, the design of a CDS ontology can follow this procedure. Additionally, this methodology applies the idea of module (also described in [74]). A module is the minimum subset of axioms of the imported ontology that must be incorporated into the importing ontology to be able to infer the same knowledge that could have been inferred if the whole ontology had been added. In this way, the CDS ontology would only contain the minimal number of axioms from the context and the domain ontologies. This would improve the performance of the reasoning procedure as well. Other features Reusability. By definition, design patterns must be applicable to different problems and domain areas. Our pattern effectively fulfills this objective since it provides a general guideline for representing significance without imposing application-dependent restrictions on the domain and the context ontologies.

111 4.4. Context-aware reasoning 107 Standardization. One of the main prerequisites for the CDS pattern was OWL-DL compliance. In other words, the resulting ontology should not include new constructors nor be in OWL-Full. As explained, the pattern generates a new OWL-DL ontology, whose complexity is bounded by context and domain models. Thus, though the reasoning process may seem somewhat less than straightforward, current tools (i.e. DL inference engines) can be directly used, without having to extend, modify, or re-implement them. Expressivity. The pattern allows significance to be represented, and makes the most of OWL expressivity. For instance, σ-connection hierarchies can be defined to assert inclusion relations between them. Actually, the resulting model is an OWL ontology, and can be modified as needed. Further improvements may be easily incorporated, e.g. definition of several bridge properties with different semantics to qualify the connections between contexts and domain, or the addition of properties to profile classes. 4.4 Context-aware reasoning The main reasoning task involving a significance ontology consists in finding all the concepts in the domain ontology which ought to be considered in a given context. In this section, we describe a complete and decidable algorithm that performs this operation by carrying out basic DL inference tasks. Formulation Definition 5. Let K D be a domain-specific ontology, K C a context ontology, and K S a CDS ontology, with their respective signatures S(K D ), S(K C ), and S(K S ). Let scenario E be a concept E S(K C ). The domain knowledge in K D that is significant in the scenario E w.r.t. K S, denoted as D(E, K S ), is a set which includes the concepts I such that:

112 4.4. Context-aware reasoning 108 D(E, K S ) = {I I Con(K D ) K S = {E C n, P n,m P, I D m }} Essentially, we are interested in the concepts of the domain ontology that: are similar to the complex domains asserted to be significant to the complex contexts which are similar to our query. In this case, similarity is computed as concept inclusion 4. Thus, I stands for the concepts I defined in the domain ontology that are more specific than the complex domains D j which are σ-connected to the contexts C i more general than E. The domain significant in a scenario can be retrieved by performing several subsumption tasks: Algorithm 1. D(E, K S ) can be computed in practice as follows: 1. {C n } = {C n C E C n } 2. {P k,l } = {P k,l P (P k,l R c.c k ) (C k C n )} 3. {D m } = {D m D (P k,l R d.d l ) (D m D l )} 4. D(E, K S ) = {I Con(K D ) I D m } The output of the algorithm is the set {I} of simple domain concepts of K D which ought to be considered in the query context E. The reason to retrieve the I Con(K D ) and not simply D m is the following. We assume that the knowledge about the domain is only in K D, and D m are constructions built for the sake of convenience. Thus, it may occur that a 4 Interestingly enough, other similarity measures could be implemented. Measurement of similarities between ontologies is a topic that has been widely studied in the literature, particularly in the biomedical domain [166].

113 4.4. Context-aware reasoning 109 D m has no direct correspondence with a concept in the domain. Hence, the algorithm obtain the concepts of the domain that are similar (i.e. included) in D m. Since the definition of the significance ontology does not allow σ-connections involving anonymous contexts or domains to be created, steps 2 and 3 of the algorithm could be simplified as follows: {P k,l } = {P k,l P (P k,l R 1.C k ) (C n {C k })} {D m } = {D m D (P k,l R 2.D l ) (D m {D l })} Next, we present an example of the algorithm. Example 4.4 Domain significant to a context in Nomadic Healthcare. Given the σ-connections in Example 4.3, the question arises regarding which information of the HIS should be checked if the doctor is treating a hemorrhagic and unconscious patient with a penetration wound. This is accomplished by using Algorithm 1 to calculate the restricted domain of this complex context concept. E Hemorrhage Unconsciousness PenetrationWound 1. C n = {C 1, C 2 } 2. P k,l = {P 1,1, P 2,2 } 3. D m = { D 1, D 2 } 4. I= { HDRBloodPressureDisorder, HDRDrugIntollerance, HDRProcaineIntolerance, HDRPenicillinIntolerance} Once it is known which HDRs from the HIS are interesting, the concrete values for the patient may be retrieved. In this case, only records for

114 4.4. Context-aware reasoning 110 HDRProcaineIntollerance are available for the patient jgomez. So, the doctor will be reminded that patient jgomez is positiveprocaine. The example shows that descendants of E are not considered during the reasoning process. These concepts correspond to more specific context situations, which will probably lead to more specialized domain information. However, it may be interesting to calculate the σ-connections involving these subcontexts, and to provide them as feedback information to the user, who may be recommended to describe further details of the current scenario. Example 4.5 Additional results in Nomadic Healthcare. In this example, C 3 in P 3,3 is subsumed by E: C 3 Unconsciousness (Hemorrhage hasintensity.high) IrregularPenetrationWound Unconsciousness Hemorrhage IrregularPenetrationWound E Consequently, the doctor could be advised to carry out other clinical trials to see if the specific part of this restriction ( hasintensity.high qualifier of Hemorrhage) is present, but has not been diagnosed as yet. If this knowledge is subsequently supplied, more information about the patient (HDRCoagulationDisorder) will be considered significant.

115 4.4. Context-aware reasoning 111 Properties Decidability and completeness Proposition 3. Algorithm 1 is decidable and complete, i.e. concepts I related to the query concept E through σ-connections. it finds all the Proof. From the expressions in steps 1-4 of Algorithm 1, trivially every P k,l subsuming the (hypothetical) σ-connection P E,I linking E and I is retrieved. By definition, E C n C k n, k and I D m D l m, l. According to Proposition 1, we directly obtain that P E,I P n,m P k,l. Computational complexity The definition of the CDS ontology entails that P i,j definitions are (at most) in the DL ALC (in fact, they are in ALE) 5. Therefore, the computational complexity of the CDS model is mainly conditioned by the complexity of C i and D j expressions, the other concepts defined in the CDS ontology. The complexity of these concepts subsequently depends on the complexity of the ontologies K C and K D, which contains the definitions of the terms used to build C i and D j, and must be imported by K S. In the simplest case (i.e. K C, K D and K S ontologies are in ALC), reasoning within the CDS ontology is asymptotically bounded by concept subsumption complexity, which is EXPTIME-complete for ALC with GCIs, according to Table A.4. If we suppose that K C and K D do not add further complexity, it is possible to reduce the complexity of K D by restricting the allowed expressions for C i and D j, moving consequently to a less expressive logic (Table 4.6 [58]). Restricting negation to atomic concepts and disallowing union concepts would enclose the CDS ontology to ALE, which has PSPACE complexity for general 5 Notice that if the conditions for hierarchical CDS ontologies are assumed (Proposition 2), the complexity increases to ALCIF

116 4.5. CDS Plug-in for Protégé 112 reasoning. Another alternative consists on using only acyclic TBoxes, which would give complexities of PSPACE for ALC and CONP for ALE. Other choices are not appropriate, however. Moving from ALC to ALU does not reduce the complexity, either in the general case or with acyclic TBoxes. Moving to AL is not possible, because existential quantification cannot be restricted. Similarly, expressivity of FL is too limited. Table 4.6: Complexity of reasoning with TBoxes in basic DLs DL \ TBox Acyclic General FL PTIME PTIME AL CONP PSPACE ALE CONP PSPACE ALU PSPACE EXPTIME ALC PSPACE EXPTIME According to this formulation of the CDS pattern, role hierarchies are not necessary. Nevertheless, they may be considered for the sake of convenience, in such a way that subroles of R c and R d can be defined with particular semantics and handled in consequence. This increases the complexity to ALCH, but with the advantage that reasoning for the general case still remains EXPTIME. In any case, since ALCH and ALCIF are less expressive than SHIF(D) (equivalent to OWL-Lite), reasoning in practice with available DL engines (e.g. Pellet) will be quite efficient as they are highly optimized and worstcase inferences are infrequent. Hence, more complex logics with extended semantics could be considered as well to extend the basic formulation without significant performance impact. 4.5 CDS Plug-in for Protégé We have developed a plug-in for the Protégé platform, which allows users to create, edit, test and reason with a CDS ontology. Our plug-in adds a new tab

117 4.5. CDS Plug-in for Protégé 113 Figure 4.2: CDS Tab plug-in in Protégé IDE to the Protégé-OWL environment (Protégé enhanced with the OWL plug-in) where a simplified view of the CDS ontology is displayed and queries can be introduced. A preliminary version can be found in es/~jgomez/thesis/cdsplugin. The plug-in is based on the CDS-API, a library to programmatically manage models created with the pattern, which can also be downloaded. We can distinguish four sections in the tab, depicted in Figure 4.2: 1. Context section. The left side of the tab shows the context ontology (K C ) and the complex contexts (C i ) in the CDS ontology. The con-

118 4.5. CDS Plug-in for Protégé 114 text ontology can be optionally hidden. New complex contexts can be created by using the context vocabulary; existential restrictions for the new C i are automatically added. It is also possible to edit or delete existing contexts. 2. Domain section. The right side mirrors the context side, but instead of the context ontology, the domain ontology (K D ) is presented. New complex domains D i can also be easily created, and editing and deleting are allowed as well. 3. σ-connections. The central section of the tab shows the σ-connections in the ontology K S. This is probably the most interesting part, since it simplifies the task of creating new σ-connections. To build a σ- connection, the user has only to select a complex context in the left box (C i ) and a complex domain in the right box (D j ), and then push the new connection button. A new σ-connection (P i,j ) will be created as a subclass of the currently selected σ-connection, and the corresponding existential restrictions will be automatically generated. 4. Reasoning. The bottom section allows the retrieval of domain knowledge significant to a given context, i.e. it implements Algorithm 1. When a new complex concept for querying is created, its restrictions are shown and the run query button is activated. Results are displayed in the Results tab of this reasoning section and additional information about the obtained classes can be consulted. From the formal description of the pattern, it can be deduced that some additional configuration is needed to make the CDS plug-in work correctly: it is necessary to state the URIs of the external ontologies (K C, K D ); the top concepts for the σ-connections, the complex contexts, and the complex domains (P, C, D ); and the URL of the DIG reasoner to be used. To assist this procedure, a wizard-like window is presented to the user when the properties button on the top toolbar is clicked.

119 4.6. A fuzzy extension of the CDS pattern 115 The plug-in has been developed with the CDS-API and the APIs for Protégé and Protégé-OWl version Installation is very simple. As any other Protégé add-on, it just has to be copied to the plug-in directory of the Protégé installation. 4.6 A fuzzy extension of the CDS pattern Rationale The significance ontology resulting from applying the CDS pattern has two main deficiencies. Firstly, definitions of complex context concepts C i (respectively for definitions of complex domain concepts D i ) are crisp. As a result, it is not possible to directly represent vague contexts, e.g. the patient is slightly unconscious, and partial similarity between contexts, e.g. anaphylaxis is quite similar to sepsis. The second problem is that although the significance ontology allows the developer to assert which domain-specific knowledge is interesting in a scenario, it does not measure how important this connection is, which is desirable in some applications. For instance, in our example on Nomadic Healthcare, electronic registers about previous adverse drug events are more important than others, and should be presented firstly to the doctor because avoiding an anaphylactic shock is a major priority in healthcare. Ranking the relevance relations would allow system responses to be sorted by precedence and a threshold to be fixed in order to retrieve only the top k most relevant concepts of the domain ontology. In this section, we propose an extension of the CDS design pattern to: (i) deal with vague complex contexts and domains; (ii) quantify the importance of σ-connections. Our approach relies on Fuzzy Description Logics (fuzzy DLs), a logical formalism which combines Fuzzy Logic theory and Description Logics, and defines a sound framework to represent and reason with

120 4.6. A fuzzy extension of the CDS pattern 116 imprecise and vague knowledge in ontologies. A brief introduction to fuzzy DLs and further references are provided in Section A.5. The extension of the CDS pattern results in a fuzzy ontology. This extension allows fuzzy context and domain descriptions to be represented, and significance relations to hold to a degree. A suitable reasoning algorithm to retrieve the domain knowledge relevant in a given context is also proposed. Interestingly enough, though the fuzzy CDS ontology is not OWL compliant, previous results can be applied to reduce it to a crisp representation in order to use existing inference engines [39, 41, 40]. Definition The fuzzy CDS ontology extends the original proposal by allowing contexts, domains, and σ-connections to be defined by means of fuzzy GCIs. Thus, complex contexts (respectively complex domains) can be stated to be partially similar. Moreover, the degree of subsumption in a σ-connection definition represents the importance value of the link between the context and the domain. Definition 6. Let K D and K C be, respectively, the domain and the context ontologies; C i a fuzzy complex context; and D j a fuzzy complex domain. The fuzzy significance or fcds ontology which relates the set of pairs (C i, D j ) with degree α i, j (i.e. states that D j is interesting with rank α i, j when C i happens) is a consistent fuzzy ontology f K S = T S, R S, A S such that T S (non-exclusively) includes definitions for the fuzzy concepts P, C, D, C i, D j, P i, j, which satisfy: 1. P, C, D are the superclasses top σ-connection concept, top complex Context, and top complex domain : P i,j 1 P, C i 1 C, D j 1 D 2. R c is the (fuzzy) bridge property linking σ-connections and complex contexts:

121 4.6. A fuzzy extension of the CDS pattern 117 P 1 R c.c 3. R d is the (fuzzy) bridge property linking σ-connections and complex domains: P 1 R d.d 4. P i, j is the (fuzzy) σ-connection concept linking the complex context C i and the complex domain D j : P i,j αi,j R c.c i R d.d j It is interesting to note that the context ontology K C and the domain ontology K D may be fuzzy or not. However, both C i and D j are fuzzy concepts because they are defined with fuzzy GCIs. Next, we show a fuzzy relevance ontology built from two crisp ontologies K C and K D. Example 4.6. Continuing our example, we can use the same crisp domain and context ontologies described in Examples 4.1 and 4.2. Some axioms which were not included in these examples are presented below. Crisp axioms which extend the domain ontology K D : HDRCurrentPrescription HDR HDRAntidepressives HDRCurrentPrescription (jgomezehr2 : EHR) ((jgomezehr2, jgomez) : relatedtopatient) (prozac: HDRAntidepressives) ((jgomezehr2, prozac) : composedof) Crisp axioms which extend the context ontology K C : Anaphylaxis galen:anaphylaxis Shock galen:shock Elderly hasage.trap{60, 75, 120, 120} EpinephrineAdmin galen:treatment

122 4.6. A fuzzy extension of the CDS pattern 118 The CDS ontology f K S contains definitions for C i, D j, and σ-connections that were created with fuzzy GCIs. In this case, fuzzy C i denote vague descriptions of patient situations. D j are also fuzzy concepts, but they are assigned a crisp semantics, since they correspond to the pieces of information represented in the HIS. Additionally, some new fuzzy axioms are introduced to state similarities between context concepts. These axioms could be introduced in K C to make it into a fuzzy ontology, but we have preferred to maintain the context and the domain base ontologies unaltered. An excerpt of the (simplified) f K S is shown below. Axioms which extend the context ontology Anaphylaxis 0.7 Shock SepticShock 0.5 Anaphylaxis Shock 1hasComplication 0.8 EpinephrineAdmin Definition of complex contexts C 1 1 hascomplication.elderly C 2 1 Anaphylaxis C 3 1 EpinephrineAdmin Definition of complex domains D 1 1 EHRCurrentPrescription D 2 1 EHRCurrentPrescription EHRDrugIntollerance D 3 1 EHRAntidepressives D 3 1 D 1 Definition of relations (for the sake of convenience) R a relsymptom R b relregister Definition of σ-connections P 1,1 0.6 R c.c 1 R d.d 1

127 4.6. A fuzzy extension of the CDS pattern 123 If the outputs of the algorithm are aggregated, the final results provided to the user are: (EHRCurrentPrescription, max(0.7, 0.7) = 0.7), (EHRDrugIntollerance, 0.7), (EHRAntidepressives, max(0.7, 0.7, 0.7) = 0.7). These results mean that the system alerts the doctor, and tells him to check the patient information about current prescriptions, especially those concerning antidepressive drugs, and past diagnoses of drug intolerance. All the recommendations are equally important with degree 0.7. Once the patient is identified, the concrete instances of these classes of the ontology can be obtained from the ABox A D. In this case, for the patient jgomez, the doctor is advised that the patient has a prescription of prozac and an intolerance to procaine. Properties Proposition 4. Algorithm 2 is complete, i.e. it finds all the concepts I related with E through σ-connections and the degree of this connection. Proof. The expressions of Algorithm 2 show that the retrieved P k,l, C n, D m are the same as in the crisp case. The only difference in respect to the previous algorithm is the computation of β values. We assume in this proof that the Gödel implication is used to define the semantics of GCIs and the t-norm is min, though it can be easily extended to other families of fuzzy operators. Therefore, based on proof of Algorithm 1 and Definition 7, we have merely to prove that β k,l = β k β l is equal to glb(p k,l R c.c k R d.d l ), the degree of the relevance relation between C k (a superclass of E) and D l (a superclass of I). Using the properties of fuzzy sets, we know that (A B C) α implies (A B) α and (A C) α, for some t-norm and its residuum-based im-

128 4.6. A fuzzy extension of the CDS pattern 124 plication (for example, for min t-norm and the Gödel implication). Applying this expression to our GCI, P k,l βk,l R c.c k R d.d l P k,l γ1 R c.c k (γ 1 β k,l ) and P k,l γ2 R d.d l (γ 2 β k,l ). From Algorithm 2, we have the glbs β k and β l. Since they are the greatest lower bounds, β k γ 1 β k,l and β l γ 2 β k,l. Consequently, β k β k,l β k,l β k β, for any β, and β l β k,l α k,l β l β, for any β. On the other hand, for min t-norm and the Gödel implication, (A B) α 1 and (A C) α 2 imply (A B C) α 1 α 2. Applying this expression to the GCIs of Algorithm 2, P k,l β k R 1.C k and P k,l β l R 2.D l, we have P k,l β k β l R 1.C k R 2.D l. By definition, β k,l β k β l. Consequently, β k,l β k β l and β k,l β k β l, so necessarily β k,l = β k β l. Computational complexity. An upper bound for the computational complexity of the reasoning procedure can be deduced from the research studies [39, 41, 40], where fuzzy ontologies in f SHOIN and f SROIQ have been proved to be reducible to crisp ontologies. Therefore, the overall complexity of retrieving the α-significant domain concepts w.r.t. a fuzzy significance ontology is asymptotically bounded by the complexity of the reduction plus the complexity of the reasoning within the crisp ontology. The mentioned contributions show that the complexity of this reduction for a f SROIQ ontology with Zadeh operators and the Gödel implication for GCIs (the top complexity level considered in this work) is quadratic (in space) with regard to the number of degrees used in the ontology 6. Algorithm 2 calculates a considerable number of glbs (at least, one for each retrieved concept in Steps 1-4). The computation of each glb needs at most log(n) subsumption tests, where N is the number of degrees of the 6 This complexity can be cut down to linear if a fixed number of degrees is assumed. Moreover, under certain conditions (i.e. new axioms do not introduce new atomic concepts, new atomic roles, or new degrees of truth), this reduction can be performed only once, and this overhead can be avoided.

129 4.6. A fuzzy extension of the CDS pattern 125 fuzzy ontology [246]. In the simplest case, the CDS ontology is in f ALC, which implies that the complex context and the domain expressions are (at most) in ALC; the number of degrees is fixed; and the fuzzy CDS ontology does not need to be reduced. If we assume this situation, the complexity of Steps 1-4 is upper-bounded by Con( f K S ) log(n) times the subsumption test complexity (EXPTIME for ALC). According to this result, despite the optimizations applied, reasoning with the fuzzy relevance ontology has a high computational complexity. Nevertheless, it is generally assumed that the worst cases are very infrequent in DL reasoning. Thus, as practical experiences show, the overhead produced by the fuzzy extension of the CDS pattern is assumable, and the use of fuzzy significance relations is recommended in applications that require higher descriptive power. This is the case of the Nomadic Healthcare use case, implemented in the IASO system described in the next chapter. However, in its current version the knowledge bases of IASO were built by applying the crisp CDS pattern. The use of the fuzzy approach remains to be explored in future work.

130 CHAPTER 5 A Knowledge Mobilization Application: the IASO System This section describes the IASO system, a mobile application based on the principles of Knowledge Mobilization. IASO solves the Nomadic Healthcare KMob use case presented in Chapter 2. It also shows the usefulness of the architecture and the knowledge representation model created as part of our doctoral thesis. 5.1 Problem description In the first chapter of this dissertation, we presented the Nomadic Healthcare KMob use case (Section 2.3). In this section, we give a detailed description of the design and the implementation of IASO, a prototype of a KMob system that solves the Nomadic Healthcare problem. IASO is a proof-of-concept system since it demonstrates the validity and usefulness of the contributions of Chapter 3 (the KMob architecture) and Chapter 4 (the CDS model). The example of the Nomadic Healthcare use case is the following. Dr. Greg is caring for a patient outside the hospital. He is equipped with a 126

131 5.1. Problem description 127 portable device, and wishes to consult the Hospital Information System (HIS), where the patient s clinical history is stored, with a view to prescribing a treatment for him. For instance, Dr. Greg should know whether the patient has been previously diagnosed as having an allergy to anesthetic drugs. By no means does he wish to receive the patient s complete history because he would be unable to review all the records available in the system. In fact, most of this data would be irrelevant, given the current situation of the patient and the type of treatment needed. The IASO system that we designed is capable of accomplishing this task and providing the doctor with precisely the information required. Thus, IASO delivers customized summaries of the most relevant clinical data in the patient s medical history to the doctor so that he can decide on the best treatment. The contents of these summaries depend on the current state and situation of the patient, which is introduced by the doctor as the input of the application. The new application provides answers to questions such as what should I know about this patient? and should I perform further clinical tests?. In this case, we use the data stored in the HIS of the Hospital Clínico San Cecilio of Granada. This system stores the clinical histories of the patients of the hospital. A clinical history is the sum total of all the electronic health records generated as a result of the healthcare services received by a patient. In other words, a patient s history includes all the information concerning his previous and current clinical treatments, diagnoses, and prescriptions. The system relies on a database which links one clinical history to each patient. Information is stored in registers, and the registers are organized in electronic documents. Documents are classified depending on the medical specialization that they are related to. The structure and contents of documents are defined with in terms of templates, which specify which data fields must be filled to generate a document. Figure 5.1 shows the logical structure of the database of the hospital. It should be pointed out that the system implemented by the Hospital is

133 5.1. Problem description 129 The San Cecilio HIS is a client-server application specifically developed for this hospital. Physicians can use the software to retrieve patients histories by using the PCs in their offices. The HIS implements a security policy that prevents doctors from accessing information generated by procedures carried out in medical specializations other than their own. In order to guarantee data integrity and security, the system has a password-based identification mechanism. The current system behaves reasonably well in situations in which the doctor has sufficient time to manually consult, filter, and extract useful information from the stored electronic documents. Nevertheless, problems arise in two situations: (i) when the system must be accessed from outside the hospital; (ii) when the doctor does not have enough time to review the information provided, or when the information cannot be processed. The first problem can be solved by implementing a gateway to access the HIS from outside the hospital. This is relatively easy to do if security issues are not considered. For instance, a Web interface that replicates query forms would allow remote access with different tools, including mobile devices. However, the second issue is more difficult to resolve since more knowledge must be added to the system to avoid information overload (see Section 4.1). A knowledge base stating which clinical data is relevant in a given patient situation must also be created. Data summaries would be composed when the user consults this knowledge base. IASO elegantly solves both of these problems. The IASO application has the characteristic features of KMob systems. It is a ubiquitous system, since application services can be accessed from anywhere, at anytime, and with any device. The system must behave in consonance with the context of use, and discover which information is needed by the doctors in each case. Doctors do not need to tell the system how this information can be retrieved since the system is capable of automatically inferring it. As already mentioned, in this application, it is particularly important to be concise and to summarize the available data in order to avoid information overload. Last but not least, the system has to integrate heterogeneous information sources

134 5.2. Related work 130 as well as different communication technologies. Consequently, we applied the KMob principles, methodologies, and tools analyzed in this thesis. The system was designed by specializing of the architecture presented in Chapter 3. The implementation was carried out by using the technologies described in that chapter. The knowledge base that supports the creation of the context-dependent summaries was created by relying on the design pattern proposed in Chapter Related work The management of the clinical data of patients has always been a principal focus of interest in Medical Informatics. However, two problems which arise in this area are data storage and data retrieval. Effectively solving both problems is crucial for providing better healthcare services. The acquisition and storage of clinical data has been extensively studied since the appearance of the first information systems. Currently, there are various interesting proposals that target the creation of standards for electronic health records (EHRs) [84]. One of the most recent of these initiatives is OpenEHR 1, which claims to improve the previous specifications for EHR management systems. OpenEHR defines ADL (Archetype Description Language), a language for describing the medical concepts that can be represented in an HIS [10]. These concepts are called archetypes. For example, the archetype blood pressure, which includes the values of the systolic and the diastolic blood pressure, the place where the measurements have been obtained, and the device which has been used, can be defined with OpenEHR. A list of possible ADL archetypes can be found at the OpenEHR website 2. The retrieval of clinical data is the other problem that HIS research work is currently trying to solve. Retrieval does not only involve querying HIS 1 2

135 5.2. Related work 131 databases, which is performed with suitable consultation languages (e.g. EQL for OpenEHR). It is also necessary to understand the data obtained. A standard for EHRs does not completely solve this issue because the requester may not know what the values mean. If the requester is a human user, he will probably be able to decipher this data, but if the procedure is automatic, interpreting such data is almost impossible. This is especially problematic when systems using different representation models are obliged to understand each other. In order to support interoperability and exchange of data, the meaning of the terms used by each organization must be well-defined and published. As a result, there is much research now in progress, whose objective is to endow HIS data with semantics. Adding formal metadata to describe HIS registers allows the patients data to be automatically processed. These metadata must be incorporated at two levels: (i) the level describing EHR meaning; (ii) the level describing EHR contents. The first of these objectives is achieved by using an EHR metamodel. For instance, OpenEHR primitives are formally characterized in the OpenEHR UML model. The OpenEHR metamodel has been translated to OWL in such a way that archetypes can be specified by using an OWL ontology [30, 143, 222]. The second objective is part of the more general problem stemming from the formal description of terms used in Medicine. As it is well-known, this is one of the most frequently studied application domains of ontologies. It is beyond of the scope of this work to provide a review of medical ontologies. Important medical ontologies such as UMLS [45], Galen [221], and SNOMED-CT [70], which were originally coded in other representation languages, have now all been translated to OWL. There is a considerable number of contributions that offer solutions for HIS remote access. Some of them even use portable devices [82, 110]. With the rise of Web technologies, this problem has been successfully solved. The main challenge for the developers of these systems is to guarantee security

136 5.3. Design 132 and integrity of the data, which is especially important given the high degree of privacy required for medical records. To the best of our knowledge, there is little or no significant research on the automatic summarization of patients clinical histories for on-line consultation. Nevertheless, this facility has been stressed by some authors as a very interesting feature for HISs to have [102]. We strongly believe that contextdependent summarization will not only be desirable, but essential in order to make the most of the large medical data warehouses that will be available in the very near future. 5.3 Design The KMob system developed to meet the requirements explained in Section 5.1 is called IASO 3 (Intelligent ASsistant for Outdoors healthcare). IASO allows nomadic users to access the HIS of the Hospital Clíinico San Cecilio. Users, equipped with mobile devices, provide a description of the clinical situation of the patient and his identifier, and the system infers which information of the HIS ought to be made accessible. Thus, in order to avoid information overload, the resulting information is a summary of the available data for the patient. To create this system, we had to successfully accomplish the following tasks: 1. The construction of a knowledge model capable of describing which subset of the data stored should be considered in a given scenario. 2. The implementation of the software that delivers this information to the (doctors ) mobile devices. 3 Iaso (also Iaso Tholus or Jaso ; in Ionic Greek, Ieso ) was the Greek goddess of recovery from illness. Iaso was the daughter of Asclepius and had three sisters and a stepsister: Panacea, Aceso, Aglæa-Ægle and Hygeia. Iaso helped sick people together with Panacea, Aglæa and Hygeia.

137 5.3. Design 133 IASO knowledge base The IASO knowledge base was created by applying the crisp version of the CDS design pattern. We developed three OWL ontologies that abstractly represent: (i) the data registers of the clinical histories managed by the HIS (the domain); (ii) a vocabulary to describe the patients clinical situations (the context); (iii) links stating that certain data registers are significant in a given situation (the σ-connections). Figure 5.2 illustrates the relations between these three ontologies. The contents and the structure of the ontologies are extensions of the (OWL translation of the) examples included in Chapter 4. Figure 5.2: Schema of the IASO context, domain, and significance ontologies Hospital Information System Clinical Situations Domain HIS Abstract Model I Patient Situation Description Model Context D m I P n,m C n E Context-Domain Significance Model As mentioned in Chapter 4, it is possible to reuse existing ontologies to build the context, domain, and significance models. We used the OWL translation of the Galen ontology [218], available in the Web 4, to create the Pa- 4

138 5.3. Design 134 tient Situation Description Model. A local copy of Galen was imported from this ontology. Likewise, a standard EHR representation model could have been used to develop the domain ontology. Nevertheless, since the HIS database has a very idiosyncratic structure, we decided to build the domain ontology from scratch. The HIS Abstract Model includes concepts that model patients, clinical histories, medical specializations, electronic documents, etc. The instances of these concepts are the concrete values stored in the HIS. This signifies that it would then be necessary to import instance data from the HIS to the HIS Abstract Model. We solved this problem by implementing a bridge between this ontology and the HIS in such a way that HIS data is retrieved on demand as ontology instances. This solution is explained in Section 5.4. In this version of the IASO CDS ontology, σ-connections have been created by relying on the advice of experts in the field and specialized bibliography. In the future, we plan to study if it is possible to semi-automatically build the CDS ontology by relying on formal medical guidelines. The resolution of a query with the IASO CDS ontology consists of the three stages explained in Example 4.4. Firstly, a description of a patient situation (created in terms of the Patient Situation Description Model) and the identifier of the patient are provided by the user. Secondly, using this description as the input, the algorithm capable of inferring the domain significant to a context (Section 4.4) is executed. The result of the algorithm is a set that includes the concepts of the HIS Abstract Model which are regarded as significant. Thirdly, the instances of these concepts that correspond to the patient are retrieved. These values are the final output of the query resolution process. IASO architecture The IASO architecture instantiates the abstract architecture proposed in Chapter 3. We chose a client-server communication schema to organize the appli-

139 5.3. Design 135 cation. Accordingly, client-server technologies were used to implement IASO, as explained in the next section. We believe that the client-server pattern is the most suitable for this system. The most important reason for this is that the query resolution process is too complex to be executed with a mobile device. The mobile agent should manage a DL reasoning engine and a full version of the CDS ontology, including instances, to completely resolve any query. This is not currently viable. Therefore, the mobile agent only knows the Patient Situation Description vocabulary, and is the desktop agent who carries out the query-resolving process. Since client and server roles are clearly identified, the client-server paradigm is a natural way of structuring the system. Figure 5.3 shows the Society Diagram of the IASO application. It depicts the Nomadic Agents, Desktop Agents, Services, and Knowledge Models of the system. The IASO Client Agent is a Nomadic Agent that runs on the users mobile devices. It manages a copy of the Patient Description Model, which is used to create the descriptions of the clinical situations that are sent as part of the queries to the IASO Server Agent. This client agent offers a friendly interface to introduce these descriptions. Once a query has been introduced, the client agent acquires the IASO Client role. This role encompasses all the functions aimed at: (i) requesting the IASO Query Service; (ii) processing the results of the query to present them to the user in a suitable format. The IASO Query Service is the service that processes user queries. The input of this service is a description of a concept built with the Patient Description Model vocabulary and a patient ID. The output of the service is a set of concept descriptions corresponding to the significant registers retrieved and the instances of these concepts 5. The IASO Server Agent is a Desktop Agent that runs on an application 5 This ontological data is expressed with the HIS Abstract Model. Therefore, it might also be useful to manage a copy of the HIS Abstract Model in the IASO Client in order to interpret the results. However, we consider that the results should be interpreted by the user, who is an expert in the area.

141 5.4. Implementation 137 server. When this agent acquires the IASO Server role, it provides the IASO Query Service. In order to solve IASO Clients queries, the IASO Server Agent manages the IASO CDS Ontology, which relates the descriptions created by means of the Patient Description Model ontology with sets of HIS registers modeled by using the HIS Abstract Model. Worthy of mention is the participation of the San Cecilio HIS in the system. This is an External Knowledge Model, and consequently, it is modeled as an external agent. As commented in the previous sections, the instances of the HIS Abstract Model must reflect the contents of the HIS. Therefore, there is a dependence relation between the ontology and the HIS itself. 5.4 Implementation We developed a proof-of-concept prototype of the IASO system described in the previous section [42]. This prototype is available at es/8084/iasotest/entrypoint. The prototype simplifies the design of IASO by assuming that the ontologies and databases that participate in the system are reduced versions of the complete ones that would be used in a practical implementation. Thus, the architecture of the IASO prototype is the one depicted in Figure 5.3, but the size of the context, domain, and CDS ontologies, as well as the HIS database, has been reduced. More precisely, the simplifications in the prototype are the following. First, the CDS ontology contains only a few σ-connections. Secondly, the simplified version of the HIS database only reflects the clinical histories with one medical specialization, which is implicitly represented. This database only contains certain test values, which allowed us to sidestep security and privacy issues. Thirdly, the HIS Abstract ontology only models the information stored in this simplification of the HIS. Apart from these considerations, the prototype offers all the features that the complete IASO system would

142 5.4. Implementation 138 provide. The prototype can be easily extended, and the analysis of its properties can be inductively generalized to the eventual complete system. The IASO architecture was implemented by using the client-server technology framework proposed in Section 3.4. More specifically, we developed the IASO prototype as a Web-based application. The clients and the server communicate with HTML forms that are transmitted with the HTTP protocol. Figure 5.4 shows the technologies applied to implement the IASO prototype. The IASO Client Agent is a Web browser that can access to the Web pages created by the IASO Server Agent. Thanks to this simplicity, this implementation of the client guarantees that most mobile devices can participate in the system, despite their computational limitations, as long as they are able to access the Web. The IASO Server Agent provides an access point to the query-resolving service throughout an HTML form. This form allows the client to introduce a query and send it to the server. The query format in this implementation is an ad hoc ontology expression though it could be serialized to one of the possible OWL syntaxes. The IASO Server Agent receives and solves queries with the knowledge available in the IASO CDS Ontology and the HIS Database. In order to manage the CDS ontology, the server uses the CDS API, which implements Algorithm 1, and a DL inference engine (Pellet). The IASO Server Agent application runs on an Apache Tomcat Web server. In order to minimize the drawbacks of the HTTP interaction, the IASO Server Agent was implemented with JSF and AJAX technologies. The JSF distribution used in the prototype is the open source library Apache MyFaces 6. Since MyFaces supports AJAX, the IASO Client Agent can execute complex Javascript code. The use of JSF and AJAX in our prototype facilitates the creation of an attractive interface that clearly presents the input and the output information in the user s mobile device. The Local Knowledge Model of the IASO Server Agent is composed of the three previously mentioned ontologies: HIS Abstract Model, Patient De- 6

144 5.5. Execution 140 scription Model, and IASO CDS Ontology. These ontologies can be published in the same application server where the IASO Server Agent runs or in another Web server, since the CDS API transparently manages either local or remote ontologies. In this implementation, they were deployed in a second Apache web server 7. An outstanding feature of the knowledge base in the prototype is the presence of the SQL Bridge. This bridge is responsible for transparently retrieving data from the HIS database as if they were instances of the ontology, but without actually importing them. In this way, the register contents of the HIS do not need to explicitly be part of the HIS Abstract Model. The SQL Bridge was implemented by using D2RQ, a toolkit to describe mappings between relational databases and OWL/RDF(S) ontologies and to manage the resulting models. D2RQ is described in Section B.4. The SQL Bridge avoids two important problems. On the one hand, synchronization between ontology instances and database values is not required, which is a costly process. On the other hand, ontology inference procedures are more efficient, since the time and memory needed to reason with such a large ontology would be excessive. 5.5 Execution The IASO prototype execution process is the following: 1. A user, equipped with a portable device that can access the Web throughout a wireless or cellular network, launches the Web browser (IASO Client Agent) and downloads the HTML query form from the server (IASO Server Agent). 2. On the form, the user describes the situation of the patient by using terms of the Patient Description Model. Before sending back the query form, the user also introduces the patient ID. 7

145 5.5. Execution On receiving the query, the server transforms the description of the clinical situation of the patient. The transformed description is used as the input of the implementation of Algorithm 1 provided by the CDS ontology. The result of this procedure is the set of concepts from the HIS Abstract Model that are relevant. 4. The server uses the SQL Bridge to retrieve the instances of the relevant concepts from the HIS database. 5. The resulting information is conveniently formatted and sent back as an HTML form to the user. Figures 5.5 and 5.6 show two screens corresponding to the input and the output forms of the IASO prototype, respectively. These pictures were obtained by solving Example 4.4 with the IASO prototype at ugr.es/8084/iasotest/entrypoint. The Windows Mobile 5 emulator and the Opera Mobile navigator were used to access the system. Figure 5.5 presents the input form. On the left (A), the available terms are listed, whereas on the right (B), the introduced query is shown. The description of the clinical situation depicts a patient, named Juan Gomez, who is unconscious, hemorrhagic, and has a penetrating wound (the terms are interpreted conjunctively). Figure 5.6 shows the results obtained for this query. The clip icons (A) represent the concepts of the HIS abstract model that are relevant. In this case, the significant registers are those related to blood pressure disorders, drug intolerance, procaine intolerance, and penicillin intolerance. The ok bullets (B) represent instances of these concepts retrieved throughout the SQL Bridge, i.e. the values of the HIS database corresponding to the relevant registers associated with Juan Gomez. For instance, the value of the register ProcaineIntollerance is Procaine allergic. The warning bullets (C) provide further information about this query. More precisely, this is a list of clinical situations that are more specific than the one described in the query. These more specific clinical situations might

146 Figure 5.5: Input form of the IASO prototype 5.5. Execution 142

147 Figure 5.6: Output form of the IASO prototype 5.5. Execution 143

148 5.5. Execution 144 be considered in subsequent consultations. In the example, in the query the doctor may consider adding the qualifier High to the hemorrhage symptom, because patient data is available that is relevant to this situation. As expected, the architecture and the context-dependent knowledge representation model proposed in this thesis provide excellent support for the development of an application that solves the Nomadic Healthcare KMob use case. The IASO application and the prototype implemented show that both of them are valuable contributions to KMob.

149 CHAPTER 6 Conclusions and Future Work As part of our research, we studied Knowledge Mobilization, a research area aimed at providing integral solutions for the challenges that arise when developing mobile systems for the delivery of knowledge retrieved from large information sources to nomadic users. The general objective of this research is the investigation of theories, techniques, and tools that facilitate this process. More specifically, we found potential solutions for two computational Knowledge Mobilization problems: (i) the access and distribution of heterogeneous knowledge in mobile systems; (ii) the overload of information that users experience if all the available knowledge is delivered to their mobile devices. We have seen that contributions from areas such as Distributed Artificial Intelligence, Ubiquitous Computing, Semantic Web, Soft Computing, or Mobile Computing, can help to achieve successful Knowledge Mobilization. Chapter 2 fulfills the first of our objectives, which was to further develop the concept of Knowledge Mobilization (or KMob). In this chapter, we examined previous definitions of Knowledge Mobilization, and specified the features of KMob systems. Despite the many approaches for the development of intelligent mobile systems, none really provides a satisfactory solution for the problems mentioned above. Moreover, the plethora of existing technologies 145

150 Conclusions and Future Work 146 and the heterogeneity of mobile platforms and devices make the development of such systems even more difficult. On the basis of our findings, we proposed a new architecture that describes the structure, relations, and entities of a KMob system. We provided a general definition of a KMob architecture, which can support different configurations, communication schemas, etc. It goes without saying that the requirements of mobile systems can vary considerably, and strongly depend on the applicacion domain. The architecture described in Chapter 3 fulfills the second objective of this thesis, which is directly related to the problem of distribution of knowledge in mobile systems. The use of the AML language in the specification of the architecture makes it both comprehensible and reusable. Along with the architecture, we studied various current technologies that can be applied to implement KMob systems. We classified these technologies in three frameworks, which correspond to three different system archetypes. The frameworks target the coordination of system entities (multi-agent approach), interchange of knowledge (tuplespace approach), and delegation of tasks (client-server approach), respectively. We also dealt with the problem of information overload in knowledgeintensive systems, and especially in KMob systems. We determined that information overload can be overcome by using contextual knowledge to customize system answers to user environment. Consequently, we proposed a design pattern (the CDS model) to create significance ontologies, which are knowledge bases that state which information is relevant in a given context. Significance ontologies can be used to create summaries containing only context-relevant knowledge. This is accomplished by reasoning with an associated inference algorithm. Thus, the third objective of the thesis is attained with the CDS pattern presented in Chapter 4. Furthermore, we implemented two tools to create and manage significance ontologies, namely the CDS Java API and the CDS plug-in for Protégé. These tools offer additional support to KMob system developers. As an im-

151 Conclusions and Future Work 147 provement of the CDS pattern, we proposed an extension that allows fuzzy significance ontologies to be created. This extension permits the representation of fuzzy contexts and domains, which is very useful in several application domains. The fuzzy CDS pattern allows imprecise context and domains to be represented, and ranking of significance relations. The KMob architecture and the significance ontologies are an integral approach to KMob systems development. This assertion was demonstrated in Chapter 5, where the design and the implementation of a KMob system is described. The IASO application is a system that solves the Nomadic Healthcare KMob use case. IASO is based on the abstract architecture that was specified, and relies on a knowledge base that follows the CDS design pattern. Additionally, a prototype of IASO was implemented by using the client-server technology framework. Thus, IASO is evidence that these two results are valid, which is the last (but certainly not the least) of our objectives. Since the sub-objectives of this thesis were fulfilled we can affirm that the general objective was also achieved. We studied two important problems that arise in knowledge-intensive mobile systems, namely knowledge distribution and information overload, and we proposed valid solutions for them. The solutions presented in this thesis have certain limitations though in our future research we already envision ways to improve and significant enhance them. Likewise, new research lines have come to light as the result of this work. Actually, another important contribution of this research is that it opens the door to an extremely promising field of study. From a general point of view, our proposals do not target a specific domain though they have been tested in the Nomadic Healthcare use case. Without any loss of generality, the abstract architecture, the examples of the CDS model, and the knowledge base were specifically implemented in the IASO system. However, these results could just as usefully been applied to other application areas. The KMob architecture could be improved by specifying in greater detail the orchestration and choreography of agents and services, which at the

152 Conclusions and Future Work 148 moment is mainly left to the application designer. Orchestration defines the external services that are required by services to fulfill a task, whereas choreography establishes how messages are created and exchanged to request a service. These two features could be specified by using AML Protocol Sequence and Protocol Communication Diagrams. In addition, the description of service features with a semantic language should be considered. Semantic Web Services are a recent technology that proposes adding formal metadata to Web Services in such a way that services can be automatically located, invoked, and integrated (see Section B.5). Semantic Web Services can be incorporated into our architecture with relative ease, and this would be another interesting direction for future work. Nowadays Semantic Web Services is a very active topic of Semantic Web research since the W3C has not as yet published a specification. Further studies concerning the knowledge representation model are also needed, and would be a very enriching research goal. For instance, as already mentioned, the context-dependent reasoning performed with significance ontologies is similar to the inference procedures of certain variants of classic Logic. Thus, the relation of context representation models and other formalisms, such as temporal and non-monotonic logics, should be explored with a focus on whether they can be mutually reduced. Independently of the CDS pattern approach, the creation, publication and promotion of best practices for Semantic Web ontologies is essential for the advancement of Semantic applications. In this regard, it is worth mentioning that ontology patterns could be described with a formal ontology language and published in a publicly available repository. Further research on the fuzzy extension of the CDS design pattern should also be carried out. We strongly believe that the ability to reason with fuzzy context descriptions is an important contribution of this model, and it could be exploited in different scenarios. Other minor aspects to be developed are: (i) the extension of the CDS Protégé plug-in to facilitate the creation of fuzzy significance ontologies, which are currently not supported; (ii) the refinement of the reasoning process with fuzzy significance ontologies, which

153 Conclusions and Future Work 149 is computationally complex. In the near future, we expect to continue working on the IASO system and to continue improving the current prototype. It will thus be necessary to extend the domain, context, and significance ontologies in order to better represent the data of the San Cecilio HIS, the eventual patient situations, and the medical protocols that determine which procedures should be used in each situation. A major challenge will be to guarantee the security and integrity of communications between components of the system, given that medical information should be private. In conclusion, there has been very little research on intelligent mobile systems. Mobile technologies have obviously changed the way that information is delivered in the same way that network technologies did in the previous decades. Nevertheless, mobility is much more than a set of new technologies for the transmission of information. Mobility entails a paradigm shift that is closely related to today s necessities of nowadays (it both increases them and resolves them). Immediacy, massiveness, location-independence, or context-awareness are problems that Computer Science can solve, or at least mitigate, with intelligent software. Thus, in order for system users and developers not to be overwhelmed in the mobile age, suitable knowledge models, methodologies, architectures, supporting tools, etc. for intelligent mobile systems need to be developed. This is precisely what we promised to do in our doctoral thesis, and it is what we have accomplished as shown by our proposals and the results obtained in our research.

154 APPENDIX A Ontologies and Description Logics This appendix focuses on ontologies, a widely-used knowledge representation formalism, and its close relation with Description Logics, a family of logics for representing structured knowledge. First, ontology fundamentals are presented, followed by a brief introduction to the representation of knowledge and reasoning with Description Logics. We then describe ALC, the Description Logic used in our research. The appendix concludes with a short note on fuzzy Descriptions Logics. A.1 Background Artificial Intelligence investigates Intelligent Systems (IS), defined as computational systems aimed at solving complex problems by using algorithms inspired in intelligent human problem-solving methods when classical techniques fail [223]. Knowledge Engineering is a subtopic of Artificial Intelligence that is concerned with Knowledge Representation (KR), the study of how the agents of an IS manage what they know before deciding what to do [51]. In this context, intelligence is achieved reasoning, namely, the ability to automatically infer implicit conclusions from explicit knowledge. 150

155 A.1. Background 151 Representing knowledge basically consists of writing descriptions of the entities of a domain using the symbols of a language. Since computational KR requires these descriptions to be interpretable by a computer, representation languages must be formal, i.e., they must have a well-defined specification. First Order Logic (or Predicate Logic) was the language initially used in KR. Unfortunately, representation of knowledge using First Order Logic poses certain problems. For example, its verboseness makes it tedious and unintuitive. Considerably more important is the fact that according to Church and Turing theorems, reasoning about general First Order Logic formulas is a semi-decidable process: it cannot be known if the algorithm which finds if a predicate is true will finish for one that cannot be satisfied. Verbosity has been overcome by creating other representation languages. Generally speaking, even though these languages are not more expressive than First Order Logic and may not even have a logical substratum, they allow knowledge to be acquired and managed more easily. This group includes cognitive models, and more specifically, network-based models [160]. The second limitation, undecidability, was handled by only considering decidable and complete subsets of First Order Logic. Decidable means that all inferences will finish in a finite time period, and complete means that all entailments are guaranteed to be computed. The primary motivation of Description Logics is to characterize different families of logics which, depending on their expressivity (i.e., the primitive constructors allowed), encompass certain computational properties. Two additional difficulties in current IS are the following: (i) the necessity of having a huge amount of distributed and heterogeneous information sources that must be incorporated to the knowledge model of the system in order to have the most complete, up-to-date information; (ii) the convenience of reusing previous knowledge bases in order to minimize the effort of developing a new application. Ontologies are a knowledge representation formalism aimed at dealing with all these problems, since, as shall be explained, they possess the intu-

156 A.2. Definition 152 itiveness of cognitive models; provide a formal semantics based on Description Logics; and promote information integration and knowledge reuse. A.2 Definition The term Ontology comes from Philosophy, which defines it as the study of part-of relationships and entity dependencies [56]. Ontology as a science analyzes the features of possible things, and the categories in which they can be included. In Knowledge Engineering, the concept of Ontology has evolved over the past decades. There is now a consensus of opinion that an ontology is a rigorous and exhaustive conceptual schema, focused on a certain domain and designed to facilitate information communication and reuse among different computational systems. Ontologies are considered to be a proper formalism for the representation of knowledge in modern IS [64], and are one of the most frequently used models nowadays. Actually, they have been proposed for the support of metadata management in the Semantic Web [27], and not surprisingly, we use ontologies in this work for representing knowledge in KMob applications. One of the most widely cited definitions of ontology comes from Studer, Benjamins, and Fensel: an ontology is a formal, explicit specification of a shared conceptualization (in [250], based on [105] and [48]). The authors state that an ontology is a knowledge model which describes from a common perspective the objects in a common domain using a language that can be processed automatically. This language is usually 1 a Description Logic-based representation. Since Description Logics have proved to be suitable ontology languages [14, 120], for all practical purposes, the term ontology can be regarded as a Description Logic knowledge base. Hence, we concentrate on Description Logics in the remaining sections of this Appendix. 1 KIF (Knowledge Interchange Format) [100] or F-Logic [142, 141] are other formalisms to represent ontologies which are not based on Description Logics.

157 A.2. Definition 153 An ontology is developed from the following primitive elements: Concepts. Concepts or classes represent the basic ideas of the domain which must be understood, and they determine sets which classify domain objects. Concepts are arranged in a hierarchy. Accordingly, a concept of an upper level is more general than a concept of a lower level. Instances. Instances or individuals are concrete occurrences of a concept. Relations. Relations or roles represent binary connections between individuals or individuals and typed values (integers, strings, etc.). Axioms. Axioms establish restrictions over concepts, instances, and relations, describing their attributes by delimiting their possible interpretation. Ontology features have several advantages over other formalisms. These advantages are the following: information sharing among different people or software agents, knowledge reuse, separation between declarative and procedural knowledge, and acquisition and analysis of knowledge. Sharing knowledge representations is one of the main objectives of ontologies. For instance, let us examine the case of two web sites, one supplying information about symptoms and medical diseases, and another displaying a catalogue of pharmaceutical products. If a common ontology defining the semantics of the clinical terms is used, a software agent will be able to integrate information from both sites, thus providing value-added services. For example, drug prescriptions in the diagnosis site could be automatically linked to drug contraindications in the pharmaceutical site. In this way, sharing knowledge allows information to be more automatically located and integrated. Knowledge reuse is another fundamental ontology benefit. Ontologies are especially designed to save time and effort in the knowledge acquisition process by promoting the combination of previous models that describe

158 A.3. Description Logics 154 specific parts of the domain, and refining more general models to represent particular details of the domain. Moreover, ontologies clearly distinguish between declarative and procedural knowledge: ontologies are composed of explicit definitions of domain entities, which guarantees that if the available information changes, the assertions in the model can be modified without having to re-implement the software which uses it. Once an ontology is developed, a formal specification of the domain will be available. This makes it possible to both manually and automatically validate and verify the knowledge represented, and to incorporate it into a reliable repository. A.3 Description Logics Basics Baader, Horrocks, and Sattler define Description Logics (DLs) as a family of knowledge representation languages that can be used to represent the knowledge of an application domain in a structured and formally well-understood way [15]. DLs have features of cognitive models, such as Minsky s frames [92], Sowa s conceptual graphs [237], or Quillian semantic networks [213], but they have the advantage of providing a formal substratum that these formalisms lack. It was Brachman and Levesque who showed that most cognitive models can be endowed with formal semantics, expressed with fragments of First Order Logic, and furthermore, that the fragment considered determines the complexity of reasoning procedures with the models [52, 161]. In this way, DLs were born. Research on DLs is focused on: (i) studying the theoretical foundations of DLs (e.g. semantics, reasoning, and complexity of the various DLs); (ii) developing knowledge representation frameworks to support DL management

159 A.3. Description Logics 155 (e.g. representation languages and inference procedures); (iii) implementing practical applications that rely on them (e.g. Semantic Web). An extensive introduction to these three areas is provided in [17]. DLs are ontology languages that represent domain knowledge by asserting axioms built from concept, role, and instance expressions. Complex concept and role expressions are defined by using the logic-based constructors provided by the concrete DL. The expressivity of a DL, i.e. the semantics that can be represented with valid expressions, determines the complexity of the resulting model, more precisely, the complexity of the reasoning procedures within the model. Hence, DLs are structured in levels, each named with a string of capital letters that denote the allowed expressions. Having more constructors in a logic means that it is more expressive, and consequently, the computational complexity is greater. The minimal DL usually considered is AL, which stands for attributive concept description language. AL allows complex concepts to be: the top ( ) or the bottom ( ) concept, a negation of an atomic concept ( A), a concept intersection (C 1 C 2 ), a value restriction ( R.C), or an existential quantification ( R. ). Complex roles cannot be defined in AL. These complex concepts and atomic roles can be used in concept inclusion axioms (C 1 C 2 ), instance membership axioms (a: C), and role membership axioms ((a, b):r). In the following section, we describe AL, an immediate extension of AL, whereas other interesting DLs are introduced in Section A.3. The Description Logic ALC In this section, we summarize the formal features of ALC [228], the DL mainly considered in this dissertation. We present ALC syntax and semantics as a particular case of general DLs in such a way that its definition can be easily extended to more expressive logics. Signature. The symbols used in a DL are its signature or vocabulary. Formally, the signature is the disjoint union S = C R I, where C = {A} is

160 A.3. Description Logics 156 the set of atomic concepts (or classes); R = R A the set of atomic roles (or properties); and I = {a, b,...} the set of individuals (or instances). From the atomic elements in S, new complex concepts Con(S) = {C (i), D (i),...}, roles Rol(S) = {R (i) }, and axioms Ax(S) = {O (i) } can be composed (subscripts are not used when disambiguation is not needed). By extension, the signature S(O) of an axiom (respectively for roles and concepts) is the set of atomic elements of S which are included in O (respectively R and C). Concept and role constructors. ALC extends AL with the complete concept negation constructor. Complex concepts and roles in ALC are built according to the syntax rule in Table A.1. It can be observed that only atomic roles are allowed in ALC. Given that De Morgan s laws hold, C D is a shorthand for ( C D) and R.C for ( ( R.C)). Therefore, concept union and complete existential restrictions can be represented in ALC, which is at least as expressive as AL plus UE. Table A.1: Syntax and semantics of concepts and roles in ALC Constructor Syntax Semantics Concept constructors Top concept I Bottom concept Atomic concept A A I I Concept negation (C) C I \ C I Concept intersection C D C I C I Concept union (U) C D C I D I Universal quantification R.C {x : x, (x, y) / R I or y C I } Existential quantification (E) R.C {x : y, (x, y) R I and y C I } Role constructors Atomic role R A R I A I I Axioms. A DL ontology is a triple K = T, R, A, where T (the TBox) and R (the RBox) contain, respectively, axioms about concepts and roles (terminological axioms), and A (the ABox) contains axioms about individuals (asserts). The signature of an ontology S(K) is the union of all the signatures S(O) of the axioms in K. Accordingly, an ALC ontology is a DL

161 A.3. Description Logics 157 ontology where A is an ALC-valid TBox; R is an ALC-valid RBox; and A is an ALC-valid ABox. A DL TBox and in particular, an ALC TBox T consists of a finite set of general concept inclusion (GCI) axioms of the form C D, which means that concept C is more specific than D, or that D subsumes C. A concept definition C D (C and D are equivalent) is an abbreviation of the pair of axioms C D and D C. Concept expressions for C and D can be derived inductively from atomic primitives using the previously mentioned ALC concept constructors. In general, a DL RBox R consists of a finite set of role axioms stating role properties such as inclusion, transitivity, functionality, etc. (Table A.3). However, in ALC the RBox is assumed to be empty. A DL ABox A consists of a finite set of axioms about individuals. In ALC, these axioms can describe an individual with respect to a concept (a : C, which means that a is an instance of C) or a pair of individuals with respect to a role ((a, b):r, which means that (a, b) is an instance of R). The set of concepts defined in an ontology is denoted as Con(K). The set of roles defined in an ontology is denoted as Rol(K). Interpretation. An interpretation I of a DL ontology K is a pair I = ( I, I) where I, the domain of the interpretation, is a non-empty set, and I is a function which maps: 1. each individual a in K with an element a I, 2. each concept C in K with a subset C I I, 3. each role R in K with a subset R I I I. This interpretation is conveniently extended for complex concepts and roles. In ALC, this extension is given by the inductive definitions in Table A.1. An interpretation I is a model of (i.e. satisfies) the axiom:

162 A.3. Description Logics 158 a:c iff a I C I, (a, b):r iff (a I, b I ) R I, C D iff C I D I, an ALC KB K = T, R, A iff it is a model for each element in T, R and A. Other Description Logics There are a handful of logics with different levels of expressivity in the literature about DLs. This section offers an overview of the syntax and semantics of some selected extensions. Different combinations of the extensions may lead to the same language since some of them can be mutually reducible. The formal description of the DLs already mentioned can be consulted in the corresponding references. Concept and role constructors. Table A.2 shows the syntax and semantics of some additional role and concept constructors. In the table, S denotes a simple role. A simple role is an atomic role, the inverse of a simple role, or a role that only subsumes simple roles. The operator denotes the composition of binary relations. Axioms. Table A.3 presents further role and instance axioms that can be used in expressive DLs. Observe that a DL TBox, irrespectively of the expressivity of the logic, usually only contains GCIs. D denotes a predefined datatype such as integer, real, etc. Interpretation. Table A.2 shows the interpretation of the additional constructors presented in this section. Extending the ALC case, an interpretation I of an expressive DL is a model of (i.e. satisfies) the axiom: (a, b): R iff (a I, b I ) R I,

165 A.3. Description Logics 161 Relevant Description Logics Some commonly used DL families are: FL, which stands for AL without concept negation, top, and bottom concept. Its immediate extension FL corresponds to FL plus a domain restriction constructor for roles [52]. EL, which takes a different perspective and disallows value restrictions. Thus, it provides as concept constructors only the top concept, conjunction, and (complete) existential restriction, besides concept equivalences as the only axiom [12]. EL + +, an extension of EL which adds the bottom concept, nominals, concrete domains, and GCIs [13], is the logic underlying the EL++ profile of OWL 2 (see Appendix Semantic Web). SH, which extends ALC with transitive roles and role hierarchies [122]. SHIF, which extends SH with inverse and functional roles [121]. This logic is almost equivalent to the Lite level of the standard ontology language OWL (see Appendix Semantic Web). SHOIN (D), which extends SH with nominals, inverse roles, cardinality restrictions, and datatypes [121]. This logic is almost equivalent to the DL level of the standard ontology language OWL (see Appendix Semantic Web). SROIQ(D), which extends SHOIN (D) with qualified number restrictions, disjoint roles, reflexive and irreflexive roles, role chains, complex role inclusions, universal role, local reflexivity of concepts, negated role assertions, and (in)equality assertions [119]. This logic is almost equivalent to the most-expressive and decidable level of OWL 1.1.

166 A.4. Reasoning in Description Logics 162 A.4 Reasoning in Description Logics Basics Reasoning within a knowledge base is the automatic procedure aimed at inferring new axioms which have not been represented and are logical consequences of the axioms represented. Usually, reasoning in DLs can be carried out with concepts in the TBox, individuals in the ABox, or TBox concepts and ABox individuals together. In DLs, the basic reasoning task regarding concepts is concept satisfiability. Intuitively, a concept is satisfiable if it is not contradictory of the rest of the knowledge in the ontology. Another important task is concept subsumption, which infers if a concept is more general than another concept. The concept equivalence test, which determines whether two concepts are the same, and concept disjointness, which determines whether two concepts include any common individuals, are immediate extensions of the concept subsumption check. Formally, these concept inference tasks are defined as follows: A concept C is satisfiable or consistent w.r.t. a knowledge base K if there exists some model I of K such that C I is not empty. Extensively, a TBox T is satisfiable if every axiom in T is satisfiable. A concept C is subsumed by a concept D w.r.t. a knowledge base K if every model I of K is a model of C D. This is denoted as K = C D (K entails C D). Two concepts C and D are equivalent w.r.t. a knowledge base K if C is subsumed by D w.r.t. K, and D is subsumed by C w.r.t. K. This is denoted as K = C 1 C 2 (K entails C is equivalent to D). Two concepts C and D are disjoint w.r.t. a knowledge base K if C I D I = holds for every model I of K.

167 A.4. Reasoning in Description Logics 163 Trivially, satisfiability, equivalence, and disjointness of concepts can be reduced to concept subsumption. For instance, C is unsatisfiable iff C is subsumed by. On the other hand, if a DL allows complete negation and intersection of concepts, subsumption, equivalence, and disjointness of concepts can be reduced to the satisfiability problem [227]. For instance, C is subsumed by D iff C D is unsatisfiable. Insofar as reasoning with individuals is concerned, inferences in the ABox can be performed with respect to the whole knowledge base or by only considering the axioms in the ABox (the TBox and RBox are assumed to be empty). The basic inference task is to test if an assert of the ABox is not contradictory with the other axioms in the ontology, or particularly in the ABox. Other possible queries are to check if certain relationships between concepts, roles, and individuals hold. Formally, the basic inference tasks with instances are defined as follows: An instance axiom O is satisfiable or consistent w.r.t. a knowledge base K if there exists at least one interpretation I that is a model of both O and K. The ABox A is said to be consistent w.r.t. K if every axiom in A is consistent w.r.t. K. An assert is simply consistent if the TBox and the RBox are supposed to be empty. An instance axiom O is said to be entailed by the ABox A if every model I of A is also a model of O. This is denoted as A = O (A entails O). This test can be extended to be performed w.r.t. to a knowledge base K. If O is a membership axiom (a:c), this test is called instance checking. Similarly to concept inferences, instance checking can be reduced to ABox consistency checking, given that A = (a : C) iff A { (a : C)} is inconsistent. It has been proved that ABox consistency can be reduced to concept consistency in languages with the nominal constructor (O) and the fills constructor (a concept is defined as the set of individuals which are related to an instance) [227].

168 A.4. Reasoning in Description Logics 164 It should be underlined that, when reasoning with DL ABoxes, the open world assumption stands. The open world assumption supposes that the set of axioms in a knowledge base is not complete, and consequently, new knowledge cannot be inferred inductively. In contrast, the closed world assumption supposes that the set of axioms is complete, and inductions can be safely made. For example, let us suppose an ABox containing two axioms, hasp rescription(juan, diazepam) and hasp rescription(juan, omeprazole) with no other knowledge about them in the TBox. With the open world assumption, the response to the query how many prescriptions does Juan have would be unknown, whereas with the closed world assumption, the response would be two. Based on these basic inference tasks, more complex reasoning services can be offered. Usually, DL reasoners implement a classification procedure, which finds the place of a concept in the hierarchy, i.e., its direct subclasses and superclasses. Other non-standard inferences in DLs are described in [16]: the least common subsumer(s) of a collection of concepts, the most specific concept(s) that include(s) an instance, the rewriting of concept descriptions, and the matching of concept expressions using concept variables. The most common algorithms for reasoning with DLs are the so-called tableau-based algorithms. The first tableau-based algorithm, proposed by Schmidt-Schauss and Smolka [228], solved the satisfiability problem for ALC concepts. This proposal has been adapted to more expressive extensions of ALC, and extended to deal with ABox consistency queries, as widely explained in [17]. The complexity of the reasoning procedures using tableau algorithms depends on the complexity of the language considered, which is high even for the basic DLs (see next section). Fortunately, worst-case inferences are infrequent, and the procedures have been highly optimized to offer good execution times in the typical cases.

169 A.4. Reasoning in Description Logics 165 Complexity of reasoning To be concise, the computational complexity of an algorithm measures the number of computational resources required to solve a certain problem. A problem P is in complexity class C if there exists an algorithm in C that solves P (then C is the upper boundary for P). A problem P is C-hard if all the problems in class C can be reduced to P polynomially (then C is a lower boundary for P). P is C-complete if it is C-hard and in C. A formal definition of complexity and an introduction to complexity classes can be found in [199]. As explained in the previous sections, DLs research focuses on the relation between the computational complexity of reasoning procedures and the expressivity of the DL used in the representation. Reasoning in DLs has a high computational complexity. As a matter of fact, concept satisfiability with general TBoxes in the (not very expressive) DL ALC is an EXPTIME-complete problem. Fortunately, the worst-case scenarios do not occur very often in practical applications, and thus, the reasoning algorithms behave fairly well. Basic fragments of DLs, such as DL-Lite family [60], are being studied to guarantee the tractability of the reasoning (i.e. that it can be performed in polynomial time). The seminal work of Brachman and Levesque for FL [52], which formally proved the intuition that the more expressive the logic, the more complex the reasoning, has given rise to further research on complexity. An extensive review of the work dealing with complexity analysis of ALC-based DLs can be found in Donini et al., who study the complexity of the concept satisfiability and instance check problems in AL[E][U][C][R][N ] as well as the source of this complexity [81]. Calvanese focuses on non-expressive DLs with restricted TBoxes [58], a contribution that has been completed with additional results for ALCQI in [59]. More expressive logics, such as SHOIN and SROIQ, have been recently studied in [254] and [119]. The Description Logic Complexity Naviga-

170 A.5. Fuzzy Description Logics 166 tor is a useful and well documented utility capable of exploring the complexity of reasoning with TBoxes and ABoxes in several extensions of ALC [264]. Table A.4 summarizes the complexity of reasoning tasks for some of the DLs presented in Section A.3. Table A.4: Complexity of reasoning different DLs w.r.t. general TBoxes Concept satisfiability / ABox consistency DL Acyclic TBoxes General TBoxes EL + + PTIME PTIME ALC PSPACE-complete EXPTIME-complete SHIF EXPTIME-complete EXPTIME-complete SHOIN NEXPTIME-complete NEXPTIME-complete SROIQ a NEXPTIME-hard NEXPTIME-hard a Acyclic RBoxes are required to keep the logic decidable. A.5 Fuzzy Description Logics Basics Although DLs have proved to be a very powerful formalism for knowledge representation, it is also true that ontologies cannot deal with imprecise and vague information, which is inherent to most real world domains 2. Consequently, further extensions of DLs have been proposed in order to represent this kind of knowledge. Since Fuzzy sets and Fuzzy logic are suitable formalisms for imprecise knowledge, a promising direction is to enhance DLs with fuzzy representation mechanisms, which generate fuzzy ontologies. A fuzzy set is a generalization of the classical notion of set. With classical (or crisp) sets, an element can either belong to a set or not, whereas with fuzzy sets, membership in a set is a question of degree. More formally, let 2 Interestingly enough, one of them is the Web. The W3C Incubator Group on Uncertainty Reasoning for the World Wide Web (http://www.w3.org/2005/incubator/ urw3/) studies how uncertainty can be managed in the context of the Semantic Web.

171 A.5. Fuzzy Description Logics 167 X be a set of elements called the reference set. A fuzzy subset A of X is defined by a membership function µ A (x), or simply A(x), which assigns any x X to a value in the interval of real numbers between 0 and 1. 0 means no-membership and 1 full membership (as in classic logics), but now a value between 0 and 1 represents the extent to which x can be considered to be an element of X. Likewise, all crisp set operations are extended to fuzzy sets. The intersection, union, complement, and implication set operations are performed by a t-norm function, a t-conorm function, a negation function, and an implication function, respectively. Analogously, fuzzy relations define a partial association between two or more elements. In this work, we use Zadeh s family of functions and Gödel s implication, which are defined as follows: Zadeh t-norm α β = min{α, β} Zadeh t-conorm α β = max{α, β} Łukasiewicz negation α = 1 α Kleene-Dienes implication α β = max{1 α, β} 1, if α β Gödel implication α β = β, if α > β A comprehensive introduction to Fuzzy Logic, including a detailed explanation of these operations, can be found in [146]. Several fuzzy extensions to DLs are described in [165]. They can be differentiated by the fuzzy semantics added to the DL constructors, the expressivity of the base logic, and the family of fuzzy set operators considered. For instance, FuzzyOWL [243] is a proposal for extending the OWL language (i.e., SHOIN (D)) so that it has fuzzy capabilities. Since it is beyond of the scope of this appendix to provide a full introduction to Fuzzy DLs, we refer the reader to [225] for further studies on the topic. Briefly, fuzzy DLs (fdls) extend DLs by allowing concepts to denote fuzzy sets of individuals and roles to denote fuzzy binary relations. The notion of interpretation is extended to the fuzzy case in such a way that: (i) an

172 A.5. Fuzzy Description Logics 168 individual of the domain may belong to a concept to a certain degree in [0, 1]; (ii) a pair of individuals of the domain may belong to a role to a certain degree in [0, 1]. The semantics of the constructors used to build nonatomic concepts and roles are conveniently adapted; e.g. the semantics of the concept intersection are given by a t-norm function. Axioms are also extended to the fuzzy case, holding to a degree. For example, given two fuzzy concepts, a terminological axiom may be asserted to define a fuzzy inclusion relation between them. In a fuzzy DL we can define, for instance, BloodBorneDiseases as the set of diseases that can be spread by contamination of blood. hepatitisc is a full member of this set (degree equals to 1), whereas nephr opathiae pidemica also belongs to the set, but to a somewhat lesser degree (equal to 0.7). Similarly, two individuals can be partially related through a role: causes(hepatitisc, livercancer) with degree 0.6. Other axioms may also be fuzzified, e.g. GCIs: BloodBorneDiseases is a subset of InfectiousDiseases with degree 0.7 because some bloodborne diseases are infectious, whereas others are not. The fuzzy DL f ALC In this section, we shall consider the fuzzy DL f ALC, used in Chapter 4 of this dissertation. This logic was firstly described in [246]. We shall follow the formulation in [39, 41, 40], which is based on the former, restricting to f ALC the more expressive fdls f SHOIN and f SROIQ proposed in them. Complex concept and role expressions in f ALC have the same generation grammar as in ALC (Table A.5). Axioms in f ALC are the fuzzy extension of the crisp asserts in ALC. Let = {, >}, = {, <}, and α [0, 1]. Thus: A f ALC TBox consists of fuzzy GCIs, which constrain the truth value of a GCI. Fuzzy GCIs are expressions of the form C α D, denoting that C is included in D with degree α. A f ALC RBox is empty.

173 A.5. Fuzzy Description Logics 169 A f ALC ABox consists of a finite set of fuzzy assertions, which constrain the truth value of an assert. A fuzzy assertion can be an expression of the form a : C α (a is a member of C with degree α), a : C α (a is a member of C with degree α), or (a, b) : R α ((a, b) are related through R with degree α). It can be observed that negative GCIs or negative role membership axioms are not allowed. Obviously, concept and role interpretations have fuzzy semantics. Concepts are fuzzy sets of individuals and roles are fuzzy relations between pairs of individuals. A f ALC interpretation maps every individual a onto an element a I I ; every concept C onto a function C I : I [0, 1]; and every role R onto a function R I : I I [0, 1]. For a t-norm, a t-conorm, a negation function and an implication function, Table A.5 depicts the semantics of the interpretation of concept and roles in f ALC. Table A.5: Syntax and semantics of concepts and roles in f ALC Constructor Syntax Semantics Concept constructors Top concept 1 Bottom concept 0 Atomic concept A A I (x) Concept negation C C I (x) Concept intersection C D C I (x) D I (x) Concept union C D C I (x) D I (x) Universal quantification R.C inf y I{R I (x, y) C I (y)} Existential quantification R.C sup y I{R I (x, y) C I (y)} Role constructors Atomic role R A R I (x, y) A A fuzzy interpretation I is a model of (satisfies): a:c α iff C I (a I ) α, a:c α iff C I (a I ) α,

174 A.5. Fuzzy Description Logics 170 (a, b):r α iff R I (a I, b I ) α, C α D iff inf x I{C I (x) D I (x)} α, a fkb f K = T, R, A iff it satisfies each element in T, R and A. We assume that there are no fuzzy axioms of the form τ 0, τ 1 (which are tautologies) or τ > 1, τ < 0 (which are obvious inconsistencies). An axiom τ is a logical consequence of a knowledge base K, denoted K = τ iff every model of K satisfies τ. The greatest lower bound (glb) of a fuzzy axiom τ is defined as the sup{α : K = τ α }. Due to the standard properties of the fuzzy operators, the following concept equivalences hold [246]:,, C C, C C, C, C, R. =, R. =. Moreover, f ALC allow some sort of modus ponens and chaining of GCIs: Proposition 5. For α, β [0, 1] and = {, >}, the following properties are verified: (i) a:c α and C D β imply a: D α β. (ii) C α D and D β E imply C α β E. Reasoning in fuzzy Description Logics Fuzzy DLs cause crisp reasoning procedures (like tableau-based algorithms, Section A.4) to no longer be valid. Consequently, in order to perform reasoning tasks with them, new inference algorithms must be developed. This is the approach taken is most research in the area. The first contribution in this sense was fuzzydl [44], a reasoner for f SHOIN which additionally supports GCIs, Zadeh and Łukasiewicz semantics, and explicit definition of fuzzy concepts with triangular and trapezoidal membership functions. A related approach is presented in [242], where a reasoning algorithm for the

175 A.5. Fuzzy Description Logics 171 expressive fuzzy DLs f SI and f SHIN (with Kleene-Dienes semantics) is described. Nevertheless, an alternative, which has been explored by fewer authors, is to define reduction procedures with a view to transforming fuzzy representations to equivalent crisp ones. This would be done in such a way that existing algorithms and inference engines can be used to carry out reasoning tasks. The first research in this direction was done by Straccia, who developed a reasoning preserving procedure for fuzzy ALC [247, 245]. This approach was extended by Bobillo, Delgado, and Gómez-Romero, who successively consider the more expressive fuzzy DLs f SHOIN [39], f SROIQ [41] and f SROIQ(D) [40].

176 APPENDIX B The Semantic Web This appendix is an introduction to the Semantic Web. The first section describes the main objectives of the Semantic Web initiative, as well as the overall structure of the Semantic Web in relation to the current Web. The second and third sections offer an overview of RDF and OWL languages, with a special focus on OWL. The fourth section describes other Semantic Web technologies such as ontology editors, inference engines, APIs, and database publishing tools. After an explanation of Semantic Web Services, the semantic extension of Web Services, the appendix concludes with a reflection on the future of the Semantic Web. B.1 Basics The Semantic Web is an extension of the current Web, whose aim is the automation of document processing and information retrieval. The Semantic Web appears to solve certain problems of the current web stemming from the large quantity of available resources and the limitations of search engines. The overabundance of documents on the Web makes it difficult to locate the most relevant ones for a specific user query. Web languages are only able 172

177 B.1. Basics 173 to describe the syntax of the documents. This results in manual information integration processes. In their seminal paper on the Semantic Web, Berners-Lee, Hendler, and Lassila propose improving the Web by giving information a well-defined meaning, better enabling computers and people to work in cooperation [27]. The meaning of web resources is represented by means of formal metadata describing their semantics. Consequently, the Semantic Web requires new standards and technologies to create and publish such metadata, which are managed by software agents to find, discover, locate, and integrate information better than today s lexical search engines. Semantic Web research is coordinated by the World Wide Web Consortium (W3C) 1, an international organization devoted to the creation of standards and guidelines for the Web. Under the direction of T. Berners-Lee, various academic institutions and corporations participate in the elaboration of these standards. Semantic Web Activity 2 embodies the W3C groups working on the Semantic Web: languages for metadata (RDF, OWL), rule-based representations, applications, etc. Recommendations (i.e. the final specifications endorsed by W3C members), are the final deliverables produced by the groups as the result of their discussions. The Semantic Web is implemented as a successive set of layers of various levels of abstraction, which have been developed by relying on the Web standards. Figure B.1 shows the most recent layercake diagram 3, which is explained in [230]. 1. The URI/IRI layer offers the most basic support for the Semantic Web, and pertains to the identification of resources. URIs (Universal Resource Identifiers) and IRIs (Internationalized Resource Identifiers) are used to name entities in the Semantic Web, which can be documents, people, places, or anything else worth representing (http://www.w3.org/2007/03/layercake.png)

178 B.1. Basics 174 Figure B.1: Semantic Web layers 2. The XML layer provides a metalanguage to define the syntax of Semantic Web languages. The XML grounding facilitates the interoperability of languages. 3. The RDF layer provides the basic means to associate semantics to Web entities. RDF is a simple language to state assertions regarding entities in the form of object-attribute-value triples (see Section B.2). 4. The next layer contains languages that improve RDF expressivity. The query language SPARQL allows complex consultations of RDF repositories. RDFS adds certain constructs to RDF in order to represent basic ontological semantics, for example, class-subclass relations. OWL is the W3C language used for ontological knowledge representation. RIF is a specification (still under elaboration) of a rule interchange language that will ultimately provide a common framework for rule management in the Semantic Web.

What is the Common Problem that Makes most Biological Databases Hard to Work With, if not Useless to most Biologists? RUNI VILHELM MRAG Americas, Inc. 110 South Hoover Blvd., Suite 212 Tampa, Florida 33609-2458

Parents What you need to know about college admission tests Your child will want to take a college admission test, such as the SAT or other college entrance exams, when he or she is a junior or senior.

Management effectiveness evaluation: for the CBD and for better parks Principles for MEE Methodologies Key question: How will the evaluation help management? Before choosing a methodology or undertaking

Guía Integrada de Actividades Contexto de la estrategia de aprendizaje a desarrollar en el curso: The activity focuses on the Task Based Language Learning (TBLL). The task is used by the student in order

Chapter 12 Chapter 12 Intellectual Development from One One to Three to Three Contents Section 12.1 Brain Development from One to Three Section 12.2 Encouraging Learning from One to Three 1 Section 12.1

Estrategias para la Reducción de Riesgos y Ciber Ataques Luis Zamora Consultor en Tecnología 1 This document is for informational purposes. It is not a commitment to deliver any material, code, or functionality,

Resumen de Entrevista: Asociación de Agentes de Aduana del Puerto de Manzanillo 1. To your knowledge, to what extent do customs brokers run into operative inconveniences when it comes to collecting payment

Another academic year just started and HETS wishes you success in all your endeavors during this year. This is the time for all our resolutions to take place in producing results for our learners. We have

1 Make Your Return-to-Work Process Fit Your Company At Texas Mutual Insurance Company, we work hard to help employers maintain a safe work place, but we know that no business is immune to on-the-job injuries.

When to select APA and other Transfer Pricing options Challenges and Opportunities for the Maquila Industry Agenda 1. Background 2. Type of Maquiladoras 3. APA as an option for PE exemption and compliance

ABSTRACT the task- Based Approach: a way to improve the didactic competence of pre-service teachers in Colombia using technology This article focuses its attention on an innovative application of the Task-Based

Dear Parent, Today was the 100th Day of School, and what better way to celebrate than with activities all about the number 100? With the help of Peg and Cat the problem-solving, math-loving duo from PBS

THE HISTORY OF SOCIAL WORK EDUCATION IN SPAIN: DOES HARMONISATION MAKE SENSE? LA HOMOLOGACIÓN DE ESTUDIOS EN LA COMUNIDAD EUROPEA: PERSPECTIVAS DESDE EL PUNTO DE VISTA DEL TRABAJO SOCIAL PAZ MÉNDEZ-BONITO

Survey Open-Ended s Open-Ended s Parent Survey for schools Question 1. What do you like best about our school? s. The learning enviroment and the individual care for each child needs IB program the good

PREDICTING THE INTENTION OF USING A TECHNOLOGY PRODUCT OR SERVICE THROUGH A FUZZY CONTROLLER Libertad Caicedo Acosta (District University Francisco José de Caldas, Bogotá, Colombia) licedoa@correo,udistrital.edu.co

COMPUTER CLASS REGISTRATION FORM (Please Print Clearly Lea con cuidado) To register for the Computer Technology Program, please complete the following form. All fields in this form must be filled out in

General Certificate of Education Advanced Level Examination June 2014 Spanish Unit 4 Speaking Test Candidate s Material To be conducted by the teacher examiner between 7 March and 15 May 2014 (SPA4T) To

Indicators of teaching and learning science through inquiry in primary classroom Wynne Harlen UK Overview of workshop Part 1: Why IBSE? What do we want to achieve through it? Part 2: Thinking about how