First Order Predicate Calculus

 

Predicate Calculus:  The appeal of predicate calculus is its simplicity.  In particular, it has a straightforward syntax that allows us to concentrate on the semantics of a knowledge-base rather than the details of the syntax.

 

Syntax:  The syntax of predicate calculus (or actually first-order predicate calculus - FOPC) consists of Terms, Predicates, Connectives and Quantifiers.

 

Terms:  Terms are simply ways of referring to things.  It can be a Constant, a Function, or a Variable.  All three of these, however, are simply ways of referring to things in the world.

 

Constants:  These are essentially names.  Roughly speaking, they name objects in the world.  FIDO and BOB are typical constants.  The constraints on what constitutes an object, however, are fairly loose.  As a result, JUSTICE, PURPLE, 137 and MY-UNICORN are all perfectly reasonable constants.  Often, we use the convention of generating new names for common objects by building a name out of the general object type and a number (e.g., CAR1, HOUSE15 and MUSTANG5).

 

Functions: These are also names of things.  But they are names of things that we don't have names for.  For example, (FATHER-OF BOB), is a name we can use to denote Bob's father even when we don't know the name of Bob's father.  The difference between Constants and Functions is that Functions have parameters that determine the value of the Function.  Do not make the mistake, however, of thinking that there has to exist a way to find the actual value (or name) of a Function.  (FATHER-OF BOB) does not return the name of Bob's father.  It is just another way of naming him.

 

Variables:  These are going to show up when we look at quantifiers.  They are useful when we want to say that something is true of all-things or that something is true of at least one-thing.  In general, they are used when we want to say something about collections of objects rather than individuals.

 

Predicates: These are used to state facts about the objects in the world denoted by Constants and Functions.  Sometimes these statements concern  a feature that an object has, as in (HAPPY BOB) or (SAD (FATHER-OF BOB)).  Statements about what we call features, however, are just special cases of naming relationships between objects, as in (OWNS BOB MUSTANG1) and (OLDER-THAN (FATHER-OF BOB) BOB).  If we assert that a predication (this is a predicate applied to a set of arguments) is true, this is meant to indicate that the object actually has the feature or that the relationship between objects mentioned holds.  Individual statements each have a truth-value (true or false).

 

Connectives: There are four basic connectives: AND, OR, NOT and IF.  These are used to combine individual predications into compound statements such as:

 

          (AND (OWNS BOB MUSTANG1) (COLOR MUSTANG1 BLUE))

          (OR           (LOCATION BOB (HOME-OF BOB))

                              (LOCATION BOB (HOME-OF SALLY)))

          (IF (LOCATION BOB (HOME-OF SALLY)) (HAPPY BOB))

          (NOT (COLOR MUSTANG1 RED))

 

Just as individual statements have truth-values, compound statements built out of Connectives have truth values that are determined by the truth values of their constituents.  The point of Connectives is to make statements about the relationships between the truth values of individual statements.  It is these relationships that allow us to later draw inferences.

 

The semantics of these Connectives should be clear and intuitive.  The intuitive meaning of IF, however, is not the actual meaning in the calculus.  The meaning of IF diverges from our intuitions in those cases in which the antecedent is false --- making the overall truth value of the compound statement true.

 

For example, the FOPC statement for "If I were on Mars, I could fly"  -

 

(IF (LOCATION KRIS MARS) (ABLE KRIS FLY))

 

- is true, as long as I am not on Mars.  Unlike the word "if", which implies a causal relationship between the antecedent and the consequent, the Connective "IF" implies no such relationship.

 

QUANTIFIERS:  The two quantifiers FORALL and EXISTS allow us to make statements that apply to classes of object rather than individual objects.  Each of the these Quantifiers also introduces variables. 

 

FORALL introduces what we call universal variables while EXISTS introduces what we call existential variables.  Statements containing universal variables are interpreted as meaning that the statement is true for all objects in the universe (god what power).  Statements containing existential variables are interpreted as meaning that the statement is true of at least one object in the universe.

 

The syntax of quantifiers is as follows:

 

          (FORALL (-vars-) statement)

          (EXISTS (-vars-) statement)

 

The statement (FORALL (X) (OR (BEAUTIFUL X) (UGLY X))) means everything is either ugly or beautiful.  On the other hand, the statement (EXISTS (X) (HONEST X)) means that there is something in the universe that is honest. 

 

