SOME VOCABULARY FOR SOCCER AGENTS A program is REACTIVE if it simply responds to the situation. It is DELIBERATIVE if it performs some kind of computation that might be called REASONING in order to DECIDE on an ACTION. It PLANS if it envisions future states that result from its CHOICES of action. A program possesses KNOWLEDGE if it moves tokens/symbols around that have a meaning or semantics both to the program (internal semantics) and the programmer (external semantics) that describe something, that can be true or false. True or false? You might say that it just takes the right attitude and then something becomes knowledge. I'd say, it takes the right attitude and a design that takes advantage of that attitude. All programs move symbols, but the ones that are meaningful to the programmer (e.g., print statements) might be EPIPHENOMENAL (have no bearing on the CAUSAL structure or CONTROL structure of the program). KNOWLEDGE might be thought of as the ability for the program and programmer to converse about the environment, even in the most trivial way. The simplest KNOWLEDGE is STATE. A variable that takes on UP/DOWN, TRUE/FALSE, has to be the simplest. Beyond that, a state vector, like the ones used in physical sciences or control theory. Moving up the ladder, a program might represent STATES, GOALS, INTENTIONS, ENVIRONMENT as sets of assertions in a logical language (don't you *ever* think that there is just one logic that can underly linguistic phenomena!!!!), or include probability distributions. Some knowledge is META-KNOWLEDGE, knowledge about knowledge, such as knowing what you do or don't know. Some knowledge is DECLARATIVE -- you could ASSERT it and we could fight about whether it is true or not. Some knowledge is PROCEDURAL, which is supposed to be KNOWING HOW rather than KNOWING THAT. A subroutine that adds is procedural knowledge. A subroutine that looks up 1 plus 1 to get 2, probably has some kind of declarative knowledge, and the procedural knowledge for doing table-lookup. The problem is that people use the phrase PROCEDURAL META-KNOWLEDGE, which is ambiguous: is it supposed to mean knowledge about procedural knowledge (such as which procedures work when) or procedural knowledge about knowledge (such as theorem-proving strategies)? Most of your programs will be reactive with procedural knowledge, but you might surprise me. To make your knowledge declarative, you usually have to worry about KNOWLEDGE REPRESENTATION (e.g., which logic to use?) and REASONING (using the logic). KR is the analogue of DATA PROCESSING. DATA is KNOWLEDGE when both you and the program treat it as describing states of the world. PROCESSING is REASONING when the data being processed are subject to the rules of the logic. Lots of symbols in DATABASES are represented knowledge, but not processed in interesting enough ways to be called reasoning. If DATAMINING of databases occurred in REAL TIME, it would be like reasoning. Reasoning does not have to be mathematical, does not have to be deep, does not have to follow "standard" canons of logic. A programmed pattern of illogic could be reasoning (reasoning illogically). Chess programs represent positions and reason about the effects of actions and the resulting value when they plan. INTELLIPATH reasons when it diagnoses, even if it is just pumping conditional probabilities through their paces. I suppose you could say that NINTENDO reasons when it renders situations, since it is reasoning about what are the effects of actions on states, but it doesn't seem USEFUL to TAKE THE INTENTIONAL STANCE (--Daniel Dennett, Tufts) in that case. When you grow older, you will realize that most KR&R is just the invention of compact notations that allow less than full commitment or specificity in the description of something (lots of ways of saying OR). Most of my colleagues don't realize this. What system of representation and reasoing isn't just notation is an interesting question (and the answer is the same as the question, why is RPL drawn to legal reasoning?). RULE-BASED control or design is when you use a set of rules -- if...then... statements, and just that (although you could add a bit of PROCEDURAL ATTACHMENT, which is like saying that you're using functional programming, but permitting PROG every once in a while, or you're using structured programming, but have a few GOTO's here and there). The set of rules themselves don't do anything, so there must be an INTERPRETER, or rule-processing stragegy/regimen. This should at least say in what order the rules are processed, and what to do when rules conflict. Rule-based programming is liked because it is one of the highest levels of abstraction at which programs can be specified (imagine a higher level -- just specifying goals, or constraints, to be satisfied). It's also liked because non-programmers (like experts and authorities) can read the programs. And it's liked because then the AI program starts looking like a rule book, or a set of laws... A program LEARNS if it changes (improves?) its behavior over time as the result of past experience. You could say that any program that drops data on a file or conditions probabilities or DETACHES rules is learning. But usually we mean something more impressive when we say that a program learns. It learns EXTENSIONALLY if it learns by example. It learns INTENSIONALLY (not intentionally!) if it can process descriptions (maybe someone TELLS IT!) at some higher level of generality, with descriptions of classes, not just particulars. We normally want to see at least a TRAINING stage followed by improved performance. You might say that the checkers program is being trained in the first 1000 games, for its 1001 game. But some programs really sit for weeks snicking through data trying to optimize this parameter or that (learning becomes simply parameter tweaking). Learning was popular in decades past because lots of psychologists were also studying this kind of thing. They tell us to think of things like learning by doing, learning by watching, learning by listening... I prefer now just to think of the learning toolbox: optimizers (including GENETIC ALGORITHMS and NEURAL NETS), inducers (including THEORY-FORMATION programs, DECISION-TREE INDUCTION and CLASSIFIERS -- incidentally, this includes all the REGRESSION methods that are the staple of the social sciences -- in that case, it is the social scientists who are trying to learn from the data), CHUNKERS and shortcutters (which are trying to group past experiences, usually adding MACROS), and CASE-BASED REASONERS (which are trying to THEORIZE about past instances, and include EBL, EXPLANATION-BASED LEARNING... whatever that is!). Perhaps we'll classify these in detail some time. A program is DECISION-THEORETIC if it chooses action based on probability and UTILITY -- which you might think of as the universal currency of cost. It is GAME-THEORETIC if it chooses its strategy in light of the strategies of its adversary. It is PROBABILISTIC if it uses a measure that satisfies the KOLMOGOROV AXIOMS for probability. Most pair this with some approaches from the BAYESIAN theory of CONFIRMATION. Otherwise, if it reasons with UNCERTAINTY in some other way, we might just say it does uncertain reasoning. There are lots of different methods for reasoning under uncertainty, some of which are even studied in statistics depts. Dempster-Shafer, Shackle (surprise), Popper (confirmation), Carnap, Jeffreys (maxentropy), Fisher (fiduciary), and Neyman-Pearson (classical statistics) are some names here. Others are just crappy methods you invent while you're programming. We call those AD HOC methods. FUZZY LOGIC is a KR&R strategy, not a way of reasoning under uncertainty. Most people are confused on this point because uncertainty uses numbers and so does fuzzy logic. But they are distinct. You could have a probabilistic fuzzy approach, or a fuzzy Dempster-Shafer approach.