APPROPRIATENESS

Andrew Basden,
Information Systems Institute, University of Salford

ABSTRACT

This paper is based on the difference between knowledge representation and programming. In knowledge representation three things have traditionally been aimed for: sufficiency, efficiency (tractability) and expressive power. Though important in supporting other work in Articifial Intelligence, they have not led to knowledge representation formalisms that make it easy to encapsulate real life knowledge in the computer. Most require expert programming. While there have been some attempts at 'stitching together' various formalisms, the results have not been impressive. We are as far away as ever from the situation in which lay people can encapsulate their own knowledge.

A new, additional goal is needed: appropriateness. This paper explains appropriateness and discusses how it might be achieved. It proposes an ontological approach, leading to the idea of irreducible aspects of knowledge. This idea has explanatory power concerning the deficiencies of current formalisms. It also has implications for design of knowledge representation systems, for integration and for evaluation metrics.

Contents

  1. Introduction: The aim of knowledge representation; how it differs from 'programming'
  2. Limitations in knowledge representation formalisms
  3. What is needed? Appropriateness is the forgotten element
  4. Some examples of where 'programming' must be done
  5. Towards Appropriateness: elements of the theory of appropriateness
  6. Conclusions

1. THE AIM OF KNOWLEDGE REPRESENTATION

Traditionally, the main aims of knowledge representation (KR) have been to support AI workers in their attempts at cognitive simulation, natural language processing or robotics. Here I want to focus on another aim that is growing in importance. Brachman (1990) calls it 'KR to the People'. Increasingly during the 1980s, we saw KR emerging from the AI laboratories to become a kind of easy-to-use programming language, often declarative in nature. It started with Expert Systems but its relevance is becoming more widely recognised.

KR offers an alternative to programming. Both are means of encapsulating knowledge of a domain in a computer, but with KR, the job should be easier. With KR knowledge of a domain can be encapsulated in a computer by a lay person, whereas with programming there is a need to attend to programming constructs that have no direct relevance to the domain. The difference arises not so much from the issue of declarative versus procedural, but rather that genuine KR allows one to focus largely on issues at what Newell (1982, 1993) calls the knowledge level while programming requires one to focus on issues at the lower symbol level that have no real meaning at the knowledge level.

It is in this sense that the issue of KR will be discussed in this paper: as a means of expressing knowledge in order to easily encapsulate it in the computer, and its difference from programming will be a key theme.

Various knowledge representation formalisms have been proposed by the AI community, most stemming from pioneering work in the 1970s - production rules, logic, frames, etc. In this paper we use the term knowledge representation formalism (KRF) to denote the basic KR idea, such as first order predicate logic (FOPL), KR language (KRL) to denote the style of syntax and operational semantics employed to give life to the idea (e.g. PROLOG), and KR system (KRS) to denote particular software packages that implement the language (e.g. Quintus PROLOG). The KRS is what the knowledge engineer experiences, but it embodies the KRL and reflects the underlying KRF, so when I use the term, KRS, I assume considerations of KRL and KRF as well. Following Brachman (1990), KR will include reasoning - but not just deductive reasoning. While the main emphasis will be on KR that comes from AI, other approaches exist that can allow representation of knowledge, such as spreadsheets, object orientation and procedural languages like C or COBOL.

2. KRF LIMITATIONS

Each KRF has its own strengths and weaknesses. None has proved to offer genuine knowledge representation for all types of knowledge. All have their limitations which result in the knowledge engineer having to perform some programming. FOPL, for instance, is good for handling knowledge about items and relationships, but it has limitations, outlined in Ringland and Duce (1988). KRSs based on it make rather heavy weather of quantitative values and of change, for instance. By contrast, C is nearly ideal for handling changes and values but clumsy when used for items and relationships. If a KRF is limited the knowledge engineer is forced into programming to circumvent its deficiencies.

