Toward truly intelligent information systems-from expert systems to automatic programming

Knowledge-Based 2YSTEMT Knowledge-Based

Systems

10 (1998) 363-396

Toward truly intelligent information systems-from automatic programming

expert systems to

Setsuo Ohsuga Department

of Ir~formution

und Computer

Science, School of Science md Engineerin,y.

Received 24 March 1997; revised 27 October

Wusrda

University,

1997: accepted

3-4-I

3 November

Ohkubo Shirzkurku-ku.

Tokyo 169 Jupm

1997

Abstract The objective of this paper is to discuss a way of designing intelligent systems that assure autonomy, generality and practicality in problem solving to the greatest extent and can solve complex problems. There are various types of problem solving, depending on the object, and often more than one subjects concern the same problem with different roles in complex problem solving. In order to achieve our goal in this environment, a new architecture for the system and a new modeling scheme for representing problems including human activity are discussed, as well as a way of generating problem-specific problem solving systems. Several new concepts are included in this paper: a multi-level function structure and its corresponding knowledge structure, multiple meta-level operations, a multi-strata model to represent problems including human activity, etc. It is shown that the system realizes not only the generality but also the practicality of problem solving by enabling automatic programming. 0 1998 Elsevier Science B.V. All rights reserved. Keywords:

Intelligent

information

systems; Multi-strata

model; Automatic

1. Introduction The objective of this paper is to propose a new computer system which behaves like a person at problem solving and is able to solve complex problems. Here the term problem solving is used in a very wide sense to mean every activity to derive an answer meeting given conditions in a given environment. There have been a lot of systems which have been called intelligent. The author however does not know of any truly intelligent system. A person can develop computer programs, for example, because he/she is truly intelligent. There is no such system that can do that in the same way as a person. The largest differences between persons and computers in problem solving are autonomy in solving complex problems and generality to include the wide range of activities in the actual scope. For example, a person can see the same object from different viewpoints generating different problems but a computer software has only a fixed view to a problem. If a computer system happens to acquire both autonomy and generality in solving real problems, then it will be able not only to have a large capability itself in problem solving, but to collaborate with other systems and/or persons to create greater power. Still more the intelligent systems must assure the practicality of obtaining solutions in a short time. It is believed that generality and 0950-705

1/98/$1Y.O0 0

PII SO950-705

1998 Elsevier

I (98)00032-X

Science

B.V. All rights reserved

system generation

processing time requirements are often contradictory to one other. What is required here, however, is not a matter of trade-off between them, but simply a new method to fulfill these requirements. In order to assure autonomy, problems must be expressed as correctly as possible at the beginning. Since persons are often weak in clarifying and representing their ideas, intelligent systems are required to aid them in externalizing their ideas. A problem solving process, then, is divided into two parts: externalization; and exploration. This paper mainly concerns the latter. Hori [ 11, the author’s colleague, is conducting research on the former. Generality requires a system to process a wide class of problems. Hays-Ross asserts that AI systems should be multi-faceted so that these can solve different tasks in Ref. [2]. A way to achieve this goal is to build a problemspecific problem solving system using the components provided in the system. PROTEGE II, a knowledge-acquisition shell that uses problem-solving methods to derive the modeling of tasks [3] has this approach. This system, rooted in former research works such as Refs. [4,5], builds a method of problem solving for the given problem. But the task of building up the problem-specific system is left to persons. Thus, generality is acquired for the sacrifice of autonomy. A new method must be developed in order to achieve the

364

S. Ohsuga/KnowledRe-Busrd

goal of meeting both autonomy and generality. This is the major objective of this paper. A basic and important concept underlying the system to achieve this goal is modeling. A modeling scheme to represent a problem is introduced, using various multi-level concepts such as a multi-level function structure and its corresponding knowledge structure, multiple meta-level operations, a multi-strata model to represent problems including human activity, etc. The multi-level concept is rather a popular one in many Al systems. Many AI systems include more or less this concept. But none of these systems could achieve the goal of this paper, e.g. none could be a multi-faceted system in the sense Hays-Ross required. The approach taken in this paper is to introduce a new multi-level concept so as to enable the system to consider and make decisions dynamically on the way to continue the problem solving during the problem solving process. In a sense it is to include many virtual persons in the problem solving executed in the system. In this way a very general and autonomous problem solving system is attained. It is shown that this framework also enables us to define intelligent works like programming formally. This shows a possibility and a way of automatic programming. This is conceptually a very different approach to computerized programming from the other works like [6,7] in software engineering which stand on the belief that programming must be done by persons. It is useful for the system to meet the practicality condition. The system presented in this paper consists of providing a couple of closely related subsystems: one is to provide a set of rather simple functions as the components from which the complex problem-specific systems are composed; and the second is to develop a method of organizing a required system autonomously. Some of the components in the first steps have been implemented. For example an automatic, single purpose design system has been implemented. It was applied to chemical compound design under the grant of The Science and Technology Agency of Japan. The second part is now being implemented. A language has an important role in representing and realizing the concepts as discussed above. Its role in realizing the idea as above and its structure is discussed briefly. In this paper, definition of intelligent systems is presented first in order to clarify the research objective in Section 2. Then some basic issues on research are discussed in Section 3. Various concepts and methods to meet the conditions presented are discussed in Section 4. An outline of the concrete representation of knowledge to realize these concepts and methods is in Section 5. A language issue for representing these concepts is also discussed in this section. Some real problems that need the representation scheme invented in this paper are presented in Section 6. In Section 7, automatic programming is discussed as an important method of assuring the system practicality. The objective of this section is not to discuss automatic programming in detail but to show that the whole processes of making

Swtrms

10 (IWK)

363-396

programs can be represented Section 8 is the conclusion.

2. What is intelligent

and processed

in the system.

system?

What is the condition of a system being intelligent? To give a definite answer to this question is difficult. Instead a set of inhibitive conditions as follows are adopted here as the minimum requirements. Systems that can join only a part of the problem solving process are not intelligent. Systems that are available only for specific problems are not intelligent. Systems that are not practical are not intelligent. These are simply phrased as the requirements of autonomy, generality and practicality respectively. A brief description of the significance of these requirements is given as follows. Autonomy doesn’t mean that systems are required to have complete automation in problem solving, but requires that the systems must be able to accept problems directly from outside and enter the process of solving them by themselves. The meaning and significance of this requirement becomes clear by thinking of a counter-example. If the languages for outer- and inner-representations of problems are completely different, then there must be someone who translates them from one to the other. A typical case is ordinary computer systems, in which a person must translate the original problem into a program. If the system uses a representation scheme with which both outer- and inner-representations of problems is possible, the system meets the first condition. Let such a system be said to have the basic structure for autonomy. Even if a system has the basic structure for autonomy, it may not be able to solve a problem because it lacks some knowledge, and it needs a person’s help. But it can achieve the larger capability by acquiring knowledge, and accordingly the autonomy increases. Thus the meaning of the first requirement is that the system has the basic structure for autonomy. It doesn’t imply that the system can understand full natural language and problems can be represented by natural language. Many problems, especially engineering problems, cannot be represented conveniently even by natural language, but use special domain specific methods for representing problems. Intelligent systems must provide users with such a method that it is comprehensive for users for representing their problems, and at the same time the problems represented in this way must be dealable with directly by the problem solving scheme of the system. The second requirement is for the system to solve a variety of problems of different types and different domains [2]. Problems are divided into different types: deterministic and non-deterministic; or confirmation type and exploration type. Intelligent systems must be able to deal with different types and domains of problems. This implies that the

S. OhsuRa/Kno~lrdKr-Ba.\ed Sy.s'sterns 10 (1998136.7-396

365

to convert

the original problem into the internal representation, is left to people. This cannot meet the condition of

(a) Conventional Information Processing Procedural Repessntation

Kmwlcdgc Reprcxntalion

I

Inter&l

I Formof

~Dexription of Applications

@) Knowledge Processing Fig.

I, Principle of information processing.

systems must be provided with a wide range of knowledge covering different domains in order to adapt to the different situations and to deal with different problems spanning these different domains. Also, a high level capability is required for the system to select dynamically such knowledge as is appropriate for solving the problem in hand. The third requirement is for the systems to meet the practical condition of problem solving. In particular, the time the systems spend for solving problems must be as short as possible. In general, the more general a system becomes, the longer the time is required for problem solving. Thus, these requirements sometimes contradict each other. New ideas and methods must be developed for dissolving these contradictory requirements. This requirement implies that the systems must decide for themselves the best method for the given problem, and often be able to generate automatically a procedural program when a system is given a problem and is required to obtain the specific values for the different inputs. Converting the problem solving into a procedural program and then executing the latter is a more efficient way than to obtain all the results by an exploratory operation.

3. Basic issues on intelligent

systems

Before going into detail to meet these conditions, basic issues are discussed. 3.1. Conceptucd architecture

some

qf intelligent systems

The whole of the problem solving process is from accepting external representation of problems to generating solutions. In order to represent problems in the system a language is necessary. The language has to meet two conditions: it has to be processable by the fixed processor; and it has to be usable for representing problems. In ordinary computers only the procedural language is used both for processing by the processor and for representing problems. Because of its limited power of expression, it can cover only a part of the whole process and the large part of the process,

autonomy. The knowledge based system, on the other hand, introduces the second language to separate the above two aspects, as well as a conversion mechanism between them. The second language is a declarative knowledge representation language. The conversion either in the declarative forms or from the declarative to the procedural form is necessary. This is the inference. It can be implemented as a procedural program on conventional computers. This is the necessary condition of an intelligent system to satisfy the requirement of autonomy. Merely to have the second language is not enough, however, for meeting the condition of generality, but new methods must be developed for the purpose. This is the matter of designing the latter half of the above processing. The specification for the second language must be decided so that it can represent these methods. Fig. I shows the principles of information processing.

3.2. Deduction as basic logical operation The requirement for generality requires the systems to deal with different type of problems such as: analysis; design; control; decision making; diagnosis; planning; scheduling; teaching. The systems must be provided with the various methods to solve these problems. For example, different approaches are necessary for analytic-type problems and synthetic-type problems like design problems. This difference is stated sometimes plainly in logical terms as the difference between deduction and abduction. In general, there are different activities requiring different types of reasoning, such as deduction, induction, abduction, non-monotonic, default etc. However the ways of realizing the different reasoning differ. Reasoning other than deduction includes uncertainty in the result to a certain extent. In many cases real problems are complex, and problem solving involves constructing a sequence (or more generally a structure) of primitive operations such that its execution leads the process to the goal. If each primitive operation involves unmanageable incorrectness or uncertainty, this is accumulated in the constructed structure and the correctness of the result is lost. Hence, completeness and soundness should be required in the primitive formal operations so that the problem solving system is assured to generate the right conclusion, as far as possible every time. This compels us to use only deduction as the primitive operation, and to represent the other types of reasoning at the macro-level operations, in terms of deduction in the latter half of the process in Fig. 1. This is the stand-point of this paper. There may be a possibility of using the other types of reasoning as the basic operation in some method of predicting the correctness of the results.

S. Ohsuga/KnowledRe-Based S.ysrems 10 (IYYK) 363-396

366

3.3. Humun-computer

interactions

There is a substantial difference in role between the computer and the person in cooperative problem solving. Problems are always created by people. After that, the problem is solved. It involves various activities such as making a plan, decomposing a large problem into parts, building models and so on. Intelligent computer systems are expected to take an initiative in these tasks, so that they reduce the burden of the person to a large extent. This is the meaning of autonomous problem solving by computers. With such computer systems the human-computer relation changes from the conventional one in which the person takes the initiative and the computers can take part fragmentally in the total problem solving process. In general, there are two types of interaction between the person and the computer. One is essential interaction, and the other is non-essential but unavoidable interaction. Since the problem originates from the person, it must be transferred to the computer at some point of the problem solving process, and the answer must be sent back. These interactions are essential. After the computer accepts the problems it can solve them if its problem solving capability is large enough. Otherwise it needs the person’s help. This interaction however is not essential because, the larger capability the computer acquires, the less the necessity for the interaction becomes. But since the capability cannot always be large enough, this interaction is unavoidable. The objective of intelligent system design is to reduce the unavoidable interactions as far as possible. These interactions correspond to the different stages of problem solving: creation of a problem; and solving the problem. An ideal style of cooperation is to separate these parts in a total problem solving process, and to automate the second part as far as possible. In reality, this is difficult to achieve completely, because human thinking is quite nebulous, and it is very often difficult for a person to state all of an idea clearly at a time. Some part of the information may remain in the person’s brain. This information must be accessed later in the problem solving stage. The person may not note that his/her problem definition is incomplete until the computer stops and ask the person to supply it. Moreover, in the second stage, the computer cannot solve problems automatically, because of the lack of problem solving power. Thus, in order to approach the above goal, the following two technologies must be developed. 1. To aid person to clarify his/her externalize it; and 2. To accept person’s idea/problem autonomously.

idea/problem

and to

and find its solution

Let these be called the externalization and the exploration phase, respectively. Externalization has been considered completely the human party’s role so far. The objective of the work in

