The Unified Problem-solving Method Development ... - CiteSeerX

E s p rit P ro je c t 2 7 1 6 9 IB R O W 3 A n In te llig e n t B ro k e rin g S e r v ic e fo r K n o w le d g e -C o m p o n e n t R e u s e o n th e W o rld -W id e W e b

The Unified Problem-solving Method Development Language UPML

Dieter Fensel4, Enrico Motta3, V. Richard Benjamins2, Stefan Decker4, Mauro Gaspari5, Rix Groenboom6, William Grosso7, Mark Musen7, Enric Plaza1, Guus Schreiber2, Rudi Studer4, and Bob Wielinga2 Abstract

Abstract. Problem-solving methods provide reusable architectures and components for implementing the reasoning part of knowledge-based systems. The Unified Problem-solving Method description Language UPML has been developed to describe and implement such architectures and components to facilitate their semiautomatic reuse and adaptation. Spoken in a nutshell, UPML is a framework for developing knowledge-intensive reasoning systems based on libraries of generic problem-solving components. The paper describes the components and adapters, architectural constraints, developments guidelines, and tools provided by UPML. UPML is developed in the course of the IBROW3 project providing an internet-based brokering service for reusing problemsolving methods. Identifier Class Version Version date Status Distribution Responsible Partner

Deliverable 1.1, Chapter 1. Deliverable 3 01-02-1999 prefinal Public University of Karlsruhe, Institute AIFB

i


IBROW3 Consortium This document is part of a research project funded by the Esprit Programme of the Commission of the European Communities as project number 27169. The partners in this project are: Spanish Council for Scientific Research-IIIA (ES), the Open University (UK), the University of Amsterdam, co-ordinator (NL), and the University of Karlsruhe (DE)

1Spanish

Council of Scientific Research (CSIC) Artificial Intelligence Research Institute (IIIA) Campus UAB 08193 Bellaterra, Barcelona, Spain Tel: +34-3-580 95 70; Fax: +34-3-580 96 61 Contactperson E. Plaza E-mail: [email protected]

2University

3The

4University

Open University Knowledge Media Institute Walton Hall MK7 6AA, Milton Keynes, United Kingdom Tel: +44 1908 653506; Fax: +441908 653169 Contactperson: Enrico Motta E-mail: [email protected]

of Amsterdam Department of Social Science Informatics (SWI) Roetersstraat 15 NL-1018 WB Amsterdam, The Netherlands Tel: +31 20 525 6784; Fax: +31 20 525 6896 Contactperson V.R. Benjamins E-mail: [email protected] of Karlsruhe Institute AIFB Kaiserstr. 12 D-76128 Karlsruhe, Germany Tel: +49-721-608392; Fax: +49-721-693717 Contactperson D. Fensel and R. Studer E-mail: {dfe,studer}@aifb.uni-karlsruhe.de

Industrial advisory committee: Daimler Benz (DE) Artificial Intelligence Application Institute (UK)

Further Authors 5Department

of Computer Science, University of Bologna, Italy [email protected] 6University

of Groningen, Department of Computer Science, P.O. Box 800, NL-9700 AV Groningen, NL, [email protected]

7Knowledge

Modeling Group at Stanford Medical Informatics, Stanford University, 251 Campus Drive, MSOB X-215, Stanford, California, USA [email protected], [email protected]

D 1.1, Chapter 1

ii


Revision Information

Revision date

Version

01-11-1998

1

01-01-1999

2

01-02-1999

3

D 1.1, Chapter 1

Changes

iii


Contents 1. Introduction 2. The Architecture of UPML 3. The Different Elements of the UPML Architecture 3.1. Graphical Notations of UPML 3.2. Ontology 3.3. Task 3.4. Domain Model 3.5. Task-Domain Bridge 3.6. Problem-Solving Method 3.6.1. The UPML Architecture of Problem-Solving Methods 3.6.1.1. Complex Problem-Solving Methods 3.6.1.2. Primitive Problem-Solving Methods 3.6.1.3. On the Difference of Task and Competence Specifications 3.6.2. An Example Problem-Solving Method 3.7. Problem-Solving Method Refiner 3.8. PSM-Task and PSM-Domain Bridges 3.9. The Meta Ontology of UPML 4. A Language for UPML and Its Semantics 4.1. Structured Specifications 4.2. Declarative Specifications of Functionality 4.3. Specifications of Control 4.4. Specifications of Communication 5. Architectural Constraints, Guidelines, and Tools 5.1. Constraints 5.2. Design Guidelines 5.2.1. How to Develop an Application System 5.2.2. How to Develop reusable Component Libraries 5.2.3. How to Implement Systems and Components 5.3. Tool Environment of UPML 5.3.1. The UPML Editor 5.3.2. The UPML Browser and “Reasoner” 5.3.3. The UPML Verifier KIV 6. Conclusions, Related Work and Future Work 6.1. UPML: A Software Architecture? 6.2. UPML and UML 6.2.1. UPML viewed from a Methodological Perspective 6.2.2. The Unified Modeling Language 6.2.2.1. A Typical UML diagram 6.2.3. Using UML to describe UPML 6.3. Related Approaches in Knowledge Engineering 6.4. Outlook

