<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-0212">
  <Title>Visualization of Protocols of the Parsing and Semantic Interpretation Steps in a Machine Translation System</Title>
  <Section position="4" start_page="85" end_page="88" type="metho">
    <SectionTitle>
3 Displaying the Data
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="85" end_page="86" type="sub_section">
      <SectionTitle>
3.1 Display of the Constituent
Structure
</SectionTitle>
      <Paragraph position="0"> The obvious solution to the issue of visualizing the Overall constitutent structure of a sentence, namely displaying it as a conventional parse tree representation, turns out to be not very practical at closer examination. Since some parsers employed in our system may return more than just one structure for any given input, and since  partial parses are very relevant for debugging, we are, in fact, not dealing with a single parse tree but rather with a 'parse forest' which may contain dozens or even hundreds of complete and partial trees. A development tool that confronts the developer with a large number of spelled-out ambiguities is not satisfactory, because it does not allow efficient access to relevant areas in the data space. Moreover, even in cases where there is only one single parse tree, the tree may not fit on the screen, and even if it does, there will be little room left to display the feature structures associated with each node.</Paragraph>
      <Paragraph position="1"> Therefore, instead of using conventional tree representations, the parse sequence is maintained as such and displayed as a cross-linked sequence of minimal trees, essentially in the same way it is recorded in the process protocol.</Paragraph>
      <Paragraph position="2"> However, it is formatted in a manner that supports the correct interpretation of the symbols as mother and daughter(s) (cf. the lower left frame in Figure 5). In addition, the explicit information contained in the individual entries of the process protocols is augmented by information that can be inferred from the process protocol as a whole and will not be visible when just looking at the protocol. Note, for example, that category labels are given not only for the mother node but also for the daughter nodes, and that the mother-daughter relation contained in the individual protocol entry is back-referenced to the daughter nodes in the HTML representation, so that the subsequent use of the node can be traced easily. In contrast, detailed information about the properties of the individual constituents, which tends to obstruct the view of the overall structure, is removed from this trace of display and stored in a separate file. Nevertheless it is readily at hand by means of hyperlinks, as will be explained immediately below.</Paragraph>
      <Paragraph position="3"> What is not visible in Figure 5 is that all category labels, and the node numbers in subscript after the category labels of daughter and parent nodes, are hyperlinks. A mouse click on a category label causes the browser to display the feature structure associated with that node in the frame on the right. A click on the node number leads to the respective node within the same (left) frame. This setup provides the user with the means to easily navigate the parse tree or parse forest, and, at the same time, allows him or her to inspect the features associated with each node in detail. In both frames, ambiguities (multiple structures associated with one node) are preserved by marking the alternatives with clear headings. Since parse sequence and feature structures are separated and displayed in different, adjoining frames in the browser, a very compact yet informative form of data visualization is achieved.</Paragraph>
    </Section>
    <Section position="2" start_page="86" end_page="86" type="sub_section">
      <SectionTitle>
3.2 Visualization of the Relation
between Constitutent Structure
and Input Text
</SectionTitle>
      <Paragraph position="0"> Before we turn to the representation of feature structures, let us briefly comment on the top frame in Figure 5. This frame displays the text of the original input sentence and serves two purposes. First, a click on the caption \[show range\] in either one of the lower frames 1 causes the browser to display the range covered by that node in red (as opposed to black for the surrounding context), and, secondly, in the 'clickable' mode of the top frame the input sentence serves as an index: a click on a word leads to the respective node in the parse sequence in the lower left frame, so that particular points of interest can be accessed easily during the grammar development process.</Paragraph>
    </Section>
    <Section position="3" start_page="86" end_page="87" type="sub_section">
      <SectionTitle>
3.3 Representation of Feature
Structures
</SectionTitle>
      <Paragraph position="0"> Our approach to the display of feature structures also diverges from representation formats that are well established in the literature. Commonly used representations -- representations as graphs with labeled arcs and as attribute-value matrices (cf. Figure 3) -- tend to become too large once the feature structures reach a certain complexity. Moreover, both of them require extensive calculations and graphical processing, which have to be paid for in terms of processing time. Instead, our tool represents feature structures as unordered lists in HTML.</Paragraph>
      <Paragraph position="1"> Each list element represents an attribute-value pair. Atomic values are separated from their attributes by an equal sign (=); complex values (embedded feature structures) are represented as embedded lists.</Paragraph>
      <Paragraph position="2">  an unordered list with path abbreviations.</Paragraph>
      <Paragraph position="3"> In this representation format, the feature structure represented by the AVM in Figure 6 would be rendered as shown in Figure 7.</Paragraph>
      <Paragraph position="4"> In order to achieve a more compact representation, we use a convention that is commonplace in the HPSG literature (Pollard and Sag, 1994, and others), namely, we abbreviate single paths by the use of a vertical bar (I). Thus the representation in Figure 8 is equivalent to the one shown in Figure 7.</Paragraph>
    </Section>
    <Section position="4" start_page="87" end_page="88" type="sub_section">
      <SectionTitle>
