Third edition of Artificial Intelligence: foundations of computational agents, Cambridge University Press, 2023 is now available (including the full text).
12.3.2.1 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.
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.
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
Recursive rules let you state what is live from what is connected to what:
live(outside).
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:
light(l2).
down(s1).
up(s2).
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.