Knowledge Representation:
Generic Tasks, Ontologies

Tutor

Rob Stephens

Room 2P27

Tel: 3136

Robert.Stephens@uwe.ac.uk

Introduction

Many psychologists and philosophers argue that genuine expertise is based on procedural knowledge (eg John Anderson) or tacit, embodied skills and knowledge (eg Hubert Dreyfus). However, knowledge modeling relies heavily on declarative knowledge. Recall that the knowledge level principle in knowledge modeling demands a model of knowledge separate from any symbolic instantiation of that knowledge. Declarative knowledge representation yields this most flexibly. Moreover, the idea of knowledge modeling, as indeed, Knowledge Management and the Semantic Web, suggests that we make declarative statements of knowledge that are independent of a 'knower'. Identifying this as a trend in modern society, the French philosopher Lyotard has put it in this way:

We may thus expect a thorough exteriorization of knowledge with respect to the 'knower', at whatever point he or she may occupy in the knowldge process. The old principle that the acquisition of knowledge is indissociable from the training of minds, or even of indviduals, is becoming obsolete... The relationship of the suppliers and users of knowledge to the knowledge they supply and use is now tending ... to assume the form already taken by the relationship of commodity producers and consumers to the commodities they produce and consume - that is, the form of value.
JF Lyotard, 1984, The Postmodern Condition

In knowledge modeling the use of skeletal models or generic tasks and the principle of knowledge typing are particularly important. Generic tasks are templates of problem-solving activities that can be configured together to describe any intelligent activity.

At least five different types of knowledge are distinguished:

1. Tasks correspond to the goals that must be achieved during problem solving.
2. Problem-solving methods are ways to achieve the goals described in tasks. In some knowledge modeling frameworks, problem-solving methods define subtasks to which other problem solving methods can be applied. We will call such a decomposition a task instance.
3. Inferences describe the primitive reasoning steps in the problem solving process. Inferences are also called mechanisms. Together, the inferences form a functional model which is sometimes called the inference model or inference structure.
4. Ontologies describe the structure and vocabulary of the static domain knowledge.
5. Domain knowledge refers to a collection of statements about the domain.

These different knowledge model components are related as follows:

• task-goals
  realised by
• problem-solving methods
  generate
• task-instances
  invoke
• inferences
  refer to
• ontologies
  describe
• domain knowledge

Models, activities and principles in knowledge modeling are related in the following way:

Knowledge modeling starts with the selection of a modeling templates. These can either be a general modeling framework such as KADS or a partially instantiated knowledge model or generic tasks.

Generic Tasks

It is posited that much of problem solving (and possibly of intelligence itself) is accomplished by appealing to a set of information processing activities known as Generic Tasks. These tasks are each domain and problem independent and combinable to create a large variety of problem solving behaviors.

Each Generic Task is a specialized type of problem solving which is described functionally. By describing a task functionally, a method for solving that task is fairly easy to construct. The method then dictates the types of knowledge required to solve that problem.

Generic Tasks were first thought up by B. Chandrasekaran and researchers at The Laboratory for Artificial Intelligence Research at The Ohio State University. This research has led to the enumeration of the following tasks:

1. Hierarchical Classification
2. Routine Recognition (also called Hypothesis Matching)
3. Abductive Assembly and Layered Abduction
4. Routine Design and Routine Planning
5. State Abstraction
6. Hypothetical Reasoning (What Would Happen If)
7. Data Inferencing

Hierarchical Classification

Hierarchical Classification - the task of finding the most specific category of object or hypothesis that matches the current situation. The process of Hierarchical Classification is one of descending a taxonomic hierarchy of objects (physical or conceptual) or hypotheses pertaining to the domain, considering each node for plausibility.