D 1.1, Chapter 1

8 10 14 14 14 19 22 25 25 27 27 29 30 31 33 37 41 50 50 51 51 52 55 55 58 59 62 64 68 68 68 69 74 74 75 75 76 77 79 81 81

iv

5.1 7. Glossary 5.2 8. References 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 5.29 5.30 5.31 5.32 5.33 5.34 5.35 5.36 5.37 5.38 5.39 5.40 5.41 5.42 5.43 5.44 D 1.1, Chapter 1

83 86

5

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 6.22 6.23 6.24 6.25 6.26 6.27 6.28 6.29 6.30 6.31 6.32 6.33 6.34 6.35 6.36 6.37 6.38 6.39 6.40 6.41 6.42 6.43 6.44

Figures Fig. 1.. A model of expertise for a simplified diagnostic task.

11

Fig. 2. The UPML architecture for knowledge-based system.

12

Fig. 3. The graphical representation of the example.

15

Fig. 4. The definition of an ontology.

16

Fig. 5. The definition of an ontology with sorted logic.

17

Fig. 6. The definition of an ontology within a frame-based epistemology.

18

Fig. 7. A task ontology for diagnostic problems.

19

Fig. 8. The definition of a task.

20

Fig. 9. The task specification of a diagnostic task.

21

Fig. 10. A domain ontology of anesthesiology.

22

Fig. 11. The definition of a domain model.

23

Fig. 12. The domain model anesthesiology.

24

Fig. 13. The definition of a task-domain bridge.

26

Fig. 14. The td-bridge complete and parsimonious explanation @ anesthesiology.

26

Fig. 15. The definition of a complex problem-solving method.

28

Fig. 16. The definition of a primitive problem-solving method.

29

Fig. 17. A PSM ontology of search.

31

Fig. 18. A problem-solving method search.

32

Fig. 19. The subtasks of search.

34

Fig. 20. The definition of a refiner for complex problem-solving methods.

35

Fig. 21. PSM and task refiners that refine search to hill climbing

36

6

D 1.1, Chapter 1

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.23 7.24 7.25 7.26 7.27 7.28 7.29 7.30 7.31 7.32 7.33 7.34 7.35 7.36 7.37 7.38 7.39 7.40 7.41 7.42 7.43 7.44

Fig. 22. A PSM ontology of search with preference

37

Fig. 23. The definition of a PSM-task bridge.

38

Fig. 24. The pt-bridge hill climbing @ complete and parsimonious explanation.

38

Fig. 25. The definition of a PSM-domain bridge.

40

Fig. 26. The pd-bridge hill climbing @ anesthesiology.

40

Fig. 27. The class hierarchy of the UPML meta ontology.

42

Fig. 28. The attributes of the UPML meta ontology.

43

Fig. 29. The attributes of the UPML meta ontology.

44

Fig. 30. The two effects of assumptions.

60

Fig. 31. The three dimensions of PSM description and development.

64

Fig. 32. Java Translation of the problem-solving method search.

66

Fig. 33. Refiner Search PSM.

67

Fig. 34. Interface BridgeComponent.

67

Fig. 35. Snapshots of the UPML editor.

69

Fig. 36. The browsing and querying interface of OntobrokerUPML.

71

Fig. 37. The answer of OntobrokerUPML for a query.

72

Fig. 38. Verifying a PSM with KIV.

73

Fig. 39. Structural Relationships.

77

Fig. 40. Inheritance Diagrams.

78

Fig. 41. A Sequence Diagram.

78

Fig. 42. A UML diagram from the collaboration process.

80

D 1.1, Chapter 1

7

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20 8.21 8.22 8.23 8.24 8.25 8.26 8.27 8.28 8.29 8.30 8.31 8.32 8.33 8.34 8.35 8.36 8.37 8.38 8.39 8.40 8.41 8.42 8.43 8.44

1

Introduction