3.4 Sorting and Use of Colors
</SectionTitle>
      <Paragraph position="0"> In the process protocols, features usually appear in random order. In order to ease the locating of features and the comparison of feature structures, features are generally listed in alphabetical order in the display. However, since not all information contained in the feature structures is equally important, some features receive special treatment.</Paragraph>
      <Paragraph position="1"> The main purpose of the parsing and semantic interpretation steps within the translation process is to build up a more language-independent representation of the semantic content of the input text. This information is stored in the SEM feature of the feature structure associated with each node. Within these substructures, the INSTANCE feature plays a central role: it specifies the concept from the Sensus ontology 2 (Knight and Luk, 1994; Hovy and Knight, 1993) that the object referred to by the expression in the source language is an instance of. For example the Japanese expression 1992 year &amp;quot;best dresser&amp;quot; award refers to an instance of a prize or award (~) which is modified 3 by the string &amp;quot;&lt;.X b V l/,, @-- (&amp;quot;best dresser&amp;quot;) and temporally located in the year 1992: the &amp;quot;Best Dresser&amp;quot; Award 1992. Other features on the same 'level' as the INSTANCE feature specify arguments (in the case of predicates and relations) and further modifications of the object in question. In order to accomodate the central role of the INSTANCE feature, it is always pushed to the top of the list of features under its governing attribute in the feature structure, and displayed, together with its value, in red instead of black. This increases its visibility in the display of the feature structures, so that it can be spotted easily. The lower right frame of the main window in Figure 9 shows the feature structure discussed here.</Paragraph>
      <Paragraph position="2"> 2If an appropriate concept cannot be found in the ontology, an English gloss is used instead.</Paragraph>
      <Paragraph position="3"> ZThis representation does not specify the nature of the modification. We currently do not have the means to automatically determine the specific character of the modification.</Paragraph>
      <Paragraph position="5"> Also, in order to help the developer distinguish the different frames and windows (see below) of the visualization tool, we use different background colors for different frames. For example, the background of the lower right frame of the main window is kept in a light blue, whereas other windows have yellow or white backgrounds.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="88" end_page="88" type="metho">
    <SectionTitle>
4 Integration of Additional
Resources
</SectionTitle>
    <Paragraph position="0"> Whereas the data discussed so far is almost always of interest for the developer, other types of information are requested less frequently. For example, one may want to check a word's entry in the dictionary, or see the grammar rule that was used to create a particular node. Dedicating a frame in the main window to the display of this kind of data did not seem an appropriate solution. Display space is far too precious to be wasted on a frame that is used only occasionally. Instead, this kind of information is provided in separate browser windows. The grammar rules contain unique IDs that are preserved in the feature structures associated with each node. The converter uses these IDs to set links to an HTML version of the grammar. The links are listed under 'Rules applied' in the lower right frame (cf. Figure 9). For terminal nodes, a click on the lexical symbol in either of the lower frames will access the cgi interface of the dictionary and deliver the complete lexical information that is available for the respective entry. Figure 9 shows a sample of the developer's screen with the main and the two subsidiary windows.</Paragraph>
  </Section>
  <Section position="6" start_page="88" end_page="89" type="metho">
    <SectionTitle>
5 Evaluation
</SectionTitle>
    <Paragraph position="0"> The prime criterion for the evaluation of a visualization tool like the one described is its effect on the efficiency of working with the data. Since the tool was mainly developed for in-house use by a small team of developers, we did not carry out formal experiments in order to assess the increase in productivity. Based on my personal experience in working with both the simple process protocols and the visualized version as a grammar developer for the Japanese modules,  I estimate the speedup at a factor of two to at least ten, depending on the size of the structure to be analyzed: the larger the structure, the greater the benefit of visualization.</Paragraph>
    <Paragraph position="1"> Also, the tool has proven to be valuable for demonstration purposes, as the structuring provided by this kind of display helps people who have no previous experience with our system and maybe are even unfamiliar with natural language processing in general understand the process in more detail. In particular, since many people are now familiar with the internet and the interfaces provided by web browsers, our impression is that people who see our system for the first time tend to be able to focus on the data rather than the interface more quickly. Again, this claim has not been tested experimentally.</Paragraph>
  </Section>
  <Section position="7" start_page="89" end_page="89" type="metho">
    <SectionTitle>
6 Technical Information
</SectionTitle>
    <Paragraph position="0"> The converter was implemented in Perl and currently works in off-line mode only, that is, the HTML files have to be created first and can then be used. Processing time depends very much on the size of the structures as well as other factors beyond the immediate control of the author such as network traffic and overall processing load on the machine. On a Sun Ultra, processing typically takes between a few seconds for short sentences (converting the protocol for the sentence in Figure 9 takes about 3 seconds) and several minutes for very large and ambiguous structures.</Paragraph>
  </Section>
class="xml-element"></Paper>