Strategy - Establish-Refine.
Descend the hierarchy in a depth-first manner. At each node, determine if it is plausible in the context of the current case. If plausible, the node establishes, if implausible the node rejects. If a node establishes, attempt to refine it into more detail by establishing any or all of its children. If a node is rejected, its entire subtree is ignored. Nodes which neither establish or reject may be suspended for future use. It should be noted that this traversal strategy does not have to be implemented in a depth-first manner, nor serially. In fact, it is envisioned to be a parallel process (although not implemented that way currently).

Knowledge - There are two forms of knowledge required in Hierarchical Classification:

1. A taxononic hierarchy
2. For every node, establish/reject knowledge

The hierarchy may be a true tree or a tangled hierarchy. In a tangled hierarchy, some children will have multiple parents. Special connectors can be used refered to as "AND" and "OR" nodes. An "AND" node specifies that for the child to be considered, all of its parents must establish. An "OR" node specifies that the child can be considered if any of its parents establish. "AND" and "OR" specifications allow for a variety of behaviors in tangled hierarchies. Nodes may also be specified as mutually exclusive and also as exhaustive. If a set of nodes are exclusive, then at most one can establish. If a set of nodes are exhaustive, then at least one node must establish. If nodes are specified as exclusive or exhaustive and these rules are not met, an error is provided.

Establish-Reject knowledge may take on a variety of forms. Each node must have some knowledge that allows the hierarchy to determine if it is relevent for the current case. This knowledge may be in the form of pattern matching (for instance, by using Routine Recognition), by appealing to rules, logic, neural network activation strengths, reasoning from first principles or other methods. This knowledge must supply the hierarchy with one of three values: Establish, Reject, Suspend.

KADS

KADS uses models to aid and discipline the knowledge acquisition process. The objective in KADS is to complete a conceptual (knowledge level) model of the domain expert's knowledge, including his/her problem solving strategies, before doing any program building.

When eliciting knowledge from the domain expert, the KADS scheme which organises knowledge into several layers:

1. Facts about entities in the domain, and their relationships, are found in the bottom layer.
2. Strategies for finding pieces of information (or other small-scale tasks) are found in the layer above.
3. Strategies for performing larger tasks, such as doing a diagnosis, are found in the layer above.

For structuring the domain knowledge in this way, KADS provides a library of Interpretation Models. These are descriptions or templates of various different general problem-solving tasks that are very similar to generic tasks (above). e.g. if you decide that a diagnositic activity is being undertaken, there will be an interpretation model corresponding to this.

It will describe the contents of the various layers, in general terms, and give you guidance as to what pieces of knowledge you should expect the domain expert to provide you with.

Imposing a structure on the knowledge acquisition task in this way should ensure that:

1. The knowledge is stored, in its final form, as an intermediate, knowledge level representation; This can yield any number of actual (symbol-level) systems, that may exploit contemporary technologies.
2. The conceptual model is declarative and contains knowledge which has a suitable degree of depth.
3. The knowledge acquisition task is shorter, and of predictable length.

The KADS Models

The KADS models are organized as follows:

The concept stage relates to the knowledge level and the artefact stage the symbol level.

Organizational Model

The CommonKADS organizational model recommends examination of an organization from five major perspectives:

• the activities of the organization;
• the structure of the organization;
• the processes in the organization;
• the power/authority in the organization;
• the resources in the organization.

Each perspective is represented by a single diagram, or by text. These five perspectives can be combined into cross-products which provide the most useful information. For example, the CommonKADS Organizational Model was used to model a Social Security department; a cross-product of activities and structure was produced which highlighted an area of inefficiency, because one of the activities (archiving) was being performed by three different divisions of the department.

Task model

The Task model shows the tasks carried out in the course of a particular process. If the organizational model indicates a particular function which might usefully be automated, a task model can be produced which provides a detailed description of the tasks which carry out that function. The task model may also identify the inputs and outputs of each process (or task), and the decomposition of tasks into more specific sub-tasks. Its purpose is to allow identification of tasks which could usefully be performed by an automated system, or by a program and a user working in conjunction.

Agent Model