Problem-solving methods (PSMs) for knowledge-based systems (KBSs) (cf. [Schreiber et al., 1994]; [Stefik, 1995], [Benjamins & Fensel, 1998]; [Benjamins & Shadbolt, 1998]) decompose the reasoning task of a KBS in a number of subtasks and inference actions that are connected by knowledge roles. Therefore PSMs are a special type of software architectures ([Shaw & Garlan, 1996]): software architectures for describing the reasoning part of KBSs. Several problem solving method libraries are now available (c.f., [Marcus, 1988]; [Chandrasekaran et al., 1992]; [Puppe, 1993]; [Breuker & Van de Velde, 1994]; [Benjamins, 1995]; [Musen 1998]; [Motta, 1997]) and a number of problem-solving method specification languages have been proposed, ranging from informal notations (e.g. CML [Schreiber et al., 1994]) to formal modeling languages (see [Fensel & van Harmelen, 1994], [Fensel, 1995b] for surveys). The IBROW3 project [Benjamins et al., 1998] has been set up with the aim of enabling semiautomatic reuse of PSMs. This reuse is provided by integrating libraries in a internet-based environment. A broker (cf. [Benjamins, 1997], [Fensel, 1997a], [Fensel & Benjamins, 1998a]) is provided that selects and combines PSMs of different libraries. A software engineer interacts with a broker that supports him in this configuration process. As a consequence, a description language for these reasoning components (i.e., PSMs) must provide human-understandable high-level descriptions with underpinned formal means to allow automated support by the broker. Therefore, we developed the Unified Problem-Solving Method description Language UPML [Fensel et al., 1999]. UPML is architectural description language specialized for a specific type of systems providing components, adapters and a configuration of how the components should be connected using the adapters (called architectural constraints). Finally design guidelines provide ways to develop a system constructed from the components and connectors that satisfies the constraints. UPML summarizes the experience that has been collected by the following modeling languages developed for knowledge-based systems: CML [Schreiber et al., 1994], DESIRE [van Langevelde et al., 1993], FORKADS [Wetter, 1990], KARL [Fensel et al., 1998b], KBSSF [Spee & in ‘t Veld, 1994], MCL [Fensel et al., 1998a], (ML)2 [van Harmelen & Balder, 1992], MLPM [Fensel & Groenboom, 1996], MODEL-K [Karbach & Voß, 1992], MoMo [Voß & Voß, 1993], Noos [Arcos & Plaza, 1996], OMOS [Linster, 1992], QIL [Aitken et al., 1993], and TFL [Pierret-Golbreich & Talon, 1996].1 In terms of architecture description languages (cf. [Kogut & Clements, 1995], [Clements, 1996]) UPML is architectural description language specialized for a specific type of systems. The content of the paper is organized as follows. In section 2, we will sketch the architectural framework that is provided by UPML. Sections 3 discuss the different 1. Comparisons of these languages with languages from related areas of computer science (ASM [Gurevich, 1994], DDL [Spruit et al., 1993], LCM [Wieringa, 1995], PDDL [Spruit et al., 1995], Transaction Logic [Bonner & Kiefer, 1993], TROLL [Jungclaus, 1993], VDM-SL [Jones, 1990], and Z [Spivey, 1992]) can be found in [Fensel, 1995b] and [van Eck et al., 1998].

8

D 1.1, Chapter 1

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18 9.19 9.20 9.21 9.22 9.23 9.24 9.25 9.26 9.27 9.28 9.29 9.30 9.31 9.32 9.33 9.34 9.35 9.36 9.37 9.38 9.39 9.40 9.41 9.42 9.43 9.44

elements of our architecture: ontologies, tasks, domain, problem-solving methods, refiner, and bridges. In addition it provides short comparison with software architectures in general. Section 4 discusses semantic issues of UPML providing the formal semantics UPML is based on. Section 5 introduces the architectural constraints that ensure well-defined architectures, the development guidelines of UPML (a detailed discussion can be found in [Fensel & Motta, submitted]), and the tool environment UPML is accompanied with. Finally, we provide conclusions, discussion of related work and an outlook in section 6. Al glossary is provided in section 7. This paper only provides toy examples as illustrations. A realistic case study where UPML is applied to a library of problem-solving methods for parametric design is described in [Motta et al., 1998]. The main focus of the paper are the component and connector types provided by UPML. The development guidelines and their underlying theoretical background are described in more detail in [Fensel & Motta, 1998], [Fensel & Motta, submitted] and [Fensel & Schönegge, 1998]. The precise formal definition of the architectural constraints is still ongoing work and follow the line of [Fensel & Schönegge, 1997].

D 1.1, Chapter 1

9