One response to such limitations has been to produce hybrid KRSs which seek to integrate two or more KRFs in one package. Rule based systems excel at inference, but it is difficult to model a problem situation in rules - for instance, a housing scheme comprising several different types of house, each on a slightly different soil and with a slightly different shape and size of garden. Not only is it a tedious business to apply rule sets to each house individually, but it is not easy to represent the relationships among the houses, even such simple types of relationship as the set. The object oriented approach, on the other hand, is good at handling sets, but is rather weak at inference. So when they are brought together in one KRS, as in Kappa-PC, the knowledge engineer should have the right KR formalism for the knowledge at hand. Rules can be used for IF-THEN inference, and objects (and classes, methods, etc.) for modelling the problem situation.

But such integration has not really succeeded. Reports from the late 1980s suggest that to make use of KEE for real life applications means that between 30% and 50% of the code is raw LISP. The author's own experience in a project using Kappa-PC is that it requires a programmer to use it. The KRF seems even more remote from the knowledge engineer in usefulness than the humble production rule. This contrasts markedly with his experience some years before of using Savoir, when a domain expert was able to build his own complete Expert Systems (Basden, 1989). Savoir allowed more genuine knowledge representation and required less programming. It is ironic, moreover, that Savoir on a 286 PC proved to be faster than the more 'powerful' Kappa on a 486.

Experiences like this - and they are not uncommon - suggest that KR research and development has been aiming in the wrong direction. One clue was given by Brachman (1990), who calls these attempts at integration 'stitching together'; they merely involve bringing together extant KRFs in one package. As Brachman complains, little thought was given to what uses the KRS will be put.

3. WHAT IS NEEDED?

What is required in a KR system that will support the lay person in encapsulating knowledge? A number of answers have been offered.

Brachman (1990) suggests that usability is an important requirement and he identifies knowledge presentation, browsing, querying and explanation as the elements of usability. We see here the influence of the Human Computer Interaction community. While these features are useful (albeit making the KR system more complex to use) they do not attack the basic point: the process of expressing your knowledge may still require you to engage in programming. These issues of usability are characteristics of the KRS, but go no deeper. We still need to examine the KRF because it is at this deeper layer that the requirements emerge.

The first and probably most basic requirement of a KRF is that of sufficiency. The KRF should provide at least some way of representing and manipulating or reasoning with all types of knowledge that will be encountered. This way might involve some programming, aggregating more primitive facilities into a complex whole. But if the KRF is not sufficient - and most are today - there will be certain types of knowledge that cannot be represented at all or certain types of reasoning or manipulation that are impossible. For instance, a KRF based on pure propositional logic cannot increment Fred's age on his birthday, except by throwing away one knowledge base and building a new one. Sufficiency is a basic necessity, but it is not itself sufficient to yield KR as we have defined it.

The second is efficiency. The KRS should be able to make its inferences in reasonable time and hold its knowledge without consuming unreasonable resources. An important consideration in efficiency is tractability; FOPL is intractable in the worst case. A number of attempts are being made to address this problem, most involving either logics of reduced expressive power or incomplete inference. See Crawford and Kuipers (1991) and Selman and Kautz (1991). Russell and Wefald (1989) tackle tractability by means of meta reasoning. Wider issues of efficiency are often tackled on a pragmatic basis, but Rosenschein (1990) has suggested the use of mechanisms with in-built world knowledge to increase efficiency. While efficiency and tractability are important in KR they are not sufficient to reduce the amount of programming needed.

The third requirement that has attracted a lot of attention is expressive power. Levesque and Brachman (1985) give two benefits of expressive power. One is to encapsulate a lot of knowledge with few keystrokes. Inheritance mechanisms increase expressive power in that we can encapsulate in our knowledge base the fact that 'all cats have whiskers' in one sentence, rather than having to enter such knowledge about every cat. The subroutining capability of third generation languages likewise increases expressive power. The other is to express incomplete knowledge (such as saying 'Either John or Jill is tall' without saying who). FOPL provides both types of benefit. Sorted logics increase expressive power still further and also aid the deductive process (Frisch, 1989). But expressive power has its dangers. It shifts the knowledge engineer's attention away from the specific cases - those cats that have lost their whiskers. Also, it often has the opposite effect we are aiming for here. Expressive power often implies terse and powerful syntax, and thus restricts KR activity to an elite who know how to wield such power.