Russell and Norvig provide an extended FOPC that includes a few more features:

 

Equality:  Equality is what you’d expect it to be.  It defines a relationship between terms.  It is short hand for the use of a “equals” predicate.  In effect, dog1=dogof(bob) is the same as writing equals(dog1, dogof(bob)).

 

The Uniqueness quantifier:  $! simple means that there exists one and only one instance of what falls under the scope of the quantifier.  We will tend to write it as “EXISTS!”.

 

IFF: If and only if.  This is equivalent to a->b b->a.

 

 

The Kinship domain

 

(forall (m c) (iff (= (Mother c) m) (and (Female m) (Parent m c))))

 

(forall (w h) (iff (Husband h w) (and (Male h) (Spouse h w))))

 

(forall (x) (iff (Male x) (not (Female x))))

 

(forall (p c) (iff (Parent p c) (Child c p)))

 

(forall (g c) (iff (Grandparent g c) (exists (x) (and (Parent g x) (Parent (x c))))))

 

(forall (x y) (iff (Sibling x y)

                         (and (not (equal x y)) (exists (p) (and (Parent p x) (Parent p y))))))

 

TELL and ASK

 

(TELL KB (forall (m c) (iff (= (Mother c) m) (and (Female m) (Parent m c))))))

 

(TELL KB (and (Female MAXI) (Parent MAXI SPOT) (Parent SPOT BOOTS)))

 

(ASK KB (Grandparent MAXI BOOTS))

 

(ASK KB (EXISTS (x) (Child x SPOT)))

 

The Situation Calculus

 

•         States that change: (At Agent 1 1 S1)

 

•         States the stay the same: (Wall 0 1)

 

•          Functions that establish relationships between situations: (equal (Result Forward S1) S2)

 

•          Actions expressed as their effects (effect axioms)

          Here actions are objects in the world.

 

          (Portable Gold)

          (forall (s) (if (Atgold s) (Present Gold s)))

          (forall (x s) (if (and (Present x s) (Portable x)) (Holding x (Result Grab s))))

 

          (for (x s) (not (Holding x (Result Release s))))

 

•         Frame axioms to establish the lack of change

 

          (forall (a x s) (if (and (Holding x s) (not (equal a Release))) (Holding x (Result a s))))

 

 

The Frame Problem

 

          The Representational Frame Problem (too many Frame Axioms)

 

          The Inferential Frame Problem (too many inferences when no change is taking place)

 

          The Qualification Problem (how to make sure an action is guaranteed to work)

 

          The Ramification Problem (implicit consequences)

 

 

 

Knowledge Engineering

 

What to Represent

 

Using FOPC as a Representation Language:  It takes a little practice to use FOPC well.  There are two sorts of problems that people tend to run into: the choice of predicates and the use of quantifiers. 

 

Predicates: Decisions about which predicates to use for a given domain tend be ad hoc in nature.  That is, there are no hard a fast rules that govern the choice of predicates.  There are however, some guidelines.

 

          The symptom of having got [the vocabulary] wrong is that it       

          seems hard to say anything useful about the concepts one has        

          proposed... It is easier, fortunately, to recognize when one [has   

          got it right]: assertions suggest themselves faster than one can        

          write them.

 

                                           Patrick Hayes 1984

 

          The initial choice of [primitives] to represent a new domain is     

          necessarily ad hoc.   We make an initial, tentative commitment

          to a new set... in the new knowledge domain.  In the process of

           codifying new knowledge, using the knowledge in computing

           programs... we modify, change or even replace our original

           choice.

 

                                        Schank and Carbonell 1979

 

The point here is that the best way to go about learning how to axiomatize a domain is to give it a try and learn from the problems you encounter.

 

There are some rules of thumb that do come in useful with a few predicates that tend to be very powerful.

 

Naming objects: The first rule of thumb has to do with naming items.  All objects have to have names (at least all objects in your data base).  We tend to make up names for things that relate to what they are.  One convention is to take the TYPE of an object and add a number suffix to it in order to build a name for it.  A particular LATHE, for example, would get the name LATHE10 or LATHE15.  While this means nothing to any program using the name, it does make the code more readable.

 