this paper is to make it a collaborative operation. The computer technology for this collaboration includes stimulating and aiding the person to clarify his/her idea/problem in their mind, to form concepts, and to represent the concept explicitly. Hori, one of the author’s colleagues, is conducting this research [ 11. It concerns a study of creativity. Exploration, on the other hand, is the basis of autonomy. It includes various technologies to look for and to find solutions for the given problem autonomously. Generality and practicality are required in exploring. These are the requirements for the system to adapt to different situations, even unexpected ones, and to generate proper response to real problems (not toy problems) in the required time. This paper concerns mainly with this problem. Ohsuga conducted research on problem (2), such as on how to decompose large scale problems [S] and design general purpose knowledge based systems [9]. Although these works were not satisfactory in solving the above problems completely, the research is definitely making steps towards this goal. This is the discussion from the stand-point of making computer systems autonomous as far as possible. Computer users may wish to interact and make decisions themselves, positively, while solving problems in a field. This research does not intend to inhibit these interactions.

4. General purpose problem solving system (GPPSS) The condition of a problem solving system in general are that it should be able to deal with different problems in the same system. There are various types of problems such as analysis, design, control, decision making, diagnosis, planning, scheduling, teaching and so forth. Most of these are not well dealt with by conventional software methods, but require the system to have a capability to find a solution itself in a large search space. Since the space is open, self controlled exploration in the space is necessary. The system must be provided with the various methods to solve the different type of problems, each of which is represented by a specific knowledge chunk. Furthermore, a complex problem concerns different problem domains, and since a problem requires domain specific knowledge, the system must be provided with a global knowledge base including the various domain knowledge. In order to use knowledge effectively, the system must be able to extract only the necessary knowledge from the knowledge base referring to the type and the domain of the problem to be solved. For this purpose knowledge must be well structured. These are the requirements for the architectural design of the latter half of the problem solving system in Fig. 1. Some parts of this idea have already been implemented by the author’s group and applied to various problems. The system named KAUS (Knowledge Acquisition and Utilization System) has been developed for this purpose [lo].

S. OhsugalKnowledge-Based

Sytems

10

(1998)363-396

367

process the model is modified repeatedly, looking for a solution. This is the exploration. Thus the model plays a central role in the whole process of problem solving, and externalization and exploration are combined by the problem model. A modeling scheme meeting this condition must be defined.

Fig. 2. Exploratory problem solving.

4.1. Exploratory

problem solving

Human beings today use a general method of problem solving known as the scientific method. In this method a problem is represented explicitly, is analyzed and evaluated as to whether it satisfies the given requirements, and if not it is modified. This analysis/modification process is repeated until the goal is reached. Representing this method explicitly and giving it to computer systems is necessary for achieving the goal mentioned above. Knowledge is used for promoting this process. This method is formalized and represented as shown in Fig. 2. This approach is adopted partly in some expert systems. But most of them are still problem dependent, because knowledge sources and their management must be specified by human experts to each specific problem. In Fig. 2 the different blocks represent the different operations. Every operation is realized as a common deductive operation applied on a specific knowledge chunk. Since the solution space is open and unknown beforehand, there must be a function for guiding and controlling the exploration. The system uses various controls to restrict the search area as narrowly as possible, while assuring that the solution is still included. The parts shown outside of the block for the main part of problem solving in Fig. 2 represent this concern. The operations inside the blocks are dependent on problem domains, though this problem solving scheme itself is common to a wide class of problem domains. 4.2. Problem model Every problem must be represented explicitly in this scheme. The problem model plays an important role here. It has many aspects. First of all, it is a representation of the problem as a requirement to be met. It is modified until a representation is reached which is accepted by the person as a solution. Thus, the model represents the state of the problem solving process at every instance of time and a solution in its final state. Every decision is made on the basis of the model representation at the time. The incipient stage of this process, namely building a problem model for the first time, requires a person to externalize his/her idea/ demand. This is the externalization. In the remaining

4.2.1. Object model An object model is a representation of an object in the world which the person has an interest in and wishes to know about, and therefore it is called such. This object model is the basic concept in the above method, and a modeling scheme to represent any object must be defined. An object has various aspects with different functionalities. and it is almost impossible and not necessary to represent them exhaustively. Instead, only some aspects in which the person has an interest are included. Different models are necessary not only for representing different problems, but for representing the different aspects of an object even in the same problem (as will be shown later), the generative power of the modeling scheme must be large enough. It is desirable that a single modeling scheme can generate different object models. In general, such information is necessary to represent an object correctly and therefore be included in an object model as: (1) StrUCtUml information to represent a structural organization of the object from its components: (2) functionality to represent attribute. property. function, behavioral characteristic of the object and each of its components, relation with the other entity, each of which is represented by a predicate in relation with the object structure; and (3) relation among the representations of functionality to define specitic functional capability of the object. An object structure is composed of components by two kinds of hierarchical relation; is-a and part-of. Based on the part-of relation a part-whole hierarchy is composed as a skeletal structure. Every component or the object itself, represented by a node in the structure, is linked with the other entity not included in the part-whole structure by the is-a relation. In this global structure various predicates are given to represent functionality to the related nodes. Among them those represented by two (or more) place predicate specify binary relations of structural components. In many cases the same type of binary relations represented by the predicate with the same predicate symbol hold between pairs of components in the same hierarchical level. This defines a graph structure. In this case, instead of giving a predicate to every pair, a table of the pairs is made to which a predicate is provided to give a meaning. The table, or database, is related with the object model structure [ 1 11. Thus, as a variation from the above standard form of model representation, the one with graph structure is conveniently used. The predicates are related to each other by some additional predicate formulas which represent the constraints as introduced into the components in the object

368

S. Ohsuga/KnowledKe-Based S~rms

10 (I 998)363-396

ftmctionalityO.......

WI

e

*

(a) An illustration of link mechanism

..

-. rkiati,& functionality13 (a) Hierarchical

structure

functionality 1 .%

@) Representation of object model relation-between Relation among functionalities ; (‘k4 xl,Ya yl,zl,u, rl, a) [position(Pl,xl, yl, u) :- pxition(FO,

~9 @,u), anglc(L1, u), lmgth(L1, zl), UrS(zl, u. 11). sum(x0, rl, xl), sin(z1, u. r2). sum(y0, 4

(b) Graph structure Fig. 3. Representation

; e ELiI c

scheme of object model.

yl)]

(Ad, x2, X3, yl, y2 y3. d. 23.~1, ~2, tl, Wrcat)(Adangle)(Evl, vt/reat) [psition(P;?, x2, y2, u) :- psition(P1, xl, yl, u), angle(L2, vl), Icngth(L2, ZZ), 0x(72, vl. sl), sum(x1. sl, x2), sin(z.2, vl, ~2). sum(y1. ~2, y2), position(P3, x3, y3. u). angk+3. v2), lmgth(LJ. ~3). cos(z3, v2,tl). sub(d, 11, x2), sin(z3, ~2, t2), sum(y3,t2, y2)]. Query; angle := (al, a2. a3, ----, c-4)

