13.4.2 More General Questions

Yes-or-no questions and functional relations do not cover all of the cases of a query. The general form of a query occurs when free variables are present in a query that is to be asked of the user.

Example 13.19: For the subgoal p(a,X,f(Z)) the user should be asked something like
for which X,Z is p(a,X,f(Z)) true?

which, of course, should be put in terms that the user can understand.

The user would then be expected to give bindings for X and Z that make the subgoal true, or to reply no, meaning that there are no more instances. This follows the spirit of the query protocol for asking questions of the system.

A number of issues arise:

  • Should users be expected to give all instances that are true, or should they give the instances one at a time, with the system prompting for new instances? One of the major criteria for acceptance of a knowledge-based system is in how sensible it appears. Asking questions in a natural, logical way is a big part. For this reason, it may be better to get one instance and then prompt when another instance is needed. In this way, the system can, for example, probe into one individual in depth before considering the next individual. How well this works depends on the structure of the knowledge base.
  • When should you not ask/re-ask a question? For example, consider the question
    For which X is p(X) true?

    to which the user replies with an answer that means X=f(Z), (i.e., "for all values of Z, p(f(Z)) is true"). In this case, the user should not be asked about whether p(f(b)) is true or whether p(f(h(W))) is true but should be asked about whether p(a) or even whether p(X) is true (asking for a different instance). If the user subsequently replies no to the question

    For which X is p(X) true?

    what is meant is that there are no more answers to this question, rather than that p(X) is false for all X (because the system has already been told that X=f(b) is a true instance).

    The general rule is that the system should not ask a question that is more specific than a positive answer that has already been given or is more specific than a question to which the user has replied no.

  • Should the system ask the question as soon as it is encountered in the proof process, or should it delay the goal until more variables are bound? There may be some goals that will subsequently fail no matter what the user answers. For these goals, it may be better to find this out rather than asking the user at all. There may also be free variables in a query that, subsequently, will become bound. Rather than asking the user to enumerate the possibilities until they stumble on the instance that does not fail, it may be better to delay the goal.

    Consider the query ask p(X)∧q(X), where p(X) is askable. If there is only one instance of q that is true, say q(k), it may be better to delay asking the p(X) question until X is bound to k. Then the system can ask p(k) directly instead of asking the user to enumerate all of the p's until they stumble on p(k) being true. However, if there is a large database of instances of q(X) and few values of X for which p(X) is true, it may be better to ask for instances of p(X) and then to check them with the database rather than asking a yes-or-no question for each element of the database. Which is better depends on the estimated number of individuals for which p(X) is true, the estimated number of individuals for which q(X) is true, and the costs associated with asking the user.

These pragmatic questions are very important when designing a user-friendly interface to a KB system.