The Agent model represents the capabilities required of the agents who perform a process, and constraints on their performance. The agent model represents all the agents which participate in a problem solving process. It is often useful to develop two agent models: one which is based on the task model, showing which agents are currently involved in performing particular tasks, and one which predicts the agents and capabilities required to carry out future tasks.

Communication Model

The Communication model shows the communication required between agents during a process; it may also specify the form of messages, and specify who takes the initiative in a transaction. The communication model indicates all the transactions which take place between different agents. Normally, this will comprise transactions between a knowledge based system and other agents. It is therefore often convenient to combine the Communication model with the Agent model.

Knowledge Model

The Expertise model is a model of the expertise required to perform a particular task. This model is divided into three components:

• declarative knowledge about the domain;
• the inference processes required during problem solving;
• a task structure specifying the hierarchical decomposition and ordering of the inference processes.

Domain Level

The domain knowledge in the model of expertise represents the declarative knowledge which has been acquired. CommonKADS suggests that each item of declarative knowledge is classified into one of the four categories outlined below:

• Concepts: classes of objects in the real or mental world of the domain studied, representing physical objects or states;
• Properties: attributes of concepts e.g. colour, weight
• Expressions: statements of the form 'the property of concept is value'
• Relations: links between any two items of domain knowledge.

Once items of domain knowledge have been classified, they can be used in domain models, which show relations between different items of knowledge. For example, a domain model might show all acquired examples of one concept causing another; or it might show a taxonomic hierarchy of concepts, connected to each other by {^is-a} relations.

CommonKADS also recommends that the domain knowledge is represented at a more abstract level, at which generic statements about the structure and contents of domain models are expressed. The terms used at this abstract level are stored in a model ontology, and the statements at this abstract level are known as model schemata. This abstraction is intended to form a basis for re-using domain models in different problem solving situations.

The domain knowledge in the CommonKADS Expertise model therefore consists of a domain ontology (i.e. a collection of classified terms) and a number of domain models which represent relations between items from the domain ontology. In addition, it is recommended that an abstract view on the domain knowledge is created.

Inference Knowledge

The second subdivision of the Expertise Model records knowledge about inference which may be performed in order to solve a problem. This information is represented in inference structures, which are diagrams showing how various inferences and knowledge roles link together to perform problem solving.

CommonKADS provides a library of generic inference structures, indexed by the type of task which is being performed (classification, diagnosis, configuration, etc.). These generic inference structures can be used as a starting point for developing an inference structure for a particular application.

Task Level

The task level of the model of expertise is normally represented as a graphical hierarchy.

Task knowledge differs slightly between KADS-I and CommonKADS, because KADS-I has an explicit strategy level of knowledge, whereas CommonKADS considers strategic knowledge (now known as problem solving knowledge) to be orthogonal to the domain-inference-task decomposition of the Expertise Model. In both cases, however, the task knowledge which needs to be modelled consists of various tasks which have to be performed and actions which have to be achieved, and breakdowns of these tasks into subtasks. In addition, CommonKADS has an explicit category for tasks which pass information to or from the problem solving process (known as transfer tasks); a selection of problem solving methods (pre-defined generic task structures); and a detailed specification of how tasks should be defined.

CommonKADS also provides definitions for a library of problem solving methods i.e. pre-defined task structures for certain tasks.

Design Model

The Design model culminates in the design of a knowledge based system to perform all or part of the process under consideration. The design process in CommonKADS is broken down into three stages:

• Application design: decomposing the Expertise Model into a number of components. Decomposition can be functional, object-oriented, or specific to a particular AI paradigm (e.g. genetic algorithms).
• Architectural design: deciding on the AI techniques and representations which would be most appropriate for implementing the different decomposed items.
• Platform design: deciding how to implement these AI techniques and representations in the chosen programming tool on the chosen hardware.

While it is possible to represent the Application Design (at least) in diagrams, CommonKADS does not recommend any graphical format for the Design Model; instead, it is expected that the different stages of this model will be represented using text.

Tutorial