# 14.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 which individuals and relations to represent. It may seem that they can just refer to the individuals and relations that exist in the world. However, the world does not determine which 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 14.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 which individuals to represent, they also choose which 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 14.3.

Suppose you decide that “red” is an appropriate category for classifying individuals. You could 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:

 $\mbox{{ask}~{}}~{}red(X).$

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

 $\mbox{{ask}~{}}~{}X(a).$

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, as well as parcels. There is now a new binary relation $color$ between physical individuals and colors. Under this new representation you can ask, “What color red?” with the query

 $\mbox{{ask}~{}}~{}color(X,red).$

and ask “What color is block $a$?” with the query

 $\mbox{{ask}~{}}~{}color(a,C).$

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

###### Example 14.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 14.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 14.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.

Sometimes we will write a triple as a simple three word sentence:

 $subject~{}~{}verb~{}~{}object.$

meaning the atom

 $prop(subject,verb,object)$

or in functional notation as

 $verb(subject,~{}object)$

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.

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

###### Example 14.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$, or more simply as the triple “a is_a parcel”. Type is often written as is_a.

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.

On the other hand, some predicates may seem to be too complicated for the triple representation:

###### Example 14.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

 $\displaystyle{{prop}(b123,course,cs422).}$ $\displaystyle{{prop}(b123,section,2).}$ $\displaystyle{{prop}(b123,start\_time,1030).}$ $\displaystyle{{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:

 $\displaystyle{{prop}(b123,instructor,fran).}$ $\displaystyle{{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.