Minsky (1981) proposed that we should concentrate on sufficiency and efficiency in the enterprise of defining a good KRF. Levesque and Brachman (1985) agreed with most that expressive power is desirable, but showed that there is a tradeoff between it and tractability. But even if we were able to achieve all three of these, we would still not have a means of ensuring that lay people can easily encapsulate knowledge in a computer without programming. While sufficiency, efficiency and some measure of expressive power are desirable in a KR system, something else is needed - what we will call appropriateness.

4. SOME EXAMPLES OF WHERE 'PROGRAMMING' MUST BE DONE

In order to determine what the missing ingredient is, let us look at some examples in which programming is required and examine some of the problems that arise.

4.1 Inverse relationships

In real life most (binary) relationships have inverses: Contains is inverse of IsIn, etc. Entering one automatically implies its inverse. But most KRFs do not support these directly. leaving the knowledge engineer to program the system to treat one as the inverse of the other. We want to allow the knowledge engineer complete flexibility as to in which direction they specify the relationship, so, in PROLOG, for instance, we might add "Contains (X,Y) :- IsIn (Y,X)." This may seem a minor addition for the knowledge engineer to make, but there are two problems. One is that in a system with many types of relationship it is all too easy to omit one of the inverse sentences, or to make an error in entering it. Especially, our lay knowledge engineer either may not have read the relevant part of the manual warning him/her to do this, or may forget. The second is more serious. Adding the above will enable the system to treat IsIn relationships as Contains, but to treat Contains relationships as IsIn we must also add "IsIn (X,Y) :- Contains (Y,X)." This introduces an infinite loop, a danger to which the lay knowledge engineer should not be exposed. To overcome it requires either expert programming or counter-intuitive restrictions on the form of the knowledge base. The problem seems to be that the KRF is not fully appropriate to the type of knowledge found in the real world.

4.2 Pointers in C

Any type of relationship can be difficult in third generation languages like C. Usually relationships are implemented as pointers. For instance, if we wish to express the idea that a certain field contains a number of Lapwing nests, then we must establish a relationship between them. We might have two structures, Field and LapWingNest, each of which has pointers to the other:

      struct Field  {
        ...
        struct LapwingNest *Contains;
        ...
        };

      struct LapwingNest  {
        ...
        struct Field *IsIn;
        struct LapwingNest *NextNest;
        ...
        };

The IsIn pointer allows us to find the Field, given the LapwingNest. The Contains and NextNest pointers form a linked list which allows us to find any of the Nests in a given Field. Using pointers in this manner, even though sufficient, efficient and adequately expressive, leads to problems. First, it is well known that pointers are a major source of bugs. Second, for a one-to-many relationship of this kind, the knowledge engineer has to shoulder all the responsibility of maintaining the linked list - and of remembering the extra NextNest pointer in the first place. Sometimes it is advisable to have a doubly linked list, and the task becomes even more complex. For many-to-many relationships the programming task is worse still. Third, pointers do not have the richness of real relationships. For instance, to add types (IsIn, Contains) that are accessible at run time rather than at compile time, the knowledge engineer must not only know how to add the required type data, but must know where to put it. Pointers are not a truly appropriate way of expressing relationships.

4.3 Change in the knowledge base

Change is endemic in real life. Suppose our knowledge base includes information about the number of eggs in each Lapwing's nest. Such information must be regularly updated as eggs are laid. With a procedural language like C representing such change can be very natural ("ThisNest- >Eggs += 1;") but with logic programming we have a problem. In many PROLOGs special programming is required: first RETRACT the proposition that the number of eggs is whatever it is, then ASSERT a new proposition that it is one greater. This goes against the declarative nature of logic, and depends on hidden side effects, which can always be dangerous. More complex changes require more complex - and more error prone - programming. The problem is exacerbated by the frame problem (McCarthy and Hayes, 1969), which is concerned with how the effects of a change are propagated. During the 1980s considerable research effort has been devoted to the problem of handling change , under the umbrella of non-monotonic reasoning, whether to represent a dynamic world as above or to handle common sense. However one gets the impression that a lot of the effort seems mis-directed. Brachman (1990), for instance, says, "An irony of work on NMR is that ... most current NMR proposals drastically compound the already difficult problem of deductive reasoning. We urgently need to determine how NMR can be used to make commonsense inference faster, not slower." Perhaps the root of the problem is that the KRFs being used are fundamentally inappropriate for handling change.

