13.2.1 Choosing Individuals and Relations

Given a logical representation language, such as the one developed in the previous chapter, and a world to reason about, the people designing knowledge bases have to choose what, in the world, to refer to. That is, they have to choose what individuals and relations there are. It may seem that they can just refer to the individuals and relations that exist in the world. However, the world does not determine what individuals there are. How the world is divided into individuals is invented by whomever is modeling the world. The modeler divides up the world up into things so that the agent can refer to parts of the world that make sense for the task at hand.

Example 13.2: It may seem as though "red" is a reasonable property to ascribe to things in the world. You may do this because you want to tell the delivery robot to go and get the red parcel. In the world, there are surfaces absorbing some frequencies and reflecting other frequencies of light. Some user may have decided that, for some application, some particular set of reflectance properties should be called "red." Some other modeler of the domain might decide on another mapping of the spectrum and use the terms pink, scarlet, ruby, and crimson, and yet another modeler may divide the spectrum into regions that do not correspond to words in any language but are those regions most useful to distinguish different categories of individuals.

Just as modelers choose what individuals to represent, they also choose what relations to use. There are, however, some guiding principles that are useful for choosing relations and individuals. These will be demonstrated through a sequence of examples.

Example 13.3: Suppose you decide that "red" is an appropriate category for classifying individuals. You can treat the name red as a unary relation and write that parcel a is red:
red(a).

If you represent the color information in this way, then you can easily ask what is red:

The X returned are the red individuals.

With this representation, it is hard to ask the question, "What color is parcel a?" In the syntax of definite clauses, you cannot ask

because, in languages based on first-order logic, predicate names cannot be variables. In second-order or higher-order logic, this would return any property of a, not just its color.

There are alternative representations that allow you to ask about the color of parcel a. There is nothing in the world that forces you to make red a predicate. You could just as easily say that colors are individuals too, and you could use the constant red to denote the color red. Given that red is a constant, you can use the predicate color where color(Ind,Val) means that physical individual Ind has color Val. "Parcel a is red" can now be written as

color(a , red).

What you have done is reconceive the world: the world now consists of colors as individuals that you can name. There is now a new binary relation color between physical individuals and colors. Under this new representation you can ask, "What color is block a?" with the query

To make an abstract concept into an object is to reify it. In the preceding example, we reified the color red.

Example 13.4: It seems as though there is no disadvantage to the new representation of colors in the previous example. Everything that could be done before can be done now. It is not much more difficult to write color(X,red) than red(X), but you can now ask about the color of things. So the question arises of whether you can do this to every relation, and what do you end up with?

You can do a similar analysis for the color predicate as for the red predicate in Example 13.3. The representation with color as a predicate does not allow you to ask the question, "Which property of parcel a has value red?," where the appropriate answer is "color." Carrying out a similar transformation to that of Example 13.3, you can view properties such as color as individuals, and you can invent a relation prop and write "individual a has the color of red" as

prop(a , color , red).

This representation allows for all of the queries of this and the previous example. You do not have to do this again, because you can write all relations in terms of the prop relation.

The individual-property-value representation is in terms of a single relation prop where

prop(Ind , Prop , Val)

means that individual Ind has value Val for property Prop. This is also called the triple representation because all of the relations are represented as triples. The first element of the triple is called the subject, the second is the verb, and the third is the object, using the analogy that a triple is a simple three-word sentence.

The verb of a triple is a property. The domain of property p is the set of individuals that can appear as the subject of a triple when p is the verb. The range of a property p is the set of values that can appear as the object of a triple that has p as the verb.

An attribute is a property-value pair. For example, an attribute of a parcel may be that its color is red. Two parcels may be identical if they have the same attributes - the same values for their properties.

There are some predicates that may seem to be too simple for the triple representation:

Example 13.5: To transform parcel(a), which means that a is a parcel, there do not seem to be appropriate properties or values. There are two ways to transform this into the triple representation. The first is to reify the concept parcel and to say that a is a parcel:
prop(a , type , parcel).

Here type is a special property that relates an individual to a class. The constant parcel denotes the class that is the set of all, real or potential, things that are parcels. This triple specifies that the individual a is in the class parcel.

The second is to make parcel a property and write "a is a parcel" as

prop(a , parcel, true).

In this representation, parcel is a Boolean property which is true of things that are parcels.

A Boolean property is a property whose range is {true, false}, where true and false are constant symbols in the language.

Some predicates may seem to be too complicated for the triple representation:

Example 13.6: Suppose you want to represent the relation
scheduled(C , S , T , R),

which is to mean that section S of course C is scheduled to start at time T in room R. For example, "section 2 of course cs422 is scheduled to start at 10:30 in room cc208" is written as

scheduled(cs422 , 2 , 1030 , cc208).

To represent this in the triple representation, you can invent a new individual, a booking. Thus, the scheduled relationship is reified into a booking individual.

A booking has a number of properties, namely a course, a section, a start time, and a room. To represent "section 2 of course cs422 is scheduled at 10:30 in room cc208," you name the booking, say, the constant b123, and write

prop(b123 , course , cs422).
prop(b123 , section , 2).
prop(b123 , start_time , 1030).
prop(b123 , room , cc208).

This new representation has a number of advantages. The most important is that it is modular; which values go with which properties can easily be seen. It is easy to add new properties such as the instructor or the duration. With the new representation, it is easy to add that "Fran is teaching section 2 of course cs422, scheduled at 10:30 in room cc208" or that the duration is 50 minutes:

prop(b123, instructor, fran).
prop(b123, duration, 50).

With scheduled as a predicate, it was very difficult to add the instructor or duration because it required adding extra arguments to every instance of the predicate.