<?xml version="1.0"?><!DOCTYPE article SYSTEM "/project/take/software/searchbench_offline_processing/paperxml_generator/aclextractor/src/python/../resource/dtd/paperxml.dtd"><article><header><firstpageheader><page local="1" global="18"/><title>TAUM-AVIATION: ITS TECHNICAL FEATURES AND SOME EXPERIMENTAL RESULTS</title><pubinfo>Copyright 1985 by the Association for Computational Linguistics. Permission to copy without fee all or part of this material is granted provided that the copies are not made for direct commercial advantage and theCLreference and this copyright notice are included on the first page. To copy otherwise, or to republish, requires a fee and/or specific permission. 0362-613X/85/010018-27$03.00 Computational Linguistics, Volume 11, Number 1, January-March 1985</pubinfo><author surname="Isabelle" givenname="Pierre"><org  name="Département de Linguistique Université' de Montréal CP" country="Canada"/></author><author surname="Bourbeau" givenname="Laurent"><org  name="Département de Linguistique Université' de Montréal CP" country="Canada"/></author></firstpageheader><frontmatter><p><b>TAUM-AVIATION: Its Technical Features and Some Experimental Results</b></p><p><b>Pierre Isabelle and Laurent Bourbeau</b></p><p><b>Département de Linguistique Université' de Montréal CP. 6128, Suce. A, Montréal, Qué, Canada H3C 3J7</b></p></frontmatter><abstract><b>Upon the completion of its highly successful TAUM-METEO machine translation system, the TAUM group undertook the construction of TAUM-AVIATION, an experimental system for English to French translation in the sublanguage of technical maintenance manuals. A detailed description of the resulting prototype is offered. In particular, the paper includes: a) some figures on the size of the system; b) a description of the underlying translation model (indirect approach, analysis/transfer/synthesis scheme); c) a presentation of the basic computational techniques (use of a specialized high-level metalanguage for each linguistic component); and d) some results on the evaluation of the prototype.</b> </abstract></header><body><section number="1" title="Background 1.1  historical notes"><p>In 1965, with funding from the National Research Coun­cil of Canada, the <b>CETADOL </b>research center in computa­tional linguistics was created at l'Université de Montréal. Around 1970, the center narrowed its focus to the prob­lem of machine translation <b>(MT), </b>renaming itself <b>TAUM </b>(Traduction Automatique Université de Montréal). In the next few years, several <b>MT </b>pro types were developed: <b>TAUM-71, TAUM-73, </b>and <b>TAUM-76 </b>(Colmerauer et al. 1971, Kittredge et al. 1973, Kittredge et al. 1976).</p><p>Starting in 1973, the Canadian Secretary of State Department (Translation Bureau) assumed responsibility for funding the project, in the hope that tangible results would soon emerge. Between 1974 and 1976, <b>TAUM </b>produced its first practical application: the <b>TAUM-METEO </b>system, for the translation of weather forecasts (Chevalier et al. 1978). Since 1977, this system has been used on a daily basis for the Canadian Environ­ment Department (Chandioux and Guéraud 1981). Its current workload represents an annual volume of 8.5 million words (Bourbeau 1984). In spite of its very narrow scope, <b>TAUM-METEO </b>represents an important breakthrough in <b>MT, </b>since it is the only system that currently produces high quality translation without the need for human revision (although approximately 20% of the input is rejected).</p><p>The <b>AVIATION </b>project was undertaken in 1976, even before the on-site implementation of <b>TAUM-METEO </b>was completed. The aim was to develop a system capable of translating aircraft maintenance manuals. Obviously, this was a more difficult challenge than translating weather forecasts. The magnitude of the task necessitated a massive infusion of new personnel and the development of a set of new metalanguages (e.g. <b>LEXTRA, SISIF). A </b>prototype of the <b>TAUM-AVIATION </b>system, restricted to hydraulic system maintenance manuals, was demon­strated in 1979.</p><p>The following year, an independent evaluation (Gervais 1980) concluded that it was not possible to envisage immediate cost-effective production using <b>TAUM-AVIATION</b>. This evaluation led the Translation Bureau to stop funding the <b>TAUM-AVIATION </b>project, and to look for a broader funding base for <b>MT </b>research and development in Canada. In the meantime, the <b>TAUM </b>Group had to be disbanded.</p><subsection number="1.2" title="languages translated"><p><b>TAUM-AVIATION </b>is designed in such a way that a core portion of the system is independent of particular language pairs: linguistic descriptions constitute <b>data </b>for <b>Table </b><b>1.</b><page local="2" global="19"/><b></b></p><p><b>Size of compiled codes and memory requirements.</b></p><p>(a) compiled linguistic data; (b) compiled interpreter for linguistic data <b>Table </b><b>2.</b><b>   </b><b>Metalanguage compiler sizes.</b></p><p>the system. However, from a linguistic perspective, the project was exclusively focused on English-to-French translation.</p><p>In addition, the linguistic descriptions incorporated into the system are addressed not to general language but to the particular sublanguage of maintenance manuals (Lehrberger 1982). The notion of sublanguage is presented in Kittredge and Lehrberger (1982).</p></subsection></section><section number="1" title=".3 project size"><p>The initial staff of seven researchers in 1976 was rapidly increased to a peak of 20 people during 1979, and then slowly decreased until the project was terminated.</p><subsection number="1.4" title="system size"><p>TAUM-AVIATION was implemented on a CYBER 173 computer, with the NOS/BE <b>1.4 </b>operating system, but was designed so as to be practically machine-indepen­dent. Most components of the system are based on the following scheme: certain linguistic data (dictionaries, grammars) are compiled into an object code interpreted at run time against the input text. <b>Table </b><b>1 </b>gives an idea of the size of the runtime code, together with typical memory requirements for execution. <b>Table </b><b>2 </b>gives the size of the programs used to compile the linguistic data.</p></subsection></section><section number="1" title=".5 size of dictionaries"><p>The dictionaries list only the base form of the words (roughly speaking, the entry form in a conventional dictionary). In March 1981, the source language (English) dictionary included 4054 entries; these entries represented the core vocabulary of maintenance manuals, plus a portion of the specialized vocabulary of hydraulics. Of these, 3280 had a corresponding entry in the bilingual English-French dictionary.</p></section><section number="2" title="Application Environment"><p>TAUM-AVIATION remains an experimental system. It is designed to take as input a text that is in a photocompo­sition-ready format; a pre-processing program stores the formatting codes, which will be reinserted in the trans­lated text. No use is made of manual pre-editing.</p><p>The translation process is fully automatic. If desired, it can be interrupted after dictionary lookup to obtain a list of unidentified words, and enter any such words in the dictionary.</p><p>Revision of the machine output is normally necessary: the domain is too complex for results comparable to those of TAUM-METEO. The designers of the system decided not to rely heavily on "fail-soft" strategies such as constraint relaxation or partial parses; these strategies make the quality of the output totally unpredictable. Thus, the material passing through the system is trans­lated relatively well (very well by MT standards), and the revisor is less likely to feel overwhelmed by linguistic garbage. The price to be paid is a failure to produce any output for a relatively high proportion of the input sentences (somewhere between 20 and 40 per cent, at the stage of development reached in 1981). For a sample of translations produced by TAUM-AVIATION, see the Appendix.</p><p>The development of TAUM-AVIATION has not been taken far enough for a definitive assessment to be made of the linguistic and computational strategies that it embodied:<page local="3" global="20"/> the total system throughput was approximate­ly 100,000 words.</p><table class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p></p></td><td class="cell"><p>Size of compiled code</p></td><td class="cell"><p>Runtime CM requirements</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p></p></td><td class="cell"><p>(6-bit K/char)</p></td><td class="cell"><p>(60-bit octal K/words)</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Component</p></td><td class="cell"><p>(a)</p></td><td class="cell"><p>(b)</p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Pre-processing</p></td><td class="cell"><p>60</p></td><td class="cell"><p>15</p></td><td class="cell"><p>34</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Morphological analysis</p></td><td class="cell"><p>77</p></td><td class="cell"><p>48</p></td><td class="cell"><p>40</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Source language dictionary</p></td><td class="cell"><p>1958</p></td><td class="cell"><p>72</p></td><td class="cell"><p>40</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Syntactic/semantic analysis</p></td><td class="cell"><p>205</p></td><td class="cell"><p>56</p></td><td class="cell"><p>120</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Bilingual dictionary</p></td><td class="cell"><p>1919</p></td><td class="cell"><p>107</p></td><td class="cell"><p>40</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Syntactic transfer and synthesis</p></td><td class="cell"><p>113</p></td><td class="cell"><p>63</p></td><td class="cell"><p>56</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Morphological synthesis</p></td><td class="cell"><p>99</p></td><td class="cell"><p>64</p></td><td class="cell"><p>24</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Post-processing</p></td><td class="cell"><p>43</p></td><td class="cell"><p>15</p></td><td class="cell"><p>34</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table><table class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Metalanguage</p></td><td class="cell"><p>Used for</p></td><td class="cell"><p>Compiler size (compiled code, 6-bit K/char)</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>SISIF</p></td><td class="cell"><p>pre- and post-processing</p></td><td class="cell"><p>43</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>REZO</p></td><td class="cell"><p>syntactic/semantic analysis</p></td><td class="cell"><p>155</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>LEXTRA</p></td><td class="cell"><p>lexical transfer</p></td><td class="cell"><p>130</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>SYSTEMES-Q</p></td><td class="cell"><p>structural transfer; syntactic synthesis</p></td><td class="cell"><p>28</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table></section><section number="3" title="General Translation Approach"><p>The <b>TAUM-AVIATION </b>system is based on a typical second generation design (Isabelle et al. 1978, Bourbeau 1981). The translation is produced <b><i>indirectly, </i></b>by means of an analysis/transfer/synthesis scheme. The internal organization of the major components of the system is based on the notion of linguistic level. Finally, the linguistic data are generally separated from the algorith­mic specifications.</p></section><section number="3" title=".1   transfer model"><p>The overall design of the system is based on the assump­tion that translation rules should not be applied directly to the input string, but rather to a formal object that represents a structural description of the content of this input. Thus, the source language <b>(SL) </b>text (or successive fragments of it) is mapped onto the representations of an <b>intermediate language, </b>(also called <b>normalized structure) </b>prior to the application of any target language-dependent rule.</p><p>No one knows how to construct a universal, language-independent semantic interlingua.   The inter<b>mediate language used in the TAUM-AVIATION system is largely language dependent:</b><b> it consists of semantically annotated deep structures for SL and TL sentences. A certain degree of language independence is attained by the use of a common "base component" (a context-free grammar that enumerates the admissible deep structures) for both SL and TL. But the lexical items are left intact, and a transfer module is used in order to map the lexical items of SL onto those of TL.</b></p></section><section number="3" title=".2   linguistic organization"><p><b>The arrangement of the system into three major modules (analysis, transfer, synthesis) reflects a theoretical model of translation operations: it is claimed that these oper­ations take place at a "deep" level, between language-de­pendent meaning representations. Moreover, each one of the three modules is arranged internally along the lines of a linguistic theory: the components of these modules correspond to the standard levels of linguistic description (lexicon, morphology, syntax, semantics). This contrasts with older systems, the structure of which frequently had no direct relationship to any definite theory of language and translation.</b></p><p><b>Figure </b><b>1 </b><b>shows the internal structure of the TAUM-AVIATION system.</b></p><doubt alpha="0.0" length="6" tooSmall="False" monospace="0.0">(*■-^\</doubt><p><b>I intermediate I I representation </b><b><i>J</i></b></p><doubt alpha="0.0" length="1" tooSmall="False" monospace="0.0">1</doubt><p><b>_J intermediate A representation</b> <b>post-process.</b><b>■orphology</b></p><doubt alpha="100.0" length="6" tooSmall="False" monospace="0.0">syntax</doubt><p><b></b></p><p><b><u>^TL text</u></b></p><p><b>Figure </b><b>1.   </b><b>Overall Structure of the TAUM-AVIATION System.</b></p><table class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>T</b></p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>R</b></p></td><td class="cell"><p><b>lexical</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>A</b></p></td><td class="cell"><p><b>1</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>N</b></p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>S</b></p></td><td class="cell"><p><b>1</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>F</b></p></td><td class="cell"><p><b>structural</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>E</b></p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>R</b></p></td><td class="cell"><p></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table><table class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>1</p></td><td class="cell"><p><b>&gt;</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>A</b></p></td><td class="cell"><p><b>syntax/</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>N</b></p></td><td class="cell"><p><b>semantics</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>A</b></p></td><td class="cell"><p><b>Î</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>L</b></p></td><td class="cell"><p><b>lexicon</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>y</b></p></td><td class="cell"><p><b>f</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>s</p></td><td class="cell"><p><b>morphology</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p><b>i</b></p></td><td class="cell"><p><b>t</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>s</p></td><td class="cell"><p><b>pre-</b></p></td><td class="cell"><p><b>process.</b></p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table><page local="4" global="21"/></section><section number="4" title="Linguistic Techniques 4.1  processing units"><p>It is well known that some translation problems can only be solved trough textual, as opposed to sentential, proc­essing. However, we still know too little about discourse analysis techniques to use them effectively in large-scale systems. Thus, the processing unit in <b>TAUM-AVIATION </b>is the sentence.</p><p>Fortunately, anaphoric pronouns are quite rare in technical manuals. A more frequent problem is the use of anaphoric definite noun phrases. Consider for example the text fragment in (1):</p><p>( 1 )   Remove hydraulic filter bypass valve. This valve is located below accumulator No. 1.</p><p>A word like <b><i>valve </i></b>cannot be translated correctly in isolation. Depending on the type of valve, French will use <b><i>clapet, robinet, soupape, </i></b>etc. In the second sentence of (1), the word <b><i>valve </i></b>is used anaphorically. To translate it correctly, one has to refer to its antecedent: the modifier <b><i>bypass </i></b>determines a specific French equivalent.</p><p><b>TAUM-AVIATION </b>cannot solve problems of this type. The designers of the system preferred to concentrate their efforts on the best possible sentential analysis. And in fact, in spite of a relatively advanced sentence analyz­er, translation failures due to weaknesses in sentential processing (e.g. scoping problems for conjunctions, nominal compounds, etc.) turned out to be <b><i>much more frequent </i></b>than failures due to anaphor problems, as evidenced by the error compilations of Lehrberger (1981)</p><subsection number="4.2" title="the analysis module: ambiguity problems"><p>Ambiguity is a language-internal phenomenon and it is the responsibility of the analysis module to resolve it. Sometimes, it is possible to ignore certain ambiguities, in the hope that the same ambiguities will carry over in translation. This is particularly true in systems like <b>TAUM-AVIATION </b>that deal with only one pair of closely related languages. The difficult problem of prepositional phrase attachment, for example, is frequently bypassed in this way. Generally speaking, however, analysis is aimed at producing an unambiguous intermediate represen­tation.</p><p>The analysis module comprises four components: pre­processing, morphology, lexicon and syntactic/semantic analysis (see Figure 1). The pre-processing component segments the input text into successive words and into processing units. In this latter function, it can be seen as a degenerate text grammar. Because this is carried out deterministically, without interaction from the other components, segmentation problems occasionally arise.</p><p>Morphological analysis includes complete rules and exception lists for English inflectional morphology, cate­gory assignment rules for numbers and rules for dealing with unknown words. No rules are provided for deriva­tional morphology. The system handles some types of compositional morphology, but this is done in the syntactic component, since compounds frequently exhibit prop­erties that are otherwise thought of as syntactic; for example, internal conjunction is possible (e.g. <b><i>four- and six-cell batteries).</i></b><b><i></i></b></p><p>Syntactic and semantic analysis are very tightly inte­grated in the <b>TAUM-AVIATION </b>system. First, both of them are implemented using the same metalanguage, a particular version of Wood's <b>ATNs </b>(see section 5, below). Second, both components interact freely during analysis. It is nevertheless convenient to describe them separately.</p><subsubsection number="4.2.1" title="syntax"><p>The <b>TAUM-AVIATION </b>system includes a large-scale grammar of English capable of handling most constructions that occur with some frequency in the sublanguage of maintenance manuals (Lehrberger 1982). The rules are based on an extensive lexical subcategori-zation scheme: 12 standard categories are further subclassified using more than 75 features (excluding morpho-syntactic features). This is in addition to the use of lexical "strict subcategorization" frames comparable to those of transformational grammar.</p><p>Since the intermediate representation used for transfer is a type of semantically annotated "deep structure", and since maintenance manuals make use of a very complex syntax, it was necessary to provide the parser with a rich transformational component. Thus, the inverses of several transformations from standard transformational theory are used: passive, extraposition, raising, etc.</p><p>In dealing with texts as complex as technical manuals, the parser is faced with difficult ambiguity problems. Ambiguities are already present in the input to the parser, at the lexical level. These ambiguities may concern the syntactic properties of the lexical element (e.g. <b><i>light </i></b>is a noun, a verb, or an adjective); or they may concern primarily its semantic properties: pure homo­graphs like the two nouns <b><i>lead </i></b>or polysemous items like the noun <b><i>line.</i></b></p><p>The parser will as a side effect eliminate some lexical ambiguities; for example, if <b><i>Check valve </i></b>is to be taken as a sentence, syntax tells us that <b><i>check </i></b>must be a verb. However, the parser will itself introduce <b><i>structural </i></b>ambi­guities, owing to the existence of syntactically undeter­mined choice points in the application of grammar rules. Two examples of structural ambiguity are adjective scope as in (3), and conjunction scope, as in (4).</p><doubt alpha="57.1" length="63" tooSmall="False" monospace="0.0">(3) a )     (liquid oxygen) tanks a' ) ?? liquid (oxygen tanks)</doubt><doubt alpha="62.7" length="51" tooSmall="False" monospace="0.0">b ) correct (oil level) b' ) ?? (correct oil) level</doubt><doubt alpha="61.3" length="75" tooSmall="False" monospace="0.0">(4) a )     (pressure and return) lines a' ) ?? pressure and (return lines)</doubt><p>b ) jack and (jacking adapter) b' ) ?? (jack and jacking) adapter<page local="5" global="22"/></p><p>These examples show that with <b>ADJ NOUN NOUN </b>sequences and <b>NOUN CONJ NOUN NOUN </b>sequences, two different syntactic groupings are possible. But only one of them is semantically acceptable and results in a correct translation.</p><p>Moreover, some lexical ambiguities, instead of being eliminated in the parsing process, will constitute a further source of structural ambiguity, each reading of the rele­vant lexical item being compatible with a different syntactic structure. In example (5), <b><i>drain </i></b>can be taken either as a noun or as a verb, when appropriate adjust­ments are made to the surrounding syntactic structure.</p><p>(5)   Remove dust cap and drain plug.</p><p>Thus by itself, a syntactic parser produces a highly ambiguous output, and further constraints are needed in a practical <b>MT </b>system.</p></subsubsection><subsubsection number="4.2.2" title="SEMANTICS"><p>Semantic processing in the <b>TAUM-AVIATION </b>system performs two related tasks: a) it filters the syntactic structures, eliminating as many ambiguities as possible; and b) it associates with each node of the tree a set of semantic features which will be used by transfer rules.</p><p>Most semantic features originate in the dictionary, where lexical items are described in terms of some 35 features that form a <b>tangled hierarchy. </b>Predicative lexical items (verbs, adjectives, certain prepositions) are assigned selectional restrictions on their possible argu­ments in terms of these semantic features.</p><p>Selectional restrictions constitute the main semantic mechanism used by the system to eliminate ambiguities of two types:</p><p>a. structural ambiguities introduced by syntactic rules; thus the spurious structure proposed by the parser for (5) is eliminated because the verb <b><i>drain </i></b>does not accept as direct object something in the semantic category of <b><i>plug.</i></b></p><p>b. lexical ambiguity in the semantic properties of certain lexical items; polysemous words like the noun <b><i>line </i></b>(which can denote either an abstract geometrical object, or physical objects such as conductors) are frequently disambiguated by selectional restrictions; for example, in <b><i>Flush the line, </i></b>the concrete sense is selected.</p><p>In order for selectional restrictions to work properly and for trees to be correctly annotated, it is necessary to apply <b>semantic projection rules </b>which assign sets of features to tree nodes. In <b>TAUM-AVIATION, </b>the seman­tic rules work in a compositional fashion, raising selec­tively certain features from daughter nodes to their mothers (Isabelle 1985). Rules such as the following are used:</p><p>• all of the semantic features of a headnoun are raised onto the dominating <b>NP </b>node;</p><p>• the intersection of the features of two conjoined <b>NP </b>nodes is raised onto the dominating <b>NP </b>node; and</p><p>• when the headnoun is a partitive noun (e.g. <b><i>portion), </i></b>and the <b>NP </b>has an <b><i>of NP </i></b>complement, the features of this complement are raised onto the dominating <b>NP </b>node.</p><p>The system also makes use of standard <b>control rules </b>for subjectless infinitives and gerundives, and of some pronoun/antecedent rules, in order to enforce semantic constraints wherever possible.</p><p>Semantic ambiguity, whether real homography (e.g. the two nouns <b><i>lead) </i></b>or polysemy (e.g. the various senses of the noun <b><i>line), </i></b>is not handled by creating multiple entries in the source language dictionary. Rather, in its single entry, the word is assigned a number of <b><i>seman­tically incompatible </i></b>features. The semantic rules seek to filter out some of these features, so that no incompatibili­ty remains. This strategy prevents the redundant syntac­tic search that results from a multiple-entry strategy.</p></subsubsection></subsection></section><section number="4" title=".3 THE TRANSFER MODULE"><p>In principle, transfer rules state correspondences between two sets of unambiguous structural descriptions. Their most obvious task is to relate the lexical items of <b>SL </b>to those of <b>TL. </b>Even if the rules are applied to unambig­uous lexical elements, the correspondences are by no means one-to-one: the lexical system of each natural language reflects a specific way of breaking down the conceptual universe. For this reason, equivalences have to be stated in terms of structural patterns rather than in terms of words or strings of words.</p><p>To take an example, there is no language-internal evidence that <b><i>hard </i></b>is ambiguous in English; however, depending on the context, it is translated into French as <b><i>difficile, dur, </i></b>etc. The French equivalents have more restricted collocations. In all those cases, transfer rules are needed to select the contextually appropriate equiv­alent.</p><p>Moreover, very frequently, these <b>lexical transfer rules </b>cannot simply substitute lexical items, leaving the tree structure unaffected. Since <b>SL </b>and <b>TL </b>lexical items frequently have different contextual requirements (i.e. subcategorization frames), translation rules have to establish correspondences between a source and a target structural pattern, as illustrated by the examples in (6).</p><doubt alpha="59.1" length="44" tooSmall="False" monospace="0.0">(6)   a. check x against y -* comparer x à y</doubt><doubt alpha="63.9" length="36" tooSmall="False" monospace="0.0">b. supply x with y -»• fournir y à x</doubt><p>c. cantilever x    monter x en porte-à-faux d. bond x electrostatically -*■ métalliser x e. service x      faire l'entretien de x</p><p>It is clear that lexical transfer rules must include powerful transformational mechanisms. This basic fact has not so far received the attention it deserves in the <b>MT </b>communi­ty. The <b>TAUM-AVIATION </b>system provides for full trans­formational power at the level of lexical transfer (Chevalier et al. 1981).</p><p>The transfer component also involves rules for <b>struc­tural transfer, </b>that is, rules that deal with linguistic contrasts not tied to any specific lexical item.<page local="6" global="23"/> Since the same base rules are used for SL and TL, this sub-compo­nent is kept to a minimum. Nevertheless, a number of structural differences between SL and TL have to be accounted for by means of contrastive rules. For exam­ple, because the intermediate language does not provide for "universal semantic tenses", the tense systems of SL and TL have to be explicitly contrasted by a set of rules.</p><p>Another task left to structural transfer is to deal with observable contrasts concerning the use of <b>optional move­ment transformations. </b>In all likelihood, the use of these transformations is governed by discourse phenomena that the system does not attempt to analyze. The strategy used in TAUM-AVIATION is to take advantage of the frequent parallelisms between SL and TL regarding these aspects of surface structure organization. Thus, the inter­mediate representation retains "traces" from SL surface structure used by the synthesis component to maintain a certain parallelism with SL. However, in some cases we know that the two languages exhibit systematic differ­ences in their use of certain movement transformations. The structural transfer grammar describes these facts. For instance, TAUM-AVIATION includes complex rules for translating English passives with various French constructions, as illustrated in the following examples:</p><p>(7) Quick-disconnect fittings should not be removed. ■* Ne pas enleverjes raccords à démontage rapide.</p><p>(8) Ensure that pump and lines are bled.</p><p>-» S'assurer qu'on a purgé la pompe et les canalisa­tions.</p><p>(9) The flaps are operated by hydraulic system no. 1. -» Le circuit hydraulique no. 1 actionne les volets.</p><subsection number="4.4" title="THE SYNTHESIS MODULE"><p>Synthesis of the TL text involves three steps: syntactic synthesis, morphological synthesis, and post-processing.</p><p>Syntactic synthesis is carried out on the basis of a large-scale transformational grammar of French. Since the input to the synthesis component is normally a well-formed unambiguous sentential deep structure, synthesis here is much simpler than analysis. This is not to say that synthesis of natural language texts is generally easy. Generating a coherent text from an abstract discourse representation is certainly a very difficult problem. But in TAUM-AVIATION, synthesis can only be achieved on a sentential basis. Therefore, no attempt can be made to describe the complex discourse factors that influence sentence generation (e.g. application of "optional" move­ment transformations). As mentioned in the previous section, the strategy adopted is to try to preserve a certain parallelism with the SL sentences, since both languages have relatively similar means of expressing discourse cohesion.</p><p>Syntactic synthesis produces a string of lexical items annotated with all the information required to inflect them correctly. The morphological synthesis component then determines the final form of each word. This is done on the basis of an exhaustive description of the rules of French inflection (together with their exceptions). Post­processing reformats the TL text, making use, wherever possible, of the formatting codes of the SL text.</p></subsection></section><section number="5" title="Computational Techniques"><p>From the computational point of view, the TAUM-AVIATION system is more complex than TAUM-METEO, which is entirely written in the Q-SYS-TEMS metalanguage (Colmerauer 1971). One of the ideas underlying TAUM-AVIATION is to make use of specialized tools for different tasks in the interests of increased efficiency, though somewhat at the expense of overall simplicity.</p><p>In the implementation, the actual modules closely match the components of the linguistic model presented in Figure 1. They are applied sequentially and communi­cation between components is achieved by means of a <b>chart structure </b>(a type of loop-free graph). The arcs of these charts are labelled with tree structures whose nodes are labelled with complex symbols: a categorial label plus a set of features.</p><p>Most components are based on the following scheme. Certain linguistic data are described with a high-level metalanguage; in this metalanguage, the linguist expresses facts about tree structures. These descriptions are compiled into an abstract formal structure interpreted at run time against the material to be translated. Most of these compilers and interpreters are written in PASCAL.</p></section><section number="5" title=".1 PRE-AND POST-PROCESSING"><p>These relatively simple components, which map character strings onto sequences of chart structures and vice-versa, are implemented as sets of rules in a metalanguage called SISIF; a set of SISIF rules amounts to a deterministic finite-state automaton. These rules are compiled into list structures, which are interpreted against the input text at run time.</p><subsection number="5.2" title="INFLECTIONAL MORPHOLOGY"><p>Since it was possible to exhaustively describe the inflec­tional morphology of both French and English, there was no compelling reason to use a very high-level formalism. Consequently, in the interests of efficiency, two PASCAL programs were written for morphological analysis of English and morphological synthesis of French.</p></subsection><subsection number="5.3" title="DICTIONARIES 5.3 .1 SOURCE LANGUAGE DICTIONARY"><p>A dictionary system called SYDICAN enables the linguist to write lexical rules that associate a complex of lexical information with a string of base forms, forming a path in an input chart. Two types of rules are provided: a) rules that simply add a new path (labelled with the complex of lexical information) to the chart; and b) rules that, in <b>addition, have the effect of taking precedence over short­er matches in the chart (cf. "longest-match" strategy).</b><page local="7" global="24"/><b></b></p><p><b>The rules are compiled into list structures. At run time, they are retrieved from an arbitrarily large lexical data base and applied to the chart. The lexical database system includes some maintenance facilities, such as integrity constraints on its contents, and facilities for retrieving entries through arbitrarily complex requests on their contents.</b></p><subsubsection number="5.3.2" title="BILINGUAL DICTIONARY"><p><b>We saw in </b>4.3 <b>that lexical transfer involves rules that perform complex transformations on tree structures. The LEXTRA metalanguage makes it possible to associate with any lexical item an arbitrarily complex set of tree transformations. These transformations describe a pattern (anchored in the relevant lexical item), which is to be matched against the tree structure at run time. When a match is found, a series of associated actions specifying structural changes is performed.</b></p><p><b>An important idea embodied in LEXTRA is that a transfer component should have an explicit description of the intermediate language. In the TAUM approach this intermediate language is partially defined by a set of context-free rules that describe a common base compo­nent for SL and TL. LEXTRA takes as data this context-free grammar and guarantees that any manipulated tree structure corresponds to a permissible derivation in terms of that context-free grammar. This notion is to be related to computational formulations of transformational gram­mar such as Petrick </b>(1973), <b>where the deep structures produced by the inverse transformations are checked against the rules of the base component. No equivalent check is performed with parsing systems like ATNs.</b></p><p><b>LEXTRA rules are compiled into list structures. It was found that some of the constraints on admissible tree structures could be enforced at compile time (Gérin-Lajoie </b>1980). <b>This mechanism is very useful in the complex task of dictionary development. It helps vali­date the work of the lexicographer. At run time, the LEXTRA interpreter searches the tree structure for SL lexical items, retrieves the associated lexical rules and applies them to the tree.</b></p><p><b>5</b><b>.4   </b><b>SYNTAX AND SEMANTICS 5</b><b>.4.1 </b><b>ANALYSIS</b></p><p><b>The English grammar for syntactic analysis is written in REZO (Stewart </b>1975, 1978), <b>TAUM's version of augmented transition networks (ATNs). The REZO meta­language is different from Wood's ATNs (Woods </b>1970) <b>in several respects. Some of the differences are:</b></p><p><b>• REZO does not support morphological analysis, which is performed in a separate component;</b></p><p><b>• tree nodes are complex symbols that include sets of features on which boolean operations can be performed;</b></p><p><b>• REZO includes a number of primitives to perform pattern matching over tree structures;</b></p><p><b>• in addition to regular ATN states where all transitions are tried, REZO includes "deterministic" states where only the first transition whose test is met is followed;</b></p><p><b>• REZO accords special status to the states to which a recursive call can be made, so that the resulting gram­mar is a collection of sub-networks.</b></p><p><b>The REZO grammar is compiled into a set of instructions for a virtual machine, which is simulated by the runtime interpreter. Parsing is done in the usual top-down, depth-first, left-to-right, serial manner. The inter­preter can either work in an all-paths or in a first-path mode. One important difference from Wood's ATN inter­preter is that REZO takes as input a chart structure in which lexical ambiguities are encoded and applies the grammar in parallel to all the paths of this chart. The result is also a chart structure: REZO is thus a chart-to-chart transducer.</b></p><p><b>In </b>4.2, <b>it was mentioned that syntactic rules create structural ambiguities, and that semantic processing can eliminate some of these. Serial parsing provides another means of selecting a particular reading. Since the transi­tions of the REZO networks are followed in a fixed order, the grammar can be made to produce the most likely reading first. In TAUM-AVIATION's analysis grammar, the ordering of the transitions reflects:</b></p><p><b>• general parsing principles such as those discussed in human performance studies (e.g. Kimball </b>1973); <b>and</b></p><p><b>• sublanguage-specific statistical tendencies.</b></p></subsubsection></subsection></section><section number="5" title=".4 .2 structural transfer and synthesis"><p><b>Structural transfer and syntactic synthesis are imple­mented in the well-known Q-SYSTEMS, which we will not describe here. This introduces some heterogeneity into TAUM-AVIATION, since: a) unlike the other meta­languages, Q-SYSTEMS do not support trees with complex symbols as node labels; and b) the compiler and the interpreter are written in FORTRAN while PASCAL is used for the other metalanguages.</b></p><p><b>In fact, the original design of the system included provisions for a new metalanguage well suited to synthe­sis; but time constraints precluded its development.</b></p></section><section number="6" title="Experimental Results 6.1  cost-benefit evaluation"><p><b>In </b>1981, <b>the sponsor submitted TAUM-AVIATION to a cost-benefit evaluation, in order to determine if the system was usable in a production environment. This evaluation made by an independent consultant is reported in Gervais </b>(1980), <b>and we will only summarize the main conclusions.</b></p><p><b>Raw machine output was deemed to have a degree of intelligibility, fidelity, and style that reaches </b>80% <b>of unrevised human translations (HT).</b></p><p><b>Computational Linguistics, Volume </b><b>11</b><b>, Number </b><b>1</b><b>, January-March </b><b>1</b><b>985</b> <b>Computational Linguistics, Volume </b><b>11</b><b>, Number </b><b>1</b><b>, January-March </b><b>1</b><b>985</b><page local="8" global="25"/></p><p><b>Table </b><b>3.</b></p><p><b>TAUM-AVIATION: Its Technical Features and Some Experimental Results </b><b>MT/HT: Compared costs per word ($CDN).</b></p><p>Revised MT and revised HT have a comparable degree of quality, but revision costs are twice as high for MT; thus, globally, revised MT turns out to be more expensive than revised HT as shown in <b>Table </b><b>3. </b>However, it is noted in the evaluator's report that MT reduces by half the human time required in the translation/revision proc­ess.</p><p>The direct costs of MT could probably be reduced to an acceptable level, for example by interfacing the system with a suitable word-processing environment and by reducing the percentage of sentences for which no translation is produced (Isabelle 1981).</p><p>Cost-effective production would require the system to be applicable to at least 6 million words per year. In order to reach that target, the system would have to be extended to translate domains other than hydraulics. But the indirect costs involved in these extensions (e.g. dictionary development) are very high. Gervais concludes that it is impossible to assert that translation using TAUM-AVIATION would be globally cheaper than human translation.</p><subsection number="6.2" title="TECHNICAL EVALUATION OF PERFORMANCE"><p>Cost-benefit evaluations are certainly necessary, but a single evaluation of this type tells one very little about how the system can be expected to perform on different texts, or after further investment. TAUM developed a methodology for analyzing the performance of an MT system through a systematic examination of its trans­lation errors.</p><p>The first step is to collect all the errors in the trans­lation of the sample text; translators/revisors then have the responsibility of deciding what is to be counted as an error. A classification scheme for translation errors will include headings such as the following: incorrect TL equivalent for a word, incorrect word order, lack of an article, etc.</p><p>In itself, an absolute number of such errors for a given text is not very revealing; but a comparison of the ratio of errors to word tokens in different texts, or at various stages of development of the system is an initial source of useful information.</p><p>Still, from the point of view of system development, these "surface" translation problems are merely symp­toms for problems in some component of the system. To provide an answer to questions such as: • how many of these problems have a known solution?</p><p>• how long would it take to correct them?</p><p>• how much better would the performance of the system be after n person/months of work?</p><p>• what should the priorities be?</p><p>it is necessary to identify, for each surface problem, one or several causes in the functioning of the system. For example, the fact that, in the translation of a given sentence, a French adjective is incorrectly inflected could be caused by one or more of the following factors:</p><p>• incorrect marking in a dictionary entry;</p><p>• mistake in TL syntactic rules for agreement;</p><p>• incorrect scoping in SL analysis (e.g. give the wrong bracketing to an ADJ NOUN NOUN sequence); or</p><p>• absence of relevant marking in SL (e.g. when translating <b><i>federal and provincial governments </i></b>into French, should one pluralize the adjectives?).</p><p>A sophisticated error classification grid was developed, so that the sources of translation errors could be investi­gated in a coherent and meaningful way. Basically, this error grid reflects the internal organization of the system, so that translation errors can be assigned a precise cause in the operation of the system.</p><p>Once a coherent scheme is available, one can proceed with the classification of the translation errors found in the sample text. This classification process is difficult and tedious, but it is crucial that it be done with accuracy and consistency. Frequently, one has to follow "execution traces" to discover the exact source of a given error.</p><p>The final step is to look at the possible remedies for the problems that have been identified. A careful exam­ination of each problem source will reveal whether or not there is a known way of eliminating it, and if so, what amount of effort is needed.</p><p>If this type of technical evaluation can be carried out at successive stages of development (with both old and new texts), one gets a clear picture of the evolution of the system. The figures obtained will reveal whether or not:</p><p>• there has been substantial progress compared to previ­ous stages;</p><p>• an  asymptote  has  been  reached  in  the curve investment/improvement.</p><p>The same figures will also help determine development and research priorities.</p><p>This sort of technical evaluation was applied twice to TAUM-AVIATION in the final year of the project; only a few person-months of development had been invested in the system between the two tests.<page local="9" global="26"/> The main goal was to see how well a system developed on the basis of corpora from the domain of hydraulics would fare in the domain of electronics. Some results were as follows:</p><table class="main" frame="box" rules="all" border="1" regular="False"><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Tasks</p></td><td class="cell"><p>MT</p></td><td class="cell"><p>HT</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"><p>Preparation/input Translation Human Revision Transcription/Proofreading</p><p>TOTAL</p></td><td class="cell"><p>$0.014 ( 8%) $0.079 (43%) $0.068 (37%) $0.022 (12%)</p><p>$0.183</p></td><td class="cell"><p>$0.100 (69%) $0.030 (21%) $0.015 (10%)</p><p>$0.145</p></td><td class="cell"></td></tr><tr class="row"><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td><td class="cell"></td></tr></table><p>• In both tests, more than 70% of the failures were clas­sified as having a known solution; the vast majority of these could be corrected in 12 person/months of work.</p><p>• From a syntactic point of view, there is no notable difference between hydraulics and electronics. In fact, as a result of a minimal effort in correcting some prob­lems discovered in the test on hydraulics, the overall performance of the parser turned out to be better in the electronics test.</p><p>• As expected, there was a major dictionary problem in going from one domain to the other. Selectional restrictions as assigned for hydraulics worked so poorly that they did more harm than good to the final result.</p><p>A definitive assessment of the linguistic and computa­tional techniques on which TAUM-AVIATION is based would have required a few more applications of this evaluation/correction cycle.</p></subsection></section><section number="7" title="Future Directions"><p>Before TAUM was disbanded, Isabelle 1981 voiced the views of the group on a possible course for short- and long-term machine translation R&amp;D activities.</p><p>The difficulties encountered in the AVIATION project convinced the Translation Bureau that a more permanent and broader R&amp;D base would be required for MT to be viable in Canada. In 1983, the Translation Bureau in conjunction with the Canadian Department of Communi­cations, funded a large-scale study to review natural language processing technologies and examine opportu­nities for Canada in this field.</p><p>The consultants have submitted their report and the two Departments involved now have to determine the best way to implement the recommendations that are made therein. In the area of MT, there would appear to be three fronts on which R&amp;D could be pursued:</p><p>• the development and integration of various computer aids to human translation within a translator's work­station;</p><p>• the application of second-generation MT technology to promising sublanguages (Kittredge 1983);</p><p>• research on third-generation MT technology.</p></section><references><p><b>Bourbeau, Laurent 1981 Linguistic Documentation of the </b><b>TAUM-AVIATION </b><b>Translation System. Groupe </b><b>TAUM, </b><b>Université de Montréal, Montréal, Canada.</b></p><p><b>Bourbeau, Laurent 1984 Transfert du système </b><b>METEO </b><b>sur micro­ordinateur: étude de faisabilité. Bureau des traductions, Secrétariat d'Etat, Ottawa.</b></p><p><b>Chandioux, John and Guéraud, Marie-France    1981    </b><b>METEO: </b><b>un</b></p><doubt alpha="66.0" length="103" tooSmall="False" monospace="0.0">système l'épreuve du temps.META26(1): 18-22. Chevalier, Monique; Dansereau, Jules; and Poulin, Guy 1978</doubt><p><b>TAUM-METEO: </b><b>description du système. Groupe </b><b>TAUM, </b><b>Université</b></p><p><b>de Montréal, Montréal, Canada. Chevalier, Monique; Isabelle, Pierre; Labelle, François; and Laîné,</b> <b>Claude  1981  La traductologie appliquée à la traduction automa­tique.</b><b> <i>META </i>26(1): 35-47. Colmerauer, Alain    1971    Les SYSTEMES-O: un formalisme pour</b> <b>analyser et synthétiser des phrases sur ordinateur.</b><b> Groupe </b><b>TAUM,</b></p><p><b>Université de Montréal, Montréal, Canada. Colmerauer, Alain, et al.  1971  </b><b>TAUM-71. </b><b>Groupe </b><b>TAUM, </b><b>Université</b></p><p><b>de Montréal, Montréal, Canada. Gervais, Antoni   1980 Evaluation of the </b><b>TAUM-AVIATION </b><b>Machine</b> <b>Translation Pilot System.</b><b> Translation Bureau, Secretary of State,</b> <b>Ottawa, Canada.</b><b></b></p><p><b>Gérin-Lajoie, Robert 1980 Vérification des manipulations d'arbres en </b><b>LEXTRA. </b><b>M.Sc. thesis, Université de Montréal, Montréal, Canada.</b></p><p><b>Isabelle, Pierre; Bourbeau, Laurent; Chevalier, Monique; and Lepage, Suzanne 1978 </b><b>TAUM-AVIATION: </b><b>description d'un système de traduction automatisée de manuels d'entretien en aéronautique. COL1NG-78, Bergen, Norway.</b></p><p><b>Isabelle, Pierre 1981 Some Views on the Future of the </b><b>TAUM </b><b>Group and the </b><b>TAUM-AVIATION </b><b>System. Groupe </b><b>TAUM, </b><b>Université de Montréal, Montréal, Canada.</b></p><p><b>Isabelle, Pierre 1985 Machine Translation at the </b><b>TAUM </b><b>Group, In: King, Margaret, Ed., <i>Machine Translation: the State of the Art. </i>Edin­burgh University Press, Edinburgh.</b></p><p><b>Kimball, John 1973 Six or Seven Principles of Surface Structure Pars­ing in Natural Language, Indiana University Linguistics Club, Bloomington.</b></p><p><b>Kittredge, Richard   1983   Sublanguage-Specific Computer Aids to</b> <b>Translation:</b><b> A Survey of the Most Promising Application Areas.</b></p><p><b>Translation Bureau, Secretary of State, Ottawa, Canada. Kittredge, Richard et al. 1973 </b><b>TAUM-73. </b><b>Groupe </b><b>TAUM, </b><b>Université de</b></p><p><b>Montréal, Montréal, Canada. Kittredge, Richard; Bourbeau, Laurent; and Isabelle, Pierre 1976</b> <b>Design and Implementation of a French Transfer Grammar.</b><b></b></p><p><b>COLING-76, Ottawa, Canada. Kittredge, Richard and Lehrberger, John  1982 <i>Sublanguage: Studies</i></b> <b><i>of Language in Restricted Semantic Domains.</i></b><b><i> </i>Walter de Gruyter,</b> <b>New York.</b><b></b></p><doubt alpha="66.2" length="68" tooSmall="False" monospace="0.0">Lehrberger,  John     1981     Possibilités  d'extension  du système</doubt><p><b>TAUM-AVIATION.     </b><b>Groupe </b><b>TAUM,  </b><b>Université  de Montréal,</b></p><p><b>Montréal, Canada. Lehrberger, John   1982  Automatic Translation and the Concept of</b></p><doubt alpha="66.7" length="126" tooSmall="False" monospace="0.0">Sublanguage. In: Kittredge and Lehrberger (1982): 81-106. Petrick, Stanley 1973 Transformational Analysis. In: Rustin, R. Ed.,</doubt><p><b><i>Natural Language Processing. </i>Algorithmic Press: 27-41. Stewart, Gilles   1975   Le langage de programmation </b><b>REZO. </b><b>M.Se.</b></p><p><b>thesis, Université de Montréal, Montréal, Canada. Stewart, Gilles  1978  Spécialisation et compilation des </b><b>ATN: REZO.</b></p><p><b>COLING-78, Bergen, Norway. Woods, William A. 1970 Transition Network Grammars for Natural</b> <b>Language Analysis.</b><b> <i>Communications of the ACM </i>13(10): 591-606.</b></p><page local="10" global="27"/><p><b>input text:</b></p><p><b>HYDRAULIC PRESSURE IN-LINE RELIEF VALVE</b> 30 Identical interchangeable hydraulic pressure in-line relief valves (in-line relief valve) are provided for each ac hydraulic pump and for the dc hydraulic pump. The in-line relief valves are located in the hydraulic service center. Those for the No. 1, No. 1A, and No. IB ac and dc hydraulic pumps are on the left side next to the No. 1 service centre assembly. The in-line relief valve for the No. 2 ac hydraulic pump is incorporated in the No. 2 service centre assem­bly.</p><doubt alpha="50.0" length="26" tooSmall="False" monospace="0.0">(See figures 2-4 and 2-5.)</doubt><p>31 The in-line relief valves are poppet-type, spring-loaded to the closed position. A pressure of 3450 psi impinging on the poppet is suffi­cient to overcome the opposing spring force, and the poppet will move from its knife-edge seat.</p></references><appendix title="Appendix"><p><b>raw machine output:</b></p><p><b>CLAPET DE DECHARGE INCOR­PORE DE PRESSION HYDRAU­LIQUE</b> 30 <b><i>Des </i></b>clapets de décharge incorporés interchangeables iden­tiques de pression hydraulique (clapets de décharge incorporés) sont prévus pour chaque pompe hydraulique ca et pour la pompe hydraulique ce. Les clapets de décharge incorporés sont situés dans le compartiment hydraulique. Ceux <b><i>des </i></b>pompes hydrauliques ca et ce no 1, no 1A et no 1B sont du côté gauche à côté du bloc collec­teur no 1. Le clapet de décharge incorporé pour la pompe hydrau­lique ca no 2 est intégré au bloc collecteur no 2.</p><doubt alpha="53.3" length="30" tooSmall="False" monospace="0.0">(Voir les figures 2-4 et 2-5.)</doubt><p>31 Les clapets de décharge incorporés, <b><i>du type </i></b>champignon, sont rappelés par ressort à la posi­tion fermée. Une pression de 3450 psi s'exerçant sur le clapet-champig­non est suffisante pour vaincre la force de rappel du ressort et le clapet-champignon <b><i>s'écartera </i></b>de son siège en couteau.</p><p><b>HUMAN REVISION:</b></p></appendix></body></article>