10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 10.12 10.13 10.14 10.15 10.16 10.17 10.18 10.19 10.20 10.21 10.22 10.23 10.24 10.25 10.26 10.27 10.28 10.29 10.30 10.31 10.32 10.33 10.34 10.35 10.36 10.37 10.38 10.39 10.40 10.41 10.42 10.43 10.44

2

The Architecture of UPML

UPML unifies and generalizes the conceptual models for describing knowledge-based systems that were developed by several approaches in knowledge engineering (e.g. GENERIC TASKS ([Chandrasekaran, 1986], [Chandrasekaran et al., 1992]); ROLE-LIMITING ([Marcus, 1988], [Puppe, 1993]); KADS [Schreiber et al., 1993] and METHODS CommonKADS [Schreiber et al., 1994]; the PROTÉGÉ-II approach [Musen 1998]; COMPONENTS OF EXPERTISE [Steels, 1990]; GDM [Terpstra et al., 1993]; MIKE [Angele et al., 1996] and [Motta, 1997]). Therefore, we will briefly relate the architecture of UPML with one of the most prominent approaches in the field: the model of expertise of CommonKADS [Schreiber et al., 1994]. We will use a simple diagnostic task as an example to illustrate this model (see Figure 1). The task of the KBS consists of finding the diagnosis with the highest preference for a given set of symptoms. The task layer introduces the goal that should be achieved by the system and it decomposes the overall task into subtasks and defines control over them. It combines a functional specification with the specification of the dynamic reasoning process that realizes the functionality. The inference layer specifies the inference process that realizes the subtasks of the task layer. In our example it consists of two inference actions: • generate, which creates possible hypotheses based on the given findings and the causal relationships at the domain layer; and • select, which assigns a preference to hypotheses and selecting the diagnosis with the highest preference. The knowledge role finding provides input to the inference action generate, the knowledge role hypothesis delivers the results of the reasoning of generate to select, and the knowledge role diagnosis provides the results of select as output. The two knowledge roles causality and preference provide knowledge necessary for the inference process. It is mapped from the domain layer, which provides causal knowledge which can be used to relate findings to diagnoses and knowledge which can be used to assign preferences to possible diagnoses. A simple control flow at the task layer is defined by first executing generate and applying select to its output. The model of expertise separates domain knowledge and control knowledge. The domain layer contains the knowledge from the application domain and its terminology. The inference layer and the body of the task layer describe the dynamics of the system. The inference layer defines the elementary inference steps, the relations between them, and the role of the domain knowledge for the reasoning process. In our example, the causal relationship is used by the generate inference step and the knowledge about probabilities is used by the select step. The description at the task layer provides the definition of control over the execution of the inference steps as the inference layer defines only the data flow between inferences but not the order in which they are executed. The distinction between

10

D 1.1, Chapter 1

11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11 11.12 11.13 11.14 11.15 11.16 11.17 11.18 11.19 11.20 11.21 11.22 11.23 11.24 11.25 11.26 11.27 11.28 11.29 11.30 11.31 11.32 11.33 11.34 11.35 11.36 11.37 11.38 11.39 11.40 11.41 11.42 11.43 11.44

the domain-specific knowledge at the domain layer and the domain-independent description of the reasoning process at the inference and task layers enables the reuse of domain knowledge for different task and reasoning strategies and the reuse of problemsolving methods in different domains. The model of expertise has been developed for distinguishing different knowledge types and describing a knowledge-based system at a conceptual level. Its goal was not to describe the different software components a knowledge-based system is built of. In consequence, we had to (1) decouple different element of this model, to (2) encapsulate these different elements and to (3) explicitly model their interactions. Therefore in [Fensel & Groenboom, 1997] and [Fensel & Groenboom, to appear] we introduced an architecture for knowledgebased systems as a modification and extension of the CommonKADS model of expertise. UPML refines this architecture and introduces additional elements in it. The UPML architecture for describing a knowledge-based system consists of six different elements (see Figure 2): a task that defines the problem that should be solved by the knowledgebased system, a problem-solving method that defines the reasoning process of a knowledgeTask Layer Goal: Find the diagnosis which explains the reported findings and which has the highest preference. Body:

hypothesis := generate(finding, causality); diagnosis := select(hypothesis, preference) Inference Layer

finding

generate

hypothesis

causality

preference

Legend: knowledge role

diagnosis

select

inference action

knowledge and data flow

Domain Layer symptom

disease caused-by

[0,1] probability

Legend: concept

Fig. 1.

11

relation

A model of expertise for a simplified diagnostic task.

D 1.1, Chapter 1