4.4 Spatial concepts

Suppose our field is surrounded on three sides by a wood, as shown in Fig 1. Such knowledge may be important in establishing what kind of species of plant, bird and animal are likely to inhabit the field. In real life situations, surrounding is a primitive spatial concept, rather than a complex one. How do we represent such facts using any of the extant KRSs? Using PROLOG or some other logic programming language one may try to reduce the concept of surrounding to proximity propositions. With C or some other KRF that is strong on numeric values, one might represent the knowledge in terms of (x,y) coordinates of the boundaries of field and wood. But in both cases the knowledge engineer has to know and implement the predicates or algorithms for assessing degree and type of surrounding from proximity propositions or (x,y) pairs. While there is little doubt that both PROLOG and C are sufficient to the task, and may even be efficient, neither is appropriate to this type of knowledge. Primitive concepts in real life should be supported by KR primitives rather than requiring an immense amount of programming.

4.5 Aggregation?

Perhaps such difficulties can be alleviated by an aggregation facility? Perhaps we can leave it to the knowledge engineer to write predicates, classes or routines that implement the necessary algorithms and thereafter refer to them by simple labels? The lay knowledge engineer can even hire a programmer to build these apparently special purpose facilities. But there are three problems with relying on this approach. First, the knowledge engineer may not know of the availability of such specially-written material. Second, s/he may not be fully conversant with how it should be used: the parameter interface has to be learned and the implementation often imposes restrictions on use. Many errors occur from misuse of such material. Third, and more fundamental, the examples given above were not esoteric; they happen every day, and in many applications. In terms of real life knowledge they are simple, even primitive, concepts. So the lay knowledge engineer would expect facilities to handle such knowledge would be made available in any good KRF as primitives, and should be provided in a fully integrated manner. Aggregation facilities should of course be made available, but they are not the ultimate answer. Aggregation should only be necessary when aggregating at the knowledge level, not at the symbol level. To achieve this requires that the KRF used should be appropriate to the types of knowledge encountered.

4.6 Appropriateness

We have seen examples of where the task of knowledge engineering has required some programming, from a relatively trivial example through to one where a considerable programming effort is required of the knowledge engineer. We have seen that it is inappropriateness of the KRF that leads to this state of affairs. The root of the problem in each case is that the KRF is not appropriate to the knowledge at hand.

Appropriateness thus appears to be a necessity, along with sufficiency, efficiency and some measure of expressive power, if we are to achieve our aim of what Brachman (1990) called 'KR to the People'.

But can we define appropriateness? Ultimately it may be an intuitive rather than rationalizable concept, but we can at least characterize it by examining the problems that lack of appropriateness generates. First, it increases the sheer volume of symbol level effort required of the knowledge engineer. (Knowledge level effort is to be expected by virtue of the degree of complexity in the knowledge itself.) Second, it can mean imposing arbitrary restrictions on how knowledge can be expressed. Third, it means that there is no mapping between primitive concepts in real life and primitives in representation. Fourth, it makes it more likely that errors will be made or other dangers encountered. Fifth, it means that the task becomes more and more expert, as the knowledge engineers are required to remember what dangers exist, what specialized symbol level techniques are needed, and how to perform them. Sixth, it has led to much research effort being possibly mis-directed.

5. TOWARDS APPROPRIATENESS

How can we move towards more appropriate KRFs, KRLs and KRSs? I think there are a number of factors that we need to consider that have received little attention in the KR community to date.

5.1 Primitives

