Rules, moves and algorithms

In this section we describe some of the rules and algorithm definitions we use. The current algorithms are very simple and the behaviour of the system is therefore mainly dependent on the definitions of the update and selection rules.

Update algorithm:

1.

Are there any update rules whose preconditions are fulfilled in the current IS? If so, take the first one and execute the updates specified in the effects of the rule. If not, stop.

2.

Repeat.

Selection algorithm:

1.

Are there any selection rules whose preconditions are fulfilled in the current IS? If so, proceed to step 2. If not, stop.

2.

Does the rule specify a dialogue move? If so, stop. If not, execute the updates specified in the effects of the rule.

3.

Repeat

Control algorithm:

1.

Call the interpreter

2.

Call the update module

3.

Call the selection module

4.

Call the generator

5.

Call the update module

6.

Repeat

The update rules include rules for question and plan accommodation, as well as rules for handling grounding and rules for integrating the latest move with the DIS. The latter rules look different depending on whether the user or the system itself was the agent of the move. As an illustration, below we first see the update rule for integrating an ``answer'' move when performed by the user, and second the converse rule for the case when the latest move was performed by the system^*.

U-RULE: integrateLatestMove(answer(usr))
PRE:
• valRec( SHARED.LM, answer(usr,A))
• fstRec( SHARED.QUD, Q ),
• relevant_answer( Q, A )

EFF:
• popRec(SHARED.QUD)\\
• reduce(Q, A, P)\\
• addRec(SHARED.BEL, P)

U-RULE: integrateLatestMove(answer(sys))
PRE: valRec(PRIVATE.TMP.LM, answer(sys, Q, A))
EFF:
• setRec(SHARED.LM}, answer(sys, Q, A))\\
• popRec(SHARED.QUD)\\
• reduce(Q, A, P)\\
• addRec(SHARED.BEL, P)

In the current implementation, interpretation and generation are canned, which means that the range of input and output strings is very restricted. However, it is also possible to communicate using moves directly, e.g. by typing ask(P^(price=P)) instead of 'What is the price?'.

The semantics (if it deserves the name) represents propositions as pairs of features and values, e.g. (month=april), and questions are lambda-abstracts over propositions, e.g. X^(month=X). A set of propositions and a query together constitute a database query which is sent to the database once the system has received sufficient information to be able to answer the question. A question and an answer can be reduced to a proposition using beta-reduction. For example, the question X^(month=X) and the answer april yield the proposition [X^(month=X)](april), i.e. (month=april).