12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9 12.10 12.11 12.12 12.13 12.14 12.15 12.16 12.17 12.18 12.19 12.20 12.21 12.22 12.23 12.24 12.25 12.26 12.27 12.28 12.29 12.30 12.31 12.32 12.33 12.34 12.35 12.36 12.37 12.38 12.39 12.40 12.41 12.42 12.43 12.44

based system, and a domain model that describes the domain knowledge of the knowledgebased system. Each of these elements is described independently to enable the reuse of task descriptions in different domains (see [Breuker & Van de Velde, 1994]), the reuse of problem-solving methods for different tasks and domains ([Puppe, 1993], [Breuker & Van de Velde, 1994]), and the reuse of domain knowledge for different tasks and problemsolving methods (cf. [Gruber, 1993], [Top & Akkermans, 1994], [van Heijst et al., 1997]). Ontologies (cf. [Fridman Noy & Hafner, 1997], [Gruber, 1993], [Mizoguchi et al., 1995]) provide the terminology used in tasks, problem-solving methods and domain definitions.

Task Refiner

PSM Refiner

Fig. 21

Fig 20,21

PSM-Task Bridge

Task Fig 8,9,19

Fig. 23,24

PSM Fig. 15,16,18

Ont. Refiner Task-Domain Bridge Fig. 13,14

Ontologies Fig 4,5,6,7,10,17,22

PSM-Domain Bridge Fig 25, 26

Domain Model Fig. 11,12

Domain Refiner Fig. 2

12

The UPML architecture for knowledge-based system.

D 1.1, Chapter 1

13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10 13.11 13.12 13.13 13.14 13.15 13.16 13.17 13.18 13.19 13.20 13.21 13.22 13.23 13.24 13.25 13.26 13.27 13.28 13.29 13.30 13.31 13.32 13.33 13.34 13.35 13.36 13.37 13.38 13.39 13.40 13.41 13.42 13.43 13.44

Again this separation enables knowledge sharing and reuse. For example, different tasks or problem-solving methods can share parts of the same vocabulary and definitions. A fifth element of a specification of a knowledge-based system are adapters which are necessary to adjust the other (reusable) parts to each other and to the specific application problem. UPML provides two types of adapters: bridges and refiners. Bridges explicitly model the relationships between two distinguished parts of an architecture, e.g. between domain and task or task and problem-solving method. Refiners can be used to express the stepwise adaptation of elements of a specification, e.g. a task is refined or a problem-solving method is refined ([Fensel, 1997b], [Fensel & Motta, 1998], [Fensel & Motta, submitted]). Very generic problem-solving methods and tasks can be refined to more specific ones by applying a sequence of refiners to them.1 Again, separating generic and specific parts of a reasoning process maximizes reusability. The main distinction between bridges and refiners is that the former change the input and output of components making them fit together whereas refines may change internal details like subtasks of a problem solving methods. In the following we will see the use of a bridge to connect the problem-solving method hillclimbing with the task diagnostic problem solving (i.e., we model a task-specific refinement of a problem-solving method via a bridge) and the use of a refiner to specialize a generic search method to hill-climbing (i.e., we use refiner to specialize the algorithmic paradigm of a method). The different parts of the architecture will be discussed in the following section.

1.

Actually, UPML provides two means for refining specifications. A specification can import another one and add additional axioms. A refiner can import a specification, add new axioms and rename terminology of the imported specification. Therefore, the former is an extension of the imported theory whereas the latter “overwrites” names of the imported specification.

13

D 1.1, Chapter 1

14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 14.10 14.11 14.12 14.13 14.14 14.15 14.16 14.17 14.18 14.19 14.20 14.21 14.22 14.23 14.24 14.25 14.26 14.27 14.28 14.29 14.30 14.31 14.32 14.33 14.34 14.35 14.36 14.37 14.38 14.39 14.40 14.41 14.42 14.43 14.44

3

The Different Elements of the UPML Architecture

In the following we discuss the different elements of an UPML architecture and how they are connected. First we introduce the graphical notion of UPML and survey the structure of the entire example in 3.1. Then, we introduce the different elements of a specification. We introduce ontologies in section 3.2. Ontologies provide the definition of signatures and axioms that are used by the other parts of the architecture. Section 3.3 introduces tasks that define the problems solved by knowledge-based systems. Section 3.4 provides the definition of domain models and section 3.5 shows how tasks and domain models are connected via bridges. Section 3.6 introduces the core of UPML, the specification frame for describing problem-solving methods. Section 3.7 shows how such description of problemsolving methods can be refined to provide a structured way for the development and description of problem-solving methods and their various variants (cf. [Fensel & Motta, submitted]). Section 3.8 provides the bridges of problem-solving methods and tasks and domains. Finally, the overall structure of UPML is defined in section 3.9.

