File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/96/c96-2197_metho.xml
Size: 9,463 bytes
Last Modified: 2025-10-06 14:14:21
<?xml version="1.0" standalone="yes"?> <Paper uid="C96-2197"> <Title>An Education and Research Tool for Computational Semantics</Title> <Section position="3" start_page="0" end_page="1098" type="metho"> <SectionTitle> 2 A Tutorial System for </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="1098" type="sub_section"> <SectionTitle> Computational Semantics </SectionTitle> <Paragraph position="0"> As a tutorial tool, CI, PArtS allows students to investigate certain tbrmalisms and their relationship. It also provides the possibility for the teacher to provide interactive demonstrations ami to produce example slides and handouts.</Paragraph> <Paragraph position="1"> In this section we show how a user can interactively explore the step-by-step construction of a semantic representation out of a syntax tree. Figures 1 and 2 show a possible initial display for the sentence &quot;Anna laughs&quot; in a compositional version of I)RT (Bos et al., 1994) and in 'Montague Grammar' (Dowty et al., 198:1).</Paragraph> <Paragraph position="2"> The user controls the semantic construction process by moving to particular nodes in the derivation tree, and performing operations by using mouse double-clicks, or by selecting froln a pop-up menu. For example, clicking on app(2,1)</Paragraph> <Paragraph position="4"> in the tree shown in l?igure 2 has the effect of applying the lambda-ext)ression lA.laughs(A) to anna. The resulting display is given in t,'igure 3.</Paragraph> <Paragraph position="5"> The poI)-up menu allows a user to pertbrm single derivation steps. For example, the user can first form an application term AA.hmghs(A)(anna) and then reduce this at the next step. Menu options include the possibility of cancelling intensional operators, performing lmnbda reduction, applying meaning postulates, and \[)RS merging. The glenn also allows a user to choose whether or not to perform quantifier storage or discharge, and thereby pick a particnlar reading for a sentence. Alterxlatively the user can choose to fully process a node, in which case all readings are simultaneously displayed.</Paragraph> </Section> </Section> <Section position="4" start_page="1098" end_page="1099" type="metho"> <SectionTitle> 3 Comparing Theories </SectionTitle> <Paragraph position="0"> A major use of the tool is for comparison of different semantic theories and methods of semantic construction. To akl comparison of theories, there are translation routines between some semantic tbrmalisms. For example, \],'igure 4 shows a translation from a D|{S to a formula in Predicate Logic.</Paragraph> <Paragraph position="1"> The user can try out various options for semantic construction by using a menu to set various parameters. An illustrative subset of the parameters and their possible va.lues is given below: simple lexicon, lexicon with features.</Paragraph> <Paragraph position="2"> syntax-semantics mai)plng rule-to-.rule, syntactic template.</Paragraph> <Paragraph position="3"> syntax-semantlcs ('onstruetlon serial, parallel.</Paragraph> <Paragraph position="4"> subject applied to verb phrase yes, no.</Paragraph> </Section> <Section position="5" start_page="1099" end_page="1099" type="metho"> <SectionTitle> 4 The Library </SectionTitle> <Paragraph position="0"> Because a tutorial system of this kind has to be based largely on standard routines and algorithms that are fundamental for the area of computational semantics, a secondary aim of the project was to provide a set of well documented programs which could form the nucleus of a larger library of reusable code for this field. Most of the library contents correspond directly to particular values of parameter settings. However there are some extra library routines, for example a very generalised form of flmction composition. The library is being expanded with routines for semantic construction driven by semantic types. It is also intended to integrate a wider range of grammars, parsing strategies and pronoun resolution strategies. For program documentation we largely have followed the approach taken in LEDA (Ngher, 1993)).</Paragraph> <Paragraph position="1"> Apart from the routines concerned directly with computational semantics, there are also routines designed to aid application developers who want to provide a graphical output tbr semantic representations. These routines are mainly concerned with translating from Prolog syntax into the description string syntax used by the CLiG grapher.</Paragraph> <Paragraph position="2"> Currently they rely on the Tcl/Tk library package provided by Sicstus 3.</Paragraph> <Section position="1" start_page="1099" end_page="1099" type="sub_section"> <SectionTitle> 4.1 Modularlsatlon Principles </SectionTitle> <Paragraph position="0"> A standard approach to modularisation is to split a problem into independent black boxes, e.g. a grammar, a parser etc. This top-down modularisation is then followed by some bottom-up modularisation in the sense of supplying general utilities which each of the larger modules can use. For this application, such an approach had obvious inadequacies. For example, there are subtle differences in some steps of quantifier storage according to the formalism being used, similarly, differences even in lambda reduction (for intensional logic it is natural to interleave the step of operator caneellation between/?-reductions). Even the parsing stage cannot be totally independent unless we generalise to the worst case (the Situation Semantics fragment requires an utterance node as well as a sentence node).</Paragraph> <Paragraph position="1"> One of the aims in building the tool was to show where semantic formalisms converge. Thus there was theoretical motivation to ensure components of the system were shared wherever possible. There was also practical motivation, since there is more chance of finding errors in shared code. The solution adopted was to use parameterised modularisation. This allows differences to be located in as small pieces of code as possible (e.g. single lines the Syntax-Semantics lnt, erface of tile quantifier storage routine), with the parameters picking up the correct; piece of code at run time. There are some small costs due to indirection (instead of calling e.g. a /?-reducer directly, a program first calls a routine which chooses the /?-reducer according to the parameters). But with these parameterisation layers we provide natural points where the system can be extended or modified by the user. The approach also gets rid of the need to create large data structures which include information which would be relevant for one choice of parameters, but not the current choice. For example, in parsing, a parameterised level chooses how to annotate nodes so that the syntax trees only have the relevant inibrmation for the chosen syntax-semantics strategy. The architecture is illustrated in Figure 5.</Paragraph> <Paragraph position="2"> The result of the parameterised approach is a system which provides several thousand possible valid combinations of semantic tbrmalism, grammar, reducer etc. using a small amount of code.</Paragraph> </Section> </Section> <Section position="6" start_page="1099" end_page="1099" type="metho"> <SectionTitle> 5 The Graphical Interface </SectionTitle> <Paragraph position="0"> A major part of our work on the educational tool was the development of a general graphical browser or grapher for the graphical notations used in computational linguistics, especiMly those in computational semantics such as trees, Attribute-Value-Matrices, EKN (Barwise and Cooper, 1993) and 1)RSs. The grapher was</Paragraph> <Section position="1" start_page="1099" end_page="1099" type="sub_section"> <SectionTitle> Ii00 </SectionTitle> <Paragraph position="0"> written in Tcl/Tk, a programming system tbr developing graphical user interfaces (Ousterhout, 1994). Two attrilmtes of Tel/Tk which were important lbr this applieattion were the l)rowision of translation routines from graphic canvasses into Postscript (allowing generation of diagrams such as Figures 1 to d), and the ease of providing scaling routines for zooming.</Paragraph> <Paragraph position="1"> The grapher was designed to be extendible for future al)plications. Graphical structures are described using a (les(:ril)tion stritlg, a. plain text hi-erarchical description of the object to be drawn without any exact positioning information, l,'or example, the following tree: which aJlow tim user to perform actions by clicking on mouse-sensitive regions ill the display are;~. The grapher and an underlying application therefore can behaw.' in a way that the grapher is not only a way to visual*st the data of t;he application, but also providc.s a real interface I)etween user and af)plication.</Paragraph> </Section> </Section> <Section position="7" start_page="1099" end_page="1099" type="metho"> <SectionTitle> 6 Availability of the System </SectionTitle> <Paragraph position="0"> The system ('urrently requires Sicstus 3 plus '\['cl version 7.d and 'l'k w;rsion 4.0 (or later versions), lit, is awfilablc at the' ftp address: ftp.coli.uni-sb.de:/pub/fracas or on the WWW at the UI/J,: http ://coli. uni-sb, de/~ clears/clears, html l;urther (toeumentation of the' system is given in (l,'raCaS, 1996a) and (FraC, aS, 1996b), which are available from: http://www, cogsci.ed, ac.uk/~fracas/</Paragraph> </Section> class="xml-element"></Paper>