5.4 Querying the User

An agent receives some information as background knowledge and some as observations online. An observation is information received online from users, sensors, or other knowledge sources. Assume an observation is a set of atomic propositions, which are implicitly conjoined.

A user is a person who has need for expertise or has information about individual situations. Users cannot be expected to tell us everything that is true. First, they do not know what is relevant, and second, they do not know what vocabulary to use. An ontology that specifies the meaning of the symbols, or a graphical user interface to allow the user to click on what is true, may help to solve the vocabulary problem. However, there can be too many possibly relevant truths to expect the user to specify everything that is true, even with a sophisticated user interface. We need to ensure that users are only asked to provide information that is potentially useful. Similarly, passive sensors may be able to provide direct observations of conjunctions of atomic propositions, but active sensors may have to be queried by the agent for the information that is necessary for a task.

A simple way to acquire information from a user or a sensor is to incorporate an ask-the-user mechanism, where an atom is askable if the user may know the truth value at run time, or it can be asked of an active sensor. The top-down proof procedure, when it has selected an atom to prove, either can use a clause in the knowledge base to prove it, or, if the atom is askable and hasn’t already been asked, it can ask the user or an active sensor whether the atom is true. Users are thus only asked about atoms that are relevant for the query.

A bottom-up proof procedure can also be adapted to ask a user, but it should avoid asking about all askable atoms; see Exercise 5.5.

Example 5.14.

In the electrical domain of Example 5.8, one would not expect the designer of the model of the house wiring to know the switch positions (whether each switch is up or down). It is reasonable that all of the definite clauses of Example 5.8, except for the switch positions, should be given by the designer. The switch positions can then be made askable.

Here is a possible dialog, where the user asks a query and answers yes or no to the system’s questions. The user interface here is minimal to show the basic idea; a real system would use a more sophisticated user-friendly interface.

ask  lit_l1.
Is down_s2 true? no.
Is up_s2 true? yes.
Is up_s1 true? yes.
Answer: True.

The system only asks the user questions that the user is able to answer and that are relevant to the task at hand.