The dialogue manager keeps track of the information provided by the user by maintaining an information state or form . This form is a hierarchical structure, with slots and values for the origin and destination of a connection, for the time at which the user wants to arrive or depart, etc. An example is given in (8a). Each user utterance leads to an update of the information state. An update is an instruction for updating the information in an information state. Updating can mean that new information is added or that given information is confirmed, retracted or corrected. For example, given the information state in (8a), the update in (8b) (which might be the translation of No, I do not want to travel to Leiden but to Abcoude!) leads to the information state in (8c). The # -operator in (8b) indicates that the information within its scope (indicated by square brackets) is to be retracted, and the '!'-operator indicates a correction.
[b.] travel.destination. ([# place.town.leiden]; [! place.town.abcoude]) [c.]
The result of parsing is a QLF, a linguistically motivated and domain-independent representation of the meaning of a sentence. The translation of a QLF into a domain-specific update is done by applying translation-rules to the individual parts of a QLF. These translation rules may be context-sensitive. In particular, some parts of the QLF provide the context which determines how other parts are to be translated. For example, the QLF in (9) (corresponding to the phrase leave at four o'clock contains two p_forms, one for the predicate leave and one for four o'clock. The second gives rise to an update expression moment.at.time.clock_hour.4. The first provides the contextual information that the moment referred to is a departure-time. The translation can therefore be extended to origin.moment.at.time.clock_hour.4. There is no linguistic information which indicates that a special update-operator has to be used. In such cases, it is assumed that the information is new, and thus the assert-operator ('=') can be used, giving rise to the translation for the full phrase: origin.moment.at.[= time.clock_hour.4].
Contextual translation is a powerful technique. For instance, the utterance Groningen Amsterdam gives rise to a conjunctive QLF, containing two term expressions for locations. Translating each of the conjuncts individually would make it impossible to decide whether an origin or destination location is being specified. By translating the conjunction in one step (and assuming that the order of conjuncts corresponds to the order in the utterance), we can resolve the first locative to origin and the second to destination. As another example, the adverb graag is ignored in the translation from QLF to update if it occurs as part of a full sentence ( ik wil graag naar Amsterdam, `I would like to go to Amsterdam'), but is translated as `yes' (i.e. a confirmation of information provided by the system) if it occurs in isolation. Such a translation is motivated by dialogues of the following type:
|[system:]||Dus U wilt van Amsterdam naar Groningen reizen?|
|So you want to travel from Amsterdam to Groningen?|
Similarly, the translation of the negations nee (no) and niet (not) depends on context. If the two occur in isolation, they indicate a denial of information provided by the system. However, if nee is followed by another phrase, say a locative, it signals a correction (11a), whereas if niet is followed by another phrase, it signals a denial (11b).
[a.] 'Nee, naar Assen' ( No, to Assen)
destination.[!place.assen] [b.] 'Niet naar Assen' ( Not to Assen)
It should be noted that the translation of QLF's to updates uses primarily the information provided by NP's, PP's and adverbs. Verbs typically provide the context for translating other parts of the QLF. Also, as quantification plays no role in updates, the scope of generalised quantifiers can be largely ignored. Thus, we are able to translate QLF's into domain-specific meanings without resolving quantifier scope.