3.1

Graphical Notations of UPML

The graphical notation of UPML can be used to clarify the overall structure of the architecture of a system. Figure 3 illustrated our running example. Interestingly it also clarifies the relationship between subtasking and refinement of a problem-solving method. Subtasking corresponds to the part-of construct of knowledge representation formalisms. A problem-solving method decomposes its entire reasoning tasks into subtasks. The refinement of problem-solving methods as introduced in [Fensel, 1997b] corresponds to the is-a relationship of knowledge representation formalisms. Hill-climbing is a subclass of general search methods. Therefore it specializes some of its arguments (i.e., Initialize and Update Nodes, and the competence description).

3.2

Ontology

An ontology provides “an explicit specification of a conceptualization“ [Gruber, 1993], which can be shared by multiple reasoning components communicating during a problem solving process (cf. [Top & Akkermans, 1994], [Mizoguchi et al., 1995], [van Heijst et al., 1997], [Fridman Noy & Hafner, 1997]). In our framework ontologies are used to define the terminology and its properties used to define tasks, problem-solving methods, and domain

D 1.1, Chapter 1

14

15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 15.9 15.10 15.11 15.12 15.13 15.14 15.15 15.16 15.17 15.18 15.19 15.20 15.21 15.22 15.23 15.24 15.25 15.26 15.27 15.28 15.29 15.30 15.31 15.32 15.33 15.34 15.35 15.36 15.37 15.38 15.39 15.40 15.41 15.42 15.43 15.44

(Fig. 17) search with preference diagnosis

search

(Fig 22)

(Fig 7) hill-climbing (Fig. 21)

search (Fig. 18)

(Fig. 24) complete and parsimonious diagnoses

Derive Successor Nodes (Fig. 19)

(Fig 9)

Initialize for hill-climbing

Initialize (Fig. 19)

(Fig. 21)

Select Node (Fig. 19)

Stop (Fig. 19) (Fig. 14) Update Nodes for hill-climbing

Update Nodes (Fig. 19)

(Fig. 21)

(Fig. 26) anesthesiology (Fig. 10)

anesthesiology (Fig. 12)

bridge ontology

domain model

task

task

task refiner import

problem-solving method

problem -solving method

problem-solving method refiner

decompose

Fig. 3 The graphical representation of the example.

15

D 1.1, Chapter 1

16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13 16.14 16.15 16.16 16.17 16.18 16.19 16.20 16.21 16.22 16.23 16.24 16.25 16.26 16.27 16.28 16.29 16.30 16.31 16.32 16.33 16.34 16.35 16.36 16.37 16.38 16.39 16.40 16.41 16.42 16.43 16.44

ontology name pragmatics explanation; author; last-date-of modification; reference; URL; where and when it has been used; evalutation import list of ontology names signature list of signature definitions theorems list of expressions axioms list of expressions

Fig. 4

The definition of an ontology.

models. Figure 4 provide the ontology template of UPML. The pragmatics provides an explanation, names the authors, provides temporal information, references and information about where it can found, where and when it has been used and what the experiences with it has been. An ontology may import other ontologies which it refines by adding additional terminology and axioms. The core of an ontology is its signature definition and the axioms it provides used to characterize logical properties of the signature elements. The theorems may list useful statements which are implied by the axioms. UPML does not commit to a specific language style for defining a signature and its corresponding axioms. However, we provide two styles as possible ways for specifying signature and axioms. First we provide logic with sorts close to the specification style of (ML)2 [van Harmelen & Balder, 1992] and MLPM [Fensel & Groenboom, 1996]. Second, we provide a frame-based representation using concepts and attributes as it was proposed by CML [Schreiber et al., 1994] and KARL [Fensel et al., 1998b]. We provide these two different language styles because these languages cover different needs. 1

The simple and therefore „elegant“ sorted logic variant provides first-order logic, some reified second order constructs (i.e., syntactically second-order but semantically within first-order) and a simple sort concept. For more details on sorted logic see [Bläsius et al., 1990].

2

Frame-logic [Kifer et al., 1995] is a powerful language for rich ontological

D 1.1, Chapter 1

16

17.1 17.2 17.3 17.4 17.5 17.6 17.7 17.8 17.9 17.10 17.11 17.12 17.13 17.14 17.15 17.16 17.17 17.18 17.19 17.20 17.21 17.22 17.23 17.24 17.25 17.26 17.27 17.28 17.29 17.30 17.31 17.32 17.33 17.34 17.35 17.36 17.37 17.38 17.39 17.40 17.41 17.42 17.43 17.44