We have heard a plea that those things that seem to the lay knowledge engineer to be primitive in real life should be supported by primitive facilities in the KRF. That is not to say that the facilities are simple, foolproof, requiring no skill in their use. Not all primitive real life concepts are are simple, so it would be wrong to expect facilities to support them should be simple; there many be a number of parameters to set in using the facility. But rather, where a concept is primitive in real life there should be a primitive facility in the KRF, and the parameters required by the KRS should match those of the real life concept.

5.2 Irreducibility

If we are to identify what primitives there are then we must recognise that this entails irreducibility among the primitives. One primitive cannot be reduced to others and if we try to do so then either appropriateness or efficiency, or both, are damaged. If a KRF provides a limited number of primitives then the knowledge engineer must undertake such reduction by programming the missing primitives in terms of those that are available.

How are we to identify all the primitives needed? Does it require a large research programme to ensure that none have been missed? Ultimately it will probably be a long time before all have been discovered, but our task may be made easier because it seems that primitives are grouped. Some primitives are to do with relationships, some with spatial knowledge, etc. Our research therefore can be aided if we identify irreducible aspects of knowledge around which these primitives are grouped.

5.3 Ontology

Identifying such aspects of knowledge requires ontology. The disciplines on which KR has been based up to now, computer science, psychology and epistemology are not sufficient since they only tell us what happens during the act of knowing and how to simulate that in silicon. They cannot tell us the structure of knowledge. Only ontology can do that, and it is notable that ontology has recently become more important in KR research (Brachman, 1990).

But there are two types of ontology. The first is ontology of the real world used for instance in the construction of class hierarchies. Rosenschein (1990) uses it in a different way, suggesting incorporation of knowledge of the world into the deduction engine. This, he claims, improves run-time efficiency. This type of ontology tells us that there are such things as rabbits, that they are mammals, that there are or are not laws pertaining to the the physical, social, aesthetic or juridicial worlds, etc. But it cannot help identify aspects of knowledge. What we need is not knowledge of the world as such, but to establish world-friendly structures and mechanisms.

What we need is ontology of knowledge itself, of the world of symbolic communication and manipulation. It is this that can help us identify genuine irreducibility among aspects of knowledge and the primitives that relate to them. Sadly, the intellectual climate over the past few decades has mitigated against even asking ontological questions about the structure of knowledge, so there are as yet very few firm answers.

5.4 Aspects of knowledge

I will venture to suggest four aspects of knowledge that I believe to be irreducible to each other. They are:

Items (entities, objects) have attributes (slots), and form relationships with each other. They are persistent. Values can be the contents of attributes, but are not persistent. Functions can be seen as a kind of relationship among values or a generator of values. Spatial knowledge includes not only simple concepts like direction and distance, but also concepts like surrounding, illustrated above. The word, change, are used in preference to time since the emphasis is not on temporal sequence but the fact that things change. The KB is embedded in the world and part of it, rather than just being a detached reasoner (Winograd and Flores, 1986). Change can be discrete or continuous. Primitives in each of these aspects can be aggregated to form more complex structures; for instance a number of primitive changes can be grouped to form a subroutine or method.

I do not claim that this is in any way an exhaustive list. But it does seem that KRFs that are deficient in one or more of these prove more difficult to use for wide-ranging knowledge, and that the difficulties correlate to these deficiencies. PROLOG is (nearly) appropriate for items and relationships but is less appropriate for values, change or space. LISP is appropriate for values but less so for items, change or space. C is appropriate for values and change, but inappropriate for handling items, relationships and space. Object oriented languages are good with items, values and change, but are weak when it comes to relationships and cannot handle space. To handle an aspect for which a KRF is inappropriate will involve programming rather than knowledge representation.

5.5 Aspects and primitives

The aspects of knowledge identified above are rather high level. To design a KRF, KRL and KRS to support them demands that we identify the primitives involved in each. However, having identified the aspects we do have some guidance. What we have to do is examine how each aspect appears in real life. This process can be illustrated by examining relationships.

