<?xml version="1.0" standalone="yes"?>
<Paper uid="A97-1002">
  <Title>Natural Language in Four Spatial Interfaces</Title>
  <Section position="4" start_page="0" end_page="8" type="intro">
    <SectionTitle>
2 NAUTILUS
</SectionTitle>
    <Paragraph position="0"> NAUTILUS is built around an early version of the PROTEUS chart parser from New York University's Courant Institute (Grishman, 1986). The three subsequent system components were developed at our own facility.</Paragraph>
    <Section position="1" start_page="0" end_page="8" type="sub_section">
      <SectionTitle>
2.1 PROTEUS
</SectionTitle>
      <Paragraph position="0"> PROTEUS syntactic grammars consist primarily of two rule types: context-free rules written in BNF notation, and restriction rules written in a high-level  algorithmic language. Each restriction rule is attached to a particular nonterminal in the right-hand side of one or more context-free rules. During parsing the restriction fires immediately after that non-terminal has been constructed, testing the subtree at that point for well-formedness, or attaching an attribute value for use later on. Nodes rejected by a restriction are not added to the active chart and so do not contribute to the remainder of the parse.</Paragraph>
    </Section>
    <Section position="2" start_page="8" end_page="8" type="sub_section">
      <SectionTitle>
2.2 TINSEL
</SectionTitle>
      <Paragraph position="0"> One of the attributes composed by PROTEUS during parsing is an operator-operand regularized form intended to serve as the representation to which semantic selection and interpretation rules can be applied. The TINSEL semantic interpreter (Wauchope, 1990) applies case-frame rules and selection restrictions to the PROTEUS regularized output.</Paragraph>
      <Paragraph position="1"> The interpreter can either he invoked post-parse (applied top-down to each candidate sentential regularization) or interleaved with PROTEUS, testing each individual clausal or noun phrase immediately upon construction. In interleaved mode, if a node's regularization does not pass the case-frame or selection criteria then the node is not added to the chart, which can prune the search space and reduce parsing time considerably. If the node does pass selection, its regularization is augmented with the relevant semantic class and role information, becoming an intermediate semantic representation suitable for further processing such as reference resolution and quantifier scoping.</Paragraph>
      <Paragraph position="2"> The TINSEL interpreter is primarily modeldriven, which is to say that the case frame behavior of each predicate in the domain must be explicitly encoded in a declarative semantic representation. As a result we have not attempted to incorporate any generalized case-frame rules into the interpreter itself, so TINSEL is not bound to any particular theory of thematic relations, giving the system developer maximum flexibility in devising useful semantic representations. TINSEL does contain some general rules for handling noun phrases, however, such as automatically attempting to interpret certain prepositional phrases as implicit BE-verb relative clauses (the hammer on the table ~ the hammer which is on the table), etc.</Paragraph>
    </Section>
    <Section position="3" start_page="8" end_page="8" type="sub_section">
      <SectionTitle>
2.3 FOCAL
</SectionTitle>
      <Paragraph position="0"> The FOCAL (FOCus ALgorithm) reference resolution module was developed by visiting MIT graduate student Gina-Anne Levow. It resolves definite, indefinite, and pronominal references as sub-sets of objects from a closed-world model developed for each application. Model objects have a TINSEL semantic class attribute, permissable identifying specifiers (S.S. Loveboat, waypoint No. 2, NTDS icons), and a marker indicating if the object represents a collection of unindividualized entities (map rings, aircraft trails). FOCAL uses semantic class, number, recency, and constituent order within the sentence when choosing antecedents for anaphoric references. It assumes demonstratives (that fighter) to be anaphoric and attempts to resolve other definite references (the fighters) first as anaphoric and then as universal. Since none of our interfaces to date has involved declarative or hypothetical utterances, indefinite expressions (a fighter) are interpreted strictly as closed-world references, i.e., one of the known fighters.</Paragraph>
    </Section>
    <Section position="4" start_page="8" end_page="8" type="sub_section">
      <SectionTitle>
2.4 FUNTRAN
</SectionTitle>
      <Paragraph position="0"> The FUNTRAN (FUNctional TRANslator) module takes TINSEL and FOCAL output and constructs a quantified logical form suitable for evaluation in the runtime environment to issue a command or query to the target application. The logical quantifiers and connectives (FORALL, EXISTS, NOT, AND, etc.) have generic procedural definitions as Lisp macros, so the system developer just needs to develop a so-called Translation Function (TF) for each of the TINSEL predicates in the domain. TFs are Lisp functions (defuns) of the same name as the predicate, taking keyword arguments corresponding to each of the predicate's semantic slots, and exchanging appropriately coded information with the target application via so-called Interface Functions, described next. FUNTRAN also composes simple fragmentary English responses to database queries based on the results of the TF predicate evaluation.</Paragraph>
    </Section>
    <Section position="5" start_page="8" end_page="8" type="sub_section">
      <SectionTitle>
2.5 Back End Translator
</SectionTitle>
      <Paragraph position="0"> At this point the generic NAUTILUS code ends and the system developer must hand-craft an application-specific interface layer between the Translation Functions and the target. The nature of that interface depends on whether NAUTILUS and the target are running in the same Lisp process or as separate Unix processes, possibly on different machines. In one of our projects (InterLACE), the target application is just a Lisp program running in the same process space as the NLP system, so the primitive Interface Functions (IFs) for communicating between the two are just Lisp function calls. In two others (InterVR and InterROB), the target application runs on another Unix machine on the local net, so the IFs on the NAUTILUS side must encode and transmit message strings over an IPC socket to a corresponding decoder layer linked into the application. In the fourth project (Eucalyptus) we developed versions for both approaches, one where the application object code (compiled from C) is loaded into Lisp and the IFs are foreign function calls, and the other doing IPC message passing.</Paragraph>
    </Section>
    <Section position="6" start_page="8" end_page="8" type="sub_section">
      <SectionTitle>
2.6 Speech I/O
</SectionTitle>
      <Paragraph position="0"> For speech input we use the Phonetic Engine (PE200) from Speech Systems Inc. with the speech recognition software running on a Sun workstation to which the PE200 hardware is connected by a serial line. Under various circumstances we have linked the software in with either NAUTILUS or the application, or have run it as a separate process communicating with NAUTILUS via an IPC socket. For speech output, a DECtalk speech synthesizer is connected to the other Sun serial port and can be sent output from NAUTILUS either by Unix system calls or by writing data directly to the port.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>