modeling. Its syntax is more complex (i.e., richer). Objects, classes, attributes, domain and range restrictions, multiple attribute inheritance etc. are provided. Again these modeling constructs are integrated within a semantical first-order framework via reification. Frame logic provides more direct support in modeling ontologies, however, its syntax gets more complex and is less well known than the syntax of standard predicate logic. The definition in the style of sorted logic is provided in Figure 5. It introduces sorts, constants, functions, and predicates. The distinction between elementary and constructed sorts is important because the former define parts of a task ontology and a problem-solving methods ontology that have to be connected to a domain ontology (either directly or indirectly via a connection with intermediate connections). On the other hand, the constructed sorts are internally defined and need not to be grounded in a domain (i.e., they are grounded via the elementary sorts from which they are constructed).1 The definition of the frame-based representation style is given in Figure 6. More details on such a representation can be found in [Gruber, 1993], [Schreiber et al., 1994], [Fensel, 1995b], and [Kifer et al., 1995]. Such a signature provide object names, variables typed predicates and concept as core primitive. A concept has single-valued and set-valued attributes. An element of a class can only have a single and unique value for a single-valued attribute. An element of a class can have several values (i.e., a set) for a set-valued attribute. Each attribute has a value range defined by a set of concepts. Vice versa, each attribute has a domain restriction because it must only be applied to elements of a class it is defined for. Finally a class may have super classes from which it inherits attribute definitions. These modeling constructs add some additional syntactical sugar to Flogic, i.e. expressing their semantics in Flogic is straightforwardly.

list of signature definitions elementary sorts1 list of elementary sort names constructed sorts list of sort definitions constants list of constant definitions functions list of function definitions predicates list of predicate definitions

Fig. 5 1.

constructed sort definition = constructed sort name : constructor(external sort name) constant definition = constant name : sort name function definition = function name : sort name1 x ... x sort namen-1 → sort namen predicate definition = predicate name : sort name1 x ... x sort namen

The definition of an ontology with sorted logic.

Elementary sorts are assumed to be disjunct.

17

D 1.1, Chapter 1

18.1 18.2 18.3 18.4 18.5 18.6 18.7 18.8 18.9 18.10 18.11 18.12 18.13 18.14 18.15 18.16 18.17 18.18 18.19 18.20 18.21 18.22 18.23 18.24 18.25 18.26 18.27 18.28 18.29 18.30 18.31 18.32 18.33 18.34 18.35 18.36 18.37 18.38 18.39 18.40 18.41 18.42 18.43 18.44

The next section will provide several examples for ontologies, however, we will restrict ourselves to the more simpler style of sorted logic. We will use the following naming conventions. Sort names are words beginning with an uppercase, constant, function, predicate, and variable names begin with a lowercase. Non-quantified variables are implicitly all-quantified.

list of signature definitions object list of object definitions concepts list of concept definitions predicates list of predicate definitions object definition = object name. concept definition = c[a1 => {c11,...,c1n }, ..., ak => {ck1,...,ckn }, 1 k ak+1 ==> {ck+1,1,...,ck+1,n }, ..., ak+m ==> {ck+m,1,...,ck+m,n k+1

k+m

}] : c1,...,cn

with c, c11,..., c1n , ..., ck1,..., ckn , ck+1,1,..., ck+1,n k

1

, ..., ck+m,1,...,ck+m,n , c1,...,cn m

k+1

are concept names and a1, ..., ak , ak+1, , ..., ak+m

are attribute names with ai is single-valued for i smaller or euqal k and set-valued for k < i; and ci1,..., cin

i

are the value range of the attribute ai, and c1,..., cn

are the superclasses of c. predicate definition = p({c11,...,c1n }, ..., {ck1,...,ckn }) 1

k

with c11,..., c1n , ..., ck1,..., ckn 1

k

are concept names and ci1,..., cin

i

are the value range of the i-th argument.

Fig. 6

D 1.1, Chapter 1

The definition of an ontology within a frame-based epistemology.

18

19.1 19.2 19.3 19.4 19.5 19.6 19.7 19.8 19.9 19.10 19.11 19.12 19.13 19.14 19.15 19.16 19.17 19.18 19.19 19.20 19.21 19.22 19.23 19.24 19.25 19.26 19.27 19.28 19.29 19.30 19.31 19.32 19.33 19.34 19.35 19.36 19.37 19.38 19.39 19.40 19.41 19.42 19.43 19.44

3.3

Task

