Models and Representations in Conceptual Categories Christopher Landauer1 , Kirstie L. Bellman2
7.2.2 Environment Model Descriptions 7.2.3 Location Model Description : : : 7.2.4 Constellation Model Descriptions 7.2.5 Satellite Model Descriptions : : : 7.3 Studies : : : : : : : : : : : : : : : : : : :
Contents 1
2
3
4
5
INTRODUCTION
1.1 Model Sharing : : : : : : : : : : 1.1.1 Ontologies : : : : : : : : : 1.1.2 Problem-Solving Methods 1.2 Outline of Rest of Paper : : : : :
1 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
PROBLEM PARADIGMS
2.1 2.2 2.3 2.4
Analysis by Problem Paradigms : : Basic Algorithms for Typical Cases Values and Types : : : : : : : : : : Control Strategies : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
WRAPPING
4.1 Wrapping Overview : : : : : 4.2 Wrapping Processes : : : : : 4.2.1 Coordination Manager 4.2.2 Study Manager : : : : A First Look : : : : : : : Category : : : : : : : : : : Division : : : : : : : : : : Individuals : : : : : : : : Viewpoint : : : : : : : : : Context : : : : : : : : : : 5.6.1 Situations : : : : : 5.7 Process Rules: Behaviors : 5.7.1 Functions : : : : : 5.8 Conclusions : : : : : : : :
6
SYNTHESIS
7
ARGUS EXAMPLE
3 4 4 5
5
5 6
6 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
CONCEPTUAL CATEGORIES
5.1 5.2 5.3 5.4 5.5 5.6
8
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
7.1 Example Application Problem : : : : : 7.2 Models for Example Application : : : 7.2.1 General Description of Models
6 7 7 7
8 9 9 10 10 10 10 11 11 11
11 12 : : : : : : : : : : : : : : :
12 12 12
1 Aerospace Integration Science Center, E-mail:
[email protected],
Phone: (310) 336-1361; The Aerospace Corporation, Mail Stop M6/214, P.O.Box 92957, Los Angeles, California 90009-2957 2 Principal Director, Aerospace Integration Science Center, E-mail:
[email protected], Phone: (310) 336-2191; The Aerospace Corporation, Mail Stop M6/214, P.O.Box 92957, Los Angeles, California 90009-2957
c 1998 C. Landauer, K. Bellman Submitted to ECAI 98 March 15, 1998
8
3
PROBLEM POSING INTERPRETATION
3.1 Examples : : : : : : : : : : 3.2 ReUse without Modi cation
2 2 3 3
: : : : : : : : : : : : : : : : : : : :
CONCLUSIONS AND PROSPECTS
8.1 Current Research 8.2 Future Prospects
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
13 13 13 14 15 15
15 15
Abstract.
This paper starts by expanding the scope of the Knowledge Sharing problem to the scale of space systems: hundreds of thousands of physical components and millions of lines of code, produced by hundreds or thousands of organizations, integrated into a system that is expected to last for decades. Our problem is to organize the associated information in a meaningful way, so that it can be shared. We note that both Problem-Solving Methods and ontologies are modeling styles and need to be treated as such, with good modeling practices, and also that there is no such thing as a general purpose model in our context: all models are situated in some computational or inferential context. We describe our research work on what we called Problem Paradigms, which are a kind of abstract procedure type; on the Problem Posing Programming Paradigm, which is a new declarative interpretation for all programming languages; on Wrappings, which is a Knowledge-Based integration infrastructure for Constructed Complex Systems; and on Conceptual Categories, which is a new knowledge representation technique. We show how a judicious combination of these elements leads to a di erent synthesis of methods to address the problem of Knowledge Sharing. 1
INTRODUCTION
The problem we consider here is Knowledge Sharing, of which two approaches are particularly highlighted as being important: Ontologies and Problem-Solving Methods. We have determined the scope of the problem a little di erently, based on our work in three research areas: system engineering of software, especially in the develop-
ment of space systems,
intelligent autonomous systems, and semiotics of constructed complex systems.
Here, we rst describe our work in these areas, and then show how we change the problem to become at once more general and more amenable to solutions.
is possible because general models exist. We have gained insight into both approaches by treating them as special cases of the more general model sharing problem, and we claim that considering the commonalities between them points towards a solution. The problem with each approach separately, as we see it, and in our opinion the reason it has not worked well in practice, is that there is no such thing as generic knowledge or a generic model [3]. All knowledge is situated, in a context, for a purpose, or according to a viewpoint [23] [44] [2] [4]. Therefore, any mechanism that does not take into account the context and viewpoint cannot succeed except in the small scale. Combining the two methods by itself su ers from the same problem. Our approach to solving the problem addresses this context issue explicitly. Issues with both ontologies and problem-solving methods are addressed by our wrapping approach described below: the rapping Knowledge Bases (WKBs) for the ontologies of problem-solving methods, and the Problem anagers (PMs) for the selection process and the other Intelligent User Support (IUS) functions.
The central problem treated in our system engineering research is How can we design, build and maintain complex heterogeneous systems? In our work in the government space business [7] [38], the scale of this problem in the application domain is huge: the space systems we in this culture build today, which include both the satellites and the managing ground systems and organizations, have thousands of software components, tens or hundreds of thousands of hardware parts, and many different kinds of system components (simulations, databases, legacy programs, simple computational algorithms, ordinary text les, etc., just to consider the software). They are built by hundreds of di erent organizations, which are involved at different times and for di erent lengths of time. The systems are expected to be e ectively usable for decades. They are generally distributed (often globally) and volatile (new technologies and mission requirements are frequently inserted). There are multiple users, human and otherwise, and the system must interact with real world phenomena on perhaps several di erent time scales. This culture has built systems like this in the past, relying on what we have called \heroic engineering". Over the last decade, we have built systems that supply more useful computer support to the design process [6] [17] [3] [18] [11] [7] [38]. We are now trying to put some more science to it since the heroes are few and far between, and the systems that this culture is trying to build are continuing to get larger and more complex. Our work on autonomous systems [4] [5] [9] is based on the notion from theoretical biology that there are common structures underlying both language and movement processes in biological systems [8] [12]. The idea is that from the very simplest cells, there are some profound representational abilities (largely chemical) that allow a separation of the outside environment from the inside processing. This notion greatly a ects the architecture of an autonomous system, especially if we are trying to build it [10] [34] [35]. Finally, our work in computational semiotics (the study of the appearance, meaning, and use of symbols and symbol systems by computing systems) has led to some new notions of knowledge representation [31] [32] [27]. We describe this work in detail later on. 1.1
1.1.1
Our use of ontologies as hierarchies of knowledge su ers from many defects: they are always models of some version of what is known, according to some set of version-de ning assumptions that are usually not provided and sometimes not even known; they usually su er from rigidity and brittleness, as most sparsely interconnected conceptual structures do; the e ect of context on the hierarchy is not modeled at all, so changing the context has no e ect on the hierarchy, whereas it has an important e ect on our organization of knowledge; there isn't much connection between the static hierarchy and the processes that might do something; there is little or no re ection, so the hierarchy cannot be used to model the modeling process itself. Ontologies are models of some version of what is known, according to some set of version-de ning assumptions. The assumptions are often about the context of use of the ontology, and they simplify the hierarchy considerably. However, as a basis for modeling, the assumptions are usually not provided and sometimes not even known (we can \try out" a simpli cation model without knowing all of the assumptions that are required for its applicability). Most published ontologies are sparsely interconnected conceptual structures (including the very large ones), so their \richness of expression" is generally very low. They have replaced the rich and sloppy graded interconnectedness of concepts with explicit or computed links, and they have lost or removed most of the background information that supports the connection (numerical measures of relatedness help, but only a little bit). This thinness of connection causes the links to be di cult to change, and to break easily. Most published ontologies are constant, that is, they are not allowed to depend on their context of use (this context is part of the implicit assumptions that go into constructing the ontology in the rst place). The e ect of context on the hierarchy is not modeled at all, except as collections of boolean conditions, so changing the context has no e ect on the hierarchy except selection, whereas it has an important
odel Sharing
We describe the use and sharing of ontologies and ProblemSolving Methods as use and sharing of models, and argue that they both must be treated in this more general way. First, we note that both ontologies and Problem-Solving Methods are models. The purpose of these two approaches is knowledge sharing and reuse: ontologies try to capture domain knowledge in a generic way, problem-solving methods are a kind of abstract procedure type that corresponds to abstract data types. Ontologies are models of structure knowledge, problem-solving methods are models of process knowledge. The usual claim for both of these methods is that sharing requires \general" models, and the hope is that sharing Sub
ission
ntologies
2
C. Lan
auer,
. Bell
an
and complex e ect on our organization of knowledge. Most ontologies are hierarchies of concepts, with no kind of active processes. There isn't much connection between the static hierarchy and the processes that might do something to it or with it. Finally, there is little or no re ection, so the hierarchy cannot be used to model the modeling process itself. This last point is also crucial to our approach; we believe that an ontology that cannot examine itself is not nearly su cient for the uses we intend. With all these problems, the use of ontologies to organize knowledge has been very helpful in many application areas, and in fact, the organization of knowledge into hierarchies is part of the reason that object-oriented system design has been so successful. It is our claim that ontologies can be made much more active, much more exible, and thereby even more useful. 1.1.
ro le
- olving
and show that they are very much like the Problem-Solving Methods; our Problem Posing Interpretation of programming and other computer languages (in Section 3), and our rapping infrastructure for constructed complex systems (in Section 4). The next section describes a new knowledge representation mechanism that is theoretically grounded in semiotics, and accounts for many of the de ciencies we have noted in most published ontologies (Section 5 is about conceptual categories). Then there is a section on our combination of these methods, and a synthesis of all of them to address this problem in Section 6, and an example illustrating some of the approach in Section 7. Finally, our conclusions and other claims are in Section 8. ROBL
et o s
Problem-Solving Methods are a kind of abstract procedure type: abstract descriptions of reasoning or other behavior that can presumably be reused across domains and tasks. In a sense, Problem-Solving Methods have been the goal of computing for decades: we want to write \generic" programs, which contain all and only the essential features of the problem, and to specialize those generic programs to our particular context using some kind of partial evaluation [20] [19], sometime after program construction time and before run time. Many published algorithms are written in a kind of pseudocode because we cannot yet write them generically [43]. Part of the problem is that in general, we do not know all of the important context conditions that may a ect the organization of a program that implements an algorithm. This information is one of the things we learn as we explore the behavior of programs in various execution environments. In addition, and more fundamentally in our opinion, is that there will never be just one \generic" version of anything but very simple algorithms. This opinion comes from a long study of complexity in models [3] [47] We believe that there is no O E model that can adequately capture all of the essential features of a complex system, and that therefore, multiple models must always be used and integrated. We therefore expect there to be a hierarchy of problem-solving methods, organized by speci city or some other criteria, for each kind of problem. Finally, in order to be useful, problem-solving methods must also be connected to problems, so there must be some kind of search process for problems, and for appropriate problemsolving methods for those problems. This search requirement means that there must be appropriate ways to specify what the problems are in the rst place, and of course, there is a re ection problem because quite often, de ning the problem is the hard part. 1.
Outline o
Rest o
aper
This subsection describes the rest of the paper, and also is an outline of our approach to solving the problem. Here is a preview of things to come. We start with several sections on system engineering, in which we rst introduce the abstract procedure types we called Problem Paradigms (in Section 2), Sub
ission
R
DI
S
We have developed a novel approach to data analysis, based on the notion of a problem paradigm, which is a kind of abstract procedure type [26]. In this section, we show that these are essentially the same as Problem-Solving Methods. Of course, our earlier work only described problem paradigms as data analysis methods, but the idea is clearly more general than that. The problem domain of exploratory data and pattern analysis contains many general algorithms that are applied to speci c data [45] [13] [14] [26], and the development was advanced by the abstractions existing in the eld. There are many problem paradigms possible for a given analysis problem. They di er in viewpoint, assumptions, requirements, and behavior. Given an analysis question, it is usually possible to get more information about the answer using several di erent viewpoints than can be obtained using just one viewpoint [3]. A system organized around explicit representations of problem paradigms, data, and analysis questions can help the user by suggesting problem paradigms to t the available information and the analysis question. It can also suggest other kinds of data to collect (active data analysis) that could be used with di erent paradigms to answer the same analysis question. An analysis system implemented using this approach o ers the analyst more than just a host of methods to analyze the available information. It is also possible to perform a kind of meta-analysis: there are additional methods and information that can be used to analyze the analysis techniques and their relationships with the data [1], and the use of those techniques by the analyst, in the expectation of improving future analyses. This kind of computational re ection makes a computing system much more exible [40] [22] [28]. Problem-Solving Methods can be viewed as problem paradigms in our sense, and we believe that something is gained by doing so, because we treat not only the method that addresses the problem at hand, but also the strategies for nding and using appropriate methods. .1
nal sis
ro lem
aradigms
The term problem paradigm is used both for general classes of analysis techniques and for more specialized techniques for 3
C. Lan
auer,
. Bell
an
individual cases. In particular, some problem paradigms contain others as instances (thus we have an ontology of analysis methods). Each problem paradigm has a typical case, which is a simple analysis with simple inputs and outputs. Other problem paradigms are modi cations of the typical case in various ways: generalizations, requirement relaxations, abstractions, changes in the control strategy, and others. In fact, any aspect of a problem paradigm is subject to modi cation to produce a di erent problem paradigm. There may be more than one typical case for a given problem paradigm. The graph of problem paradigms and their explicit relationships is connected, and the analysis system is re ective because it is assumed to have access to the graph (analysis of the problem paradigm graph is another analysis problem, related to methods of expert systems). Di erent problem paradigms require di erent methods of analysis. A class of problem paradigms may have many different methods, with di ering assumptions and requirements. These methods are represented by other problem paradigms that are related to the typical case. The same analysis question may often be viewed using di erent problem paradigms, and we believe that complex analysis questions can only be adequately solved by viewing them through several di erent methods [3]. The important parts of a problem paradigm are the kinds of information used for input and computation, the necessary abstract operations on the information, and the algorithm. Most problem paradigm algorithms have a set of low level operations on the data objects that represent the information, and a higher level program control strategy, which selects and organizes the low level operations. Many successful analysis systems require the user to provide a control strategy (these include the interactive theorem provers, pattern identi cation systems, and other systems for complex applications). Most algorithms make restrictive assumptions about acceptable data, and applications often fail to meet those restrictions, thus precluding the use of the simplest forms of the algorithms. For example, time series data frequently has missing values or outliers such as measurement failures or errors, and data derived from measurements is often imprecise, so it consists of distributions of values instead of individual values. For some problems, the data must be processed on-line (i.e., as it arrives) instead of retrospectively (i.e., by waiting for it all to arrive), which imposes further constraints on the kinds of algorithm that can be e ective. For example, radar tracking of airplanes in air tra c control stations is generally most useful if done in real time. .
Basi
lgorithms
For example, the usual steepest descent minimization algorithms work just ne for multidimensional problems when the gradient can be computed easily, or when the surface is steep enough that a good direction can be chosen without computing a gradient. However, the methods have trouble with problems like linear programming, for which the constraints bound the possible directions so much that it requires a combinatorial search (or a clever algorithm) to nd the best one, and like the tangle-towns problem (zero-one programming), where there are so many dimensions that very simple evaluations take a long time. Most graph search problems can be cast as optimization problems, with some measure of similarity between path end and goal for a criterion. However, it seems that most of the motion in the search space involves nodes that are equally far from the goal, and there is no necessary relationship between the similarity measure and the graph distance (it is assumed that the one approximates the other, even if only for nodes that are very close to each other). For another example, consider the case of parsers for phrase structure grammars. Simple parsers get a string for input, and produce a set of partial parse trees, each representing a structural explanation of part of the string. A more general parser might get a set of alternative strings (described in some compact notation) from a lexer, and would need to produce a similar set of partial parse trees (for example, for morse code data or speech data, lexical processing is known to be di cult enough not to expect correct hard decisions). In order to identify a basic set of typical case problem paradigms, it will rst be necessary to examine the problems, methods, and algorithms of interest, collecting the simplest data types for one version of each technique. Then the abstract operations required for the technique will be identi ed, and other problem paradigms can be de ned using generalizations of the abstract operations. In many application domains, collections of these algorithms are being or have been collected, and even in some more di cult domains, such as programming, the algorithms are beginning to be collected and abstracted: esign Patterns [16] [15] [46] are systematic, but not yet formal or su ciently abstract, descriptions of problem-solving methods. .
Since this kind of system must consider both actual data values and abstractions thereof, it needs both abstract data types and concrete implementations thereof. Every concrete value has a type. A type is a hierarchical structure, constructed from a set of basic numeric and symbolic types, including most common abstract data types. Parameterized types will be used. If a su ciently detailed ontology is available, it will include a large set of data types, and the \specializer" program can simply refer to that when specializing the generic program to the speci c data. One value is one measurement of some situation (an ob ect is a special case of a situation, which is really just a notion of something that might be measured). It is assumed also to be a hierarchical structure, with numeric and or symbolic entries. One dataset is a set of values, all of the same type. Transformations of datasets augment the original data with struc-
or T pi al Cases
The simplest kind of analysis consists of programs that deal only with simple values, such as numbers or strings. Any analysis technique has some versions that apply directly to these simple values. Any generalizations of the simple values lead to more complicated versions of the programs, though the algorithms used can be just about the same. If the operations on objects are made more abstract, then the same technique can be applied to much more complicated values. There will therefore be several implementations of each technique, of varying degrees of applicability and abstraction. Sub
ission
alues and T pes
4
C. Lan
auer,
. Bell
an
tured descriptions of related datasets. One problem is therefore represented as a graph of datasets, with explicitly described transformations leading from the original dataset (the root) to the others. A problem is usually a tree, but any directed graph is allowed, with transformations as edge labels. Part of the research problem here is to nd a convenient notation in which to express the data types, datasets, and transformations. It is necessary in complex application problem domains to represent context explicitly, so that when the notation makes implicit assumptions about the data, they are explicitly made available in the context.
Any programming language can be interpreted in this new way. Problem Posing changes the semantics of programming languages, not the syntax. It makes a program an organized collection of posed problems, instead of an organized collection of solutions without problems (in most programs, the problems have disappeared, replaced by the solutions that have been written for them). We believe that that should make programs easier to understand, because the problems at all levels of detail remain in them. .1
.
Control Strategies
We give four examples of the Problem Posing interpretation, in imperative, functional, object-oriented, and relational languages. In C, functions are resources; so are data structures (we make no assumption that the computational resources are active: they can be repositories of data that are interpreted by other resources in the same way that executable les in U I specify which program is to interpret them). Function calls and data accesses are posed problems (converting complex data accesses to function calls is a common technique for generalization). Each function relates a posed problem to an algorithm that poses other problems (that is the code in the function de nition). Data structures are used by other resources to retain and provide data (via their structure declaration). In Lisp, S-expressions are resources (some are applicable, others not). Applications are posed problems (as in, \apply t is function to t at data"). Each applicable S-expression relates a posed problem to an algorithm that poses other problems (all Lisp computation is function application). Other Sexpressions are used by other resources to retain and provide data. In knowledge representation languages based on Lisp, we can think of the syntax extensions as speci c classes of problems, and their interpretation as speci c classes of resources provided to deal with those problems. In Smalltalk, methods are resources; so are other object components (the objects themselves are only grouping constructs). Messages are posed problems. Each method relates a posed problem, with some constraints on parameters (including which object receives the message), to other posed problems. Other object components are used by other resources to retain and provide data. In Prolog, clauses are resources; so are tuples. Goals are posed problems. Each clause relates a posed problem, with some constraints on parameters, to other posed problems. Tuples are used by other resources to retain and provide data. In each case, the usual program constructs are either posed problems or resources, and our interpretation di ers from the usual one in the same way: the usual interpretation associates a resource with a problem when they have the same name, whereas our interpretation requires an external connection, through a knowledge base or via some other means. The simplest form of our interpretation is a one-to-one map from problems to resources; this is the same as the usual one. Clearly, then, we can keep as much of the usual interpretation of a programming language as we like, from none of it to all of it, by adjusting the mapping process from problems to resources.
Many di erent control strategies are needed for analysis problems. For each problem paradigm, there are several explicit control strategies in use. The graph search problem allows several control strategies to be described and contrasted easily. ept rst graph search starts at a given node, chooses one edge to traverse, and continues, saving the other edges for possible backtracking. This is the standard backtracking mechanism, good for some problems. It needs a mechanism for making the choices at each node. Best rst graph search chooses the best option at each node. Breadt rst graph search examines all of the options to one level, then continues with deeper searches. Combinations of these techniques can also be used. Part of the research problem here is to nd a convenient notation in which to express these and other control strategies. Here too, it is necessary in complex application problem domains to represent context explicitly, so that when the notation makes implicit assumptions about the strategies, they are explicitly made available in the context. ROBL INT R R
T
OSIN TION
In this section, we describe our Problem Posing Programming Paradigm. More details can be found in the wrapping references [30] [33] [37]. All programming languages have a notion of information service, with information service requests and information service providers. We connect them now by using the same names. \Problem Posing" is a new declarative programming style that uni es all major classes of programming. Programs interpreted in this style \pose problems"; they do not \call functions", \issue commands", \assert constraints", or \send messages" (these are information service requests). Program fragments are \resources" that can be \applied" to problems; they are not \functions", \modules", \clauses", or \objects" that do things (these are information service providers). The Problem Posing interpretation separates the requests from the providers. This part is easy: compilers and interpreters always know the di erence anyway, and so do we when we write the programs. We call the service requests \posed problems". We call the service providers \resources". We can connect them through knowledge bases (or by other means). \Knowledge-Based" Polymorphism maps problems to resources: from the problem speci cation in its context to the computational resources that will organize the solution. Sub
ission
amples
5
C. Lan
auer,
. Bell
an
.
ReUse
ithout
odi
R
ation
Problem Posing is particularly e ective in combination with \wrappings", our computationally re ective, knowledge-based integration infrastructure. Wrappings are our approach to the development, integration, and management of heterogeneous computing systems. The basic notion of wrappings is to combine explicit information about resource uses ( rapping Knowledge Bases) with active processes that use the information to organize the resources (Problem anagers). In this section, we give an overview of the wrapping approach; many more details are elsewhere [28] [29] [30] [33] (and references therein). The Wrapping Knowledge Bases (WKBs) contain explicit, machine-processable, qualitative information (called wrappings) about the system components, architecture, and all the computational or information processing elements (called resources) in the system: not just how to use them, but also whether and when and why and in what kinds of combinations they should or can be used. The Problem Managers (PMs) are algorithms that use the wrapping descriptions to determine which resources to use and how to combine them to apply to problems. We have also de ned a wrapping expression notation wre [28] [33], in which to write these resources and their wrappings.
Software ReUse is one of the major practical problems facing most organizations that have or use software. It turns out that the Problem Posing interpretation o ers a new way to deal with the problem: reuse without modi cation. It applies just as well to the reuse of Knowledge-Based Systems or other syntactic representations of knowledge. Since language processors for most programming and representation languages can easily distinguish between symbol de nitions and symbol uses, any such language may be interpreted di erently via the Problem Posing Interpretation. That means we can use same languages as now, just di erent compilers and interpreters, which are looking at the same syntax with a completely new interpretation. This changed interpretation has tremendous implications for the problem of reusing programs [28]. We can use same source code as we already do, with no changes at all, and still add and replace functions because we can intercept the function calls (using code fragments generated by the new compilers) to mediate the connections between function calls and function de nitions. We automatically get an enormous increase in exibility, before we have to change any part of the system's application code. This is done by identifying and separating the posed problems from the computational resources. For example, we can intercept the function calls and separate them from the called functions. Once we have the separation, we can then insert almost any kind of integration infrastructure, for instrumentation, monitoring, using di erent functions under di erent conditions, and using completely new functions for previously di cult situations. In particular, our wrapping infrastructure is an e ective way of inserting Knowledge-Based Polymorphism into legacy systems. Thus we can gradually wean ourselves from the old code and increase our use of whatever new code is written (for example, when we must migrate the system to a new hardware base, we can do it gradually). Old code is kept only as long as it is still useful. As we propose many di erent new interpreters here, we believe that we can rely on the fact that over the last few decades, we have learned how to write them easily and well [21], and that the changes we propose to them are very small. In addition, the compilers do not need to be particularly fast (i.e., they need not be \production quality"), since we only have to use them a few times to get the old code into the new interpretation. Changes to the system are made only by adding or changing new code fragments, which can be done in any convenient language, and they are kept separate from the old code. This approach does require having enough old code to justify writing a new compiler, but many organizations do. It also has one other drawback: it is very di cult to maintain timing considerations in real-time programs this way, since the new interpretation changes the timing relationships between function calls and the corresponding returns. However, it is our opinion that managing process timing is hard anyway, no matter how the programs are migrated into new computing environments. Sub
ission
IN
.1
rapping O er ie
The advantages of our knowledge-based integration technology are (1) a simplifying uniformity of description, using the meta-knowledge organized into rapping Knowledge Bases, and (2) a corresponding simplifying uniformity of processing that meta-knowledge using algorithms called Problem anagers, which are active integration processes that use the meta-knowledge to organize the system's computational resources in response to problems posed to it by users (who can be either computing systems or humans). We have shown its wide applicability in software and system development [28] [33] (and references therein). The wrapping theory has four basic features. 1. ALL parts of a system architecture are resources that provide an information service, including programs, data, user interfaces, architecture and interconnection models, and everything else. 2. ALL activities in the system are problem study, (i.e., all activities apply a resource to a posed problem), including user interactions, information requests and announcements within the system, service or processing requests, etc.. We therefore speci cally separate the problem to be studied from the resources that might study it. 3. rapping Knowledge Bases contain wrappings, which are explicit machine-processable descriptions of all of the resources and how they can be applied to problems to support what we have called the Intelligent User Support (IUS) functions:
6
(which resources to apply to a problem), (how to let them work together), Integration (when and why they should work together), daptation (how to adjust them to work on the problem), and
Selection
ssembly
C. Lan
auer,
. Bell
an
planation (why
certain resources were or will be used).
. .
Wrappings contain much more than \how" to use a resource. They also help decide \when" it is appropriate, \why" you might want to use it, and \whether" it can be used in this current problem and context. 4. Problem anagers P s , including the Study anagers , are algorithms S s and the oordination anager that use the wrapping descriptions to collect and select resources to apply to problems. They use implicit invocation, both context and problem dependent, to choose and organize resources. The PMs are also resources, and they are also wrapped.
rapping
ro esses
The wrapping processes are active coordination processes that use the wrappings for the Intelligent User Support functions. They also provide overview via perspective and navigation tools, context maintenance functions, monitors, and other explicit infrastructure activities. . .1
oor ination
anager
The alternation between problem de nition and study is organized by the oordination anager (CM), which is a special resource that coordinates the wrapping processes. The basic problem study sequence is monitored by a resource called the Study anager (SM). which organizes problem solving into a sequence of basic steps that we believe represent a fundamental part of problem study and solution. The CM runs a sequence of steps shown in Figure 1, that manages the overall system behavior. The main purpose of the CM is cycling through the other three problems, which are posed by the CM in the context found by the rst step. This way of providing context and tasking for the SM is familiar from many interactive programming environments: the \Find context" part is usually left implicit, and the rest is exactly analogous to LISP's \read-eval-print" loop, though with very di erent processing at each step, mediated by one of the SMs. In this sense, the CM is a kind of \heartbeat" that keeps the system moving. Sub
ission
anager
The Study Manager is the central algorithm of our problem study strategy. It is the default resource for the problem \Study problem". It assumes that it is given a context, problem poser, problem, and some associated data (usually by the CM). Its purpose is to organize the resources that process the wrappings, and to cause and monitor the behaviors the wrappings describe. There may be other resources that are intended for this same problem, but the SM is the one that is chosen if no other resource applies. This overlap of function illustrates a general principle of resource coordination we have used throughout this approach to integration: instead of trying to nd one general method for all cases (which we do not believe is possible anyway), we combine general methods for certain processes with powerful specialized methods that apply in certain contexts. We have divided the \Study problem" process into three steps: \Interpret problem", i.e., nd a resource to apply to the problem; \Apply resource", i.e., apply the resource to the problem in the current context; and \Assess results", i.e., evaluate the result of applying the resource, and possibly also pose new problems. We further subdivide problem interpretation into ve steps, which organize it into a sequence of basic steps that we believe represent a fundamental part of problem study and solution. The default SM step sequence is shown in Figure 2. We get Computational Re ection with the SM from several design features. First, all of the wrapping processes, including the CM and SM, are themselves wrapped, as we mentioned before. Second, the processing is completely recursive: \Match resources" is itself a problem, and is studied using the same SM steps, as are \Resolve resources", \Select resource", and ALL of the other steps listed above for the SM and for the CM. The simple form we described above is the default SM at the bottom of the recursion. Third, there are other SMs that have slightly more interesting algorithms (such as looping through all the candidate resources to nd one that succeeds, as described in the next section). These three things mean that every new planning idea that applies to a particular problem domain (which information would be part of the context) can be written as a resource that is selectable according to context; it also means that every new mechanism we nd for adaptation or every specialization we have for application can be implemented as a separate resource and selected at an appropriate time. It is this recursion that leads to the power of wrapping, allowing basic problem study algorithms to be dynamically selected and applied according to the problem at hand and the context of its consideration. The recursion in the SM immediately gives it a more robust and exible strategy, since the resources that carry out the various steps of the processing can be selected and varied according to context. At every step, the SM has the choice of posing a new problem for that step or using a basic function that \bottoms out" the recursion. The important point to be made here is that the SM is only our most basic mechanism for controlling these steps; more advanced versions of matching, selecting and so forth will be implemented by resources that are chosen like any others, using the same recursive steps. This SM recursion is unusual, since it is a recursion in the \meta-" direction, not within the problem domain or within the planning process. The result is that planning the planning
The wrapping information and processes form expert interfaces to all of the di erent ways to use the resources in a heterogeneous system that are known to the system. The most important conceptual simpli cations that the wrapping approach brings to integration are the uniformities of the rst two features: the uniformity of treating everything in the system as resources, and the uniformity of treating everything that happens in the system as problem study. The most important algorithmic simpli cation is the Computational Reection [40] [22] [28] provided by treating the PMs as resources themselves: we explicitly make the entire system re ective by considering these programs that process the wrappings to be resources also, and wrapping them, so that all of our integration support processes apply to themselves, too. It is this ability of the system to analyze and modify its own behavior that provides the power and exibility of resource use. .
t
7
C. Lan
auer,
. Bell
an
Coor
ination Mana er Ste
s
: determine containing context from user or by invocation inde nite loop: roble : determine current problem and problem data Pose roble : use an SM to do something about problem Stu Present results : to user in
conte t
i
Stu
Mana er Ste
.
Coordination Manager (CM) Step Se uence
s
: resources : get list of candidate resources Matc Resol e resources : reduce list via negotiation, make some bindings Select resource : choose one resource to apply A a t resource : nish parameter bindings, use defaults A ise oser : describe resource and bindings chosen l resource : go do it A Assess results : evaluate
Inter ret
roble
i
.
Simplest Stud
Manager (SM) Step Se uence
process itself is an integral part of the SM behavior, not a separate kind of function. The SM recursion also means that there are many layers of study context, each with its own problem context, problem poser, and problem speci cation. Recursion in the meta-direction is another way to view Computational Re ection. ote here that the posed problem approach sidesteps many extensibility limitations, by making everything a resource, as far down as one cares to go into the implementation, and that it is the WKBs that help select whether to further the meta-recursion by invoking the SM, or to stop it by going to a specially coded resource. We are going to make essential use of this re ection in our partial evaluations: since the system has access to its own computational resources, it has a much better chance to make appropriate simpli cations and specializations than if it had no knowledge of its own structure. CONC
TU
L C
T
ORI
have both de nite boundaries and speci c elementary units. There are many models of \uncertainty" that generalize the rst constraint: probability distributions, fuzzy sets, belief functions, rough sets, and many others. As near as we can tell, there is no appropriate model that generalizes the second constraint. This lack is mainly due to the nature of mathematics as our most concrete form of reasoning: the elementary units must be de ned before we can start mathematical reasoning. This constraint is not present in linguistic reasoning [32]. In addition, we want to generalize sets in two other directions: we want to allow conte t to leak into the descriptions [2] [44], and we want to allow individuals to have di erent structures in di erent viewpoints. In many cases, the inde nite boundaries of a category are made more precise (though still somewhat inde nite) by specifying the context under which the category is being considered, thereby allowing the context to become part of the speci cation of the category. For this reason, we make context a part of viewpoint. We also note that the di erent viewpoints can give the category di erent structure, one of which can even be to take the category as an individual.
S
We introduced conceptual categories [27] as a knowledge representation method for autonomous systems [34], since they need to improve and re ne their knowledge of their surroundings, and use it in many di erent ways. The approach is theoretically grounded in computational semiotics [4] [31] [32], and accounts for many of the de ciencies we have noted in most published ontologies. In this section, we describe the approach, and claim that for the purposes of this paper, the approach is well-suited to the representation of active ontologies of both knowledge structure and process. We start by describing the generalizations of set theory that we want. We want to get away from the use of sets as the only available model for categories of knowledge, since they arti cially limit the kinds of categories that can be considered [23]. Sets Sub
ission
.1
irst Loo
In this subsection, we introduce the concepts that de ne our approach. This is an informal descriptive tour through the concepts, not a sequence of de nitions. Terms in italics in this section are technical terms in our approach that are de ned in the next sections. The most important source idea is the \thing"ness of all concepts: anything we can describe with language can be \rei ed", that is, viewed as a \thing", and referred to as a unit or viewed in a number of di erent, not wholly compatible, 8
C. Lan
auer,
. Bell
an
ways. That is, each viewpoint leads to a possibly di erent structure for the individual (and certainly to a di erent interpretation of the signi cance of the structure). These \thing"s can be grouped naturally into categories. We think of categories as including our notion of concepts or classes. We call these \thing"s individuals, and think of the categories as collections of them. It is this property that leads us to consider all concepts as individuals, at least under certain viewpoints, and to recognize that di erent viewpoints lead to di erent structures for the individuals. We can view a category as an individual under certain viewpoints, and we can view an individual as an assemblage under certain viewpoints. We can also view an individual under a certain viewpoint to be a member of a category under some viewpoint. There are two ways to study grouping of individuals into categories. We can begin with some individuals and try to identify appropriate categories, or we can begin with categories and try to examine individuals in them. Both approaches are used here. We want to generalize the notion that categories contain other categories, which are separated by their distinctions into di erent roles. A category can be divided partially by distinctions into several other categories, and the distinctions become new roles for the division (partially means not necessarily either disjoint or exhaustive, i.e., not only into subsets). The \other" categories are called constituents. We use the term \division" for ALL category structuring mechanisms, even though they are not all subset partitions, because we are dividing up the concept corresponding to the category. Categories also describe relationships among other categories. Actually, the divisions ARE the relations ips among categories, and can be viewed as e amples of a corresponding category of relationships. A relationship has roles that may be lled by other categories, so we can talk about roles without using the categories that might ll them (this style of separation is very much like the problem posing interpretation and other declarative programming styles). They can also be thought of as abstract concept types (in analogy to abstract data types and abstract procedure types [26]). In this sense, they are similar to frames with variable slots for other objects, and the models we used for Model-Based System Design [33]. Distinctions are important only relative to a certain viewpoint, so division of a category is de ned only in terms of a viewpoint. Di erent viewpoints may divide the category in di erent ways. The divisions include our notions of knowledge structures (including abstract datatypes such as \set of " and other structures). Constituent categories for di erent divisions of a category generally have di erent viewpoints from each other. When we write that a category \contains" another, it means that there is a viewpoint according to which the second category is one of the constituents of the rst one. Finally, if we extend this decomposition further to many levels, we get a kind of hierarchy of categories, related by various divisions according to various viewpoints. This hierarchy becomes a kind of \ontology" for the application domains involved, and it allows us to make much more exible use of the usual sorts of ontologies de ned in knowledge representation languages.
Sub
ission
.
Categor
The fundamental organizational entity is the category, which represents anything that can be labeled by a symbol. Categories are descriptions of all phenomena. In fact, we want our notion of category to be co-extensive with the notion of \concept" and the notion of something that we can describe and reason about. That makes it the same notion as the one we have considered before [32] for \symbols": we can make up and use names for categories long before we know everything (or anything ) that is in the categories (e.g., black holes, phlogiston, public-key cryptosystems). This is the connection between our notion and natural language processes: we are attempting to model the e ectiveness of language in referring to concepts, even though we expect there to be many more categories than words or phrases [31] (our notions of what is possible in natural language are based on American English; we believe, but do not know, that similar capabilities exist in all human languages, spoken or not). .
Di ision
The fundamental organizational relation is division a category for other categories according to a viewpoint.
o
into roles
This division is our replacement notion for the usual notion of set or structure. Our notion of division corresponds to structural decomposition of categories, but it is much more general; it allows all structuring methods to coexist. More importantly, the division is the only structuring mechanism; ALL structure descriptions are divisions. The viewpoint is intended to contain our notion of context; we describe what a viewpoint is a little later on. Divisions make some things about a category more definite. We make divisions because the more information we have about a category, the more precisely we can use it. We make multiple divisions because we think of categories as being di erent in di erent contexts, or when we consider them from di erent viewpoints. One kind of division is to specify that the category plays a particular role in some other division. This features allows us to build up as well as down with the categories. Another kind of division shows the structure of the category when considered from one viewpoint, with decomposition corresponding to subcategories of the category, and constraints corresponding to distinguishing properties of the subcategories. This division is like identifying particular subcategories. We use a viewpoint to emphasize certain distinctions among entities in a category. Distinctions can be di erences in content, structure, available information, or intended use. They are often explicit, but sometimes unknown at rst. This illustrates a major point about these categories; we can assert information about categories that we cannot compute with the information at hand. Distinctions de ne roles in the division of a category. For example, a partition of a set is a division that has roles for the various subsets, which may or may not be explicitly distinguished. The di erent components of a structured entity C. Lan
auer,
. Bell
an
are roles in the division that de nes that decomposition. The di erent steps of a structured process are roles in the division of that process into parts. Some other common ways to write about divisions are that a category \contains" entities, or that a category \describes a relationship" among entities. .
category itself. The viewpoint de nes some of the assumptions and modeling decisions that are re ected in the presented division. A viewpoint is a focus within a context. A ocus is a presumed scope and level of detail, which de nes the scope of quanti ers, and the level o detail required to express the viewpoint. A di erent focus means a di erent viewpoint, which means a di erent division. Di erent viewpoints of a category often di er only in their focus. The scope de nes the extent of the conceptual units, both structures and processes, and the level of detail de nes their conceptual \size". It is part of our ongoing research to develop notations that express or de ne scope and level of detail. There is something \compatible" about the \size" of the conceptual units in a focus that makes it seem \natural". It is important in this approach that the same category may have many di erent divisions, each with a di erent viewpoint, and that we can therefore easily imagine adding new divisions as other viewpoints become interesting. A viewpoint implies a choice of descriptive language for the corresponding division, and a corresponding language interpreter. The viewpoint is outside the division, but refers to it. One of the di cult outstanding research problems is to determine how and when viewpoints are related to each other.
Indi iduals
Individuals are
particular objects or agents or actions or events or relationships, usually associated with one or more categories. The individuals are the \things" we referred to in our introduction. An individual is intended to represent a realworld entity, the same way a category does. In many cases, what we would normally consider to be an individual is not uniquely speci ed, so we must make do with a class of possibilities. In this case, we are using the individual as a \typical" member of a category (which derives from a particular viewpoint on the individual and on the category). We can also describe the structure of the individuals in a category, at least according to a particular viewpoint. Divisions also apply to individuals, but we put the individual into a category rst, so that the divisions are the usual ones that apply to categories instead. Individuals in a category are the same as examples of the category; any structure known for an example is a structure that applies to the category, under some viewpoint, and the example is only an illustration of the corresponding division. So the way a division works for individuals and sets of individuals, since the containing category is the same, is to use the containing category. Therefore, individuals, instances, examples, and sets thereof are associated with a category, and when viewed from a given viewpoint, have the same decomposition structure as is de ned by the corresponding division, and whose constituents are examples of the constituent categories for that division. In particular, every individual is an example of at least one category, so it can be an example of one or more divisions, according to di erent viewpoints. In general, for any individual, we can represent what we want to know in several ways. We can use a division of the containing category for the individual structure, as described above, and use architectures and roles for other categories, with \boxes and lines" diagrams or hierarchies for structure, or we can imagine an abstract space containing (representations of) the individuals as elements of the space, or as a subregion in which they must lie, or as a mapping from some other structure into the space. Sometimes we are given an individual (including the current situation), and we try to form or understand the categories it may lie in. We may have to infer one or more viewpoints, and consider di erent structures for the individual. This is generally a hard problem. As we get deeper in the category hierarchy, the categories become more and more concrete, and we eventually get to sets and data structures, which in our scheme are divisions of categories. .
ie
.
We have long maintained that context provides all the interpreters for symbols, and that semantics is the interpretation of syntax. For this paper, it means that context provides all the interpreters for categories, and that semantics is the interpretation of divisions in categories. A context does not do anything. It is a passive provider of and reference to information and processes. An interpreter is a mapping from elements to actions or objects, and from constructs to patterns of action or structures. So just as focus is a collection of categories that are used as units, context is a collection of categories that are used as relationships (mappings) from some categories to others. There is a notion of speci city in context. There is a relation of \more concrete" among divisions, and interpretation is intended to map towards more concrete categories. The simplest implementation of context is a collection of mappings from attributes to values, but others are possible. A conte t is a state of knowledge, which is a collection of assumptions, specializations, relationships, and current situation. A context contains or refers to the domain-speci c prior information structures and interpreters. The environment is the situation-speci c current dynamic activity to which the system must respond. It is never the case that we know all of the context of a division, so it is essential that we be able to augment the context at any time. When we write of a category \in" a context, we actually mean the division of the category according to the viewpoint given by the context and the focus of the category.
point . .1
We use viewpoints to distinguish di erent structures for our categories, either for the individuals in the category or for the Sub
ission
Conte t
it ations
Situations 1
are particular parts of the environment (as if they C. Lan
auer,
. Bell
an
were a component or aspect of the environment, except that we don't necessarily know anything else about the environment). A situation describes part of the environment at a particular time, and in that sense is like a context individual; the di erence between the situations and other parts of context is that situations are instances of the environment in time. There is some interesting new mathematics associated with situations [2], and much work on situated planning [44] and situated behavior [34], and we believe that our approach allows us to describe the situations, so that they may be made explicit in the computations. .
ro ess Rules
this category under the computational viewpoint). We still have to make the transition from a description of the process to the process itself. There may also be an inverse function, which is a di erent division with an explicit inverse relationship. Example input-output pairs (as in memo functions) are not part of this division; they are part of the division of the function as a relation among sets (examples of this category under the relational viewpoint). As always, side e ects in the \functions" used in programming languages cause trouble, and have to be treated in special ways. External side e ects become parts of the arguments of the function (whether input or output). In a particular execution context, some of the external side e ects can become implicit arguments, because their referents are available to the computation through the explicit context. Internal side e ects such as state are special in a di erent way. They become meaningful only when the function state is an individual, not a process, so in this case, we have to deal with a possibly large set of individual states . So there is a reference problem when the function is used, to determine which of the instances is intended.
Beha iors
Our knowledge representation mechanism must be able to de ne more than just what the concepts are and how they are related. It also must be able to de ne how things change and what can happen. In a sense, we have to make the conceptual categories \active", and somehow cross the boundary between representation and computation. In order to make conceptual categories more active, we take a hint from the fact that the transition from words to data structures or functions is the transition between categories and divisions. We need to be able to describe active processes with categories (denotationally), but we also want to be able to \compute" wit them, not just on them (procedurally, functionally, or otherwise). We can de ne a process by a sequence of steps. In other words, the division would be the sequence (or other structure) of steps, and the steps would refer to other processes. This gives us a way to de ne arbitrary sequential or concurrent programs, with a variable base of indecomposable statements, using something like the wrapping expression notation wre , for example [28] [33].
.
Con lusions
The notions we have discussed here provide a di erent approach to representing structural and procedural knowledge in a complex system. We believe that they allow incorporation of most other methods of representation, and that something along these lines is necessary to allow the representation schemes to take the current context and environment into account. S
. .1
n tions
domain (which might include pre-conditions), range (which might include post-conditions), constraints (between pre- and post-conditions).
Then the examples of this division are computations, that is, speci c algorithms that compute the function (examples of ission
SIS
We have described Problem Paradigms, the Problem Posing Interpretation, Wrappings, and Conceptual Categories as an integrated approach to PSMs and Ontologies. In this section, we gather together all the strands we have been weaving, and show how they combine to address the problem of knowledge sharing. All of our work is based on the notion of explicit models and good modeling practice [3]. We have argued that Problem-Solving Methods are better viewed as Problem Paradigms, and treated as computational resources for studying problems. We have shown that the Problem Posing Interpretation separates the information service requests from the information service providers, that it applies to a very wide selection of programming and knowledge representation languages, and that it therefore allows certain kinds of migration from legacy systems into new computational environments. We have shown that Wrappings allow problems to be associated with applicable resources, and that the computationally re ective architecture allows great exibility in the selection and organization of Problem-Solving Methods. The Wrappings integrate problem-solving knowledge and domain knowledge. They also integrate computational resources for solving problems (PSMs), and for structuring knowledge (ontologies).
In addition, a category will be active when we can \apply" it to some others. Since the e ect of a category as a process depends on viewpoint, it is actually the divisions of the category that may be applied. Perhaps the most important process is applying a function to an argument: the function is then a division for some category, and the argument is an example of a division for some other category. We will, in fact, represent ALL activity with functions, some of which have side e ects on the current context. The category for a function has (at least) two di erent divisions, one for the function as computation from one category to another, in which case the examples will be algorithms, and another for the function as a relation among categories, in which case the examples are the input-output pairs (because the function is the set of such pairs, according to this division). The function as computation has the following three roles:
Sub
NT
11
C. Lan
auer,
. Bell
an
We have argued that ontologies are better viewed as Conceptual Category hierarchies, and treated as computational resources for structuring knowledge. ow we put the pieces together to get our synthesis of these methods. We assume that we have a collection of generic models and problems in some application domain, each developed with explicit context conditions and assumptions. In short, we have wrappings of the models as computational resources, and context-dependent mappings from problems to resources. Partial evaluation allows generic models to be specialized, to di erent execution contexts, styles of use, and classes of problems. There is therefore a hierarchy of specializations of these models, some of which are provided with the domain models, but most of which can be computed at the time they are needed. It is, of course, part of the conceptual category hierarchy, and the methods that use the hierarchy to select and apply models are wrapped resources. Therefore, our conceptual category hierarchy contains all the domain models, problem models, solution method models, structure and process models, and problem-solving strategy models. It also contains the programs that interpret the categories as structure knowledge or as process knowledge, the wrappings that de ne solution method knowledge for problems, and the problem managers that use the wrappings. Thus we have closed the loop from descriptions to actions and back, from knowledge representation to active application, and from functional behavior to descriptions thereof. In addition, the computational re ection that is built into the system allows a closure in the meta-application loop also: programs apply to data which describes the programs. Closing the meta-application loop is signi cant, because it gives us a place to put all the di erent components of our knowledge models. R
US
since we cannot capture all relevant details in the space available, but in the original design, we had more space and captured more relevant details. We hope we got them all, and have some con dence in the matter, but cannot prove it (it cannot be proved in principle or any other way). .1
ission
ppli ation
ro lem
The basic problem is global surveillance for hostile missile launches, tracking and subsequent destruction of those missiles. Because cost is an issue, the question came up about performing these functions with small, cheap, expendable satellites. So the problem is to consider a system of hundreds or more satellites, each of which can perform any of the required functions: sensing, tracking, destroying, and managing the allocation of other satellites as resources. Along with other input from other sources, the system is supposed to detect, track and destroy threats of many simultaneous launches. We describe in the next subsection some models and roles required for a detailed simulation of such a system. Other models of di erent aspects of the system included one for the space system itself, including the mission, space and ground segments, system development life cycle, and physical characteristics of the satellites. We will concentrate on the models for the simulation, because that illustrates an explicit environmental model in addition to models of parts of the system itself. .
odels
or
ample
ppli ation
These descriptions include both the roles that certain models play in the system and examples of models that ll such roles. For example, there is always a role for a viewer model that describes what the viewers do, and how they interact with the rest of the models. Di erent levels of delity would be modeled by di erent models in that role. ust as the roles are a kind of abstraction of the models, or of the models' places within the system, the interactions between di erent roles are abstractions of the interactions between models. The models contain all of the information and de ne all of the computations. In many cases, there was only one model available for a given role. When that happens, we use the same name for the role and for the model that lls the role.
L
We have used a model-based approach in general, and various of the mechanisms we described above in particular, in designing systems for diverse applications, such as communication protocol simulation [24] [25], associative information retrieval [39], situation assessment for current events analysis, and systems for space surveillance, tracking, and battle management using hordes of very small satellites. We believe that the design process in each case was greatly simpli ed by the use of our methods, since it allowed us to concentrate on the hard parts of the application, instead of worrying about how to t what we wanted into the design method. In this section, we describe an example design for ARGUS, the space system mentioned above (named for Argus of the Thousand Eyes). It was part of a paper study conducted a few years ago. We choose this example because the application problem is known to be obsolete, and yet it illustrates some important features of complex problems. Of course, the di culty in presenting an example in a small space is that it can't be too messy or complex, and yet we are claiming that our methods work for very complex systems. The actual system is very complex, and we hope that our description here shows the complexity, and also shows that we can manage it using our methods. Remember that according to our assertion about the messiness of systems, there will be loose ends in the description, Sub
ample
. .1
eneral
es ri tion o
o els
The basic problem structure is as follows: simulator environment scenario - Scen targets - T t ground segment ground stations - Sta locations - Loc argus (space segment) constellation - Cnst connectivity - Conn orbit - Orb 12
C. Lan
auer,
. Bell
an
link - Ln satellite - Sat mission software alarm - Alr role - Rol viewer - ie correlator - Cor manager - M r communication message delivery - M s message transfer - Mtr routing - Rte message - Ms Each model has a local state that it initializes and maintains. Dynamic models include state change rules for time, and maintain the current state and time. Discrete dynamic models also keep their time of last change. Each model has several kinds of functions: action functions, information functions, interface functions
The action functions are local to the model; they change the local model state and interact with the simulator to schedule certain other actions. The information functions are global; they are called by the action functions of any model to provide information. The interface functions are global; they are called by functions of any model to change the local model state. The simulation assumes a discrete sequence of events that change the system state (which is de ned by the collection of local model states). Continuous models use time intervals and make approximations within them (using di erential equation solvers or direct time functions). Many of the dynamic models are responders: they are given a time (or two), and reply with information relevant to that time (or time interval). Most of them can reply with a symbolic approximation formula for analysis, together with a range of validity for the given accuracy criterion, or a range of accuracy for the given validity interval. There are several levels of model complexity. One uses a static connection graph and studies routing methods under various conditions of loss, one uses an orbit model that relates the graph to locations above the earth and studies location dependent scenarios, one uses complete protocol descriptions to study error control methods. . .
nviron
ent
o el
es ri tions
o el Scen: A scenario is a timed sequence of events. A complex event is a timed poset of events (partial instead of total ordering because some time delays are random, and some depend on outside interaction). There may also be input or output time parameters that allow interactions with the environment. Events have names and are associated with models (e.g., \launch" belongs to target models, \fail" belongs to other object models). Time control of high-level events refer to a global clock. References to some primitive events will be C function calls in the simulation.
scenario
Sub
ission
13
We need notation for describing combinations of events [24] [25]. This model reads a le that describes event occurrences, using the event notation. Then the scenario model interacts with other models: Loc to initiate certain eld behaviors, T t to initiate each target (or target group) behavior, Sat and Sta to start certain failure behaviors (temporary, permanent, or intermittent). o el T t: This model includes a choice of tartar et get events (locations and times are selected by the scenario), and also their behavior of targets after launch (trajectory and other behaviors like maneuvers). For example, a scenario might call for a small number of launches spread over a few minutes. This model registers target location repeatedly with Loc. roun station o el Sta: These ground stations are permanent, but they can be temporarily or permanently down (some of them may be mobile). This model includes ground segment node and link failures, as instigated from the scenario (or from random failure rules). It also interacts with Loc for locations, motion, weather (and other elds). It has static parameters including location (for stationary objects), computer processing, transmission and switching rates, and dynamic parameters such as current location (for mobile objects), existence and availability, and other local data. . .
o ation
o el
es ri tion
We used a separate location model to coordinate all the spatial interactions because it collects all computations about whether or not interaction can or will occur into one place. o el Loc: This model contains all object lolocation cations, and all location based information: the xed ground locations, the mobile ground stations, all space objects, targets, and elds (these are the di use objects like weather, storms, atmosphere). The scenario drives most of this (but does not de ne it). The connection between targets and viewers is through locations: events are registered in certain locations, viewers interact with the locations. To implement location management, we can use a geometric hash table, mapping from regions to lists of objects (or to parts of di use objects). . .
onstellation
o el
es ri tions
Here we begin to leave numerical details of orbits out of the paper. constellation o el Cnst: This model produces satellite orbits and initial positions for some start time. It involves many satellites in each of several orbit planes (these numbers depend on the constellation being studied), also orbit inclination, right ascension of origin plane or some other standard orbit de nition parameter set. This model also computes an information service: given a satellite id, it responds with orbit parameters. o el Conn: This model contains the static connecti it connection graph model, which has no location information, only connectivity. It can be used for routing, but not as easily for scenarios (since it is not connected to locations). Any experiments performed with this model should be compared to Cnst, if Cnst is also available. C. Lan
auer,
. Bell
an
o el Orb: This model contains the altitude - peorbit riod relation (and others) from the common equational orbit models (these are the relationships among static descriptions of an orbit). It contains information functions that produce locations and local motion models (polynomials may not be good enough numerically). A local motion model is a function description that gives the position on an orbit for an interval of time (typically 6 hours). It also contains functions that, given orbit parameters and time, respond with the location, that, given orbit parameters and two times, respond with a local motion model (once it has checked that the times are close enough together). For some models, we use a forward propagator, so we need to assume (and enforce) no reverse time in the requests: for each set of orbit parameters, the sequence of times is increasing (keeps hash table mapping orbit parameters to previous times). o el Ln : This model contains informaconnection tion functions that produce potential links, range models, and range rate models. It uses Cnst to determine the orbit of each satellite id, and Orb to compute the position and a local motion model. It uses a parameter for the maximum link length. It also contains some information functions: given one satellite id, respond with list of neighbors (can use Conn or at least compare results to it); given one satellite id and time, respond with range to each neighbor; given two satellite ids and time, respond with range and range rate; given two satellite ids and two times, respond with local models of range and range rate (after checking that the times are close enough together).
. .
atellite
o el
mise). There is a tradeo between higher speed of communication from viewer to correlator and wider viewing angle for better triangulation. For this simulation, we assumed that triples are in same plane (this is one choice; many others are possible and should be studied). Each level of alarm has a certain number of active satellites, all in active triples. The precise numbers depend on the constellation. ie er o el ie : This is the steady-state background probability of false detection due to random noise. This model also interacts with location model Loc to determine which viewers see which targets. It sends LOS messages to Corr. o el Corr: This model collects LOS mescorrelator sages from assigned viewers, combines them into tracks when possible, and sends the results to responsible managers. ana er o el M r: This model collects tracks from correlators, gives summary information to alarm model, and relays information to appropriate ground stations. eli er ser ice o el M s: This model deessa e nes several types of messages, each with a characteristic size. It is purely for delivery: satellite id x sends message m to satellite id y, starting at time t model chooses time delay and probability of delivery. It doesn't use routing or protocols. essa e trans er o el Mtr This model de nes several types of messages, each with a characteristic size. It is de ned for message transfer: satellite id x sends message m to satellite id y, starting at time t routing model Rte sets single hops (could be either at source x or dynamically). It assumes simple protocols, except for routing: single-hop and end-to-end, with no error recovery mechanisms. It needs link condition summary as a bit error rate or a message loss probability. o el Rte: For each station, a re uest is a (source, routin destination) pair, a current station (for intermediate nodes), and a local state (routing tables, etc.), and a response is which link(s) to use. There is also an update note that provides link information to the routing model: it contains link successes or failures, round trip times as available, node alive notes, observed error rates, etc.. This model also performs duplicate reduction: each incoming message is saved for a short time (not message contents, only message header and a sequence number), for about 80Some messages will be lost, but not very many (this is another aspect that needs to be studied). The message range of a message de nes how far it can go. Each message is allowed to traverse a xed maximum number of crosslinks (links to satellites in nearby planes) and a larger xed maximum number of consecutive forward and backward links (links to adjacent satellites in the same plane). These numbers depend on the constellation, or more precisely on the connectivity graph. There are also policy rules that allow messages to travel through a relatively sparse network, but that also have a nite upper bound on the total number of links traversed. The time-to-die (ttd) of a message de nes how long it can be in existence. It is set at the sender and compared on each node arrival to the current time, and simply dropped if it becomes too old. essa e o el Ms : All messages are temporary, and many are created and consumed in any simulation. There is a (small) xed set of message types (of which LOS above is
es ri tions
The satellite models are the most detailed, because we are most interested in the software architecture in this simulation. o el Sat: The satellites are permanent, but satellite can be destroyed. Each one has some static parameters including satellite id, orbit parameters, computer processing, transmission and switching rates, and some dynamic parameters such as existence, role, location, a local motion model, and some local data. alar o el Alr : This model implements the policy that determines which satellites are watching (active) at which times, when to activate others, and which other satellites to activate. The local manager does the activation. There are several intensity levels of alarm. This model uses tracking summary information from managers, and a local de nition of alarm policy, to determine alarm level. o el Rol: This model handles role assignments for role the di erent mission roles, and chooses role for a given satellite: every active satellite is a viewer, a correlator, or a manager. The assignments can be changed. The scenario drives (but does not determine) the role of a satellite. The constellation model de nes its existence, the alarm model de nes the activation level of system, and this model determines role for active satellites. The addressing scheme identi es roles for a particular satellite id, as well as choosing and disseminating the roles. The active triples are sets of three co-rotating satellites in two roles a viewer, a correlator, and another viewer, in adjacent planes (for best stereo viewing angle), or in the same plane (for shortest message path length), or one each (as a comproSub
ission
14
C. Lan
auer,
. Bell
an
one). This model has some static parameters including message type, size, role, and some local data, and some dynamic parameters such as message contents, source and destination, current position (i.e., in which satellite), etc..
R
R 1
2
.
Studies 3
In studying the ARGUS system, of course one of the main results was the collection of abstractions we developed as our set of interconnected models. We also showed that we could combine the hard physics models of orbits with the uncertain and debatable models of policies, the structure models of the simulation components with the process models of their behavior, and the ARGUS system models with the simulation environment models. The result is a coherent system architecture for ARGUS, contained in a comprehensive simulation architecture, that can be simulated to whatever degree of detail is provided in the various component models. CONCLUSIONS
ND
ROS
4
ission
(September 1983) on Bar ise,
, CSLI Lecture
otes
o. 17, Center for the Stud of Language and Information, Stanford . (1989) Kirstie L. Bellman, The Modelling Issues Inherent in Testing and E aluating Kno ledge-based S stems , pp. 199-215
Kirstie L. Bellman, 10-12 in ,
5
:
olume 1, o. 3 (1990) hen Intelligence is in Control , pp. : , , , 20-23 October 1996,
:
aithersburg, Mar land (1996) Kirstie L. Bellman, Sharing or , Experience, Interpretation, and ma be e en Meanings Bet een atural and Arti cial Agents (in ited paper), pp. 4127-4132 ( ol. 5) in :
CTS 6
7
8
9
10
11
12
rospe ts
When this research has progressed further, we expect to get much more expressive power and computational e ciency in our knowledge modeling, since the models can make up their own notations for important phenomena. We also expect much more sharability of the knowledge models, since they will know how much they apply in a problem domain, how well they apply, and how to apply themselves. Even if one or more of these research directions stalls, or fails, the studies will be valuable in delimiting what we can do now to improve the state of knowledge modeling. Sub
. Smith, Inducti e Inference: Theor , ol. 15, no. 3, p. 237-269
,
Current Resear h
uture
Dana Angluin, Carl and Methods ,
,
In our wrapping research, we are further developing the wrapping expression notation wre as a notation for the Problem Posing Interpretation, and writing a partial evaluator for it. We are also studying more formally-based notations for the wrappings, including both the Wrapping Knowledge Bases and the Problem Managers. We are looking for more automatic methods for directing partial evaluations according to problem context. This problem is hard. We are also studying notations for more formal descriptions of our representations in the conceptual category hierarchy. The more analytic power we can develop here, the more effective and powerful the use of this representation mechanism will be. We are investigating automatic methods for creating and developing notations for particular problem classes or domains. This problem is also hard. .
S
in Chris Culbert (ed.),
In this nal section, we describe our current research issues in this area, and our expectations for the results. .1
NC
13 14
15
16
15
, 12-15 October 1997, Orlando, lorida (1997) Kirstie L. Bellman and April illam, A no ledge-based approach to the conceptual design of space s stems , pp. , March 23-27 in 1988, The Societ for Computer Simulation (1988) Kirstie L. Bellman, April illam, and Christopher Landauer, Challenges for Conceptual Design En ironments: The EICLES Experience , e ue Internationale de C AO et d Infographie, ermes, Paris (September 1993) Kirstie L. Bellman and Lou oldberg, Common Origin of Linguistic and Mo ement Abilities , , olume 246, pp. 915- 921 (1984) Kirstie L. Bellman, Christopher Landauer, A ote on Impro ing the Capabilities of Soft are Agents (poster sum: mar ), pp. 512-513 in , 5-8 ebruar 1997, Marina Del e (1997) Kirstie L. Bellman, Christopher Landauer, Computational Embodiment: Biological Considerations , pp. 422-427 in A. : M. Me stel (ed.), : , 22-25 September 1997, IST, aithersburg, Mar land (1997) Dr. Kirstie L. Bellman, Captain Al einhardt, SA , Deor station: A Modelling En ironment for bris Anal sis Studies on Space Debris , pp. 303-308 in , 5-7 April 1993, Darmstadt, erman (1993) Kirstie L. Bellman and Donald O. alter, Biological Pro, olume 246, pp. cessing , 860- 867 (1984) ohn M. Chambers, , ile (1977) ohn M. Chambers, illiam S. Cle eland, Beat Kleiner, , Paul A. Tu e , ads orth International (1983) Duxbur Press, Boston (1983) ames O. Coplien, Douglas C. Schmidt (eds.), Pattern Lan: guages of Program Design , , August 1994, Monticello, Illinois (1995)
Erich sides,
amma,
ichard elm, alph ohnson, , Addison- esle (1995) C. Lan
auer,
ohn
. Bell
lis-
an
17
18
19 20
April illam, A no ledge-based approach to planning the design of space s stems , , The Societ for Computer Simulation (1989) April illam, ehicles Kno ledge-Based Design En ironment , , olume 30, o. 3, pp. 342-347 (Ma / une 1993) . D. ones, Partial E aluation ,
,
35
M. Me stel (ed.),
ol-
ume 28, o. 3 (September 1996) . D. ones, C. K. omard, P. Sestoft,
22 23 24
and
M. Kaplan, (includes PC dis ),
regor Kic ales,
im des
ohn
ile
26
27
Christopher Landauer, Tools , pp. 87-93 in
Christopher Landauer, Kirstie L. Bellman, M Ds, Integration Spaces, and Learning En ironments , , : , 6-9 anuar 1998, Kona, a aii (1998)
37
Christopher Landauer, Kirstie L. Bellman, Soft are De elopment , pp. 420-429 in , : , 6-9 anuar 1998, Kona, a aii (1998)
38
Christopher Landauer, Kirstie L. Bellman, April illam, Soft are Infrastructure for S stem Engineering Support ,
i ieres, Daniel . Bobro , , MIT Press (1991)
eorge La o , , . Chicago Press (1987) Christopher Landauer, Performance Modeling of Protocols , Paper 16.2, ol. 2, pp. 219-221 in
et or
29
, 12
, IST, aithersburg, Mar land, December 1984 (December 1984) Christopher Landauer, Data Anal sis b Problem Paradigm , (internal report; not published) 26
39
31
32
33
, Cambridge
: , 2225 September 1997, IST, aithersburg, Mar land (1997); Christopher Landauer, Kirstie L. Bellman, Kno ledgeBased Integration Infrastructure for Complex S stems ,
40
, olume 1, o. 1, pp. 133-153 (1996) Christopher Landauer, Kirstie L. Bellman, Integration S stems and Interaction Spaces , pp. 161-178 in
41
Christopher Landauer, Kirstie L. Bellman, Constructed rappings , Complex S stems: Issues, Architectures and : pp. 233-238 in , , 9-12 April 1996, ienna (April 1996) Christopher Landauer, Kirstie L. Bellman, Semiotics of Constructed Complex S stems , pp. 35-40 in Alex Me stel, im Albus, . uintero (eds.), : , , : , , 20-23 October 1996, IST, aithersburg, Mar land (1996) Christopher Landauer, Kirstie L. Bellman, Mathematics and Linguistics , pp. 153-158 in Alex Me stel, im Albus, . uintero (eds.), : , , : , , 2023 October 1996, IST, aithersburg, Mar land (1996) Christopher Landauer, Kirstie L. Bellman, Model-Based ith
:
Sub
uar , Phoenix, SCS International (1997) Christopher Landauer, Kirstie L. Bellman,
ission
ashington, D.C.
ele ance ,
ni ersit , une 1980; published as
Chapter 8, pp. 117-138 in . . Odd , S. E. obertson, C. . an i sbergen, P. illiams (eds.), , Butter orths, London (1981) Pattie Maes, D. ardi (eds.), , , 27-30 October 1986, Alghero, Ital , orth- olland (1988) Mar Sha , Procedure Calls Are the Assembl Language of Soft are Interconnection: , CM -CS-94-107 ( anuar 1994)
42
Mar
Sha , Da id
arlan,
43
, Prentice- all (1996) Mar Sha , illiam A. ulf, T rannical Languages Preempt S stem Design , pp. 200-211 in
:
, 20-23 April 1992, Oa land, California (1992); includes and comilliam A. ulf, To ard elaxments on Mar Sha , ing Assumptions in Languages and their Implementations , , olume 15, o. 3, pp. 45-51 44
(March 1980) Luc A. Suchman,
:
, Cambridge
. Press
(1987) 45 46
ohn . Tu e , , Addison- esle (1977) ohn M. lissides, ames O. Coplien, orman L. Kerth (eds.), Pattern Languages of Program Design 2 , :
47
, August 1995, Monticello, Illinois (1996) Donald O. alter, Kirstie L. Bellman, Some Issues in Model Integration , pp. 249-254 in , 23-26 April 1990, ash ille, Tennessee, Simulation Series, olume 22, o. 3, SCS (1990)
rappings , pp. 169-174 in
:
34
1993,
,
December 1985 (1985) Christopher Landauer, Conceptual Categories as Kno ledge Structures , pp. 44-49 in A. M. Me stel (ed.),
Simulation Design
ul
(1993) Christopher Landauer, Clinton P. Mah, Message Extraction Through Estimation of
, 26-29 March 1995, Munich (March 1996) 30
rappings for
and Protocol Modeling
:
28
IST,
36 (1994)
: , Los Angeles, October 1984 (October 1984) 25
:
: , 22-25 September 1997, aithersburg, Mar land (1997)
, Prentice- all (1993) 21
tional Embodiment: Constructing Autonomous Soft are S stems , pp. 42-54 in udith A. Lombardi (ed.), , : , , American Societ for C bernetics, 8-12 March 1997, . Illinois (1997) Christopher Landauer, Kirstie L. Bellman, Computational Embodiment: Soft are Architectures , pp. 205-210 in A.
, , 12-15 anComputa-
16
C. Lan
auer,
. Bell
an
