1. Introduction to production systems and CLIPS
2. CLIPS interface
3. Commands
4. Representing facts (propositions and objects)
5. Basic rules
6. Production systems and conflict resolution

To Come:


7. Pattern matching
8. Goals and problem decomposition
9. Complex constraints and pattern matching

This chapter introduces production systems. See also Anderson chapter 8, the class notes, Section 2 of the CLIPS Basic Programming Guide (pgs. 3-17), and the CLIPS User's Guide.

A production system contains three basic components:

1. Knowledge Base: This contains the things the system knows about. In CLIPS there are three ways to represent these things, of which we will only use the first two. CLIPS calls this the "fact list" because CLIPS refers to both of these representation structures as "facts" (ordered and unordered respectively).
   1. Ordered facts: This corresponds most naturally to what is usually called propositional representation in cognitive science. It is most naturally used to represent facts or propositions or statements that you want to make regarding what the system believes to be true. CLIPS calls these ordered facts because the components of the data structure are ordered. I often refer to these as simple facts. (See second class lesson.)
   2. Unordered facts: This corresponds most naturally to a simple form of object representation. It is also similar to the record structures found in many computer languages. I often refer to these as template facts because they require a deftemplate command to create the data structures used to define the individual facts. CLIPS calls these unordered facts because once the detemplate is created for the type of object or fact, then the parts of the object can be referred to in any order, and in fact you don't even need to refer to all the parts of a particular object.
   3. Objects: CLIPS has a full-fledged object language called COOL. (Commercial versions of CLIPS use the object capabilities of C++ directly.) One of the main differences between Ordered Facts and COOL is that objects in the latter are organized into inheritance hierarchies. Another is that it supports Object Programming, message sending etc.. But we won't be using these capabilities since they would require too much time to get into. When you learn about Object Programming you will be able to see how you can integrate OOP with CLIPS.


2. Rule Base: This contains a set of rules each of which contains an LHS (Left Hand Side) which contains a set of CEs (Conditional Elements), and a RHS (Right Hand Side) which contains a set of actions. The CEs are each patterns which are matched against the Knowledge Base to see if the CE is currently matchable in the KB. Actually, the entire LHS is (potentailly) a complex pattern, since there are various ways (based on the use of common variables) to make the different CEs mutually interdependent. When the LHS side of a rule is match in the current KB, then the RHS actions may be taken. The actions can consist of changes to the KB (adding, deleting or modifying facts/objects), or actions outside the system such as interacting with the user (asking for information or reporting results) or interacting with other elements (such as controlling physical devices or communicating with other software). We will not be doing the latter (communicating with other software or devices in this class.


3. Inference Engine: This is the software that runs the system. You don't have to write any code regarding this component but it is useful to understand it. And there are options that can be set regarding the second part of how this system works. The inference system works in cycles that repeat until the system can't do anything else or an explict halt command is encountered. Each cycle consists of three parts.
   1. Matching: All the rules are matched to find all the ways in which they can be matched against the current KB. A single rule might match in several ways. For instance, a rule that looked for two people with the same last name might find many pairs that had the same last name, and even many pairs with matching different names (e.g., two pairs of Smiths, and five pairs of Jones). Each particular match of a rule into the KB is called an instantiation (although I and others sometimes loosely talk of it as a "matched rule".)
   2. Conflict Resolution: Now the system needs to pick one instantiation out of those produced in the first (Matching) step. There are different criteria and algorithms for doing that. (See section 5.3 in the CLIPS Basic Programming Guide and the section below in this introduction.) This is the part of the inference engine that you can set to work in different ways depending on which conflict resolution strategy you select.
   3. Action: The system then executes whatever actions are on the RHS of the instantiation which was selected by Conflict Resolution. Typically rules have variables on the RHS which appeared also on the LHS. During matching those variables are instantiated with values which are then used by the actions taking by the RHS. So for instance, a RHS action might print out the names of the pairs of people found with identical last names.
   The running of a production system consists entirely of repeating this cycle as long as any rule can match the KB (unless a halt command is given). So the system is spending a good deal of its time considering 1. what actions are possible (matching), and 2. which of those actions is best to take (conflict resolution - although other factors can play a role here as well), and only a relatively small amount of time actually carrying out the action itself. This corresponds to the fact that when people carry out complex problem solving activities they also spend much more time figuring out what to do than actually doing it (in most circumstances). Although you won't really have to concern yourself with this, It is useful to realize that the algorithms used by the inference engine are much more efficient than they might appear at first. In particular, they keep track of the partial matches between the rules and the KB and only do whatever updating the actions of the third stage might require on each cycle, rather than doing a complete new (and largely redundant) pattern matching process on each cycle.