Skip to main content

Subsection 4.3.2 Getting Started – What Predicates and Objects to Use

To use the logical tools that we’re describing, we first have to decide how to represent the knowledge that we have to work with. Let’s call this the representation problem.

In each of the examples we’ve done so far, we’ve started by defining a set of predicates. How did we pick them? How did we know that we’ve picked the “right” ones? Let’s look at some examples.

We wanted to say that everyone has to pay their taxes. So we wrote:

\(\forall \) x (Citizen(x) \(\rightarrow \) MustPayTaxes(x))

We could have defined the Citizen predicate so that it specifies the country that one is a citizen of. Then we could write, for example:

Citizen(x, USA)

If we’d done that, then we could have, if we’d wanted to, specified different rules for different countries. We could also have broken MustPayTaxes apart into pieces. We could have written:

MustPay(IncomeTax, x)), or MustPay(SalesTax, x))

In one problem, we wrote:

\(\forall \) x (HasLostWallet(x) \(\rightarrow \) Frantic(x))

But maybe we should have chosen predicates that are more general in their ability to describe losing things. Perhaps, instead of HasLostWallet(x), we should have written:

HasLost(x, Wallet), or HasLost(x, y) \(\wedge \) Wallet(y) \(\wedge \) Owns(x, y)

Note that the last one makes clear that x has lost an object that is a wallet and is, in fact, his/her own wallet.

Suppose that we want to say that everyone in the class has the flu. We could write:

\(\forall \) x (InClass(x) \(\rightarrow \) HasFlu(x))

But maybe we should choose a more general predicate that lets us talk about all kinds of diseases. Perhaps we should write:

\(\forall \) x (InClass(x) \(\rightarrow \) HasDisease(x, Flu))

In all of these examples, what’s the right thing to write?

The answer is that it depends. In particular, it depends on what other things we plan to encode and how we plan to reason with all the knowledge that we have. There is no single right answer. Whenever we set about to use our logical tools to accomplish something real, we have a design problem. We need to design a vocabulary that is powerful enough to accomplish our task but not so general that we get bogged down with details that don’t matter.

Big Idea

We choose predicates powerful enough for the job at hand but not more complicated than necessary.

When we’re doing mathematics, we generally start with primitives that have been chosen long before us. For example, we may start with the axioms that describe the integers and arithmetic. Or the axioms of geometry. Only rarely, if we’re developing a whole new theory, will we have to start from scratch choosing primitives.

When we’re working with a database and describing constraints on the values it can contain, our predicates are given to us – they correspond to the fields and the values in the database. The hard representational choices have to be made when the database itself is designed.

But suppose that we want to describe more open ended problems. Suppose we want to reason about our everyday world. Then what generally happens is that we’ll start with one set of predicates and objects. We’ll begin writing down what we know and seeing how we can reason with what we’ve written. We’ll discover that what we’ve got isn’t general enough for some new thing we want to say. So we’ll change some things and try again.

Exercises Exercises

Exercise Group.

1. Suppose that, instead of writing HasLostWallet(x), we’d chosen to describe the lost wallet situation by writing:

∀x, y ((HasLost(x, y) ∧ Wallet(y) ∧ Owns(x, y)) → Frantic(x))

Using those predicates, we could also represent some more general facts about people who lose things.

1.

(Part 1) Suppose we want to prove that people get frantic if they lose any important thing (and, in particular, a wallet). This wouldn’t have been straightforward using our original representation. But now it should be.

Consider the following facts that might be relevant:

I. ∀x (Wallet(x) → Important(x))

II. ∀x ( (∃y (HasLost(x, y) ∧ Important(y))) → Frantic(x))

III. ∀x (∃y ((HasLost(x, y) ∨ Important(y)) → Frantic(x)))

Which combination of these facts would help us to prove our conclusion:

  1. Just I.

  2. Just II.

  3. Just III.

  4. I and II together.

  5. I and III together.

Answer.
Correct answer is D.
Solution.
Explanation: I and II together is the correct answer. I says that wallets are important. We’d probably also have some other statements that say that cell phones and keys are important. II says that if there exists any important thing that x has lost then x will be frantic. III looks similar but it isn’t what we need. For one thing, it has an or when it should have an and. But, also, it asserts that there’s some y that would cause x to become frantic. We want to claim that all important y’s would have that effect.
2.

(Part 2) So now we’ve seen how a more general representation could be useful. Next let’s see whether we’ve gone far enough. We’ve got the predicate Important(x). Consider the following sentences that we might like to translate into logic:

  1. People get frantic when they lose something that is important to them (but not generally when it’s important only to someone else).

  2. People get frantic when they lose something that is both important and expensive to replace.

  3. People get frantic when they lose something that is super, super important.

Which of these statements can we encode with the representation we’ve got for describing importance? (Hint: Try to encode each of these statements. You may need some additional predicates for new concepts. But try to stick with what we’ve got so far for representing importance.)

  1. Just I.

  2. Just II.

  3. Just III.

  4. Just I and II

  5. Just I and III

Answer.
Correct answer is B
Solution.
Explanation: II is straightforward. We will need a new predicate Expensive(x), but then the sentence is easy to express. I is a problem, since our importance predicate doesn’t talk about importance to whom. To handle I, we could change it to IsImportantTo(y, x). III is a problem because things are either important or they’re not. We can’t encode levels of importance. We could do that if we changed Important(y) to ImportanceLevel(y, n), where n is, say, a number that measures importance level.