<?xml version="1.0" standalone="yes"?>
<Paper uid="W97-0618">
  <Title>A Programmable Multi-Blackboard Architecture for Dialogue Processing Systems</Title>
  <Section position="4" start_page="99" end_page="100" type="metho">
    <SectionTitle>
3 The Blackboard System
</SectionTitle>
    <Paragraph position="0"> The dialogue system is implemented as a blackboard system. The system consists of multiple blackboards each of which stores a separate database. Moreover, a certain number of agents is linked to the system. The agents implement operations on the representations stored in the discourse blackboard in a modular way. The operations are used to formulate rules that control the interaction between blackboards and agents. The rules are evaluated by a central processing unit, the general manager, that passes control to the agents to evaluate their local operations.</Paragraph>
    <Section position="1" start_page="99" end_page="99" type="sub_section">
      <SectionTitle>
3.1 The Agents
</SectionTitle>
      <Paragraph position="0"> The task of agents is to perform operations on representations stored in blackboards. To this end, each agent disposes of a set of procedures that execute the actions. To specify the interface with the dialogue system, each agent exports a set of signatures containing information about the number and form of the procedures' parameters to the general manager.</Paragraph>
      <Paragraph position="1"> When the procedure assigned to a given signature is evaluated, the general manager passes the parameters on to the agent. After having executed the procedure, the agent returns status information and possible return values, if any, to the general manager which, in turn, uses this information to decide upon the control strategy.</Paragraph>
    </Section>
    <Section position="2" start_page="99" end_page="100" type="sub_section">
      <SectionTitle>
3.2 The Blackboards
</SectionTitle>
      <Paragraph position="0"> Among the blackboards, there is one distinguished blackboard, called the discourse blackboard that stores different levels of representations of the discourse history. Database blackboards are hooked up to the discourse blackboard to make the representations more specific.</Paragraph>
      <Paragraph position="1">  The database blackboards store a set of feature structures. The functionality of a database blackboard is to provide procedures to insert, remove, and lookup feature structures. Any database lookup will return an underspecified feature structure representing all feature structures that are compatible with the feature structure passed to the lookup procedure. null  Aside from the database blackboards, there is one distinguished blackboard, the discourse blackboard representing the discourse history. For the time being, the discourse structure is a list of the generated representations. In order to access all levels of representations, this list is maintained for orthographic, syntactic and semantic representations as well as representations of referred objects which allow the discourse blackboard to be seen as four database blackboards in parallel. Moreover, links exist between the objects to access the different levels. This organization is similar to the discourse pegs (LuperFoy1995), with the main difference being that discourse pegs compile the different representations in one discourse unit while in our approach the different levels are separated and only accessible via links.</Paragraph>
      <Paragraph position="2">  Links exist between the representations in order to access the representation across the levels.</Paragraph>
      <Paragraph position="3"> In the remainder of the paper, the level of representation may also be referred to by a number ranging from 0 (object level) to three (orthographic level). Typed feature structures in the semantic level representing noun phrases can be seen as partial descriptions of objects, each of which is compatible with the description. This allows us to determine the objects by compatibility check. In figure 2 (b), the underspecified feature structure might be the result of a database request completing the description shown in 2 (a). This is the reason why the database  blackboards are attached to only one of the four levels. Every time a feature structure is added to one of the four levels, the appropriate database procedures, if any, provided by the database blackboards are executed to complete the feature structure. For instance, the object level of the discourse blackboard can be seen as database for anaphora resolution: when the representation of an anaphor is added to the semantic level of the discourse blackboard, the object level of the discourse blackboard is considered to be a standard database blackboard, and the antecedents are determined.</Paragraph>
      <Paragraph position="4"> The natural language input is analyzed by the PHOENIX parser developed by Ward (Ward1994).</Paragraph>
      <Paragraph position="5"> The parser generates a set of parse trees each of which covers a part of the input sentence. The roots of the parse trees are specified by top-level frames. Top-level frames can be changed during dialogue interaction to check if the input is or is not conform to what has been expected. Words not covered by the parse trees rootes at the top-level slots are ignored. The partial semantic parse trees are converted to a semantic representation by traversing the parse tree and applying construction rules to the nodes. The construction rules operate mostly on the semantic slots in the parse trees so that synonymy and paraphrases of expressions can be handled. The semantics of an utterance is given by a set of possibly partially specified feature structures that are stored in a discourse history. Each structure represents the semantics of a phrase of one of the main syntactic categories NP, VP, or PP. Examples of how the semantic representations of a request might look like are given in figure 6 and 7.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="100" end_page="101" type="metho">
    <SectionTitle>