Anticipating Inference: A second rule of thumb is to try to anticipate the inference rules you will need for a domain, and build the rules that support them.  If, for example, you are concerned with the size of things, it makes no sense to select predicates describing density and weight of objects.  Even though the information you will need to reason about size will be stored in your data base, it will be awkward to use.

 

ISA and INST: Two predicates that you will tend to use over and over again are ISA and INST.  ISA stands for the relationship between sets and their subsets.  The general concept HORSE, for example, has an ISA relationship with ANIMAL - (ISA HORSE ANIMAL).  INST, on the other hand, stands for the relationship between and object and the set it is a member of.  For example, HORSE1 is an INST of HORSE - (INST HORSE1 HORSE).

 

Quantification: Another issue that is often problematic is the use of quantifiers.  To get you over the initial hump of dealing with them , we will look at a few examples of particularly common uses of quantification.

 

Quantifying over a restricted range:  Usually we have very little to say about everything  but often we have a lot to say about particular classes.  For example, we might want to say that HONDAs are great cars or that STUDENTs from CHICAGO are hard working.  To represent statements about such a restricted set of things we combine FORALL with IF in the following way:

 

          (FORALL (X) (IF (HONDA X) (GREAT X)))

 

and

 

          (FORALL (X) (IF (AND (STUDENT X) (LOCATION X CHICAGO))

                                    (HARDWORKING X))

 

This idiom is so common, that you can almost assume that someone has made a mistake if you see a FORALL that doesn't have an embedded IF.  Just think about how many statements are true of all things in the universe and you'll see why you will rarely write or read a universal that doesn't include an IF.

 

Specifying an existential: Often we want to describe a set of features that some object in the world has.  We do this by embedding an AND (containing statements of the features) within  an EXISTS.  For example, if we want to say something like "there is a girl for Dave" we would just state:

 

          (EXISTS (X) (AND (GIRL X) (FOR X DAVE)))

 

Again, this is so common that you should distrust an existential that does not contain an AND. 

 

Asserting that at least two things exist: When you use an existential, you are stating that at least one thing exists for which the scoped statement is true.  What about when you want to say that two things exist.  For example, let's say we want to state that Fred has two cars.  Using an existential with two variables we could say "there exists an X and a Y such that X is a car owned by Fred and Y is a car owned by Fred."  This would look like:

 

          (EXISTS (X Y)

         (AND (CAR X) (CAR Y) (OWNS FRED X) (OWNS FRED Y)))

 

This is OK right?  Wrong - because we have done nothing to restrict X and Y to be different cars.  So we have to add an explicit statement that X and Y are not the same:

 

          (EXISTS (X Y)

         (AND (CAR X) (OWNS FRED X)

                    (CAR Y) (OWNS FRED Y)

                    (NOT (= X Y))))

 

And, of course, we can now say that Fred has three cars, four cars on up the line.

 

 

Asserting that there is only one of something: The existential asserts that there is at least one of something, but it would be handy to also state that there is also only  one of something.  The usual idiom for saying that there is one and only one of something is:

 

          (FORALL (X Y)

                    (IF (AND (MARRIED FRED X) (MARRIED FRED Y))

                          (= X Y)))

 

Thus we satisfy ourselves that Fred is not a bigamist.  If we want to say that Fred has two wives but not more, we generalize this a bit:

 

          (FORALL (X Y Z)

                    (IF (AND (MARRIED FRED X)

                                   (MARRIED FRED Y)

                                   (MARRIED FRED Z))

                          (OR (= X Y) (= X Z) (= Y Z))))

 

Saying that everyone has one: Often you want to say that each object in a class has a relationship with another thing.

 

For example:

 

          (forall (x) (if (Person x) (exists (y) (and (Dream y) (Has x y))))

 

This states that everyone has a dream, but does not restrict the dream to be different from other dreams.  For this we need to add another variable to the universal:

 

(Forall (x) (if (Person x)

                              (Exists (z) (and (Dream z)

                                             (Has x z)

                                                      (forall (w) (if (not (= x w)) (not (Has w z))))))))

 

This reads:  everyone has a dream all his own.

 

Things to do when you are a KE -

 

1          Decide what to talk about.

 

2        Turn this into a vocabulary of predicates, functions, and constants.

 

3          Encode general knowledge about the domain. (Rules)

 

4          Encode specific knowledge of a problem instance.

 

5        Pose queries.