foundations of computational agents
Instead of being agnostic about the equality of each term and expecting the user to axiomatize which names denote the same individual and which denote different individuals, it is often easier to have the convention that different ground terms denote different individuals.
Consider a student database example where a student must have two courses as science electives. Suppose a student has passed and ; then you only know whether they have passed two courses if you know . That is, the constants and denote different courses. Thus, you must know which course numbers denote different courses. Rather than writing inequality axioms for individuals, it may be better to have the convention that every course number denotes a different course and thus the use of inequality axioms is avoided.
Under the unique names assumption (UNA) distinct ground terms denote different individuals. That is, for every pair of distinct ground terms and , it assumes , where “” means “not equal to.”
The unique names assumption does not follow from the semantics for the definite clause language. As far as that semantics was concerned, distinct ground terms and could denote the same individual or could denote different individuals.
With the unique names assumption, inequality () can be in the bodies of clauses. If you want to use equality in the body of clauses, you can define equality by adding the clause .
The unique names assumption can be axiomatized with the following axiom schema for inequality, which consists of the axiom schema for equality together with the axiom schema:
for any distinct constants and .
for any distinct function symbols and .
, for any function symbol . There are instances of this schema for every -ary function symbol (one for each such that ).
for any function symbol and constant .
With this axiomatization, ground terms are identical if and only if they unify. This is not the case for non-ground terms. For example, has some instances that are true – for example, when has value – and an instance which is false, namely, when has value .
The unique names assumption is very useful for database applications, in which you do not want, for example, to have to state that and and .
Sometimes the unique names assumption is inappropriate – for example, is wrong, and it may not be the case that .
The top-down proof procedure incorporating the unique names assumption should not treat inequality as just another predicate, mainly because too many different individuals exist for any given individual.
If there is a subgoal , for terms and there are three cases:
and do not unify. In this case, succeeds.
For example, the inequality succeeds because the two terms do not unify.
and are identical, including having the same variables in the same positions. In this case, fails.
For example, fails.
Note that, for any pair of ground terms, one of these first two cases must occur.
Otherwise, there are instances of that succeed and instances of that fail.
For example, consider the subgoal . The MGU of and is , , . Some instances of the inequality, such as the ground instances consistent with the unifier, should fail. Any instance that is not consistent with the unifier should succeed. Unlike other goals, you do not want to enumerate every instance that succeeds because that would mean unifying with every function and constant different than , as well as enumerating every pair of values for and where is different than .
The top-down proof procedure can be extended to incorporate the unique names assumption. Inequalities of the first type can succeed and those of the second type can fail. Inequalities of the third type can be delayed, waiting for subsequent goals to unify variables so that one of the first two cases occur. To delay a goal in the proof procedure of Figure 13.4, when selecting an atom in the body of , the algorithm should select one of the atoms that is not being delayed. If there are no other atoms to select, and neither of the first two cases is applicable, the query should succeed. There is always an instance of the inequality that succeeds, namely, the instance where every variable gets a different constant that does not appear anywhere else. When this occurs, the user has to be careful when interpreting the free variables in the answer. The answer does not mean that it is true for every instance of the free variables, but rather that it is true for some instance.
Consider the rules that specify whether a student has passed at least two courses:
For the query
the subgoal cannot be determined and so must be delayed. The top-down proof procedure can, instead, select , which binds to . It can then call , which in turn calls , which can succeed with substitution . At this stage, the variables for the delayed inequality are bound enough to determine that the inequality should fail.
Another clause can be chosen for , returning substitution , . The variables in the delayed inequality are bound enough to test the inequality and, this time, the inequality succeeds. It can then go on to prove that , and the goal succeeds.
One question that may arise from this example is “why not simply make the inequality the last call, because then it does not need to be delayed?” There are two reasons. First, it may be more efficient to delay. In this example, the delayed inequality can be tested before checking whether . Although this particular inequality test may be fast, in many cases substantial computation can be avoided by noticing violated inequalities as soon as possible. Second, if a subproof were to return one of the values before it is bound, the proof procedure should still remember the inequality constraint, so that any future unification that violates the constraint can fail.