5 Propositions and Inference

5.3 Propositional Definite Clauses

The rest of this chapter considers some restricted languages and reasoning tasks that are useful and can be efficiently implemented.

The language of propositional definite clauses is a sublanguage of propositional calculus that does not allow uncertainty or ambiguity. In this language, propositions have the same meaning as in propositional calculus, but not all compound propositions are allowed in a knowledge base.

The syntax of propositional definite clauses is defined as follows:

  • An atomic proposition or atom is the same as in propositional calculus.

  • A definite clause is of the form

    ha1am.

    where h is an atom, the head of the clause, and each ai is an atom. It can be read “h if a1 and …and am”.

    If m>0, the clause is called a rule, where a1am is the body of the clause.

    If m=0 the arrow can be omitted and the clause is called an atomic clause or fact. The clause has an empty body.

  • A knowledge base is a set of definite clauses.

Example 5.6.

The elements of the knowledge base in Example 5.2 are all definite clauses.

The following are not definite clauses:

¬apple_is_eaten.
apple_is_eatenbird_eats_apple.
sam_is_in_roomnight_timeswitch_1_is_up.
Apple_is_eatenBird_eats_apple.
ℎ𝑎𝑝𝑝𝑦𝑠𝑎𝑑¬𝑎𝑙𝑖𝑣𝑒.

The fourth statement is not a definite clause because an atom must start with a lower-case letter.

A definite clause ha1am is false in interpretation I if a1am are all true in I and h is false in I; otherwise the definite clause is true in I.

Note that a definite clause is a restricted form of a clause. For example, the definite clause

abcd.

is equivalent to the clause

a¬b¬c¬d.

In general, a definite clause is equivalent to a clause with exactly one positive literal (non-negated atom). Propositional definite clauses cannot represent disjunctions of atoms (e.g., ab) or disjunctions of negated atoms (e.g., ¬c¬d).

Figure 5.2: An electrical environment with components named
Example 5.7.

Consider how to axiomatize the electrical environment of Figure 5.2 following the methodology for the user’s view of semantics. This axiomatization will allow us to simulate the electrical system. It will be expanded in later sections to let us diagnose faults based on observed symptoms.

The representation will be used to determine whether lights are on or off, based on switch positions and the status of circuit breakers. The agent is not concerned here with the color of the wires, the design of the switches, the length or weight of the wire, the date of manufacture of the lights and the wires, or any of the other myriad details one could imagine about the domain.

We must choose a level of abstraction. The aim is to represent the domain at the most general level that will enable the agent to solve the problems it must solve. We also want to represent the domain at a level that the agent will have information about. For example, we could represent the actual voltages and currents, but exactly the same reasoning would be done if this were a 12-volt DC system or a 120-volt AC system; the voltages and frequencies are irrelevant for questions about how switches affect whether lights are on. Instead, we represent this domain at a commonsense level that non-electricians may use to describe the domain, in terms of wires being live and currents flowing from the outside through wires to the lights, and that circuit breakers and light switches connect wires if they are turned on and working.

We have to choose what to represent. Suppose we want to represent propositions about whether lights are lit, whether wires are live, whether switches are up or down, and whether components are broken.

We then choose atoms with a specific meaning in the world. We can use descriptive names for these, such as up_s2 to represent whether switch s2 is up and live_l1 to represent whether light l1 is live (i.e., has power coming into it). The computer does not know the meaning of these names and does not have access to the components of the atom’s name.

At this stage, we have not told the computer anything. It does not know what the atoms are, let alone what they mean.

Once we have decided which symbols to use and what they mean, we tell the system, using definite clauses, background knowledge about what is true in the world. The simplest forms of definite clauses are those without bodies – the atomic clauses – such as

light_l1.
light_l2.
ok_l1.
ok_l2.
ok_cb1.
ok_cb2.
live_outside.

The designer may look at part of the domain and know that light l1 is live if wire w0 is live, because they are connected together, but may not know whether w0 is live. Such knowledge is expressible in terms of rules:

live_l1live_w0.
live_w0live_w1up_s2.
live_w0live_w2down_s2.
live_w1live_w3up_s1.
live_w2live_w3down_s1.
live_l2live_w4.
live_w4live_w3up_s3.
live_p1live_w3.
live_w3live_w5ok_cb1.
live_p2live_w6.
live_w6live_w5ok_cb2.
live_w5live_outside.
lit_l1light_l1live_l1ok_l1.
lit_l2light_l2live_l2ok_l2.

At run time, the user is able to input the observations of the current switch positions, such as

down_s1.
up_s2.
up_s3.

The knowledge base consists of all of the definite clauses, whether specified as background knowledge or as observations.