A task ontology specifies a theory, i.e. a signature and a logical characterization of the signature elements, that is used to define tasks (i.e., a problem type). An example of a task ontology is provided in Figure 7 which is used to provide the elements for defining a diagnostic problem. The ontology introduces two elementary sorts finding and hypothesis which have to be grounded in a domain model. The former describe phenomenon and the latter describe possible explanations. The two constructed sorts findings and hypotheses are sets of elements of these elementary sorts. The function explain connects findings with hypotheses. Domain knowledge must further characterize this function. Three predicates are provided. An order < used to define optimality (i.e., parsimonity) of hypotheses and finally completeness which ensures that a hypothesis explains a set of findings. The description of a task specifies goals that should be achieved in order to solve a given problem. A second part of a task specification is the definition of assumption about domain knowledge and preconditions on the input. These parts establish the definition of a problem ontology diagnoses pragmatics The task ontology defines diagnoses for a set of observations; Dieter Fensel; May 2, 1998; D. Fensel: Understanding, Developing and Reusing Problem-Solving Methods. Habilitation, Fakulty of Economic Science, University of Karlsruhe, 1998; signature elementary sorts Finding; Hypothesis constructed sorts Findings : set of Finding; Hypotheses : set of Hypothesis constants observations : Findings; diagnosis : Hypotheses functions explain: Hypotheses → Findings predicates < : Hypotheses x Hypotheses; complete: Hypotheses x Findings; parsimonious: Hypotheses axioms A hypothesis is complete for some findings iff it explains all of them. complete(H,F) ↔ explain(H) = F; A hypothesis is parsimonious iff there is no smaller hypothesis with larger or euqal explanatory power. parsimonious(H) ↔ ¬∃H’ (H’ < H ∧ explain(H) ⊆ explain(H’))

Fig. 7

19

A task ontology for diagnostic problems.

D 1.1, Chapter 1

20.1 20.2 20.3 20.4 20.5 20.6 20.7 20.8 20.9 20.10 20.11 20.12 20.13 20.14 20.15 20.16 20.17 20.18 20.19 20.20 20.21 20.22 20.23 20.24 20.25 20.26 20.27 20.28 20.29 20.30 20.31 20.32 20.33 20.34 20.35 20.36 20.37 20.38 20.39 20.40 20.41 20.42 20.43 20.44

task task-name pragmatics explanation; author; last-date-of modification; reference; URL; where and when it has been used; evalutation ontology ontology name specification import list of task names roles list of input and output role definitions goal list of expressions characterizing the output preconditions list of expressions characterizing valid inputs assumptions list of expressions characterizing knowledge requirements input role definition: input name

output role definition: output name

Fig. 8

The definition of a task.

that should be solved by the knowledge-based system (see Figure 8). Contrary to most approaches in software engineering this problem definition is kept domain independent, which enables the reuse of generic problem definitions for different applications. A second particular feature is the distinction between preconditions on input and assumptions about knowledge. In an abstract sense, both can be viewed as input, however, distinguishing case data that are processes (i.e., input) from knowledge that is used to define the goal reflect a particular feature of knowledge-based systems. Preconditions are conditions on dynamic inputs. Assumptions are conditions on knowledge consulted by the reasoner but not manipulated. Often, assumptions can be checked in advance during the system building process, preconditions cannot. They rather restrict the valid inputs. Input and output role definitions provide the terms that refer to the input and the output of the task. These names must be defined in the signature definition of the task (i.e., either in the imported ontology or in the auxiliary terminology). The assumption ensure (together with the axioms of the ontology) that the task can always be solved for legal input (input for which the preconditions hold). For example, when the goal is to find a global optimum that the assumptions have to ensure that such a global optimum exists (i.e., that the preference

D 1.1, Chapter 1

20

21.1 21.2 21.3 21.4 21.5 21.6 21.7 21.8 21.9 21.10 21.11 21.12 21.13 21.14 21.15 21.16 21.17 21.18 21.19 21.20 21.21 21.22 21.23 21.24 21.25 21.26 21.27 21.28 21.29 21.30 21.31 21.32 21.33 21.34 21.35 21.36 21.37 21.38 21.39 21.40 21.41 21.42 21.43 21.44

task complete and parsimonious diagnoses pragmatics The task asks for a complete and minimal diagnoses; Dieter Fensel; May 2, 1998; D. Fensel: Understanding, Developing and Reusing Problem-Solving Methods. Habilitation, Fakulty of Economic Science, University of Karlsruhe, 1998; ontology diagnoses specification roles input observations; output diagnosis goal task(input observations; output diagnosis) → complete(diagnosis, observations) ∧ parsimonious(diagnosis) preconditions observations ≠ ∅ assumptions If we receive input there must be a complete hypothesis. observations ≠ ∅ → ∃H complete(H, observations); Nonreflexivity of