The predicate likes has the declarative reading that the first named object (first argument) `likes' the second named object.
We could, of course, have defined likes in the reverse way. This would lead to the representation likes(ice_cream,bill) and the reading, in this case, that `ice_cream' is `liked' by `bill'.
Note that we have renamed ice-cream systematically to ice_cream.
The term ice-cream is a syntactically correct Prolog term
but it is not an atom since the rules for atoms do not allow for the
use of the
This could be got round in other ways than
the above --- e.g.
Also note that we could get away with a one argument `relation' --- viz likes_ice_cream(bill). Or even a zero argument `relation' --- bill_likes_ice_cream.
We could try the representation that bill(likes,ice_cream). Usually, predicates are associated with verbs.
This might be chosen but there is are problems: first, with the word `is'. Here, it is associated with the idea that bill possesses an attribute which has the value `tall'.
We could represent this as height(bill,tall).
Another reason for not using is(bill,tall) is that there may be many such statements in a database. Prolog would then have to sort through a large number of is/2 clauses such as is(bill,rich). If we choose height(bill,tall) then we only search through the clauses that deal with height.
Finally, the predicate is/2 is a system predicate and cannot be redefined by the user!
By the way, after all this, note that tall(bill) is quite acceptable and probably the one most people will prefer. However, we should note that this representation will make it harder to pick up any relation between tall(bill) and, for example, short(fred) whereas this is easy for heigh(bill,tall) and height(fred,short).
The declarative reading for hits/3 is that the `hit' action is carried out by the first named object on the second named object with the aid of the third object.
Note that nowhere in this reading is there any sense in which there is insistence on the first (or second) object being the identifier for a person, nor that the third object should be a `blunt instrument' etc. We could be much more rigid about the meaning.
As before, there are many variants as to how this could be done. The main point is to stick to one reading throughout the development of a program.
And again, we have mapped `cricket-bat' to `cricket_bat'.
The declarative reading is that the `travels' relation holds for the first object travelling to the second object with the means of transport described by the third object.
This is a fairly unattractive way to do things ---but is easiest for now.
The reading is that the `takes' relation holds for the first object transporting a specimen of the third object (which is or sort described by the fourth object) to the second object.
(Later we will see that we can tidy this up by writing takes(bill,jane,cheese(edam)) where cheese(edam) is a legitimate Prolog term.)
Again, the reading is that the `lives_at' relation holds for the first object `living' at an address described by the second, third, fourth and fifth objects.
This is ugly but is needed if we want to access bits of the address.
If we don't want to access bits of the address then we can get away with
'16 throgmorton street, london
Now we have a simpler relation and the second argument stands for the
The first representation of lives_at/5 has its own problems. For example, what happens if someone doesn't require a descriptor such as street or road? This has not been specified.