Relationships are typed. They can be created and destroyed. They can be one-to-one, one-to-many or many-to-many. There can be constraints on what relationships can be formed between what items. They can be expressed syntactically either as predicates, or as frame slots, or as arrows linking boxes (among other ways). As Woods (1975) pointed out, many relationships can have variable semantics. Many KRSs and database management systems offer good support for these primitives, but not for the ones that follow. Many relationships are binary, but some are of greater arity, and few KRSs can easily support this without extra programming (Schmolze, 1989). As discussed above, most binary relationships have inverses, but very few KRSs give direct support. Relationships, with items, form graphs, and these are of different types: sets, lists, hierarchies, directed acyclic graphs (DAG), etc. In each of these the relationships can be followed in various ways, and each of these ways should be made available to the knowledge engineer. Finally, it should be possible to treat all relationships as items from time to time, allowing them to have attributes (including methods), and even to form relationships with other items or relationships.

Such an analysis is, of course, incomplete, and will be required for all the aspects if we are to move towards appropriate KRFs, KRLs and KRSs that can offer 'KR to the People'. Very few seem to have attempted such an analysis. Kent (1978) is worth reading, and Sowa (1984) moved a little in this direction.

5.6 Elements of a KRS

There are often seen to be three elements to a KRS: knowledge base (KB), engine and interface. The KB holds the knowledge and so the KRS must provide mechanisms to maintain the knowledge in the KB. The engine provides machine resources to carry out the various deductive and other methods required in order to act on the knowledge in the KB. The interface is the means whereby the knowledge engineer can enter knowledge or peruse it. Usually the interface is textual but recently graphical ones have been emerging. The interface includes not just software (KRS), but also the language (KRL) in which the knowledge is expressed and a recognition of the various language styles appropriate to each kind of knowledge (KRF). In some KRFs, such as PROLOG, the interface is bundled with the KB and engine, but there is no fundamental reason why they should not be independent.

What is important here is that each aspect of knowledge, and each primitive within each aspect, requires all three elements of the KRS.

5.7 Integration

Frisch (1989) has made it clear that: "Constructing a hybrid representation system involves more than just building a multitude of components, each with its specialized representation language [interface] and specialized deductive methods [engine]." Kappa-PC, for instance, does exactly this. It has two separate components: rules and objects. There are separate editors for rules and objects and automatic rule chaining only operates over the knowledge input via the rule editor. This lessens its general appropriateness.

The aspects of knowledge must be integrated at a more fundamental level. But an ontological understanding of them actually helps in such an integration. By acknowledging, for instance, that rules operate on values - any values - then those found in the attributes of items can be operated on by means of rules, and general appropriateness is enhanced. Further, values can also be operated on by procedural statements, by predicate statements, etc. so by ensuring that these too can operate on any values, we have a more complete integration of rules, procedures and predicates around values. The knowledge engineer then does not encounter the divisions found in Kappa-PC.

Such an approach also clearly identifies what design issues are likely to be important in building a KR system. It ensures, for instance, that the value mechanism is designed and implemented in such a way that changing a value by means of a procedural statement leads to some forward chaining of the change through any rules and predicates that refer to that value. The technology to achieve this is available today, having been developed in the traditional KRFs.

6. CONCLUSION

I admit it: what I am after is the general purpose knowledge representation system. The fact that it is unfashionable to seek such a beast is perhaps an indication that the time has come to do just that. Brachman (1990) suggests that the beast may be mythical, saying, "It may not be possible to rationalize the needs of all applications in one system, and simply opting for maximal expressive power may not be the best strategy." In this he assumes that the aims that prevailed when hunting the beast was fashionable are the only ways to catch it. I do not.

The KRS I am after does not offer maximum expressive power, as defined above. Indeed, it recognises that high expressive power can have drawbacks. My aim in KR is not to solve all logic problems in a short time, but rather to provide a high level of appropriateness so that lay people can do their own knowledge engineering. I want, as Brachman rightly points out, to bring 'KR to the People'.

This paper has discussed the need for appropriateness, has illustrated what it is and has discussed how it might be achieved.

Fundamental to achieving appropriateness is an ontological approach. An ontology of knowledge will identify irreducible aspects of knowledge, and primitives of those aspects. Each of these primitives should be supported in the KRS as primitive facilities for KB, engine and interface. Then the need for programming of symbol level operations is reduced. Examples were given of where such programming is often needed, and of the problems it generates. In particular spatial knowledge needs better support.

