Humans' View of Semantics

The formal description of semantics does not tell us why semantics is interesting or how it can be used as a basis to build intelligent systems. The basic idea behind the use of logic is that, when knowledge base designers have a particular world they want to characterize, they can select that world as an intended interpretation, select denotations for the symbols with respect to that interpretation, and write, as clauses, what is true in that world. When the system computes a logical consequence of a knowledge base, the knowledge base designer or a user can interpret this answer with respect to the intended interpretation. Because the intended interpretation is a model, and a logical consequence is true in all models, a logical consequence must be true in the intended interpretation.

Informally, the methodology for designing a representation of the world and how it fits in with the formal semantics is as follows:

Step 1
Select the task domain or world to represent. This could be some aspect of the real world (for example, the structure of courses and students at a university, or a laboratory environment at a particular point in time), some imaginary world (for example, the world of Alice in Wonderland, or the state of the electrical environment if a switch breaks), or an abstract world (for example, the world of numbers and sets). Within this world, let the domain D be the set of all individuals or things that you want to be able to refer to and reason about. Also, select which relations to represent.
Step 2
Associate constants in the language with individuals in the world that you want to name. For each element of D you want to refer to by name, assign a constant in the language. For example, you may select the name "kim" to denote a particular professor, the name "cs322" for a particular introductory AI course, the name "two" for the number that is the successor of the number one, and the name "red" for the color of stoplights. Each of these names denotes the corresponding individual in the world.
Step 3
For each relation that you may want to represent, associate a predicate symbol in the language. Each n-ary predicate symbol denotes a function from Dn into {true,false}, which specifies the subset of Dn for which the relation is true. For example, the predicate symbol "teaches" of two arguments (a teacher and a course) may correspond to the binary relation that is true when the individual denoted by the first argument teaches the course denoted by the second argument. These relations need not be binary. They could have any number of (zero or more) arguments. For example, "is_red" may be a predicate that has one argument.

These associations of symbols with their meanings forms an intended interpretation.

Step 4
You now write clauses that are true in the intended interpretation. This is often called axiomatizing the domain, where the given clauses are the axioms of the domain. If the person who is denoted by the symbol kim actually teaches the course denoted by the symbol cs502, you can assert the clause teaches(kim,cs502) as being true in the intended interpretation.
Step 5
Now you are able to ask questions about the intended interpretation and to interpret the answers using the meaning assigned to the symbols.

Following this methodology, the knowledge base designer does not actually tell the computer anything until step 4. The first three steps are carried out in the head of the designer. Of course, the designer should document the denotations to make their knowledge bases understandable to other people, so that they remember each symbol's denotation, and so that they can check the truth of the clauses. This is not necessarily something to which the computer has access.

The world, itself, does not prescribe what the individuals are.

Example 12.10: In one conceptualization of a domain, pink may be a predicate symbol of one argument that is true when the individual denoted by that argument is pink. In another conceptualization, pink may be an individual that is the color pink, and it may be used as the second argument to a binary predicate color, which says that the individual denoted by the first argument has the color denoted by the second argument. Alternatively, someone may want to describe the world at a level of detail where various shades of red are not distinguished, and so the color pink would not be included. Someone else may describe the world in more detail, in which pink is too general a term, for example by using the terms coral and salmon.

It is important to realize that the denotations are in the head of the knowledge base designer. The denotations are sometimes not even written down and are often written in natural language to convey the meaning to other people. When the individuals in the domain are real physical objects, it is usually difficult to give the denotation without physically pointing at the individual. When the individual is an abstract individual - for example, a university course or the concept of love - it is virtually impossible to write the denotation. However, this does not prevent the system from representing and reasoning about such concepts.

Example 12.11: Example 5.5 represented the electrical environment of Figure 1.8 using just propositions. Using individuals and relations can make the representation more intuitive, because the general knowledge about how switches work can be clearly separated from the knowledge about a specific house.

To represent this domain, we first decide what the individuals are in the domain. In what follows, we assume that each switch, each light, and each power outlet is an individual. We also represent each wire between two switches and between a switch and a light as an individual. Someone may claim that, in fact, there are pairs of wires joined by connectors and that the electricity flow must obey Kirchhoff's laws. Someone else may decide that even that level of abstraction is inappropriate because we should model the flow of electrons. However, an appropriate level of abstraction is one that is appropriate for the task at hand. A resident of the house may not know the whereabouts of the connections between the individual strands of wire or even the voltage. Therefore, we assume a flow model of electricity, where power flows from the outside of the house through wires to lights. This model is appropriate for the task of determining whether a light should be lit or not, but it may not be appropriate for all tasks. Next, give names to each individual to which we want to refer. This is done in Figure 1.8. For example, the individual w0 is the wire between light l1 and switch s2.

Next, choose which relationships to represent. Assume the following predicates with their associated intended interpretations:

  • light(L) is true if the individual denoted by L is a light.
  • lit(L) is true if the light L is lit and emitting light.
  • live(W) is true if there is power coming into W; that is, W is live.
  • up(S) is true if switch S is up.
  • down(S) is true if switch S is down.
  • ok(E) is true if E is not faulty; E can be either a circuit breaker or a light.
  • connected_to(X,Y) is true if component X is connected to Y such that current would flow from Y to X.

At this stage, the computer has not been told anything. It does not know what the predicates are, let alone what they mean. It does not know what individuals exist or their names.

Before anything about the particular house is known, the system can be told general rules such as

lit(L) ←light(L) ∧live(L) ∧ok(L).

Recursive rules let you state what is live from what is connected to what:

live(X) ←connected_to(X,Y) ∧live(Y).

For the particular house, given a particular configuration of components and their connections, the following facts about the world can be told to the computer:

connected_to(w0,w1) ←up(s2).
connected_to(w0,w2) ←down(s2).
connected_to(w1,w3) ←up(s1).

These rules and atomic clauses are all that the computer is told. It does not know the meaning of these symbols. However, it can now answer questions about this particular house.