4 The Form of Rules
</SectionTitle>
    <Paragraph position="0"> The interaction of the agents and the blackboards is governed by a set of expert system style rules.</Paragraph>
    <Paragraph position="1"> The rules are composed of constants, typed variables, functions and predicates. The predicates and functions can tal~e variables over either possibly underspecified feature structures over Type and Feat, feature paths over Feat, or events that enable the communication with the speech recognizer and other external processing modules.</Paragraph>
    <Section position="1" start_page="100" end_page="100" type="sub_section">
      <SectionTitle>
4.1 Constants
</SectionTitle>
      <Paragraph position="0"> A constant is given by any type from the type hierarchy. Moreover, integers and strings are considered to be subtypes of the types string and int respectively and are also treated as constants. Constants stand for atomic feature structures whose type is given by the constant name.</Paragraph>
    </Section>
    <Section position="2" start_page="100" end_page="100" type="sub_section">
      <SectionTitle>
4.2 Variables
</SectionTitle>
      <Paragraph position="0"> Variables range over feature structures and under-specified feature structures. Variables are typed in the sense that they impose an informational lower bound on the type of the feature structures with which they will be substituted. Names of variables ranging over feature structures have to start with the name of their type, with a capital letter to distinguish variables from constants. Feature structures substituting variables have to be stored in the discourse blackboard. Variables are indexed with the level of representation, as in Obj : O Moreover, parts of the feature structures can be accessed by specifying a feature path such as</Paragraph>
      <Paragraph position="2"> The feature path has to obey the well-typed conditions as imposed by the type hierarchy.</Paragraph>
      <Paragraph position="3"> Variables ranging over underspecified feature structures are indicated by curly brackets as in {Obj_path} :0.</Paragraph>
      <Paragraph position="4"> Here, too, feature path application {Obj_path} : 0@\[DST\].</Paragraph>
      <Paragraph position="5"> is possible, the path value of an underspecified feature structure being the underspecified structure of all values of the path when applied to the feature structures represented by the underspecified feature structure.</Paragraph>
      <Paragraph position="6"> The variables in the rules may be instantiated with representations on each of the four levels. Consequently, there is, contrary to systems that process data sequentially, no restriction that predetermines the point at which some future agent has to perform an action simly because it relies on a specific level of representation. This fact makes the architecture well-suited for repair and rescore mechanisms that integrate scores from the speech recognizer and semantic domain knowledge.</Paragraph>
    </Section>
    <Section position="3" start_page="100" end_page="100" type="sub_section">
      <SectionTitle>
4.3 Functions
</SectionTitle>
      <Paragraph position="0"> Functions as well as predicates have to be introduced by signatures that define informational lower bounds on the arguments (if present) and the return 'value.</Paragraph>
      <Paragraph position="1"> The signature for the function pkturename that returns a string for any given type that is as least as specific as obj_zoncrete is given by picturename : obj_concrete+ ~ string where a following '+' or '-' sign indicates whether or not the argument has to be defined when evaluating the function.</Paragraph>
    </Section>
    <Section position="4" start_page="100" end_page="101" type="sub_section">
      <SectionTitle>
4.4 Predicates
</SectionTitle>
      <Paragraph position="0"> As is the case with functions, predicates are introduced by signatures. Examples are</Paragraph>
      <Paragraph position="2"> for the unification operation and the subsumption relation on feature structures. An example for an application-specific predicate is draw : string + xstring + xint + xint+ whose purpose it is to draw the icon given by the second argument into the window given by the first argument at the position that is identified by the third and the fourth arguments.</Paragraph>
    </Section>
    <Section position="5" start_page="101" end_page="101" type="sub_section">
      <SectionTitle>
4.5 Rules
</SectionTitle>
      <Paragraph position="0"> Rules are formed using constants, variables, functions and predicates together with conjunction and implication connectors. They have the general form pl (t1,1,... ,tl,n~) ,..., pk (tk,1 .... ,t~,~) (tk+,.1 .... ,..., p, (t,.,,...,t,.,,) where the Pi are predicates, and the ti/ are terms constructed over constants, variables and functions.</Paragraph>
      <Paragraph position="1"> For example, the rule displaying every object is given</Paragraph>
      <Paragraph position="3"/>
    </Section>
  </Section>
class="xml-element"></Paper>