Such an approach has a number of benefits. First, it can explain the limitations encountered in most KRSs available today. Second, the elucidation of primitives may offer the metric of quality and scope that Brachman (1990) has called for. Third, it can provide guidance on the design of KR system by virtue of specifying what each primitive is and what is therefore required of the KB, engine and interface. Fourth, since the types of primitive envisaged are ontologically fundamental they form a basis for a fundamental integration not only of the KRFs found in AI but also with those found in mainstream computer science.

Work on such an approach is underway, and will be reported in due course.

ACKNOWLEDGEMENTS

Part of the kernel for such an approach is being developed in the Intelligent Authoring project funded by SERC (GR/J 17982).

REFERENCES

Basden A, (1989), "On the use of Expert Systems to handle Corrosion Knowledge", in Jovanovic A S, Kussmaul K F, Lucia A C, Bonissone P P (eds.), "Expert Systems in Structural Safety Assessment; Lecture Notes in Engineering", Springer Verlag.

Brachman R J, (1990), "The Future of Knowledge Representation", AAAI-90, Proc. Eighth National Conference on Artificial Intelligence, pp. 1082-92.

Crawford J M, Kuipers B J, (1991), "Negation and Proof by Contradiction in Access-Limited Logic", AAAI-91, Proc. Ninth National Conference on Artificial Intelligence, pp. 897-903.

Frisch A M, (1989), "A General Framework for Sorted Deduction: Fundamental Results on Hybrid Reasoning", in Brachman R J, Levesque H J, Reiter R (eds.), KR-89: Proc. of the First International Conference on Principles of Knowledge Representation and Reasoning, pp. 126-36

Kent W, (1978), "Data and Reality", North Holland.

Levesque H J, Brachman R J, (1985), "A Fundamental Tradeoffin Knowledge Representation and Reasoning (Revised Version)", in Brachman R J, Levesque H J, (eds.), "Readings in Knowledge Representation", Morgan Kaufmann, Los Altos, California.

McCarthy J, Hayes P J, (1969), "Some Philosopical Problems from the Standpoint of Artificial Intelligence", pp. 463-502, in Meltzer B, Michie D (eds.), Machine Intelligence 4, Edinburgh University Press.

Minsky M, (1981), "A framework for representing knowledge", in Haugeland J (ed.), "Mind Design", MIT Press, pp. 95-128.

Newell A, (1982), "The Knowledge Level", Artificial Intelligence, 18, p.87- 127.

Newell A, (1993), "Reflections on the knowledge level", Artificial Intelligence, v. 59, pp. 31-38.

Ringland G A, Duce D A, (1988), "Approaches to Knowledge Representation", Wiley, New York.

Rosenschein S J, (1990), "Reasoning and Acting in Real Time", AAAI-90, Proc. Eighth National Conference on Artificial Intelligence.

Schmolze J G, (1989), "Terminological Knowledge Representation Systems Supporting N-ary Terms", in Brachman R J, Levesque H J, Reiter R (eds.), KR-89: Proc. of the First International Conference on Principles of Knowledge Representation and Reasoning, pp. 432-43

Russell S, Wefald E, (1989), "Principles of Metareasoning", in Brachman R J, Levesque H J, Reiter R (eds.), KR-89: Proc. of the First International Conference on Principles of Knowledge Representation and Reasoning, pp. 400-11.

Selman B, Kautz H, (1991), "Knowledge Compilation using Horn Approximations", AAAI-91, Proc. Ninth National Conference on Artificial Intelligence, pp. 904-9.

Sowa J F, (1984), "Conceptual structures: information processing in minds and machines", Addison Wesley, Reading, MA, USA.

Winograd T, Flores F, (1986), "Understanding computers and cognition", Addison Wesley.

Woods W A, (1975), "What's in a Link: Foundations for Semantic Networks", in Bobrow D G, Collins A M (eds.), "Representation and Understanding: Studies in Cognitive Science", Academic Press, New York.


Copyright (c) Andrew Basden 2001.

Last updated: