John McCarthy 1984
전문가시스템은 어떤 영역에서 전문가의 지식과 능력을 표현하려고 시도하는 컴퓨터 프로그램이다. 특정 영역에서의 그 성과는 매우 인상적이었다. 그럼에도 불구하고 그들 중의 어떤 것도 정상적인 사람이면 가지고 있을 상식적인 지식과 능력을 표현하지는 못하였다. 이러한 능력의 결여는 그 프로그램들을 부질없는 것으로 만든다. 이럼으로써 프로그램은 디자이너에 의해 원래 구축된 영역을 뛰어넘기 어렵게 만들고 또한 그 자신의 한계를 보통 인식하지 못한다. 많은 중요한 어플리케이션들이 상식의 능력을 필요로한다.여기서는 상식의 능력을 서술하고 그에 필요한 문제들을 서술한다.
An expert system is a computer program intended to embody the knowledge and ability of an expert in a certain domain. The ideas behind them and several examples have been described in other lectures in this symposium. Their performance in their specialized domains are often very impressive. Nevertheless, hardly any of them have certain common sense knowledge and ability possessed by any non-feeble-minded human. This lack makes them ``brittle''. By this is meant that they are difficult to extend beyond the scope originally contemplated by their designers, and they usually don't recognize their own limitations. Many important applications will require common sense abilities. The object of this lecture is to describe common sense abilities and the problems that require them.
상식의 사실과 방법론들은 오늘날 매우 부분적으로만 이해되고 있고 이러한 이해를 확장시키는 것은 AI 가 직면한 가장 중요한 문제이다. 이러한 것이 아주 새로운 관점은 아니다. 1958 년에 그러한 주제로 논문을 쓴 이래로 ``Computer Programs with Common Sense''을 계속해서 주창해왔다. 상식에 관한 연구는 AI 연구자들 사이에 언제는 일반적이었고 언제는 인기가 없었다. 요즘에는 인기가 있는 것 같은데 아마도 새로운 AI 지식들이 새로운 진보의 가능성을 보여준다. 확실히 내가 1958 또는 1969 년에 상식에 대해 논문을 썼던데에 비하면 훨씬 더 많이 연구하고 있다.그러나 상식을 형식적인 언어로 표현하는 것은 매우 어려운 것으로 증명되면서 이 영역을 공부하는 과학자들의 수는 훨씬 더 줄게된다.
Common sense facts and methods are only very partially understood today, and extending this understanding is the key problem facing artificial intelligence.
This isn't exactly a new point of view. I have been advocating ``Computer Programs with Common Sense''since I wrote a paper with that title in 1958. Studying common sense capability has sometimes been popular and sometimes unpopular among AI researchers. At present it's popular, perhaps because new AI knowledge offers new hope of progress. Certainly AI researchers today know a lot more about what common sense is than I knew in 1958 -- or in 1969 when I wrote another paper on the subject. However, expressing common sense knowledge in formal terms has proved very difficult, and the number of scientists working in the area is still far too small.
가장 널리알려진 전문가시스템중의 하나가 의사에게 혈액의 세균감염과 뇌막염을 치료하는데 도움을 주는 프로그램인 MYCIN이다. 그것은 사용자가 상식을 가지고 있고 그 프로그램의 한계를 이해하고 있다는 전제에서 상식이 없이도 잘 수행이 된다.
One of the best known expert systems is MYCIN (Shortliffe 1976; Davis, Buchanan and Shortliffe 1977), a program for advising physicians on treating bacterial infections of the blood and meningitis. It does reasonably well without common sense, provided the user has common sense and understands the program's limitations.
MYCIN 은 질문과 답변의 대화를 수행한다. 이름과 성 나이와 같은 환자에 대한 기본적인 사실을 질문한 후에 MYCIN 은 의심이 되는 세균, 의심된는 감염부위, 진단하기에 적절한 특정 증상의 존재, 실험실 검사결과, 등등에 대한 질문을 한다. 그리고 나서 어떠한 항생제의 투여를 추천한다. 대화는 영어로 하지만 대화를 콘트롤 하기위해 영어를 자유로이 구사해야 하는 것은 아니다. 그것은 문장으로 출력하지만 단지 한나의 단어나 구문으로만 타이핑된다. 그것이 이전의 전문가시스템보다 혁신적인 것은 진단을 위해서 비 확률적인 방법의 불확실성의 측정을 사용한다는 것과 의사에게 그 추론을 설명한다는 사실이며 그럼으로써 의사는 그 결과를 받아들일지를 결정할수 있다는 것이다.
MYCIN conducts a question and answer dialog. After asking basic facts about the patient such as name, sex and age, MYCIN asks about suspected bacterial organisms, suspected sites of infection, the presence of specific symptoms (e.g. fever, headache) relevant to diagnosis, the outcome of laboratory tests, and some others. It then recommends a certain course of antibiotics. While the dialog is in English, MYCIN avoids having to understand freely written English by controlling the dialog. It outputs sentences, but the user types only single words or standard phrases. Its major innovations over many previous expert systems were that it uses measures of uncertainty (not probabilities) for its diagnoses and the fact that it is prepared to explain its reasoning to the physician, so he can decide whether to accept it.
MYCIN 의 존재론으로부터 논의를 시작해보자. 하나의 프로그램의 존재는 그 변이의 영역의 집합이다. 근본적으로 그것이 무엇에 관한 정보를 가질수 있느냐 하는 것이다. MYCIN 에 존재하는 것은 세균, 증상들, 가능한 감염부위, 항생제, 치료등이다. 의사,질병,병원,죽음등은 존재치 않는다. MYCIN 이 특정 환자에 대해 많은 사실들을 질문하지만 환자조차도 존재의 일부분이 아니다. 이것은 환자가 변수의 값이 아니기 때문이며 MYCIN 은 결코 다른 두 환자의 감염은 비교할수는 없다. 따라서그것의 경험으로부터 학습에 의해서 MYCIN을 변경시키는 것은 어렵다. (ontology 는 변수와 그 값의 존재에 의해서 새로이 학습하는 것에서 그 의미를 찾는다)
Our discussion of MYCIN begins with its ontology. The ontology of a program is the set of entities that its variables range over. Essentially this is what it can have information about.
MYCIN's ontology includes bacteria, symptoms, tests, possible sites of infection, antibiotics and treatments. Doctors, hospitals, illness and death are absent. Even patients are not really part of the ontology, although MYCIN asks for many facts about the specific patient. This is because patients aren't values of variables, and MYCIN never compares the infections of two different patients. It would therefore be difficult to modify MYCIN to learn from its experience.
EMYCIN 이라고 알려진 것에 의해 작성된 MYCIN 프로그램은 소위 production system 이다. 그것은 각자가 패턴부와 액션부로 구성이 되는 규칙들의 집합이다. 하나의 규칙이 활성화되면 MYCIN 은 패턴부가 데이터베이스와 매치되는지를 검사한다. 만일 매치가 안되면 또다른 규칙을 시도해본다. 만일 매치가 되면 패턴부에 의해 결정된 변수의 값을 사용해서 패턴의 액션부를 수행한다. 질문과 치료 추천의 전과정은 엄청난 결과를 낳았다.
MYCIN's program, written in a general scheme called EMYCIN, is a so-called production system. A production system is a collection of rules, each of which has two parts -- a pattern part and an action part. When a rule is activated, MYCIN tests whether the pattern part matches the database. If so this results in the variables in the pattern being matched to whatever entities are required for the match of the database. If not the pattern fails and MYCIN tries another. If the match is successful, then MYCIN performs the action part of the pattern using the values of the variables determined by the pattern part. The whole process of questioning and recommending is built up out of productions.
production formalism 은 세균감염의 진단과 치료에 대한 많은 양의 정보를 표현하는데 적당한 것으로 판명되었다. MYCIN 이 의도된 방법대로만 사용된다면 의과대 학생이나,인턴,임상 내과의사에게 같은 방법으로 질문하였을 때 보다도 세균성 질환에서 더 나은 결과를 보였다. 그러나 MYCIN 은 대량 생산되어 사용되지는 않아왔다. 내가 원하는 의사에게 마이크로 컴퓨터에 넣어 MYCIN cassette를 파는 것이 적당한지를 물었을 때 그 영역의 전문가에 의해 주어진 이유는 다양했다. 만일 MYCIN 의 데이터베이스를 그 분야에서의 새로운 발견으로서,새로운 검사,새로운 이론,새로운 진단,새로운 항생제등과 같이 취급한다면 그것은 OK 일 것이라고 어떤사람은 얘기한다. 예를 들면 MYCIN 이 종료된 후에 Legionnaire's disease 에 대해서 그리고 연관된 Legionnella 균에 대해서 설명되어야 할 것이다. (MYCIN 은 새로운 세균에 대해서는 매우 둔감하며 단지 "인식되지 않는 반응" 이란 답변을 할뿐이다.
The production formalism turned out to be suitable for representing a large amount of information about the diagnosis and treatment of bacterial infections. When MYCIN is used in its intended manner it scores better than medical students or interns or practicing physicians and on a par with experts in bacterial diseases when the latter are asked to perform in the same way. However, MYCIN has not been put into production use, and the reasons given by experts in the area varied when I asked whether it would be appropriate to sell MYCIN cassettes to doctors wanting to put it on their micro-computers. Some said it would be ok if there were a means of keeping MYCIN's database current with new discoveries in the field, i.e. with new tests, new theories, new diagnoses and new antibiotics. For example, MYCIN would have to be told about Legionnaire's disease and the associated Legionnella bacteria which became understood only after MYCIN was finished. (MYCIN is very stubborn about new bacteria, and simply replies ``unrecognized response''.)
어떤사람들은 MYCIN을 실험적인 목적이외로는 사용할수가 없다고 얘기하는데 왜냐하면 그 자신의 한계를 모르기 때문이다. 나는 이것에 대해 MYCIN을 사용하는 의사가 그것의 한계에 대한 문서를 이해하려고 시도했는지를 묻고싶다. 프로그래머는 항상 사용자가 잘 모른다는 생각을 가지고서 개발한다, 그래서 MYCIN 의 한계에 의해 의사가 오도될 정도로 어리석지는 않다는 견해는 적어도 부분적으로는 이러한 이데올로기의 연속상에서 있을수 있다.
Others say that MYCIN is not even close to usable except experimentally, because it doesn't know its own limitations. I suppose this is partly a question of whether the doctor using MYCIN is trusted to understand the documentation about its limitations. Programmers always develop the idea that the users of their programs are idiots, so the opinion that doctors aren't smart enough not to be misled by MYCIN's limitations may be at least partly a consequence of this ideology.
그것의 한계를 모르는 MYCIN 의 예는 환자가 장에 Cholerae Vibrio 균을 가지고 있다고 MYCIN 에 말할 때 발생할수 있다. MYCIN 은 좋아라고 2 주의 테트라싸이클린을 처방하고 끝날 것이다. 아마도 이것으로 세균은 죽을 것이지만 환자는 오래지 않아 콜레라로 죽을 것이다. 그러나 의사는 설사가 치료되어야하고 그 밖의 다른 것들을 살펴야 한다는 것을 아마도 알 것이다.
An example of MYCIN not knowing its limitations can be excited by telling MYCIN that the patient has Cholerae Vibrio in his intestines. MYCIN will cheerfully recommend two weeks of tetracycline and nothing else. Presumably this would indeed kill the bacteria, but most likely the patient will be dead of cholera long before that. However, the physician will presumably know that the diarrhea has to be treated and look elsewhere for how to do it.
반면에 좁은 영역에서 조차도 어느정도의 상식이 사용될 필요가 있다는 것은 사실일 것이다. 우리는 어떤영역의 상식적 지식과 추론 능력을 보여줄 것이고 또한 MYCIN 과 MYCIN 영역에서 작동되는 다른 가설 프로그램에 응용하여 볼것이다.
On the other hand it may be really true that some measure of common sense is required for usefulness even in this narrow domain. We'll list some areas of common sense knowledge and reasoning ability and also apply the criteria to MYCIN and other hypothetical programs operating in MYCIN's domain.
Understanding common sense capability is now a hot area of research in artificial intelligence, but there is not yet any consensus. We will try to divide common sense capability into common sense knowledge and common sense reasoning, but even this cannot be made firm. Namely, what one man builds as a reasoning method into his program, another can express as a fact using a richer ontology. However, the latter can have problems in handling in a good way the generality he has introduced.
We shall discuss various areas of common sense knowledge.
1. The most salient common sense knowledge concerns situations that change in time as a result of events. The most important events are actions, and for a program to plan intelligently, it must be able to determine the effects of its own actions.
Consider the MYCIN domain as an example. The situation with which MYCIN deals includes the doctor, the patient and the illness. Since MYCIN's actions are advice to the doctor, full planning would have to include information about the effects of MYCIN's output on what the doctor will do. Since MYCIN doesn't know about the doctor, it might plan the effects of the course of treatment on the patient. However, it doesn't do this either. Its rules give the recommended treatment as a function of the information elicited about the patient, but MYCIN makes no prognosis of the effects of the treatment. Of course, the doctors who provided the information built into MYCIN considered the effects of the treatments.
Ignoring prognosis is possible because of the specific narrow domain in which MYCIN operates. Suppose, for example, a certain antibiotic had the precondition for its usefulness that the patient not have a fever. Then MYCIN might have to make a plan for getting rid of the patient's fever and verifying that it was gone as a part of the plan for using the antibiotic. In other domains, expert systems and other AI programs have to make plans, but MYCIN doesn't. Perhaps if I knew more about bacterial diseases, I would conclude that their treatment sometimes really does require planning and that lack of planning ability limits MYCIN's utility.
The fact that MYCIN doesn't give a prognosis is certainly a limitation. For example, MYCIN cannot be asked on behalf of the patient or the administration of the hospital when the patient is likely to be ready to go home. The doctor who uses MYCIN must do that part of the work himself. Moreover, MYCIN cannot answer a question about a hypothetical treatment, e.g. ``What will happen if I give this patient penicillin?'' or even ``What bad things might happen if I give this patient penicillin?''.
2. Various formalisms are used in artificial intelligence for representing facts about the effects of actions and other events. However, all systems that I know about give the effects of an event in a situation by describing a new situation that results from the event. This is often enough, but it doesn't cover the important case of concurrent events and actions. For example, if a patient has cholera, while the antibiotic is killing the cholera bacteria, the damage to his intestines is causing loss of fluids that are likely to be fatal. Inventing a formalism that will conveniently express people's common sense knowledge about concurrent events is a major unsolved problem of AI.
3. The world is extended in space and is occupied by objects that change their positions and are sometimes created and destroyed. The common sense facts about this are difficult to express but are probably not important in the MYCIN example. A major difficulty is in handling the kind of partial knowledge people ordinarily have. I can see part of the front of a person in the audience, and my idea of his shape uses this information to approximate his total shape. Thus I don't expect him to stick out two feet in back even though I can't see that he doesn't. However, my idea of the shape of his back is less definite than that of the parts I can see.
4. The ability to represent and use knowledge about knowledge is often required for intelligent behavior. What airline flights there are to Singapore is recorded in the issue of the International Airline Guide current for the proposed flight day. Travel agents know how to book airline flights and can compute what they cost. An advanced MYCIN might need to reason that Dr. Smith knows about cholera, because he is a specialist in tropical medicine.
5. A program that must co-operate or compete with people or other programs must be able to represent information about their knowledge, beliefs, goals, likes and dislikes, intentions and abilities. An advanced MYCIN might need to know that a patient won't take a bad tasting medicine unless he is convinced of its necessity.
6. Common sense includes much knowledge whose domain overlaps that of the
exact sciences but differs from it epistemologically. For example, if I spill
the glass of water on the podium, everyone knows that the glass will break and
the water will spill. Everyone knows that this will take a fraction of a second
and that the water will not splash even ten feet. However, this information
is not obtained by using the formula for a falling body or the Navier-Stokes
equations governing fluid flow. We don't have the input data for the equations,
most of us don't know them, and we couldn't integrate them fast enough to decide
whether to jump out of the way. This common sense physics is contiguous with
scientific physics. In fact scientific physics is imbedded in common sense physics,
because it is common sense physics that tells us what the equation 
means. If MYCIN were extended to be a robot physician it would have to know
common sense physics and maybe also some scientific physics.
It is doubtful that the facts of the common sense world can be represented adequately by production rules. Consider the fact that when two objects collide they often make a noise. This fact can be used to make a noise, to avoid making a noise, to explain a noise or to explain the absence of a noise. It can also be used in specific situations involving a noise but also to understand general phenomena, e.g. should an intruder step on the gravel, the dog will hear it and bark. A production rule embodies a fact only as part of a specific procedure. Typically they match facts about specific objects, e.g. a specific bacterium, against a general rule and get a new fact about those objects.
Much present AI research concerns how to represent facts in ways that permit them to be used for a wide variety of purposes.
Our ability to use common sense knowledge depends on being able to do common sense reasoning.
Much artificial intelligence inference is not designed to use directly the rules of inference of any of the well known systems of mathematical logic. There is often no clear separation in the program between determining what inferences are correct and the strategy for finding the inferences required to solve the problem at hand. Nevertheless, the logical system usually corresponds to a subset of first order logic. Systems provide for inferring a fact about one or two particular objects from other facts about these objects and a general rule containing variables. Most expert systems, including MYCIN, never infer general statements, i.e. quantified formulas.
Human reasoning also involves obtaining facts by observation of the world, and computer programs also do this. Robert Filman did an interesting thesis on observation in a chess world where many facts that could be obtained by deduction are in fact obtained by observation. MYCIN's doesn't require this, but our hypothetical robot physician would have to draw conclusions from a patient's appearance, and computer vision is not ready for it.
An important new development in AI (since the middle 1970s) is the formalization of nonmonotonic reasoning.
Deductive reasoning in mathematical logic has the following property -- called monotonicity by analogy with similar mathematical concepts. Suppose we have a set of assumptions from which follow certain conclusions. Now suppose we add additional assumptions. There may be some new conclusions, but every sentence that was a deductive consequence of the original hypotheses is still a consequence of the enlarged set.
Ordinary human reasoning does not share this monotonicity property. If you know that I have a car, you may conclude that it is a good idea to ask me for a ride. If you then learn that my car is being fixed (which does not contradict what you knew before), you no longer conclude that you can get a ride. If you now learn that the car will be out in half an hour you reverse yourself again.
Several artificial intelligence researchers, for example Marvin Minsky (1974) have pointed out that intelligent computer programs will have to reason nonmonotonically. Some concluded that therefore logic is not an appropriate formalism.
However, it has turned out that deduction in mathematical logic can be supplemented by additional modes of nonmonotonic reasoning, which are just as formal as deduction and just as susceptible to mathematical study and computer implementation. Formalized nonmonotonic reasoning turns out to give certain rules of conjecture rather than rules of inference -- their conclusion are appropriate, but may be disconfirmed when more facts are obtained. One such method is circumscription, described in (McCarthy 1980).
A mathematical description of circumscription is beyond the scope of this lecture, but the general idea is straightforward. We have a property applicable to objects or a relation applicable to pairs or triplets, etc. of objects. This property or relation is constrained by some sentences taken as assumptions, but there is still some freedom left. Circumscription further constrains the property or relation by requiring it to be true of a minimal set of objects.
As an example, consider representing the facts about whether an object can fly in a database of common sense knowledge. We could try to provide axioms that will determine whether each kind of object can fly, but this would make the database very large. Circumscription allows us to express the assumption that only those objects can fly for which there is a positive statement about it. Thus there will be positive statements that birds and airplanes can fly and no statement that camels can fly. Since we don't include negative statements in the database, we could provide for flying camels, if there were any, by adding statements without removing existing statements. This much is often done by a simpler method -- the closed world assumption discussed by Raymond Reiter. However, we also have exceptions to the general statement that birds can fly. For example, penguins, ostriches and birds with certain feathers removed can't fly. Moreover, more exceptions may be found and even exceptions to the exceptions. Circumscription allows us to make the known exceptions and to provide for additional exceptions to be added later -- again without changing existing statements.
Nonmonotonic reasoning also seems to be involved in human communication. Suppose I hire you to build me a bird cage, and you build it without a top, and I refuse to pay on the grounds that my bird might fly away. A judge will side with me. On the other hand suppose you build it with a top, and I refuse to pay full price on the grounds that my bird is a penguin, and the top is a waste. Unless I told you that my bird couldn't fly, the judge will side with you. We can therefore regard it as a communication convention that if a bird can fly the fact need not be mentioned, but if the bird can't fly and it is relevant, then the fact must be mentioned.
Davis, Randall; Buchanan, Bruce; and Shortliffe, Edward (1977). Production Rules as a Representation for a Knowledge-Based Consultation Program, Artificial Intelligence, Volume 8, Number 1, February.
McCarthy, John (1960). Programs with Common Sense, Proceedings of the Teddington Conference on the Mechanization of Thought Processes, London: Her Majesty's Stationery Office. (Reprinted in this volume, pp. 000-000).
McCarthy, John and Patrick Hayes (1969). Some Philosophical Problems from the Standpoint of Artificial Intelligence, in B. Meltzer and D. Michie (eds), Machine Intelligence 4, Edinburgh University. (Reprinted in B. L. Webber and N. J. Nilsson (eds.), Readings in Artificial Intelligence, Tioga, 1981, pp. 431-450; also in M. J. Ginsberg (ed.), Readings in Nonmonotonic Reasoning, Morgan Kaufmann, 1987, pp. 26-45; also in this volume, pp. 000-000.)
McCarthy, John (1980). Circumscription -- A Form of Nonmonotonic Reasoning, Artificial Intelligence, Volume 13, Numbers 1,2. (Reprinted in B. L. Webber and N. J. Nilsson (eds.), Readings in Artificial Intelligence, Tioga, 1981, pp. 466-472; also in M. J. Ginsberg (ed.), Readings in Nonmonotonic Reasoning, Morgan Kaufmann, 1987, pp. 145-152; also in this volume, pp. 000-000.)
Minsky, Marvin (1974). A Framework for Representing Knowledge, M.I.T. AI Memo 252.
Shortliffe, Edward H. (1976). Computer-Based Medical Consultations: MYCIN, American Elsevier, New York, NY.
QUESTION: You said the programs need common sense, but that's like saying,
If I could fly I wouldn't have to pay Eastern Airliness 
44 to haul me up here from Washington. So if the programs indeed need common
sense, how do we go about it? Isn't that the point of the argument?
DR. MCCARTHY: I could have made this a defensive talk about artificial intelligence, but I chose to emphasize the problems that have been identified rather than the progress that has been made in solving them. Let me remind you that I have argued that the need for common sense is not a truism. Many useful things can be done without it, e.g. MYCIN and also chess programs.
QUESTION: There seemed to be a strong element in your talk about common sense, and even humans developing it, emphasizing an experiential component -- particularly when you were giving your example of dropping a glass of water. I'm wondering whether the development of these programs is going to take similar amounts of time. Are you going to have to have them go through the sets of experiences and be evaluated? Is there work going on in terms of speeding up the process or is it going to take 20 years for a program from the time you've put in its initial state to work up to where it has a decent amount of common sense?
DR. MCCARTHY: Consider your 20 years. If anyone had known in 1963 how to make a program learn from its experience to do what a human does after 20 years, they might have done it, and it might be pretty smart by now. Already in 1958 there had been work on programs that learn from experience. However, all they could learn was to set optimal values of numerical parameters in the program, and they were quite limited in their ability to do that. Arthur Samuel's checker program learned optimal values for its parameters, but the problem was that certain kinds of desired behavior did not correspond to any setting of the parameters, because it depended on the recognition of a certain kind of strategic situation. Thus the first prerequisite for a program to be able to learn something is that it be able to represent internally the desired modification of behavior. Simple changes in behavior must have simple representations. Turing's universality theory convinces us that arbitrary behaviors can be represented, but they don't tell us how to represent them in such a way that a small change in behavior is a small change in representation. Present methods of changing programs amount to education by brain surgery.
QUESTION: I would ask you a question about programs needing common sense in a slightly different way, and I want to use the MYCIN program as an example.
There are three actors there -- the program, the physician, and the patient. Taking as a criterion the safety of the patient, I submit that you need at least two of these three actors to have common sense.
For example if (and sometimes this is the case) one only were sufficient, it would have to be the patient because if the program didn't use common sense and the physician didn't use common sense, the patient would have to have common sense and just leave. But usually, if the program had common sense built in and the physician had common sense but the patient didn't, it really might not matter because the patient would do what he or she wants to do anyway.
Let me take another possibility. If only the program has common sense and neither the physician nor the patient has common sense, then in the long run the program also will not use the common sense. What I want to say is that these issues of common sense must be looked at in this kind of frame of reference.
DR. MCCARTHY: In the use of MYCIN, the physician is supposed to supply the common sense. The question is whether the program must also have common sense, and I would say that the answer is not clear in the MYCIN case. Purely computational programs don't require common sense, and none of the present chess programs have any. On the other hand, it seems clear that many other kinds of programs require common sense to be useful at all.