model. In addition to these, the nodes inherit functionality from the entities to which they are linked by the is-a relation. An illustration of model that fits into this common scheme are shown in Fig. 3. The characteristics of this modeling scheme are discussed in Ref. [ 121. There is a close relation between structure and functionality of a model. Let the basic form of functionality be Functionality(Object-Structure, Value), or simply F(0, V), read as ‘functionality of object-structure is value’. Some items in the model representation, either Object-structure or Functionality may be unknown, though their existence is known. This causes a problem. Different types of problems can be represented in this modeling scheme, depending on which of Functionality, Object-structure, and Value in the predicate is the unknown term. For example, if a set of functional requirements (F and V) are given to an object but its part-of structure (0) is not known, the model represents a design problem. Different methods are necessary for solving different types of problems, e.g. for obtaining unknown structure and unknown functionality. In general, structure-tofunctionality relation is one-to-one but the functionalityto-structure relation is one-to-many. For the first case above, i.e. F(0, V), because of the one-to-one relation of structure-to-functionality, the solution is determined uniquely. The underlined term denotes a variable. For the other cases the problem is non-deterministic because of oneto-many relation of the functionality-to-structure relation for the case F(O, V). This scheme covers even the case in which a nameqf functionality is not known though data

(Au/~gle~Edreal)(Ey/reai)

psition(F2, (c)

x2, y2, u)

Relation among functionalities and qoety

Fig. 4. An example of object model-link

mechanism

show its existence. Let it be represented F(0, V) and required to create a functionality from a set of instances. A hypothetical functionality (with its tentative name) is created and tested if it explains all observations. If it does not, it is modified and this process is repeated [ 131. The first one belongs to non-exploratory problems and the second and third ones belong to exploratory problems. Fig. 4(a) shows a link mechanism used in various mechanical systems as a simple example of this modeling scheme. The link is composed of four bars. The bars are linked by the pin joints to each other. Both ends Pl and P4 are connected to the ground also by the pin joints. The bar Ll is rotated by a motor. The other bars follow this motion under the constraint produced by the other bars. An object model representation of this link mechanism is shown in Fig. 4(b). The object structure is composed of the link, bars, end-points hierarchy. Some functionalities, like the bar length, point locations are shown. In addition, there must be some formula to represent the relation between these representations of functionality as shown in Fig. 4(c) to define the operation of the object. Let us assume that a question ‘what is the trajectory of the point P?’ is asked. It is represented as ‘trajectory(linkmechanism, P, value)’ where both the link-mechanism and the point P are given and value is an unknown term. In

Fig. 5. Multi-strata

object.

general the trajectory is a continuous line. But it is replaced by a series of points. Then this question is decomposed to a series of questions to obtain a location of the point P for the different rotation angles of the bar Ll . Formally the prefix in the query predicate (Au/angle)(Ex/real)(Ey/real)position(P2, x2, y2, u) represents this requirement and variables too. This expression is translated into a loop operation when this problem is translated into a procedural program (refer to Section 5.1 for the representation scheme). The representation of the other type of question such as to find a link mechanism that generates a specified trajectory is possible. For example, a link mechanism is required to move the point P in a region R in the space. The region R may be a part of the space surrounded by some obstacles. In this case a question in the form of [trajectory(link-mechanism, point, value), in(value, R)] is asked. This example is too simple, but this modeling scheme can be used for different scale and complexity of objects. Thus problems are represented by means of a model. From a different point of view, each model is also a representation of one’s idea in terms of an object in which the person has interest. An externalization system aids a person to represent his/her idea in this basic framework of model representation. 4.2.2. Multi-strata model as problem model Building only an object model, however, is not adequate for representing one’s idea and does not initiate any problem solving. A problem arises when some subject has an intention to do something with an object. Every object has many

Fig. 6. Multi-strata

modeling.

aspects (characteristics), but only some of them, which the subject has interest in and intends to deal with, define the subject’s own problem and are included in the model. Different object models may be created depending on personal interests even if the object is the same. In ordinary problem solving, both the scope of problems and the subject of problem solving were assumed, decided implicitly, and the problem was represented only by an object model. The correct representation of problems is only in the brain of the person. A computer cannot know it. Accordingly it can undertake only a part of the tasks around the lowest level object model and therefore cannot be an autonomous nor a general purpose systern. This also caused difficulties in solving some kind of problems in computers. A typical example is computer programming. A program generates a solution (output) to the given problem (input). A program is therefore a special type of automatic problem solver and replaces a person dealing with his/her task. Hence programming is a problem of creating an automatic problem solver. An automatic programming system is a computer that should behave like a person to make programs. In order to give a precise description of such problems, a modeling scheme should not be merely a way of describing an object. but should be able to represent the more complex model involving subject in the context of a relation between subject and object. The subject can be either a person(s) or a computer program. An extension of the modeling scheme ix necessary. Everything in the world can be an ob,ject of human interest. It can be a simple physical object or an abstract concept. It can even be a problem solving process by others. In this case a problem solving process involves another problem solving process, thus forming a nested structure in which the inside process is for obtaining a solution directly on the lowest level object and the outside process is for obtaining a way of obtaining the solution in the inside process. Sometimes higher numbers of strata must be considered (Fig. 5 ). Let this be called a multi-strata object. A new modeling scheme is necessary to represent such multi-strata objects. The model must be able to encompass a variety of multi-strata objects that arise depending on the situation and characteristics of the constituents in this context. This is shown in Fig. 6. In this modeling scheme, a base stratum problem arises from some lowest stratum object (01). In the ordinary problem solving, a person (Sl) makes its model (M I). This is the basic object model, as was discussed in Section 4.2.1. In the next stratum this problem solving process is itself an object (02) and another subject (S?) solves the problem created in relation with the object. The requirement given to Sl delines the task the person should do. For example, it may be ‘design an object to satisfy the given object-level requirements’, or simply ‘solve problem’. It specifies the activity of Sl as to find an object model structure to satisfy the requirement. Similarly some command is given to S2 to specify the task the S2 should do. For example. ‘automate

370

S. OhsugalKnowledge-Based Systems 10 (199X)363-396

0 0 m;

; person’s activity ; computer’s activity effect induced in person’s mind Fig. 7. Model building methods.

the activity of lower stratum subject’ is given. The upper stratum requirement very often includes the lower stratum one. In order to represent it, a meta-level representation scheme is necessary. The author discussed in Ref. [12] that an intelligent tutoring system is a typical example which needs multi-strata modeling. This is discussed briefly in Section 6 with the other examples. As will be seen in these examples, stratification goes upward any level depending on the situation. But the basis of this scheme is the two-strata model, as shown by the thick line in Fig. 6. Even with this simple structure, this scheme represents many different cases by the combination of the higher- and lower-stratum entities with the requirements given to them. For example, the higher- and lower-stratum subjects can be the same and the higher-stratum subject is defined as an entity to think and decide the way of solving the given problem, i.e. it undertakes the strategic part of lower-stratum problem solving, while the lower-level subject executes problem solving as indicated by the higher level subject. In this case the model M2 may not be made explicitly. But if these subjects are different existences, the model M2 must be created. When the lower-stratum subjects is a person, the higher-stratum subject understands its object only through the model. A model with more strata can be represented as a recurrent form of the basic form. If a taxonomy of modeling that covers all different situations can be defined with this scheme, then it is possible to define intelligent information processing systems that can accept diverse problems with different characteristics. To discuss such a modeling scheme, therefore, is to discuss the basis of very general information processing, and resolves some difficulties involved in ordinary information processing. This implies that a general purpose information processing system, completely different from ordinary computer systems, is realizable. It is possible, however, to assume always the existence of a still outer stratum for every existing problem solving process or system. Accordingly, in principle, an infinite strata scheme may be assumed that results in an infinite taxonomy

of problem solving. Practically this is not viable, because the number of strata is limited and almost all problems can be represented by models of a certain finite number of strata because the effect of an inner process to the outer processes reduces rapidly, and it is of no practical use to take too many strata into account. Conversely it is seen sometimes that the number of strata which a person can take into consideration is less than that that is really necessary, because the human capability of dealing with very complex problems is limited. Intelligent systems being discussed here can help the person by offering a method of representing an object with the necessary number of strata. The depth of the multi-strata object which must be taken into account is represented explicitly in the model. In this way, diverse human mental activities can be formalized and represented. Among a number of possibilities realized with this scheme, special attention is paid to designing autonomous systems. It is formalized as a process of making a multistrata model and then generating a system that can replace a person as the lower stratum subject. This is discussed in Section 5.2. 4.3. Externalization

and exploration

Problem solving is divided into two parts, i.e. externalization and exploration. 4.3.1. Externalization Externalization is an activity to represent human idea/ problem explicitly, in the form of model. Externalizing idea precisely is not an easy task for every person, because of lack of clarity of ideas on the human side [ 141. People come to vague ideas but cannot express them clearly. Computers can help them to clarify and to express their ideas to some extent. Methods must be defined to help one to externalize one’s ideas. An idea/problem created in the person’s brain may have various aspects, and different methods are used to help them. These aspects are combined to define a complete model. Some (but not all) ways of helping externalization depend on the cases, as is shown in Fig. 7; (1) using past case; (2) referring to an existing object; (3) prototyping; (4) making a tentative scenario of achieving the given goal with a not-yet existing object; and (5) forming a model from a collection of fragments of ideas. Of these, (1) is well known as the casebased method; and (2) is useful when an object structure is observable. For example, an enterprise model can be made by observing an existing enterprise organization. Requirement specifications for a business information system are generated from this model [ 151. (3) is well known and is effective if it can be done, and (4) is used for starting such an activity as innovative design. For example, in designing a new type of rocket vehicle, its expected missions are first represented in the form of a scenario. This scenario defines afterward an outline of a model representation. (5) aids a person to build up his idea. For example, a computer

S. Ohsuga/KnoM,lrdRe-Hasm

Object-Model Structure

N 0.--

Systems

IO

(IYW) 363-396

371

The essential parts of the scheme are model structure generation, model analysis and model modification. In reality the exploratory problem solving scheme must be more complex in order to satisfy the above requirements. This will be shown later.

Functionarity

-..- . .. . (Reql, ReqZ, Req3, --, ReqK )

I Problem Problem Solving JI .. ... (Reql, Req2, Req3, --, ReqK) /I\ ... _ . .. . i .. (Reqj+l, -, ReqK)

1

....___ /...(Reqi+f, --, Reqj) 1 Sub!problemM (Nl o.____.________ ____ __.. O(eql,~,Reqi) 1 Sub$roblem2 1 Sub-problem1

(Reql, Req2, Req3, --, ReqK) of N is equivalent with Stmctural Relation (N : Nl, N2, --,Nk) of [ (Reql, --, Reqi)of Nl, (Reqi+l,--, Reqi) of N2, ._... (Reqj+l, --, ReqK) of Nkl Fig. 8. One-step model structure creation and problem decomposition

visualizes a person’s idea by arranging the keywords given by the user to represent the fragments of the idea in a multidimensional space on the display. Then the user in cooperation with computer manipulates these keywords so that these are arranged according to their closeness with the idea. As the result the person can find something previously unnoticed. Hori developed such a system in Ref. [ 11. The requirement, or even the specification for the thing which he/she wishes to do. or in other words a problem representation, may be made clearer through these processes. These functions form the important parts of human-oriented interfaces. The detail is out of scope. Refer to Refs. [ 1,161. What is obtained through externalization is represented by the modeling scheme presented above and is hereafter called the kernel model. 4.3.2. Exploration by multi-model manipulation The requirements for generality and practicality must be satisfied, in the exploration of which the key concept is the exploratory problem solving scheme, as shown in Fig. 2.

Function&v

Domain Model 1

Domain Model 2

Domain Model 3

Object-Model Base Fig. Y. Case-based

incipient model building

4.3.2.1. Model structure generation. In the case of analytic problem solving, a model structure is made at externalization and is given as the original problem representation. In the case of design type problem solving on the other hand, a model structure is not made but the functional requirements are given. The model structure must be created to satisfy the requirement\. A top-down model structure creation is to generate a model structure up to the depth so that the requirements at the top node could be represented as a combination of the requirements to the lower level nodes in the way decided depending on the structure (Fig. 8). This operation is repeated until a tine structure, of which every leaf node i\ a primitive component, is reached. Let a set of the original functional requirements given to the node NO be (Func 1. Func2. -, Func k) and the partial structure.be made. Let its leaf nodes be (N I, N2. -, Nm ) with the new functional requirements ( Func-i 1. Func-i2, -, Func-ini] to each node Ni. If the combination of the set {[Func-11, Func-12, -. Func-lnl}. -. (Func-ml, Funcm2, -, Func-mnm] ) are equivalent with (Funcl, Fun&. -1 Func k} under this structural relation. this structure is a consistent partial structure to satisfy the original requirements. The further detailed structure following to each node Ni may or may not be found at the time. It can be created later by making a new problem starting from Ni with the functional requirements (Func-il. Func-i2. -, Func-ini). For example, in aircraft design the initial configuration of the aircraft is made as composed of the wing. fuselage, engine, and so forth with their geometrical arrangement and a set of functional requirements for each component. The performance of the total airplane such as top speed, cruising speeds, flight range. and so forth can be estimated from the functionality of the components. In most cases an object model cannot be decomposed into the independent set of components, but there are some interrelations among them. Each sub-problem created by the decomposition must be solved satisfying these relations by negotiation with the other sub-problems. There are proposed some negotiation methods. Matsumura is proposing a general method of coming to the agreement between agents in a negotiation problem [ 17 1. He introduced a utility function to represent the significance of decision to be made in both agents and defined a process to come to the agreement. This is a process to find a point at which the values of the utility functions of both agents become equal. These agreements impose the constraints to each sub-problem solving. This enables the decomposition based cooperative problem solving. One way to create model structure is to use some former

312

S. Ohsuga/KnowledRe-Based

Swtetns 10 (IYYX) 363-306

causes the difficulty of making the best decomposition based on the classification of requirements. Actually, the above methods can be combined. It is expected that this structure merging and new division by classification of the requirements enables the system an innovative design to a certain extent.

Modification Rule; modifyMode ( Model, Ni, Mj, Model’) (a) Modification of Hierarchical Structure

modifier

‘m

@) Modification of Graph Structure (by Subgraph Matching) Fig. IO. Model structure modification.

design case. Such a method as is illustrated in Fig. 9 may be used. The past cases are arranged in such a way that can be referred by the predicate to represent functionality. It can cover the different domains. But an innovative design cannot be expected as long as new design depends too much on this old model at the early stage (upstream of design). Or some of the new design requirements may not be satisfied by the old model. In this case the structure generation leaves from the use of the old model at least partly. Some sub-structures may be merged and a new incipient model is created. The other method of structure creation is to use requirements directly, i.e. to classify the requirements into classes in such a way that each class of requirements defines a smaller design problem [S]. It is desirable that the interrelations between sub-structures as the solutions of these sub-problems become the least. Some classification methods like clustering must be used. Some strategic knowledge may be useful for classifying the requirements. It defines the measure of closeness between the requirements and makes groups of them by this measure. This measure must be such as to define a distance between entities in the object structure that the requirements concern. If the requirements Rl and R2 are concerned with the entities el and e2 and these entities are to be included in the same sub-structure in the created object structure. the measure must be such that these functional requirements are put in the same group, and vice versa. It is not necessarily easy to define such a measure and

4.3.2.2. Model modijication. Model modification, especially model structure modification, plays an important role in the basic exploratory problem solving. Depending on the ways of model representation, there are two basic types of model structural modification, hierarchical structure modification and graph structure modification as shown in Fig. 10. Both types, represented in the form of rule, replace a part of the model structure by the externally defined structure based on structure matching. But there are slight differences in the detail between them by the nature of the structure. Matching hierarchical structure is easier than graph structure. Sometimes hierarchical structure can be referred simply by the name and model modification rule is represented as ‘modelModify (Model, Mi, Nj, Model- 1)‘. This is read as ‘A part of structure Mi in Model is replaced by a structure Nj resulting in Model-l’ where Mi and Nj are the name of the nodes to represent the sub-structures to replace and to be replaced. For example, Mi is the name of a type of engine for a car which is found unsatisfactory for achieving the required performance of the car. Then it is replaced by the other type of engine, named Nj. It is assumed that the real structures are prepared in the other places. On the other hand, the structure matching of a graph is usually more difficult and is not referred by the name unless the whole graph is represented by an upper node. The modification rule includes the structure as shown in Fig. 10(b). The predicate ‘modelModify’ has to have the capability of matching structures. As a typical example of graph representation and graph structure matching, Fig. 1 1 shows a result of a chemical structure design system which implemented this idea [ 18,8]. A set of possible rules for structure modification which have been discovered through research are collected and used in the basic problem solving scheme of Fig. 2. Then, starting from the existing chemical compound (at the top of Fig. 1 l), new structures have been created successively. 4.3.2.3. Model analysis. Model analysis is a complex operation. For the purpose of analysis the system needs various methods from mathematics, operations research, physics, engineering and so on. Since different methods become necessary by the case, the analysis must be able to decide itself what method is appropriate for analyzing the model, as is discussed later. Every method or function for model analysis must be represented explicitly and prepared as knowledge. Some method may require a method-specific operational model. Then the system must generate dynamically the operational model for the method from the kernel model. Thus a model modification is

373

+I

I

lmiconazols

201-0029-02

~01-0006-02

zcl-0006-02

mol_31

~01-0003-02

azol-0001-01 mol_60

mo1_95 H

Cl

??

i

MOL

ZOOM

=

JQ-4

)..,

ON0 -43

“-J:

SELECT

CB

Cl

SET

WORLD

ORIGINRL

SHOW

= moL_74

Fig.

of

II.

Chenkxl

A

A

OperationM-1

OperalionM-N

/

Kernel Model External Model Exploration Model = AM-I/MM-I Analysis/Evaluation Model Modification/Refinement Model Fip.

12.A

GROUP

HISTORY

LOAD

SAVE

InFerence_level

= 2

number_of_candidate

= 15

structure design.

OperationA-

Models

KM ; EM-I; OM-I; AM-I; MM-I:

SRME

SMRLL

LRRGE

"KBS_data,db"

selectednol_name

Group

CONVERT

WORLD

group

of models.

necessary. sometimes even for the purpose of analysis. Method-specific knowledge must be provided to the systems for generating an operation-specific model from the kernel model. This means that not only a kernel model but the number of the method-oriented operational-models are involved in a problem solving process (Fig. 12) [ 191. The model of the link mechanism as shown above is one of such operational-models. It must be generated from a part of the geometric model that should move under the same constraint as the link mechanism. Fig. 13 shows an example of generating an operationalmodel which appeared in a model-based internal combustion engine design. The kernel model was the geometric representation of the engine structure as composed of cylinder. piston, piston ring and so on with the related functionality. It was a hierarchical structure.

374

S. Ohsuga/Kno~ledge-Based Systems 10 (1998) 363-396

Fh

H------Y

i

Pl+--

V P2+

P3

PS

P9

PISTON f

Pl4f

CYLINDER

(a) Configuration of engine R12

(b) Edge of piston ring (c) Gas flow graph Fig. 13. Generation

The engine had to be analyzed from different points of views. Among these there occurred a problem of estimating the amount of gas leaking out unexpectedly. A graph was generated from the geometric model as an operational model. Every adjacent pair of surfaces composing the geometrical model was created and tested for whether it defines a legal path along which the gas flows. These pairs of surfaces were connected to form a graph including every

‘=I_

I

I

I

I

I

O-Rule1

O-Rule3 O-Rule7 ,,.,,,,,,,,,I., 0-LkS O-Rule6 O-Rule2 O-Rule4

f

0-RuleN

<

3

Object-Knowledge Base

[Obicct-Level]

M-Rulei ; Mcta-Rule i M-Rule1 characterizes the set (0-Rulel, 0-Rule3,0-Rulc6) M-Rule2 cbaractcrizcs the set O-Rule2,O-Rttk3.O-Rule5) M-Rule3 characterizes the set I0-Rulul, O-Ruld, 0-Rule.7) M-RuleK characterizes the set (0-RulcS, CLR-1~7.0-RulcN) 0-Rulej

; Object-Rule Fig.

j

14. An example

of control structure.

of operational

model.

possible path of gas flow [20]. In reality, the quantitative estimation of gas flow was difficult. But this experiment gave a valuable view for the method of computerizing the design process. 4.4. Metu-operation solving

for defming and controlling problem

The search space at exploration is, in the usual case, vast and unforeseen. In the repetitive problem solving scheme of Fig. 2, only a small portion of the neighborhood of the current model in the solution space is explored. Guiding the selection of the next point (model) as a candidate is important. Concretely, this is to select a proper model modification operation at object-level. This is a meta-level operation. The selected knowledge being applied to an object model changes the state of the model. In order to give the system a capability of adapting to the changing environment and also the freedom of adding, deleting or changing knowledge, the meta-level operation should also be knowledge-based. Thus the concept of meta-level knowledge is indispensable for developing intelligent systems. Representation of meta-level knowledge concerns strongly the design of knowledge representation language. Different strategies can be defined for controlling the process. The following is an example of making a strategy,

S. OhsugaIKnowledge-Based

as realized in a system developed for drug design, in Fig. 11 [ 18,8]. Object-level knowledge is given in the form of rules to represent possible modifications of the existing chemical structure. The knowledge was collected by chemists. These modification rules bring different effects on the characteristics of the object and were classified by their effects. For some rule modifies an object to augment example, poisonous properties, while the others weaken this. These are classified into different classes and to each class is given a description of its effects on the model (Fig. 14). It is given as meta-level knowledge. This forms a control model, which is represented as a compound of structures composed of the classes of object-level rules and a set of predicates in the meta-level. On the other hand, the selection system selects one group of the object-level rules referring to the current state of the model and the goal state. Meta-level knowledge is also used. These meta-level rules are acquired from either chemical theories or the accumulation of rules of thumb. It is to be noted that this is the same form as the object model representation, and also as Fig. 9. If the meta-level knowledge selects only a best modification rule, the automatic problem solving proceeds in a deterministic way. If more than one rule is selected for modification, more than one model is created as new candidates. One is selected from among them either by means of the different strategies in the system or by a person. The remainders are saved for later use. There can be a necessity to change the strategy itself. In order to allow more than one different meta-level operations, a meta-meta-level system becomes necessary. For example, a person may wish to switch the control strategy from one to another. The different ways of classifying the object-knowledge may be prepared as different control models. Thus an architecture with more than one representation level becomes necessary. The number of levels is dependent on the problem and on user’s requirements. The system must be able to define an arbitrary number of representation levels. The reader may think that this makes the system very complex. This is not true. Representations and operations in all levels are the same. For example, the scheme for representing object-model in the object-level and control model in the meta-level is the same and, accordingly, the necessary set of operations is the same. What should be added to the system for enabling this multiple-level operation is no more than a management system which watches the level in which an operation is performed and executes a special short program when an operation needs to move between the different levels. This management system is named the level manager. 4.5. A way of decomposing

problems

Decomposing a problem into small problems is effective to reduce the scope of search at exploratory problem solving. The decomposition is achieved first by dividing

Systems 10

I 199X)

315

363-396

an original model structure into a set of sub-structures, then by creating a sub-problem for every sub-structure. When a model structure is already made, as is the case in analytic problem solving, the way of decomposing can be found directly based on the structure. When a model structure is not yet made, as is the case in design type problem solving, it must be made first. For the latter case the problem decomposition proceeds in two steps: (1) to make a part of an object model structure in such a way that the interrelations between the sub-problems that are defined with respect to these sub-structures are the least and accordingly each sub-problem keeps independence to the largest extent; and (2) according to the result, to decompose the problem solving process. If the condition of ( 1) is not met. then the problem cannot be decomposed. If a leaf node created by this structure decomposition defines another problem, and it is still complex, this pair of operations (( 1) and (2)) is repeated. starting from the node. Since to decompose an object model structure is the exploratory problem solving process itself (Fig. 8) the latter plays an essential role in the process of decomposition. This is illustrated in Fig. 15. It consists of: (1) making a multistrata model corresponding to each leaf node of the object model structure; 2) assigning a subject to each multi-strata model; and (3) distributing the models to the different agents. This process is further discussed in Section 5.4. 4.6. Function structure and knowledge

structure

4.6.1. Function structure As has been discussed, the different knowledge chunks with the common inference mechanism define different functions. This means that a system for solving a specific problem is realized as a specifically structured knowledge base. A collection of knowledge is classified into chunks to represent different operations such as analyzing a model, modifying a model, and so on. A structure of all these knowledge chunks forms a global knowledge base. If there is a strategic operation in the meta-level to extract a part of this structure which is suited for solving the given problem, then it defines a specific problem solving system for this problem. This meta-level operation is also represented as a knowledge chunk in the knowledge-base. A simple structure of knowledge chunks represents a simple function and a complex function defined as a structure of these simple functions is represented as a knowledge structure composed of these simple structures. The structural relation between the large structure and its component structures is obtained by analyzing the way the complex function being composed of the primitive functions. For example, the exploration based problem solving scheme of Fig. 2 is a compound function composed of the more primitive functions such as modeling, model analysis and model manipulation. In reality the exploratory problem solving scheme must

316 Define Problem

@---

Requirement OB ; Object Model

!

J

/’

. exploration

:,:...:::: rnnjiiij autom?teActivity j exploratiqn ;$;;;i ;:p ;;j: &$ .::. ..:kt’ :::I I.@ ____ ;;j: .:$iiii :.: .:.. ::.. :.::::: 1::.:ii:i: :,. ..j,:,: ..:.: ..... i j: Ol’iijj ,:: : : 02;:;: ;.- 1” ;::. ..:.: d ,.::::: i ::: I:. ::.Pt; ..I. f :.:.: ::..:. I., .‘::.: : ..“: ‘ ,:,.:. 0” :j$j i i.:.::::::; j A i ., i..makcP10gram ; ‘.

/I\

Fig. 15. Problem decomposition

be more complex in order to deal with various problems of different type, of different scale and of different domains. Model analysis is its component but is itself a very complex function because the different problems may need the different analysis methods and a sophisticated decision making process must be included in this function to select the best method of analyzing the given problem. Such a complex function must be defined independently of the other functions. A function to decompose a large scale problem into a set of small problems and to distribute them is also a complex function, and must be combined with the scheme. There must be a special method of including these independently defined complex functions in the exploratory problem solving scheme. Or, more generally, there must be a special method with which the complex functions can be combined together to define the more complex functions, any time when necessary in the system. With such a method any complex function can be defined independently of the other functions. As will be shown later, this method is represented by using multi-strata scheme of representation. Real complex problems require the compound coherent use of different intelligent functions. For example, design problem solving needs model creating, learning, model analysis, decomposing a problem into smaller problems, and so

proceas

on. The different sets of intelligent functions are used for the different objectives such as diagnosing, decision making, planning, automatic programming, etc. It is necessary therefore to study these types of problems, list the functions required to solve them and provide them to the system. This is an uneasy task but it is an indispensable step for developing intelligent systems. In this way the total activity of the system is defined and represented by the set of these functions. There can be a dependency relation among some of these functions, such that a complex function is defined using simpler ones, as was seen in the exploratory problem solving process. If a function F is defined as a compound of other functions Gi, (i = 1,2, --, n), then let F be in the relation F > Gi and be said to be greater than Gi. A partial order structure of intelligent functions is formed based on this relation [9]. Making this layered structure is similar to making the curriculum in a school. Students start from understanding the easy subjects, then proceed to the more complex issues represented on the basis of the easy functions. This is a way students can grow and acquire such high level capabilities as to solve complex problems. Computer systems which can be compared with human beings should also have a similar structure.

S. OhsuRa/KnoMledge-Uasrd Basic Form;

PWX

v

(4

Extensioa; ~zzzz>

(b)

cGiGz3 ped(pred’(X) Y)

prcd’jX1)

(d) =

. . . . . . . pr,$d’()(m) Fig. 16. Multi-Layer

Logic

(MLL)

4.62. Knowledge structure to represent function structure A single knowledge chunk represents a primitive function in the function structure while a complex function is represented by a collection of knowledge chunks which are structured according to the relations between functions. For example, the problem solving scheme of Fig. 2 is represented as a static structure of knowledge chunks. The collection of these partial structures forms a global structure of knowledge chunks to represent the global function structure. This is the global knowledge base. A sub-structure for representing a specific function is selected therefrom by a strategic and control operation. Some sub-structure of knowledge chunks to represent a function spans over multiple levels. When such a structure of knowledge chunks is used, level management is indispensable because uncontrolled movement of operation and data across the levels can cause unexpected, contradictory results. But level management is necessary only within structured chunks. When the control moves to the other knowledge chunks independent of this structure, the level concept in the former structure is no more significant. Namely, not an absolute level but only the relative level is important. When two or more sub-structures of knowledge chunks are combined to form a larger structure for meeting the requirements to given problems, a new global level system must be defined by integrating the local level systems into a new structure.

5. Internal integration

representation of basic concepts-especially of differrent functions

5.1. Knowledge Logic (MLLI

representation

language-Multi-Layer

A language for representing the concepts discussed so far is necessary. Such a language has been developed with its processor by author’s group and named Multi-Layer Logic (MLL) [21,9,10]. Before discussing a way of representing

Sysruns

10 (IYYR)

371

363-396

these concepts, the language issue is presented first briefly based on MLL. The expression used in this paper, however, does not follow exactly the syntax of MLL, but rather closer to the ordinary mathematical way of expressing predicate logic because it may be easier to read for those familiar with formal logic. This language is an extension of tirst order logic. The main extensions are: (1) introduction of data structure and a method of manipulating it; (2) high order predicate under certain restrictions; (3) open architecture to accept any procedurally defined predicate; and (4) their combination. The data structure is based on the axiomatic (Zermelo-Fraenkel) set theory, and the language has a capability to detine a new data structure as a compound of the simpler structural components by a set of pre-defined relations. These relations are; element-of (is-a), component-set-of (part-of), product-of, power-of, pair-of. The basic form to represent knowledge is. (Q,xlX)(Q,ylY)-(Q,zlZ)[R(x.

y. -. z)) ]:-~

P,(x, y, -. z)*Pz(x, y, -. z)*-*Pn(x,

y, -, z)l

in which ‘Qx’ etc. denotes either the universal quantifier (A) or the existential quantifier (E). ‘x/X’ etc. means ‘x in a set X’, ‘*’ denotes a logical connector, i.e. either conjunction or disjunction. This expression is read as ‘For all/some (Qx) x in X, all/some (Qy) y in Y,-. all/some (Qz) z in Z, if the relation Pl and/or P2 and/or - Pn hold, then R’. The prefix is often abbreviated for the sake of simplicity in the followings. An evaluation of predicate is a mapping from a set of variables (x, y, -, z) to either True or False (T, F). This mapping can be performed either by matching with the existing predicate or by a procedure. A predicate to which a procedure for evaluation is provided is named a Procedural Type Predicate (PTP). The others are NTP (Normal Type Predicate). When a PTP is to be evaluated the corresponding procedure is evoked and executed. In the following some such predicates appear, especially concerning the model manipulation. ‘create2StrataModel (subject0, i, subjectl-i, Model-i)‘, for example, requires to create a multi(two)-strata model. The number i in this expression denotes the i-th lower stratum objects looking from the highest stratum subject (subject0) composed of subject 1-i and Model-i, the lowest stratum subject and its object model respectively. If some item, say subject0, is a variable, a new node is created to represent it. Since the modeling scheme is fixed and simple, only a fixed number of operations concerning the model manipulation are necessary. Any variable (say x) can be a structural variable to represent a structure. In this case X of x/X in prefix is a set of structures. For example, if X is a product set of the sets D 1, D2, -, Dm, then x represents a tuple (dl, d2, -, dm), of which di G Di. Moreover, any term can be a closed sentence, which means a predicate without free variables. For example a predicate of the form P(x. -, y, S(u, -. w)) can be used. A certain constraint is introduced to avoid occurrence

378

S. OhsuKa/Kno~ledRe-Basrd

of logical inconsistencies. The detail is out of the scope of this paper. As a combination of these expansions, any term can be a structure of predicates (Fig. 16(c)). Using MLL as a knowledge representation language a knowledge based system named KAUS (Knowledge Acquisition and Utilization System) has been developed by the author’s group [lo] and used for many problems [22,18,1 11. The system is designed to accept any PTP as a pair of predicate and its evaluation procedure. Some simplified expression is used in the following. Every term can be a universally quantified variable in a rule with a prefix. In this case it must be in the head. The prefix (Ax/X) for the variable x in the head, however, is abbreviated except when it is necessary to represent a special meaning. In this case the variable is denoted by the character string starting with a upper-case character showing its domain name. A constant is shown by the character string starting from the lower-case letter. But if some terms are used to define a local concept, that is, closed within the single formula, they are not necessarily included in the head, but can appear only in the body. Thus, an expression such as the following appears. predicate(X1, -, Xn):- (Qy/Y)predicate’(Xl, -, predicate”(X1, -, Xn).

-, Xn, y),

It is of course possible to translate this expression into the standard form in which every quantifier is put at the prefix. But the above expression is used in the following because of its comprehensiveness. Even the prefix in the body is often abbreviated, unless it is to be noted for representing a special concept. The predicates in the body of a formula are interpreted in the order from left to right. Sometimes this order carries a part of the meaning of this formula. Thus the formula of predicates can be regarded as an independent block of a procedural unit. In fact, it can be translated into procedure if every predicate in the body is PTP, or every NTP in the formula is expanded by the other predicate through the inference until finally every predicate becomes PTP. In the following a predicate starting with # denotes a PTP. Also, the expressions A:- B, A:- C can be merged to a predicate A:- B + C where + denotes the disjunction. Generally the use of predicate logic is often inconvenient for the purpose of very detailed expression. By the use of procedural expression via PTP, this language has a larger expressive power. But PTP is itself in the framework of first order logic. Still more, the multi-level concept of the language including meta-level PTP enables the system a very fine control of the operations in the object level that are represented by the first-order logic. This increases the expressive power still more, to such an extent that it can represent most of the concepts discussed above as needed for satisfying the requirements of the intelligent systems. In this case the completeness and soundness of the first order logic are not held exactly for the language as a general characteristic. MLL however is designed in such a way that

Swtms

IO (199X) 36%3Y6

it can be translated into an equivalent tirst-order logic if the number of meta-level predicates is restricted to linite. Let a meta-level expression be given as ‘predicateH (predicateL(x), u)‘. If the number of the meta-level predicates is finite, then it is possible to define a new predicate ‘predicateHpredicateL (x, u)’ and replace the original predicate by this one. This appears a lust-order logic, but since the variables x and u are the concepts of the different levels they cannot be substituted by the same term. The restriction on high-order predicates ((2) above) is to inhibit this, and the level manager is defined to keep this constraint. Therefore MLL is a pseudo-first-order logic and mostly keeps completeness and soundness. 5.2. System generation

based on multi-strata

model

Each specific problem requires its own problem solving method represented by a problem oriented structure of functions. Let it be called a problem-specific function structure. Because of its problem dependency, the key information to generate this structure must be included in the problem representation in the form of the multi-strata model. The requirements are distributed in this problem model. These are processed from the highest stratum in order to create the problem-specific function structure. For this purpose a special operation to identify and retrieve the necessary knowledge chunks is performed in the system. For example, let a requirement ‘automate the activity of Subject1 ’ be given to a highest level subject in the multistrata model. Let its internal form be ‘automateActivity (Subjecd, Subject 1, System)’ where ‘Subject2’. ‘Subject 1‘, and ‘System’ denote respectively the subject to which this requirement is given, the subject of which the activity is to be automated, and a problem specific system to be generated in order to replace the designated subject (Subject 1) for the purpose of automating the task. The objective is to retrieve the necessary knowledge chunks to define the system and to replace the lower stratum subject. Knowledge is provided for performing this operation. As an example, let the requirement given to the Subject1 be ‘exploration(Subject1, Model, Domain)’ to mean that the ‘subject1 has to solve the problem by exploration in the specified domain defined by the object model (this expression is expanded in Section 5.3). If this is a design problem, a set of functional requirements are given and subject1 is asked to find such an object model structure that satisfies these requirements. When the requirement is given, the model is not made but a node to represent the model is created and the requirements are given to the node. The model structure is made starting from this node. In this case the requirement for ‘Subject2’ is satisfied by generating a system which can do every operation required by ‘Subjectl’ to solve the given problem. As has already been discussed, it needs a general scheme of solving the problem as shown in Fig. 2. Therefore the requirement given to ‘Subject2’ can be satisfied by

379

S. Ohsuga/Kno~ledge-Hasrd Systems IO (IYYN) 363-396

retrieving a knowledge structure to represent this scheme. The following rule can be used to fulfil this requirement. Rule for generating automation system (Rl): automateActivity (Subject2, Subjectl, System):#getSubjectRequirement(Subjectl, Requirement l)-* 1 generatesystem (Requirement 1, System)-*2 evokesubject (Subjectl, System)-*3 This is a general rule (the term underlined represents what is intended to be obtained in this rule). Let, in the above case, Subject2 and Subject1 be substituted by S2 and Sl respectively. The terms System and Requirement 1 denote a system to be generated and the requirement given to Subjectl (Sl) respectively. This rule says that a system which replaces the lower stratum subject is obtained by, knowing the requirement given to the lower stratum subject (* 1), and generating a system to satisfy the requirement (*2). This operation (“2) is defined by still the other rule as is shown below. After the ‘Requirement 1’ is substituted by the requirement to Sl in the multi-strata model, the predicate ‘generatesystem is evaluated. In the above example, ‘exploration( Subjectl, Model, Domain)’ is the requirement given to the lower stratum subject and is substituted into Requirement I. Since the knowledge to be used for solving a problem may be different by the requirement, problem types and problem domain, it is assumed that a different knowledge chunk is provided for every case. It is also assumed that the name of the problem domain is included in the requirement. Finally the lower stratum subject (Sl) is evoked for operation. This predicate is to start a problem solving for the requirement given to the designated subject using the system assigned thereto (*3). The predicates ‘generatesystem and ‘evokesubject’ included in the above rule is expanded further by the following rule. Rule for system generation (R2): generatesystem (exploration(Subject1, Model, Domain), System):#getObjectRequirement(Model, Requirement’),-*] problemType(Requirement’, Type),-*2 #makeRetrieveKey(Subjectl, Model, Domain, Type, Key),-*3 retrieveKnowledge( Subject 1, Domain, Key, KC ),--*4 makeSystem(System. KC).-*5 There are different rules for ‘generatesystem by the requirements included therein. This is the one in which the requirement to ‘Subject 1’ is ‘exploration’. KC is an abbreviation of knowledge chunk. Subject1 and Model are substituted again by Sl and 01 respectively. The type of problem must be identified from the representation of the requirement on Objectl. If it is represented in the form of ‘functionality(Object, Value)‘, there are three different

types depending on which of object, value and functionality is unknown. In the case of the object being unknown this is a synthetic type problem like a design problem. First the object level requirement is obtained (*l). The problem type is obtained by the predicate (*2). Then the necessary knowledge chunks are retrieved by (*3. “4). Different rules are retrieved for the different problem types and domains. A problem specific problem solving system can be generated including these knowledge chunks (*5 ). The requirement to Sl may be given more specifically such as design, diagnosis, control, programming etc. Then the problem type is included explicitly in the requirement. The rules for ‘generatesystem are prepared for them. Then the problem type is obtained directly. Rule for evoking subject (R3): evokesubject (Subject, System):#getSubjectRequirement(Subject, Requirementl),-* 1 getSolution(Requirement1. System).--*2 Ordinary problem solving to satisfy the Requirement1 is executed using the System (*2). The knowledge chunks can be retrieved by the following rule. Rule for retrieving knowledge chunk for design (when design was substituted into Type) (R4): retrieveKnowledge( Subject 1, Domain, Key, KC): #getTaskKnowledge(Key, TaskKnowledge).-* 1 #getDomainKnowledge(Domain, DomainKnowledge),-* #includeKnowledge(KC, TaskKnowledge. DomainKnowledge).-* The first predicate (* 1) takes out the knowledge to define a specified task from the global knowledge base. The information on the knowledge chunk is in Key. Since the scheme of performing tasks is common to many domains, this task knowledge includes knowledge chunks that relate to different domains. The second predicate (*2) also selects the domain knowledge chunk. Finally, these knowledge chunks are integrated to form the knowledge chunks as required for the given domain. 5.3. To combine different functions chunks

in separate knowledge

In many cases it is necessary to define a complex function using the other complex functions in the separate knowledge chunks. An example is the exploratory problem solving as shown in Fig. 2. Analytic function is included in the exploratory problem solving which is the collection of many different methods. What method is the best cannot be decided in advance but depends on the problem, functionality to obtain, and the problem domain. The function for analysis therefore must decide which method is suited for the present case and then generate a problem specific analysis system by identifying and retrieving the necessary

knowledge chunks before going into the actual analysis of the model. That is, analysis must include decision making and behaves like an independent system. Let such a broad analysis function be called the general analysis. Once such knowledge chunks for the problem specific analysis is ready it is used directly in the exploratory problem solving. Not only the analysis function but incipient model creation and model modification must also be generalized, and a special way to form an exploratory problem solving with them is necessary. There are the different ways of creating an incipient model. It depends on the requirements, problem type, domain etc. This decision has a large effect on the following problem solving. The model modification on the other hand is performed to resolve the discrepancy between the required- and current-functionality. When more than one requirements are not satisfied yet at a moment, there must be a strategy to decide what modification is the best for approaching the goal, i.e. the state without any discrepancy for every requirement. This is the multi-dimensional decision making and some proper method must be used. That is, model modification is also a complex function and the general modification function is necessary. The decision making included in this function must be able to decide the best method under the given condition dynamically. Such needs occur commonly to form a complex function by combining the functions that are defined not in the context of some special problem solving but independently from the others. In the following the basic form of exploratory problem solving is first shown. Then it is extended to such a general case of exploration in which more than one functional requirements are given and it is required to find an object model to satisfy them all. The objective is not to present the complete description of knowledge but to show a way of representing the concepts discussed so far. In particular the attention is focussed to the way of combining the complex functions but not to describe the content of each function fully. In order to complete the knowledge these functions must be written down to the detail. It is assumed in the following that the object requirements (Requirement) are given to a node representing an object model. A subject (Subject) is defined to the object and is given a requirement to start exploratory problem solving to make up its structure. Rule for starting problem solving (R5): exploration(Subject, Model, Domain):incipientModel(Subject, Model, Domain), -* solveProblem (Subject, Model, Domain). -*2

1

It is assumed that the design type problem is made by a person and given to the system as a combination of the subject and the object. The subject is the system itself and the object is the requirements given to a model without any fine structure. An exploratory problem solving starts by making an incipient model (*l), then goes into the actual

problem solving extended.

(*2).

This

basic

form

is afterwards

Rule for the basic exploratory problem solving (R6): solveProblem(Subject, Model, Domain):analyseModel(Subject, Model, Domain),-* 1 #satisfyModel(Model),-“2 +-#satisfyModel(Model),-*3 modifyModel(Mode1, Model’),--*4 (solveProblem (Subject, Model’, Domain))(-*5) This means that the model is analyzed (* 1) and, if the model satisfies the requirement (*2), the process finished. Otherwise (“3) the model is modified (*4) and the process is repeated (“5). In fact, in order to avoid the system falling into endless operation, this type of direct return is not allowed, but the repetitive operation is controlled by using meta-predicate (Rule 9 and 13). In this rule Subject is a subject which deals with this problem. In the very simple case where all rules necessary to interpret this rule including the domain specific knowledge are in the same knowledge chunk with this main rule, an ordinary deductive inference is achieved. In many real world problems however, more than one functional requirement is presented and needs to be satisfied. Moreover analysis and modification are so complex that their knowledge chunks cannot be ready with the main rule in advance. The extension of the above rule is necessary. 5.3.1. Incipient model creution An incipient model must be created depending on the current situation. There are different ways of making an incipient model and a good decision must be made on what method to use. A special way of selecting the proper knowledge chunk based on a decision to be made before going into the actual model creation is introduced. This is to make a tentative multi(two)-strata model and give ‘automateActivity’. as was discussed, and ‘CreateModel’ to the highest and the second stratum subject respectively. Then the operation of ‘automateActivity’ evokes ‘generateSystem’, which includes ‘CreateModel’. By providing the system a rule for this case the intended operation can be realized. Rule for incipient model creation (R7): incipientModel(Subject, Model, Domain):#create2StrataModel(Subject2, 1, Subject 1, Model),-* 1 #defineRequirement(automateActivity(Subject2, Subject, System)),-*2 #defineRequirement(createModel(Subject 1, Model, Domain)),-*3 evokeSubject(Subject2, *).-*4 A multi(two)-strata model is made tentatively with a new highest- and the second-stratum subject (Subject2 and Subjectl) being made as above (“1, *2, “3). Then this highest stratum is evoked (“4). This generates a system to create an

incipient model by means of the next Rule8. Ordinarily ‘evokesubject’ includes a system to be used for dealing with the requirement given to the subject (Subject2 in the above case). In the case of ‘automateActivity’ it is in a system knowledge base and denoted by *. The rule for ‘genaratesystem’ is given as f0llows. Rule for system generation (R8): generatesystem (createModel(Subject, Model, Domain). System):#getObjectRequirement(Model, Requirement),-* 1 modelCreationMethod(Requirement, Method, Domain),-*2 #makeRetrieveKey( Subject, Model, Domain, Method, Key),-*3 retrieveKnowledge(Subject, Domain, Key, KC),--“‘4 makeSystem(System, KC).-*5 Requirement is the set of the functional requirements. each of which is represented in the form of predicate. The requirement is taken out (* 1) and the method of creating the incipient model is decided (*2). This is itself an independent function and the way of deciding the method must be written down though it is abbreviated here. The related knowledge chunk is retrieved (*3,*4) and a specific system for model creation is formed (*5). A rule for ‘createModel’ must be provided to realize the incipient model creation as was shown in Fig. 8 but it is abbreviated. 5.3.2. Extended analysis function In general a model must be evaluated in many aspects corresponding to the different requirements. The further generalization is necessary. In order to represent this situation, ‘a state of model’ is used. It is a collection of the triples for each requirement; a functional requirement, the corresponding functionality of the current model, and knowledge chunk to be used for obtaining the functionality of the current model by analysis. Let the ith functional requirement be [predicate-i(Mode1, value-i), condition(value-i)] where ‘condition(value-i)’ is the condition of value-i to meet. In order to obtain the functionality of the current model, a query ‘predicate-i(Mode1, Value)’ is created based on the requirement and asked to a subject. The general analysis function is called for performing analysis for every item in the state. The exploratory problem solving is repeated many times until the goal is reached. In order to prevent the system falling into an endless operation, the number of repetitions must be included. The model is modified during exploration and the model analysis is repeated with a different model every time. But once an analysis method is selected for obtaining a specific functionality, the same method is used repeatedly, even if the model is different. The knowledge chunk for this method is kept in the state as the third term of the triple.

The rule of ‘exploration’ follows.

shown above is generalized

as

Rule for starting problem solving (R9): exploration(Subject, Model, Domain, K):incipientModel(Subject, Model, Domain),-*1 makeModelState(Subject. Model. Domain, State),-*2 #makeCandidateSet(Subject. Model. Domain, Candidate),-*3 repeatOperation(solveProblem(Subject. Model. State, Domain), K),-*4 decomposeActivity(Subject, Model, Domain),--*5 +-repeatOperation(solveProblem(Subject, Model, State, Domain), K),-*6 makeAnswer(‘non-solvable’).--“7 This is a generalized rule to start problem solving. This rule creates a state of the current model denoted by State (*2) and also Candidate (“3). Candidate is discussed in Section 5.3.3. Then the system enters the actual, statebased problem solving (*4). This is to repeat the operation inside the parenthesis by the specitied number. K denotes the number of the repetitive operation (refer to Rule13). ‘decomposeActivity’ is added (*5). This is discussed in Section 5.4. When no solution can be found in the specified number of repetition (K) (*6), this is reported (“7). Rule for making the current model state (RIO): makeModelState(Subject, Model, Domain, State):#createStateWord(State)--+ 1 #getObjectRequirement(ModeI. Requirement)--“2 (Ax/Requirement)(Ey/predicate)-*3 #generateProblem(x, y(Mode1, Value)),--*4 analyseModelG(Subject, y( Model, Value), Domain, System),--:+5 #insertSystem(System, State),-*6 #insertFunctionality(y(Model. value), State)]--*7 This rule makes the current model state. The actual problem solving is achieved based on the state. A framework of the state word is first made as the empty state (* 1). The object requirement ‘Requirement’ is taken out (“2). Then an item of the state is created for each functional requirement. The scope and type of variables used there are specified ($3) where the local variables x and y represent a functional requirement in the ‘Requirement’ and a query to be made from the functional requirement respectively. The query is generated such that the predicate symbol is the same as the required functionality and the value is a variable (*4). Then the general analysis function is called including this query (“5). As is given below, this function finds the knowledge chunk suited for this query type as well as the result of analysis showing the functionality of the current model corresponding to the requirement. This

382

S. Ohsuga/KnowledRr-Based

knowledge chunk and the functionality state (*6,*7).

is inserted into the

Rule for general analysis (Rl 1): analyseModelG(Subject, y(Mode1, Value), Domain, System): #create2StrataModel(Subject2, 1, Subject, Model),-*1 #defineRequirement(automateActivity(Subjecd, Subject, System)),-*2 #defineRequirement(analyseModelS(Subject, y(Mode1, value), Domain)),-*3 evokeSubject(Subject2, *)-*4 The predicate ‘analyseModelG’ represents a general analysis operation including the selection of a method among many possibilities. It makes a structure of a multi(two)strata model by creating a new highest stratum subject, Subject2, (* 1) and gives it a requirement ‘automateActivity’ (*2). Moreover the rule gives the lower stratum subject the requirement ‘analysisModelS’ to obtain a specific analysis function to be executed using the selected knowledge chunk (*3). Then Subject2 is evoked ($4). It executes the requirement ‘automateActivity’ again but, since the requirement included in the ‘automateActivity’ is different from the one used before, the different rule for ‘generatesystem is needed. Rule for analysis method generation (R12): generatesystem (analyseModelS(Subject, y(Mode1, Value), Domain), System):selectAnalysisMethod(Subject, y(Mode1, Value), Domain, Method),-* 1 #makeRetrieveKey(Subject, Model, Domain, Method, Key),-*2 retrieveKnowledge(Subject, Domain, Key, KC),-*3 makeSystem(Subject, System, KC),-*4 The specific analysis method is selected on the basis of model, requirement, and problem domain (*l). According to the selected analysis method (Method), a key for retrieving a knowledge chunk is made (*2) and the knowledge chunk is retrieved (“3). It may include the rules for transforming the (kernel) model into an operational model for executing the selected method as was discussed as multimodeling in Section 4.3.2. This preparation stage of exploratory problem solving is important. After then the main exploratory problem solving process uses the selected specific knowledge chunk repeatedly. Rule for the simple repetitive operation (R13): repeatOperation(solveProblem(Subject, Model, State, Domain), K):(Ax/integer[ l,K]),-*l [solveProblem(Subject, Model, State, Domain),-*2 #countAndTest(x)].-*3

Systems 10 (19%‘) .?63-306

This rule controls the repetitive operations. The repetition number is checked by (*3) based on the variable defined in (*I).

Rule for the actual exploratory problem solving (R14): solveProblem(Subject, Model, State, Domain):reviseState(Subject, Model, State, Domain),-* I #satisfyModel(Model, State),-*2 f-#satisfyModel(Model, State),-*3 modifyModel(Subject, Model, State, Domain, Candidate, x)1,-*4 This appears almost the same as the basic rule (R6), except for a few changes. ‘analyseMode1’ is replaced by ‘revisestate’, because to analyze a model is to revise the state of the model to adapt to the change of the model by modification in the previous cycle (*l). Since a repetitive operation is prepared in the previous rule, direct going-back is deleted. Rule for multi-requirements analysis function (R15): reviseState(Subject, Model, State, Domain):#copy(State, State’),-*1 (Au /State’)(Ax, y/predicate),-*2 [#stateTerm(u, (x, y, KC)),-*3 #generateProblem(x, y(Mode1, Value)),-*4 analyseModelS(Subject, y(Model,Value), Domain, KC),-*5 #insertState(u, (x, y(Mode1, value), State)],-*6 #/replace(State, State’).-*7 A new state word, State’, is created to make the state separate from the old one, to keep the latter while revising (*l). Then the scope of the variables are specified to repeat the following operations for every item of the state (*2). The variables x and y are specified as the first and second terms of the state, i.e. a functional requirement and a functionality of the current model (*3). A new query is generated from the requirement (*4), then the specific analysis function ‘analyseModelS’ is called (“5). This is the ordinary knowledge processing by deductive inference. The knowledge chunk has already been prepared. The result of analysis is inserted to the term in the state to renew it (*6). After all the items of the state have been renewed, the state is switched from the old one to the new one (*7). 5.3.3. Extended modification function Model modification also needs to include a strategy of modification. In particular in the case of the multiple functional requirements, a multi-dimensional decision-making based on the state of the model becomes necessary. Still more, there is a problem of plural candidates of modification. When a model is to be modified there can be plural ways of model modification. The one that is considered the best is selected. But the others can be revived afterwards, and should be saved. These must be included in the possible methods of modification. For this purpose the generated candidates of modification must be well managed. When

S. OhsuRa/KnowledRe-Based

more than one modification rule is possible, the new models are generated by applying them to the current model. These are saved in Candidates and a new model is selected out of them. When the current model is to be modified, either the modification method is looked for for the first time or it has already been found and the candidate models are in the Candidate. The rules for model modification including this test is made as follows. Rule for general modification function (R16): modifyModel(Subject, Model, State, Domain, Candidate): #newModification(Model),-*l modifyModelNew(Subject, Model, State, Domain, Candidate’),-*:! +-#newModification(Model),-*3 selectNewModel(Model’, Candidate),-*4 #replaceModel(Model’, Model).-*5 The above test is performed by ‘newModification’ (* 1). If this is the case, then the modification method must be decided (*2). The rule for generating the new model modification rules is made in a similar way to the general analysis function, as follows. Otherwise a candidate for a new model is selected from Candidate(*4, *5) Rule for generating model modification rules (R17): modifyModelNew(Subject, Model, State, Domain, Candidate):#create2StrataModel(subject2, 1, Subject, Model),--” 1 #defineRequirement(automateActivity(Subject2, 1, Subject, System)),-*2 #defineRequirement(modifyModel-S(Subject, Model, State, Domain, Candidate, System)),-*3 evokeSubject(Subject2, *).-*4 ‘evokesubject’ activates ‘automateActivity’ which activates ‘generatesystem’. This includes the decision of a method of model modification as follows. Rule for modification system generation (R18): generatesystem (modifyModel-S(Subject, Model, State, Domain, Candidate), System):decideModifMethod(Subject, Model, State, Domain, Method).-* 1 #makeRetrieveKey( Subject, Model, Domain, Method, Key),-*2 retrieveKnowledge(Subject, Key, Domain, KC),--“3 makeSystem(System, KC).-*4 A method of modification must be decided on the basis of the model state (* 1). There can be more than one unsatisfied requirement. Every requirement is given the different weight depending on its significance of its satisfaction. The decision must be made taking this into account as well as the discrepancy between the requirement and the

Systems 10 (1998)

383

363-396

current functionality for every requirement. This is a multi-dimensional decision making problem. There are various decision making methods. For example, a decision theory based on the utility function may be introduced. This decides what functional requirement(s) must be improved in what order. Then the best order of applying the existing object model modification rules is decided. This is to decide the way of retrieving the modification rules and, in turn, to make a key for retrieving the rules in the model modification knowledge chunk (*2). The control method as an extension of the one such as is shown inFig. 14 is assumed used. The knowledge chunk for this method is retrieved (*3) as the actual model-modification as shown in Fig. 10. At the end of automateActivity the actual modification rule is executed. Rule for actual model modification (R19): modifyModel-S(Subject, Model, State. Domain, System, Candidate):(Ax/System)-* 1 [modifyModelO(Model, x. Model’),-*2 #saveModel(Model’. Candidate)],-*3 #selectModel(Model”. Candidate),-*4 #replaceModel(Model, Model”).-*5 ‘System’ includes a set of possible modification rules. For every rule in System (*l), a new model is generated (*2) and added to the Candidate (*3). Then one model is selected as an actual new model (*4) and replaced the old model by this new one (“5). 5.4. Decomposing

problems

Also to be mentioned as one of the important functions enabled by the multi-strata modeling scheme is problem decomposition. Decomposition methods for analytic problems and for synthetic problems are different. In the case of analysis, the object model structure is given and to decompose a problem is to cluster the set of variables to achieve the best approximation. For the synthesis on the other hand, to decompose is to create a model structure that satisfies the given requirements, to define a subproblem for each leaf node of the structure, and to distribute them to the separate subjects. The latter process is discussed here. Since its outline has already been presented in Section 4.5, only its internal form to realise the process illustrated in Fig. 15 is shown. When a model structure is created in exploratory problem solving (R13), the original problem is decomposed to a set of sub-problems. Rule for decomposition (R20): decomposeActivity (Subject, Model, Domain):furtherDecomposable(Model),-* 1 decomposeProcess(Subject, Model, Domain),--“2 +-furtherDecomposable(Model),-*3 When a model structure

is made (R14), it is checked for

further decomposability (*l). If either the leaf of the structure is the primitive components or the functional requirements at the leaf nodes are strongly inter-related to each other, then it is judged now non-decomposable (*3). Otherwise the decomposition process goes further (*2). ‘decomposeProcess’ represents the actual operation for decomposing the further problem solving process. The objective of this operation is to assign a subject to each sub-problem and distribute it to the different agent. A problem that is thought unsolvable by computer systems is left for processing by a person. Rule for process decomposition (R21): decomposeProcess(Subject, Model, Domain):(Ax//Model)(Ey/Node),-* 1 [#leafNode(x) #nodeIndex(x, i),-*3 #create2StrataModel(Subject, i, Subjectl, x),-*4 problemSolvable(x, Domain),-*5 classifyProblem(Subject, i, Subjectl, x, Domain),-*6 +-problemSolvable(x, Domain),-*7 (Eu/Person),-*8 [assignSubjectPerson(Subjectl, u, x),-*9 #defineRequirement(problemSolving(u, x, Domain)), - * 10 #displayProblem(u, x, Domain)].-*1 1 A multi(two)-strata model is created for each leaf node of the model structure. The scope and type of variables are defined (“1) and the node is tested if it is the leaf node (“2). x//Model in (*l) means that x is (a node) in a-part-of relation with Model. The node is identified by an integer ‘i’ (“3). This node is regarded as a new model for a new problem created by decomposition. A new two-strata model is created inserting the second stratum subject ‘Subject 1’ between the current subject (Subject) and the leaf node (“4) as the ith lower subject to Subject. The problem concerning to the leaf node is checked for solvability by the system (“5) and, if so, the problem is checked further for the programmability (“6). If the problem is not solvable by the system (*7), then some person must be assigned to the subject. Someone in Person (“8) is assigned to Subject1(*9), a requirement for problem solving is made (*lo) and is presented to the person (“11). Rule for classifying problem (R22): classifyProblem(Subject, i, Subjectl, Model, Domain):problemProgrammable(Mode1, Domain),-* #create3StrataModel(Subject, i, Subject3, Subject2, Subject 1, Model),-*2 #defineRequirement(automateActivity(Subject3, Subject2, Domain, KC)),-*3 #defineRequirement(makeProgram(Subject2, Subject1 , Domain, Program)).-*4 evokeSubject(Subject3, *),-*5

1

f-problemProgrammable(Model, Domain).--“% exploration(Subject1, Model, Domain)),-*‘7 The problem is classified by the programmability. If it is programmable (*I), then a multi-strata model is made (“2) by creating the new subjects, Subject3 and Subject2. In the following operations, the highest stratum subject (Subject) is no longer necessary and is ignored. It remains only for recording the history of decomposition. The requirements ‘automateActivity’, and ‘makeprogram’ are given to Subject3 and Subject2 respectively (*3,*4). Then Subject3 is evoked (“5). As will be presented in Section 7. this enables the programming in the system. If, on the other hand. the problem is not programmable (*6), then a new exploratory problem solving starts (*7). The system with these methods of combining different functions can accept new functions with the least change of the existing system and can grow to acquire higher intelligence.

6. Some examples

of multi-strata

model

6. I. Education sytem The multi-strata scheme is necessary for representing education systems. A student intends to solve a problem given by a teacher, for example, on a natural phenomenon in the course of natural science. In this problem solving, the subject is a student and the object is a natural system. The teacher has a different problem, being to make appropiate problems for the student to lead him/her towards understanding of the natural system. These problems must be made considering the level of understanding of the student. The student tries to make a model of object being studied and this whole is the teacher’s object. The teacher tries to make his or her own model. Moreover, if some third person intends to replace the teacher by an intelligent tutoring system, there emerges an outer problem solving process, in which this person is a subject and the teacher and his/her problem is the object. Thus in this case a three-strata structure is formed. The requirement to this third person is again to ‘automate activity’, as discussed above. The requirement to the teacher is ‘teach student on X’, in which X is an object to be taught. This is represented ‘teachStudent(subject1, i, student, TeachObject, Domain)’ formally in which i represents the ith student, the TeachObject is substituted by an object which the teacher is teaching and Domain is the domain in which this Teaching-object belongs, in this case natural science. Then the requirement in the predicate ‘generateSystem( subject, requirement, system)’ included in the ‘automateActivity’ is substituted by ‘teachstudent’ to generate ‘generateSystem(Subject, teachStudent(Subject 1, i, Student, TeachObject, Domain), System)‘. The rule for expanding this requirement must be made. It must be different from that for ‘SolveProblem as was shown before. That had only a single object, but teachstudent has

S. OhsuRa/Kno~ledRe-Hasrd

Systems

IO (1998)

363-396

385

payMoney(SubjTeller, ClientName, DrawAmount),-* sendReport(SubjTeller, SubjReport, Date, Time, ClientName, AccountNumber. DrawAmount).-*

Fig.

17. Enterprise

model

two objects, i.e. students having their own objects, and the things to be taught, and the latter can be an object including human beings, such as social science. This makes the modeling of the teaching more complex. Furthermore, since a teacher cannot look into a student’s mind directly, he/she has to make a model of the student based on the answers of the student to the given problems [23,24]. Today, any method of making a student model is not yet established. It must be studied first, and then a rule for ‘generatesystem’ must be made. 6.2. Enterprise

model

and enterprise

design

Enterprises are becoming the objects of scientific/technological consideration. An enterprise is composed of many persons, and there is a conventional method of representing the enterprise organization as a hierarchy by a simple boss/ clerk relation. If, however, the person at a higher level has a role of evaluating the activities of persons at the lower level, then the conventional method is inadequate. A multi-strata model may be necessary. Each person is assigned a specific role, depending on the position in this structure. A person at the highest level, say a president, has a role to make or keep a vision of the enterprise as a whole, and a corporate strategy. These are the highest level requirements given to this model. To make business strategy may be the role of the senior executive at the next level. On the other hand. the actual operational tasks are assigned to the persons at the lower levels (Fig. 17). Each task is represented as a functionality for the subject, and relations among them define the activities of the enterprise. In an old style bank system, for example, a teller at the counter (a subject) cooperates with other persons to respond to the request by a client to draw money. Let this be represented simply as the follows. Rule for draw money (R23): drawMoney(SubjTeller, ClientName, Date, Time, AccountNumber, DrawAmount):checkDeposit(SubjTeller, SubjDB, ClientId, Date, Time, AccountNo, DrawAmount),-*l

This is made only for the purpose of explanation and is very much simplified. SubjTeller, SubjDB and SubjReport denote the subjects having the roles of telling at the counter desk, operating database and accumulating information in order to make a report. This relation and further ones including ‘checkDeposit’ and ‘sendReport’ define the activities of the bank. Usually this kind of rule has been rnade at the beginning and exists in every bank. Nowadays, some special machines like cash dispensers are introduced in the enterprise and are the important constituents of the enterprise. These machines accept various user’s requests such as money drawing by cash card, money depositing by a bankbook, sending money to an account in another bank, and so on. Each request is represented formally in a similar form such as ‘drawMoney’, as shown above. The machine is a human interface to generate the formal request. To define the enterprise the relations of the tasks in the model that includes these machines must be provided. Even if many persons are included in an enterprise. if every task is well defined as parts of the task to accomplish the objective of the enterprise, then the enterprise ia modeled by the ordinary object modeling scheme. It clarities the activity of the whole enterprise and of the persons working there. and accordingly it is used for making a specification of programs to be developed to this enterprise. For example, a job is defined as an information flow in the structure. Tasks are defined as the way of dealing with this information at the related nodes along this flow. This process is shown explicitly in the model and ‘ISvisualized (Fig. 17). Activities such as ‘drawMoney’ shown above can be made in this way. This is an example of externalization. If it is judged that this enterprise is not fitting to the changing social environment, then it must be restructured. The proper organization that adapts to the environment has to be found by analyzing the model for the adaptability to the environment, and if it is judged inappropriate, then by restructuring. This is similar to engineering design, and is called enterprise design here. There must be a designer (or designers) who deals with the enterprise as a design object. In this case ;I multi-strata model becomes necessary, in which the designer is a subject and the enterprise is the object. Simulation may be the only method to analyze the enterprise to achieve this design. If every functionality and their relations are represented in detail in the model and knowledge for tinding the required quantities is provided, then the enterprise model as shown above can be used as a simulation model and the simulation is possible. Such a simulation has been performed for a part of a hypothetical bank organization by Ushijima [25]. He simulated the behavior of a team of employees who sell and

386

S. Ohsugcr/KnowledRe-Based

buy money according to the variation of the money price in the market. Different levels of freedoms in decision making are given to senior and junior staff in this team. The simulation was performed using real economic data in past and balance sheet was made for 80 units of period. Different approaches for restructuring are possible. In some companies the persons at the higher ranks evaluate the lower rank people for the purpose of restructuring. In this case, a multi-strata model may be created. This kind of restructuring was included in the above experiment. According to the result, the organization of this team was restructured. 6.3. Automatic

programming

A computer program is an automatic system to generate a solution to a given input and replaces a person who has been working with this task. A programmer makes the program after analyzing the tasks done by this person. Automatic programming is therefore to automate the generation of automatic system. This method also needs to be represented by a multi-strata model. A subject Sl processes a task, the lowest stratum object 01. For example, 01 is a transaction in an office information processing system and Sl is a teller at the counter in a bank. The object-level requirement Rl is made by a manager as tasks performed there. The requirement R2 given to the subject Sl may be ‘to process this task’. A programmer is the next stratum subject S2 with a next stratum object 02 composed of S 1 and 0 1. S2 is given a requirement R3 ‘to make a program for Sl’. A third stratum subject S3 studies the activity of S2 and generates a system to replace it. The requirement R4 to S3 is to ‘automate the activity of S2’ again. Automatic programming is realized in two steps. The first step is to generate a system to satisfy the requirement of producing required output for the given input. This is to generate a problem specific, autonomous problem solving system, as discussed in Section 4.3. The given problem can be solved by exploration in principle. The second step is to convert the exploration based problem solving to a deterministic, procedural form. The method of automatic programming is different case by case, especially by the characteristics of the lowest stratum object and the tasks allotted to S 1. This is discussed in Chapter 7.

7. Automatic

programming

for assuring

practicality

To generate a problem-specific problem solving system helps to solve problems more efficiently than to do with a simple knowledge base including all knowledge. In this sense it contributes practicality. But this is not yet enough. An exploratory problem solving is not an efficient method. A procedural program is a more practical approach if a problem can be solved algorithmically and the operation is

Systems 10 (199X) 363-396

repeated many times. But the ordinary way of programming by person is problematic. In this chapter it is considered therefore a way of making program in the system as a special type of problem solving. 7.1. Problems form

which can be represented

in the procedural

Not necessarily all problems can be solved in an algorithmic way, but some problems need essentially the exploratory method. It depends on the characteristic of each problem. In the case of office programs, as discussed above, the task of Sl could be specified to the detail in relation with object 01. The task of a worker is stated explicitly in the algorithmic way in a system engineer’s brain before programming today. This is in reality making a part of enterprise model. If such an enterprise model has already been made explicitly by means of multi-strata model and the object 02 is made clear, then it is no more necessary for a system engineer or a programmer to analyze the object him or herself. Thus problems must be classified into the programmable class and the others. For the programmable class of problems the models do not change during problem solving. The program once determined can be fixed afterward and makes a solution to an input in the deterministic way. This is the condition of representing problem solving in the form of a procedural program. For this type of problem solving, making an object model like an enterprise model is a harder and more important task than programming itself which can be automated, as will be discussed below. The other problems need exploratory problem solving. The task of programming is itself an exploratory problem solving by the subject S2 for finding the program as a solution. Even if an object-level problem needs exploratory operation, its programming is still possible if the scope of searching solution is limited to the finite set. Then a procedure of selecting one from the set of alternatives, interpreting selected knowledge and backtracking, i.e. an inference operation, can be included in the program. But a program including such a run-time inference is usually inefficient, and a faster program can be made by interpreting and compiling knowledge in advance and including only its result in the program. A table-driven program is an example. Alternatives in decision making can be enumerated by interpreting knowledge off-line and representing the result in the form of decision table consisting of pairs of a value of a control variable and the corresponding operation. Then an exploration is replaced by a table look-up operation. A program can execute table look-up and call for the corresponding operation. In order to clarify this, a decision table is provided in the form of predicates. Let an operation ri be selected from a set (rl(y), r2(y), -, m(y)), in which y represents a (set of) variable(s) defined in these operations. Let the operations be represented by z(y). This is a meta-level representation.

An item of a decision table is a pair(i, z(y)) in which i is an index and z is a corresponding operation name (one of rl OI r2 or - or rn). Then a decision table is defined as ‘decisionTable (TableName, Index, z(y))‘. The table look-up operation first takes out an index for the given value of x then selects the corresponding operation. The index is obtained by some operation to classify a control variable x of a known predicate p(x) into a set of finite discrete classes. Let it be classify(x, i). In the program this causes the same effect as control by control knowledge in the meta-level in the exploratory operation. In other words, the effect of control knowledge is included in the program as the control structure of the program. The knowledge confines the scope of the object knowledge to the set (r I, r2, -, rn), which is effective for solving the given problem. In order to generate the control the following form is used together with the decision table. Rules for decision table (R24): index (x. Index):- p(x), classify(x, Index). selectRoutine(x. z(y)):- index(x, Index), decisionTable(TableName, Index, z(y)), callRoutine(x. z(y)). z(y) is substituted by one of rl(y), r2(y), -, m(y), depending on the index value obtained by classifying the value x to the classes. The predicate ‘decisionTable’ is a meta-level expression and a specific procedural program is provided to replace it at the time of translation into a procedural program. The predicates ‘index’ and ‘decisionTable’ belong to the problem specific knowledge. Therefore these are included in the object model. A special program structure (such as branching/conditional/case-of statement) is generated by using this knowledge, according to the special syntax of the ordinary programming language. When n = 2 in ‘SelectRoutine’, this represents an if-statement. Finally ‘callRoutine(x. z(y))’ is a predicate which is used only for transferring operation control to z(y). callRoutine(x.

z(y)):-

z(y)

Sometimes a decision tree is made instead of a decision table. In this case tree search operation is used instead of table look-up operation. One may think that the table look-up or the tree search can be represented by a set of the separate first-order predicates as follows’: rl(y):r2(y):_

p(x), index(x, I). p(x). index(x, 2).

m(y):-

p(x). index(x. n).

’One may think these expressions somewhat strange because the variable y appears only in the head. Variable y is a (set of) variable defined in the selected operation. It may or may not be included in p(x) and index(x, i) in the body. In the former case as above, ri(y) behaves as a proposition to the predicates including the variable x. There is no substantial difference hetween these two cases. To make the expression rather simple, the above expression is used.

This is a way of representing the execution of an exploratory operation. But this is not appropriate for generating a procedural program, because with this representation it is not possible to represent the procedure to select one out of possible alternatives in a program. This is discussed in Section 7.3.2. In the other cases for which the alternatives can neither be fixed nor finite, the representation of problem solving in the form of a procedural program is difticult because it implies interpreting unknown knowledge in the execution of the program. In this case it is better to use a declarative form of expression with an inference engine. This is the reason why knowledge representation may often be an alternative to ordinary programming language. Thus problems are classified into two classes. one which can be translated into procedural programs and the other for which exploration is indispensable at problem ‘ t-l. If and only if tl + n*t2 > tl + t2 + t3 + n*t4, i.e.. (11*-l )t2--n’Q4 > t3. converting to a procedural program is more effective than using the exploratory method directly.

388

7.2. The operations

S. Ohsuga/Knowledge-Based

of the second/third-stratum

subjects

For a problem belonging to the programmable class, a procedural program is made. A multi-strata model is made in Rule22. The highest- and the second-stratum subjects of the multi-strata model are given the requirements ‘automateActivity’ and ‘makeprogram respectively. The lowest-stratum subject has already been given the requirement such as ‘drawMoney’ in the example before. The highest stratum subject generates a system for making a program for this requirement. This is composed of the knowledge chunks corresponding to the first and the second steps for making a program; the first is for generating the interim representation of the program structure by solving the given problem and the second is for converting the structure into a program code. The second-stratum subject makes a program using these systems. There can be different types of objects to which the programs are to be made. The first step above is problem dependent, i.e. requires different operations for different program requirements. On the other hand, the second part is common to all cases. The problem specific knowledge chunks must be retrieved for the first part but the common knowledge chunk is used for the second part. The office program, as shown before, is a type to which the operational description of the task and the scope of input requests are specified. In this case a program is generated according to the protocol represented in the form of the relation between functionality in enterprise model. The protocol was to define operations for the user’s requests like ‘drawing money’. Let this class of program requirement be called the task-processing type. An exploratory operation is necessary in order to generate a basic structure of program in the form of a deduction tree. In order to generate the general deduction tree to cover all the possible inputs to the system, the system selects an instance input (or instance inputs), finds its solution leaving a deduction tree behind, then generalizes the tree. Then the tree is converted to the program. Backtracking occurs in exploratory problem solving. It is necessary to trace the problem solving procedure for creating the deduction tree. In order for the system to record the path successful in reaching the goal, a special type of inference operation is necessary. Since the inference engine is a program, it is possible to include this tracing function in the inference. The mode of inference is specified as either normal mode or trace mode. Exploratory problem solving can be represented in the procedural form if the scope of search at exploration is finite or an algorithmic search operation is specified, like genetic algorithm. This is another type of programming. Programming method is very different from that shown above. In general different types require different programming methods. In the following the task-processing type is paid attention. The following rule is used to expand the predicate ‘generatesystem in automateActivity activated by Rule 22.

Systems 10 (I 998) 363-396

Rule for generating automatic programming system (R25): generatesystem (makeProgram(Subject2, Subject 1, Domain, Program), System):#getSubjectRequirement(Subjectl, Requirement),-* 1 generatesystem (Requirement, System),-*2 The requirement to the lowest subject (e.g. drawMoney) is taken out (* 1) and a system to solve the problem and to make a deduction tree is retrieved (*2). After that, ‘makeprogram is activated (by ‘automateActivity’). Rule for making program (R26): makeProgram(Subject2, Subject I, Domain, Program):#getSubjectRequirement(Subject 1, Requirement, Input),-* 1 identifyProgramType(Requirement, Type),-*2 makeProgramS (Subject2, Requirement, Input, Type, Program).-*3 The main role of this rule is to identify the programming type depending on the requirement, and provide the different rule by the type for making a program. The requirement of the program is obtained (*l) and its type is identified (“2). The rule corresponding to this type is called (*3). Rule

for generating

task-processing

type

program

(R27) makeProgramS(Subject2, Requirement, Input, Type, Program): generateInstance( Requirement, Input, InsRequirement),-* 1 solveProblemTrace(InsRequirement, System, InsTree),-* generalizeTree(InsTree, Input, Tree),-*3 convertToProg(Subject, Tree, Program).-*4 This is a rule specified to the task-processing type. The problem is specified by the task composed of the required operations and the scope of inputs. In this rule a set of instance inputs are selected from Input and an instance requirement (InsRequirement) is generated (* 1). It is solved in the trace mode using the system generated for the operation and leaving the deduction tree (InsTree) (*2). This tree is generalized to Tree to cover all the input in the given scope (*3). Finally a program is generated from-this tree (*4). The method of making the deduction tree and its conversion to a program is discussed in Section 7.3.

7.3. Generating

a program code

7.3.1. Structural components of program An automatic programming system must be able to generate very complex programs. In general, a complex program is synthesized from less complex programs, each

of which is, in turn, composed from still simpler programs. At the leaf of the structure are primitive programs to do primitive operations. The primitive programs are the components of making a large program. Developing a large program therefore is to make a structure of the component programs. In any procedural programming language, every program structure is composed of a limited choice of structural components such as sequence, branch, loop and so on. In addition, the structure of the main-program and subroutine is important from the practical point of view. Hence the system must be able to represent these structural components and generate any complex program structure by means of these components. In this section the expressions in logic that correspond to the program structural components are discussed. 7.3.1.1. Suhutine cdl. A subroutine is a separated part of a program, and the reasons for taking this structure are the convenience of program development in the first place and saving memory for those parts of program that are repeatedly used. In a logical sense. whether to separate a program into a main program and subroutine(s) or not iq insignificant. It is therefore no way to represent this program structure by first-order logic. but a higher order logic expression is necessary. We can use ‘subroutine(z(y))‘, similar to ‘callRoutine(x, z(y))’ which was used in the definition of decision table for this purpose. ‘suhroutine(z(y))’ generates a subroutine call procedure for the predicate z(y). Let us assume, for example, ‘solveProblemT’ counts the number of the same predicate being included in the succeeded path in generating the sequence of predicates. If a predicate P is included more than twice, then P is replaced by ‘subroutine(P)‘, and generates the program for P independently. Binding variables in P may be different in every call. The program P must be defined to include the definition of variables, as is discussed later. 7.3.1.2. Brunch. Branch is an operation to select a path among many by the specified conditions. It corresponds to executing the following predicates in an exploratory process. predicate( x, y):- p(x), condition- 1(x), predicate- 1(x, y) predicate(x. y):- p(x), condition-2(x), predicate-2(x, y) _ predicatecx.

y):- p(x). condition-n(x),

predicate-n(x,

y)

This means that predicate-i(x. y) is selected for predicate(x, y) if the ith condition holds. We saw in the discussion of a decisiov table before that only the path selected by the specific index corresponding to a specific input is left, but the others are discarded. The other paths may be selected in the same program for the other inputs. In order to generate a program to cover all the cases that can occur with the required inputs, the selection mechanism must be included

in a program. One way is to use a decision table. However this is rather a specialized way. Alternatively it is realized by an integration of the separate rules as follows. This imposes some constraints on knowledge representation (refer to Section 7.3.2.). Rule for branch operation

(R26):

predicate( x, y):- p(x), condition-

I (x ). predicate- I (x. y)

+ p(x ), condition-2(x), predicate-2(x. y) + - + p(x), condition-n(x). predicate-n(x.

y)

7.3.1.3. Loop. A loop is a way of repeating operations. The operation in every cycle of a loop may be different, but it must be represented in the same form including a parameter which differentiates each operation. Let i denote the i-th operation cycle. Then there are two cases depending on the way in which the i-th operation is detined. i.e. (A) one which is based only on the index i and (B) the other which includes operation including parameters other than i. 7.3.1.3.1. Case (A). This is the ca\e in which the i-th operation is closed with respect to i. that is. the i-th operation includes only the index i. An example of this case is an operation to obtain a sum of n values. v I, v2.-. vn, in which the i-th operation of the loop ib detined based on vi, a function only of i. Then the operation is represented such as to include sum = sum -t \i and i + I = i in the ordinary program in which ‘sum’ is a variable to represent a partial sum. The loop is repeated until i becomes equal to n. The ‘sum’ is not a variable in the mathematical sense, but is a place holder in programming. It play\ an important role to represent every cycle in the same form and allow5 a repeated operation as a loop. On the other hand. every variable in predicate logic must be defined mathematically, and there is no concept of place holder. An alternative method is necessary therefore to represent operations in the same form for all cycles. A concept of set can he used instead of the place holder. Let summing up vi to ‘\um’ be replaced adding an entity vi to a set s. Thus the set \ contains v I. ~2. -. vn when the loop ends. Then an additional operation to sum up all the elements in the set s produces the required result. The looping itself corresponds to ;I quantifier in the predicate. As an example, let a predicate (Ax/dl)(Ey/d?)(predicate(x,

y). addToSet(y.

\)‘I

be evaluated. The reader may note that the link mechanism, as was shown in Fig. 4, had this type of query. Therefore it can be translated into a loop. Coming back to the simple example above for explanation, that predicate says that y meeting predicate(x, y), a relation with respect to Y. is to be saved in the $et s. The variables x and y correspond to i and vi as above respectively. Then this i\ Skolemized to an expression like predicate( x/d I, f( x)/d2), addToSet( f(x Yd2. s) in which some y satisfying

the relation

‘predicate(x,

y)’

S. Ohsuga/Knowledge-Based

390

with respect to x is represented by y = f(x) in the form of a mathematical function. This is transformed into a procedural operation such as [while xedl, y = f(x) and s = s + y] in which + denotes an add-to-set operation. After the end of the loop, an additional operation to sum up all the elements in s, ‘sumUpSet (s, v)‘, must be executed. This is not the best way but has some flaws. First, it needs a memory space for the set to contain y = f(x) for all x’s. Second, it needs the additional operation ‘sumUpSet (s, v)’ after the end of the loop. In order to improve these while assuring to generate the same operation as the ordinary loop operation, a special predicate to combine the add-to-set operation and ‘sumUpSet’ operation is defined such as ‘addSet’ without violating the logical concept. This predicate has the compound effect such as to add an element to a set and sum up all the elements in the set. For example, if (Ax/dl)(Ay/d2)(Av/d3)(sumUp(x, y). addSet(y, is provided

y, v):-

predicate(x,

s, v))

in the system and the query

(Ax/table)(Ey/real)(Ev/real)sumUp(x, which corresponds to x in the table)

y, v)? (sum up y

is presented, then the following expression transformed into a loop operation, (Ax/dl)(Ey/d2)(Ev/d3)(predicate(x,

is deduced and

y), addSet(x, s, v)).

7.3.1.3.2. Case (B). In the other case in which the operation is not closed with respect to i but includes some values relating with i - 1, i + 1 or so on, such an operation as addset cannot be defined because, in this case, the quantity to be added to the set may not yet be evaluated. A typical example is a recursive function which needs a function value with another index than i which may not yet be evaluated. Note that the following is only for the purpose of discussing the structure of loop operation and not of discussing the general recursive function. The above case is further divided into two classes. One is a case in which a recursive function is included in the other known function. This is represented in the mathematical form,

Systems 10 (IYM)

363-396

and recursiveFunc(x, 0, a) recursiveFunc(x, i, y):- recursiveFunc(x, knownFunc(x, i, u), operation*(u, z, y),

The other is the case in which a recursive included in the other function, such as f(x, 0) = a f(x, i) = f(x, i -

function

is not

1) * g(x, i)

where the function g is a known function arithmetic operation. In the logical form these are represented, recursiveFunc(x, 0, a) recursiveFunc(x, i, y):knownFunc(x, i, z, y)

recursiveFunc(x,

and * is an

i -

1, z),

1, z).

respectively. The difference between them is whether ‘knownFunc’ includes the value of the recursive function of the previous step or not. In the second case ‘knownFunc’ can be evaluated at every step and added to a set (s) as was the simple loop case of (A) above since the value of the recursive function at the previous step does not appear in the known function. operation* defines the operation to apply to the set after the loop ends. Then the value of a recursive function for i = 0 is obtained and these of the other cycles are obtained by applying operation* to the obtained value successively in the reverse order of the loop. Thus the set s must be an ordered set. In the simple loop case the set could be unordered. Therefore the operation for the set after the loop can be performed in any order and, moreover, it could be moved into the loop. This is the difference between the case of a simple loop and that of a recursive function. In reality however, if operation* is commutative like addition and multiplication, then the operation can be achieved in any order and it can be distributed in each cycle of the loop as was the case of the simple loop. If operation* is not commutative, then the set operation must be done precisely in the reverse order of i, and therefore must be done only after the end of the loop. In the first case, on the other hand, in which a known function includes the value of a recursive function, the known function cannot be evaluated until a recursive function is obtained. In this case a loop is formed and the known functions are preserved unevaluated in a set. When a known value for a recursive function is reached, the loop ends, and the given functions are evaluated successively in the strictly reverse order of the loop. This operation cannot be moved in the loop, but the second loop is necessary after the first loop for obtaining the required value of the recursive function. There can be more complex cases, such as a two-way recursion like, f(x, i) = f(x, i-l)*f(x,

f(x, 0) = a f(x, i) = g(x, i, f(x, i - 1))

i -

i - 2).

This is classified into (B) by the above classification. In converting these to procedural programs the ordinary compiling technique is used. This is not a matter to be discussed here. 7.3.1.4. Database access. A database is an independent system from the application problem and a method of accessing databases must be provided. Actually the database, especially a relational database, and logic are very close conceptually, and it is possible to generate the database access procedure, by SQL for example, automatically. There have been a number of research works on this issue and the author and his colleague

S. Ohsuga/KnowledKe-Based

discussed the method in Ref. [ 111. It is out of the scope of this paper. 7.3.2. Knowledge representation suited for programming Let the exploratory problem solving system find a sequence of predicates to reach the goal from the given problem. In order to generate a procedural program from the sequence, a special way of knowledge representation becomes necessary. As was seen before some basic operation units, like branch, are represented by two or more separate rules. This is inconvenient in translating into procedural form. It is better to be integrated into a single form including disjunction as follows, so that a single rule corresponds to a single procedural operation unit. (#l) (Ax/dI)(Ay/d2)[predicate(x, y):- p(x), conditionI(x), predicate-1(x, y) + p(x), condition-2(x), predicate-2(x, y) + - + p(x), condition-n(x), predicate-n(x, y)] When the quantifier and the domain of every variable in the separate predicate is the same, it is possible to represent the integrated form in the prefix normal form as above. When this condition is met, the prefix is omitted hereafter. The decision table and recursive function are represented in a similar form as follows. selectRoutine(x, z(x)):- p(x), classify(x, i), decisionTable(TableName, i, z(x)), callRoutine(x, z(x)), recursiveFunc(x, i, y):- recursiveFunc(x, 0, a) + recursiveFunc(x. i - 1, z), knownFunc(x, i, z, y). In order to avoid a difficulty expected to arise logically in dealing with the disjunctive expression, it may be better to restrict it only to the exclusive disjunction, i.e. one and only one predicate in the disjunction is true at a time. It is not necessary nor desirable to assume order-sensitivity. It is to be noted that a set of the predicates with the same head but with different domains, (Ax/dl)[predicate(x):(Ax/d2)]predicate(x):-

predicate-l(x)], predicate-2(x)],

(Ax/dn)(predicate(x):-

predicate-n(x)],

can be integrated into a disjunctive set of dl, d2,-. dn as the domain,

form having the union

(#2) (Ax/d)[predicate(x):(x E dl ),predicate-l(x) + (x E d2),predicate_2(x) + (x E dn),predicate-n(x)]

+ -

inwhichd= U,=,,,di. This gives a rule to interchange between a set-theoretical and a logical expression. This rule is used for generating branch operation as shown in the next section. Let there be a set of rules in which the condition parts may not be mutually exclusive.

391

Systems IO (199X) 363-396

predicate(x, predicate(x, -

y):- p(x), condition- 1(x). predicate- 1(x, y) y):- p(x), condition-2(x), predicate-2(x, y)

predicate(x

y):- p(x), condition-n(x),

predicate-n(x.

y)

The rules are then classified into the different sets such that the rules in each of the sets are mutually exclusive. The set of mutually exclusive rules are merged in a disjunctive rule. There arises more than one disjunctive rule, as follows. predicate(x y):- p(x), condition-al(x), predicate-al(x, + - + p(x), condition-ak(x), predicate-ak(x, y) predicate(x y):- p(x), condition-b1 (x), predicate-bl(x. + - + p(x), condition-bm(x), predicate-bm(x, y)

y) y)

predicate(x y):- p(x), condition-p 1(x). predicate-p1 (x. y) + - + p(x), condition-pn(x), predicate-pm x, y) There may be the different ways of classitication. A different set of the separate disjunctive rules can be made corresponding to the different classifications. It is desirable that the disjunction in each rule is not only exclusive but exhaustive, i.e. every value x of p(x) meets exactly one and only one condition in a disjunctive rule. In this case everything can be done with a single disjunctive rule. All the other rules are redundant and can be discarded. Or, if there are the other rules meeting this condition too, the best one is retained. Since the disjunctive rule is converted to a branch operation in the procedural program, the rule with the least disjunction is the best. But usually this condition is not met when the rules are made independently. In this case more than one disjunctive rule are retained. This is a matter of rule design. Among all predicates, some are called the terminal predicates and are given a mark. Predicates accompanied with some specific procedure, that is, PTP, are the terminal predicates. The predicates representing the program structures such as ‘branch’ and ‘loop’ and those concerned with database access, as discussed before, are also dealt with as terminal predicates, tentatively. for the convenience of transformation. 7.3.3. Generution of u sequence qfpredicates

us LIsource of

programming

In order to generate a procedural program the second stratum subject S2 studies first a way of satisfying the given requirement like ‘drawMoney’ in the office system. In the case of an automatic programming system, this is to solve the problem using domain knowledge by exploration. The result is a deduction tree composed of the related predicates in the knowledge. By tracing the problem solving, only the predicates to generate the succeeding path are included in the tree. For example, an input format is detined for a moneydrawing operation to form a problem in the bank application.

Table 1 Inference rule of MLL (Qs. S)

(Qt, V

Unifiability condition

(Qr. RI

(A 0% 0% (A

(A, (A, (E (E.

ScT S f~ T( = Z) # empty S>T None

(A. S) (E. Z)

S) S) S) S)

T) T) T) T)

It includes variables, internal form is

and each variable

(A. T) (6. -1

has its domain.

Its

(Ax/person)(Ay/person)(Az/day)(Au/time)(Av/integer)(Aw/integer)drawMoney(x, y, z, u. v, w) where x is SubjTeller, y is ClientName, z is Date, u is Time, v is AccountNumber, w is DrawAmount. It includes various instances. The scope of the instances it covers and consequently the scope of the generated program depends on the domains of the variables in the expression. Each variable domain is shown independently of each other in the above expression. Hence it is possible to include some combinations of the instances which do not occur in the real world. These are don’t-care cases. It may be possible to make the input format to exclude these cases, but this makes the requirement expressions complicated and brings some inconvenience to users. Unless the don’t-care cases have a bad effect, they can be included in the scope of the program. Otherwise, the program is required to check the legality of the input. In order that a program is able to accept every instance in the scope of the input, the program should have the variables to encompass the possible cases of the input. One way to assure this, if possible, is to try to solve this problem including the variables (called simply the general problem hereafter) by exploration. If a solution could be found, then the generated path and accordingly the program generated therefrom by transformation encompasses all the required cases. This simple approach of handling all the cases uniformly is not always successful, however, because different instances may require different processing. For example, it is difficult to obtain a solution for a general problem if it includes database access because this is an instance-based operation. The cases requiring the different processing must be classified. Before trying to solve this general problem directly, an instance problem is generated from the general problem by tentatively specifying the constant values for the variables, and then this instance problem is solved. The reason for doing so is twofold; first, a deduction tree produced for this instance problem (instance tree hereafter for short) can be used effectively to create the deduction tree for the general case (general tree for short) in most cases, and second, if it cannot get a solution, then it means that the

prepared knowledge is not sufficient and persons can knou in early time that the general problem cannot be solved. Thus. first the instance problem is solved by exploration. This results in an instance tree. Then it is generalized to result in a general tree. Since mostly the same rules are referred to as those for the instance problem for solving the general problem, the basic structure of the deduction trees for both cases are similar (but not exactly the same). For the purposes of generalization. every node is reviewed successively starting from the top and the predicate is generalized. At the top node, this is to replace the instance problem to the original one. Let there be already a structure originating from the top that was generated for the instance problem. Let the rule used there be of the form A:- B 1, B2. -, Bn to which A is unified with the predicate of the instance problem (instance predicate hereafter). Then an AND tree composed from B 1, B2, -, Bn is generated where Bi (i = 1. 2, -, n) denotes Bi of which variables and quantifiers are modified by the unification with the instance problem. Then the next level nodes, Bl, B2. -, Bn are tried to be generalized. This is not to put them back to Bi’s, because the original form of the rule may not be a proper rule for the general problem (A may not be unifiable with the original problem). This checking and generalization is performed as follows. For ease of explanation the case of a single variable is shown here. Let the original query, the rule, and the deduction be represented (Qsx/S)F(x), (Qtx/T)[F(x):G(x)], and (Qrx/ R)G(x) respectively, in which (Qs, S), (Qt, T), and (Qr, R) are (the quantifiers, the domains of the variable x) of the query predicate, the rule and the conclusion, respectively. Then the propriety of the rule and (Qr, R) are obtained from the first two by the inference rule, as is shown in Table 1. This table shows the unifiability condition, as well as the domain and quantifier of the deduction by the relations between the quantifiers and domain sets of the query predicate and the rule. For the more general case refer to Ref. [2 11. Thus, the new quantifier and the domain of variable for the new predicates are determined and the predicates B I ‘, B2’, -, Bn’ are obtained as the generalized predicates. This operation is repeated to the bottom of the deduction tree. It can happen that a rule A:- Bl, B2, -, Bn was appropriate to solve an instance problem, but not for the general problem, because the variable domain of the rule is different from that of the general problem and the above unifiability condition is not met. In this case, another rule must be looked for. If there is another one, A:- C 1, C2, -, Ck meeting the condition, the sub-structure below A of the instance tree is canceled and the process starts from scratch with the new rule. If there is no such alternative rule, the problem cannot be solved with any existing single rule. There is a possibility of combining some rules with the same head to generate a disjunctive rule of which the domain of the variable is the set-theoretical union of the domains of the rules (refer to #2 in Section 7.3.2). If this disjunctive rule meets the unifiability condition, then the original sub-structure is

S. OhsuKa/Knowled~e-Leased

La;

Systems 10 (I 998) 363-396

evaluated at instance problem solving

??not evaluated in instance problem solving

RULES(Ax/Rl)[f(x) :- gl(x), P(x), g3(x)] (Ax/Wgl(x) :- PW PM. PWI 644=W@) :- SW. qW9.SW1 (Axm)[g3(x) :- W), q9,

r3(x)]

(Ax/Dl)[rl(x) :- sl(x)] :- W)l

(~2)kUx)

(Ax/D3)[rl(x) :- s3(x)] :- +91

(~)kl(x)

Dl uD2 UD3 2 R

. . ..I..... (‘wDn)[rl(x) (‘Q?[sl(x)

:- m(x)] :- t1w, Wx)]

Fig. 18. Deduction

tree and its generalization.

replaced by a disjunctive (OR) node which is translated afterward to a branch operation. This disjunctive rule may have already been made, as discussed before. Then a disjunctive rule could be used in the instance problem. If exclusiveness is assumed between predicates, as discussed in Section 7.3.2, then each path can be considered separately. As can be seen in Fig. 18, only a predicate that is unified with the given instance problem is used in this disjunction, and the deduction proceeds further along the selected predicate. The other nodes were not used, but will be used for generating the general tree because the disjunctive expression may be necessary as the deduction of a general problem. If a disjunctive rule of the form A:- Dl + D2 + - + Dm is used, then the predicates in a disjunctive sub-structure composed of Dl, D2, -, Dm must be made to represent a general tree. This corresponds to a branch or a loop operation. In any disjunctive rule there must be at least one variable to discriminate the cases. In the example of branch operation shown before it was x in p(x). In generating a general tree, the domain of this variable in this rule must meet the unifiability condition with respect to the domain of the corresponding variable in the problem. The domain of this

variable in the disjunctive rule is the set-theoretical union of the domains of the variable in all predicates in the disjunction. For example, in the disjunctive rule as given above (#2 in Section 7.3.2), the domain d as the set-theoretical union must include the domain of the corresponding variable in the problem. Contrarily, the domain d can be much larger than the required domain dp of the problem and, a domain dn in some predicate, say predicate-n(x), may be out of dp. Then this predicate is not necessary and should be erased in order to generate a least necessary branch. If di, (i = 1, 2, -, n), are not mutually disjoint. then some difficulty arises. For example, let di and d2 be not disjoint. Let dl = dl’ + c and d2 = d2’ + c in which dl’ and d2’ are disjoint. In this case, either predicate- 1 or predicate-2 can be selected for x in c. It can happen that, depending on this selection, the following process changes. The system must be able to divide c into cl and c2 such that predicate- I and predicate-2 are selected for the domain dl ’ + c 1 and d2’ + c2 respectively, so that the problem can be solved, and, if possible, in the optimal way. Assuming that the number of rules is finite, it is possible to make disjunctive rules in this way. As was seen so far the representations of the logic and mathematical set have to be interchanged

frequently depending on the relation between rules and problems. The propriety of the rule is checked, and OR sub-tree is generalized in this way. In the instance tree, a sub-tree is made only below the node that matched with the instance problem. In order to make the general tree the sub-trees starting from the other nodes than the used one must be generated corresponding to the other instance problems. The new processes must be originated from those nodes regarding the predicates as if these are new problems. While making such a disjunction sub-tree that represents a loop operation, another disjunction can appear. In this case a multiple loops is generated. Database access also forms a special sub-tree. Its content depends on the database schema and the given requirement. While solving the instance problem by exploration, procedural predicates (PTP) may be come. This deduction path ends here and the predicate forms the leaf nodes of the tree. A mark is given to the predicate to show that it is to be replaced by the accompanying procedure. The nodes corresponding to branch, loop and database access are also given the mark in a general tree to show that the respective commands are to be inserted in generating a procedural program. 7.3.4. Data structure Data structure is important as well as program structure. Different from the program structure that concerns problem solving procedure, a data structure concerns an object from which the problem is created. That is, data structure is a computerized representation of object model structure. As was discussed in Section 3.2, any term in a predicate can be a data structure. In this way data structure is included naturally in knowledge and model representation. There is no reason to differentiate the representation of data structure used in knowledge and model representation from that used in the procedural program. The same data structure can be used. Then predicates are transformed into procedural program without changing the definition of the data structure. 7.3.5. Transformation into a procedural program After the general tree is built, it is transformed into the procedural code. The predicates at the terminal in the tree is threaded in the order from the left to the right to form a sequence of the predicates. The sub-tree starting from the branch nodes are processed separately from the main tree. A set of subsequences of predicates thus generated are merged finally. The source code of the procedural program is generated in this way [26]. It is possible to divide the general tree into parts so that each part can be processed in parallel. Every procedural predicate in this sequence is replaced by its accompanying procedure to generate the procedural program. Every variable in a predicate is given a domain and the quantifier in the prefix determined by the rule of Table 1. In translating into procedural program, the type and the scope of variable

can be specified based on the domain. For example. a procedural predicate (Ax/integer)(Ey/real)inverse(x, y) is translated into int x; real y; y = l/ x; Every predicate follows.

is processed one by one from the top as

(0) For every variable in a predicate, its type and scope are declared as above. (1) identify the predicate type; procedural predicate/ loop/branch/database access (or the access to the other, independent systems), (2) the procedural predicate is replaced by the accompanying procedure, (3) for a loop type predicate, the loop type is analyzed, a specific loop structure is introduced for each type with the additional operation if necessary (such as evaluating the functions in a set as was discussed in the recursive function), and the subsequence, generated from the subtree independently, is embedded in the loop, (4) for a branch type predicate, a branch command is prepared, and the subsequences, generated from the sub-trees, are combined with the branch, (5) for database access, an access sequence is generated and replaces the predicate.

7.3.6. Considerations program is 7.3.6.1. Consideration [A]. A procedural generated in three steps; instance problem solving, generalization of the deduction tree and conversion to the procedural program. The first two steps are for obtaining the path to the given goal which is used as the source of program. These steps are problem solving by exploration. An input format is decided for the problem. The objective is to obtain the general deduction tree for the given problem. If it can be obtained in whatever way, the goal is reached. The instance problem is used to facilitate the process. There are three possible cases on the outcomes of this problem solving process. These are 1. An instance problem cannot be solved. 2. An instance problem can be solved but the general tree cannot be obtained. 3. An instance problem can be solved and the general tree can be obtained. If an instance problem cannot be solved, then the knowledge provided in the system is not sufficient and must be reconsidered. The deduction tree should be displayed at the time the processing stops for the convenience of persons who should find what knowledge is missing. The second case implies various difficulties. A substantial one is the way of making the disjunctive rules. A general problem (including variables) represents a set of the instance problems. A rule may be used for solving an

S. Ohsuga/Knowledge-Rused Swtrms 10 (I 99X) 363-396

instance problem but another rule (with the same head) may be necessary for another instance. Therefore one needs the set of these rules that are used for each instance problem. It is assumed here that there exists a number of alternative rules with the same head. If the quantifiers and the domains of variables are the same, these can be combined together and represented formally by a disjunctive rule. If the rule built up in this way can be a deduction of the given problem, then a branch operation can be generated. Thus the more alternatives there are, the larger flexibility the system acquires. If all alternatives could be identified in advance, and an exhaustive and exclusive disjunctive rule has been made, only this rule may be used and the other rules are discarded. In this case, the best procedural representation may be generated. If, on the other hand, the necessary alternatives cannot be represented by a single disjunctive rule but are distributed to several rules, then a set of branching operations must be generated. The largest problem is the way of identifying the necessary rules correctly. There are two possibilities of solving this problem: to use many instances and to analyze the structure of the rules selected by the instance problems. By using more instances, the set of necessary rules can be identified more correctly. But it is not easy to decide a best set of instances. On the other hand, if the rule selected for solving an instance problem contains some predicate that classifies the possible cases (such as p(x) in the case of Section 7.3.2), then there is a reason to think that there are others as well as the selected one. These have the same head as the selected one but with different classification conditions in the predicate. These rules are closely related to each other and can be combined to a disjunctive rule. This syntactic way of forming a disjunctive rule is not complete. Two methods discussed above, i.e. to use many instances and to use the syntactic method of forming a disjunctive rule, may be used together in order to find the correct form. 7.3.6.2. Considerution [El. There remain some problems in the above method. For example, detailed specification of variables like ‘double length’ is not included. This needs an additional requirement. 7.3.6.3. Consideration [Cl. Automatic programming is an automatic procedure to make a program structure of the procedural units in the pre-defined set. A deduction tree decides the program structure to represent a problem solving process. A procedural predicate defines a procedural unit. There can be different types of procedural units. Some of these are to represent very basic programming techniques such as for manipulating data structure. This class of programs is used widely in the different problem domains in common. The others are the domain specific procedural units to represent the basic concepts in each problem domain. The latter class of procedural units may change as the technology in this

39s

domain advances. The language must be able to allow users to define arbitrarily the procedural predicates with a corresponding procedural unit.

8. Conclusion Why should we develop intelligent systems? Or we may ask this in another way. Can we do only with the conventional information technology in the future? To try to answer this question helps us to make the requirements for the future information systems. The problems which arise in the future in many areas of social activities are expected to grow very large and complex [27]. They are already coming to, and will soon exceed, the limit of human capability. In fact human capability is limited in many aspects, such as the limit for dealing with a large scale problem, the limit for adapting the required speed in doing things, the limit of controlling the error, the limit of understanding the meaning of what is happening, the limit of understanding the trans-disciplinary problems. etc. Thus the conventional human based style of problem solving cannot be held anymore but some alternative method, at least a strong supporting method, is needed. It may be surely said that computer technology is the only way to help persons to overcome this difficulty. We recall the recent news that ‘Deep Blue’ beat the World Chess Champion. There was no other way of beating the champion but with a computer. Such computers are not based on conventional technology, but more intelligent systems become necessary. The minimum requirements for the computers are autonomy, generality, and practicality, as was discussed in Section 2. Autonomy doesn’t mean for systems to require complete automation, but requires that a person and a computer change their positions in a problem solving process, and systems can be in-line of the process, while the person helps. Then the system can not only grow by acquiring knowledge, but can make a record of every decision made during the problem solving process. This enables one to check the process afterward and to maintain it. It also serves people to cooperate for solving large problems. To satisfy the requirements for generality and practicality are indispensable for assuring the effectiveness of this system. This paper discussed these issues. Some knowledge representations were presented. But these are the examples to show the feasibility of the idea. Some important macro functions, as the following, are referred only by name. problemType (R2); To identify the type of problem from the requirement, modelCreationMethod(R8); To decide the method of model craetion, selectAnalysisMethod(R12); To select analysis method for the problem,

396

S. Ohsuga/Knowledge-Based

decideModifMethod(R18); To decide model modification method based on the model, furtherDecomposable(R20); To check the further decomposability, problemSolvable (R2 1); To check the solvability of the problem, problemProgrammable (R22); To check the programmability of the problem. These functions must be represented in the form of rules in order to complete the system. Some parts discussed in this paper have already been tested. These attempts were to prove the validity of the way of approaching the goal. The author’s group is coming to the final stage of achieving the goal of this paper as research work.

References [ 11 K. Hori, A system for aiding creative concept formation, IEEE Transactions on Systems, Man and Cybernetics 24 (6) (1994). [2] F.H. Ross, Artificial intelligence, what works and what doesn’t?, AI Magazine 18 (2) (1997) 99-l 13. [3] A.R. Puerta, S.W. Tu, M.A. Musen, Modeling tasks with mechanisms, International J. of Intelligent Systems 8 (1993) 129- 152. [4] J. McDermott, Preliminary steps toward a taxonomy of problem solving methods, in: S. Marcus (Ed.), Automating Knowledge Acquisition for Expert Systems, Kluwer Academic, 1988, 225-256. [5] M.A. Musen, Conceptual models of interactive knowledge acquisition tools, Knowledge Acquisition 1 (1989) 73-88. [6] R.K. Jullig, Applying Formal Software Synthesis, IEEE Software, pp. I l-21. [7] C. Rich, Y.A. Feldman, Seven layers of knowledge representation and reasoning in support of software development, IEEE Trans. on Software Engineering 18 (6) (I 992) 45 1-469. [8] S. Ohsuga, How knowledge based systems can solve large scale problems-Model based decomposition and problem solving, Knowledge Based Systems 5 (3) (1994) 38-62. [9] S. Ohsuga, A way of designing knowledge based systems, Knowledge Based Systems 6 (1) (199.5) 21 l-222. [lo] H. Yamauchi, KAUS6 User’s Manual, RCAST, University of Tokyo, 1993.

Systems 10 (1998) 363-396 [l11 H. Yamauchi,

S. Ohsuga, Loose coupling of KAUS with existmg RDBMSs, Data and Knowledge Engineering 5 (3) (1990) 227-25 1. [12] S. Ohsuga, Multi-strata scheme for conceptual modeling, Informanon Modelling and Knowledge Bases VIII. 10s Press, 1997. I I -2.9. [13] N. Zhong, S. Ohsuga, Discovering concept clusters by decomposing data-bases, Data and Knowledge Engineering 12 (1994) 223-244. [I41 A. Bijl, Showing your mind, in: Proceedings of the Fourth European-Japanese Seminar on Information Modelling and Knowledge Bases, IOS Press, 1994. [ 151 J.A. Bubenko. Jr., B. Wangler, Objectives driven capture of business rules and of information system requirements, in: IEEE Systems, Man and Cybernetics ‘93 Conference, 1993. [I61 Y. Sum] et al.. Computer aided communications by visualizing thought space structure, Electronics and Communications in Japan. Part 3 79 (10) (1996) 1 l-22. [ 171 Y. Matsunaga, Negotiation support agent based on fuzzy decision making with intermittency chaos, Journal of Information Processing in Japan, in press. [18] E. Suzuki, T. Akutsu, S. Ohsuga, Knowledge based system for computer-aided drug design, Knowledge Based Systems 6 (2) ( 1993) 1. [19] E. Toppano, L. Chittaro, C. Tasso, Dimensions of abstraction and approximation in the multimodeling approach, in: Proceedings of the Fourth European-Japanese Seminar on Information Modelling and Knowledge Bases, 1994. [20] G. Han. S. Ohsuga, H. Yamauchi, The application of knowledge based technology to CAD, in: J.S. Gero (Ed.), Expert Systems in ComputerAided Design, Proceedings IPIF WG 5.2 Working Conference, NorthHolland, 1987, 25-55. [21] S. Ohsuga, H. Yamauchi, Multi-Layer Logic - A Predicate Logic Including Data Structure As Knowledge Representation Language, New Generation Computing, 1985.403-439. [22] J. Guan, S. Ohsuga, An intelligent man-machine system based on KAUS for designing feed-back control systems, in: Artificial Intelligence in Engineering Design, Elsevier Science, 1988. [23] H.U. Hoppe. Deductive error diagnosis and inductive error generation for intelligent tutoring systems, Journal of Artificial Intelligence 5 (1) ( 1994) 27-49. [24] J. Self, Model-based cognitive diagnosis, Journal of User Modeling and User Adaptive Interaction 3 (1993) 89-106. [25] M. Ushijima, Ph.D. Thesis, University of Tokyo, 1995. [26] C.Y. Li, S. Ohsuga, A meta knowledge structure for program development support, in: Proceedings of the 5th International Conference on Software Engineering and Knowledge Engineering (SEKE), 1993. [27] W. Wayt Gibbs, Software chronic crisis, Scientific American (Sept) (1994).