<?xml version="1.0" standalone="yes"?>
<Paper uid="C88-1004">
  <Title>A MODEL FO\](~ 'DIL~SFER CONTROL IN THE METAL MT-SYS'rEM</Title>
  <Section position="2" start_page="19" end_page="21" type="abstr">
    <SectionTitle>
3.- Basic Definitions.
</SectionTitle>
    <Paragraph position="0"> In this section there follows a number of definitions which will be used throughout the rest of the paper.</Paragraph>
    <Paragraph position="1"> 3.1.- Local tree.</Paragraph>
    <Paragraph position="2"> A local tree is a part of a structural description which is currently being dealt with by the particular rule which is under consideration. For example, given an analysis tree of the form</Paragraph>
    <Paragraph position="4"> in which the number between \[\] indicates (for reference) the rule which has built this particular node, the local tree when rule \[2\] is applied would be: /No{2\]  the current local tree, the Head Node is the controller node. Otherwise, the Head Node must be egplicitely stated for each particular tree structure, normally being the X(BAR-I) child node, in a local tree d~inated by a root node X(BAR) Notice that this definition of Head Node has been tailored ad-hoc for this model end deviates considerably fro~ the traditional notion of Head in the X-bar theory, for instance.</Paragraph>
    <Paragraph position="5"> Dependent Node \[DN\]: A child node of the local tree which is controlled bya ~, Free Node \[FN\]: A child node of the local tree which is not controlled by any HN.</Paragraph>
    <Paragraph position="6">  NC~J~/S \[DN\] within a local tree if in order for the DN/4 to be properly transferred, It/they must have a set of f-v-pairs whose particular values are to be updated with those values borne by the HN after this n~i~3 has been transferred.</Paragraph>
    <Paragraph position="7"> Bad:really, our notion of Control coincides with the one given by the GKPS \[Gazder 85\]. Control is a language-dependent relationship between nodes, in which there is a controller node and one or more contgullee node/s, which ultimately subsumes the concept of agreement (subject-predicate, noun-adjective, etc.). In the Transfer Process, nodes which are controllers must be transferred prior to their controlleas, in order to ensure the right agreement b~tween them in the target language.</Paragraph>
    <Paragraph position="8"> Not:.~cs that a local tree may present different types of Control l~pendences (see Fig. I), with one Dependent Node (the NP\[2\] z~ode below, dominating a local tree where the NO node controJ.s the DET node for Gender and Number), with two Dependent Nodes (the CLS node dominating a local tree where the NP\[$SUBJ\] controls both the PRED node for Person and NumSer and the ~DJ node for Gender and Number), or no Dependent Nodes at all (the PP node dominating a local, tree where neitht,r the NP node nor the PREP nodes control each</Paragraph>
    <Paragraph position="10"> Given a local tree, consisting of a Root Node a.</Paragraph>
    <Paragraph position="11"> one or more child nodes (including a Bead Node, and possibly one or more Dependent Nodes, and one or more Free Nodes), we can split the local Transfer Process sequence of  the Root Node dominating the local tree into three steps: * Transfer the Bead Node.</Paragraph>
    <Paragraph position="12"> * Copying the Control Features (CFs) set from the already transferred Head Node into the Dependent Node/s {if any).</Paragraph>
    <Paragraph position="13"> * Transfer the Dependent Node/s, and the Free Node/s (if any).</Paragraph>
    <Paragraph position="14"> 4.- General Information to be Supplied to the System DB  Basically, three types of information must be stored into the system DB end used later on by the Transfer Process. Physically, this information is implemented in form of a LISP list, although this is purely a parochial progra~ing decision.</Paragraph>
    <Paragraph position="15"> 4.1.- HEAD Feature List \[HFL\]: It contains information stating which f-v-pairs are considered to be members of the set HEAD. The decision of which f-v-pairm must be HFPSD members is crucial to the model. In a first approach, we will adopt a pragmatical criterion. This means that we will include as HEAD features those f-v-pairs which are currently percolated in the corresponding gules, and which we make sure are actually needed for the Transfer Process.</Paragraph>
    <Paragraph position="16"> However, the aim is to extrapolate from this first approach a (maybe language-dependent) theoretical hypothesis about HEAD Features which enables to state a general criterion to establish the HF membership.</Paragraph>
    <Paragraph position="17">  4.2.- Lcxieal Access Table |LkT\]: It contains L~/~GUAGE-DEPENDENT information stating which sets of f-v-pairs (Lsxical Access Features \[LAF\]) are needed in order for each (major) Lexlcal Node to be rightly transferred. Xn METAL, Isxical nodes are transferred by calling the XLX operator in the TRANSFER p~rt of the corresponding rules. XLX takes ar~t'~ents specifying the needed target lan@uage stem retrieval information for a given category, whether an inflsxion must be attached to the stem, and the retrieval information for this inflsxion. Thus, the LAT table contains information about Lexical % Access Features, Inflexion Attachement infoz~atinn (when needed) and Inflection Lexical Access Features (ILAF). In fact, this would be quite similar to the NLX table proposed by Tommy Loomis in \[Loomis 87\].</Paragraph>
    <Paragraph position="18"> Here is a schematic example of the Lexical Access Table:</Paragraph>
    <Paragraph position="20"> In the case of VST, fo~ instance, the ~AT would indicate that, for Spanish, a Verb Stem (VST) Lexical Node must be accessed in the target monolingual lexicon database through the current values of the MD, NU, PF, Pg and TN features as keys, that a V-FLEX inflexion must bs attached to it, and that this inflexion should be accessed through the current values of CL, MD, NO, PF, PS, TN.</Paragraph>
    <Paragraph position="21"> 4~3.- Control Type Table \[CI~\]: This table contains LAN~3AG~-~DEPENDENT information stating the Control Dependences for different local trees dominated by different Root Nodes. In this table, for each possible Root Node category (RN), its corresponding Head Node (HN), Dependent Nods/8 (DN) and Control Features (CF), if any, are specified.</Paragraph>
    <Paragraph position="22"> Here is one example of three CTT entries, one for CLS ~, (with two potential Control Dependences), one for ~(one CD) and one for PP- (no CDS) dominated local trees :</Paragraph>
    <Paragraph position="24"> ~m first entry specifies that, given a local tree with a CLS root nods, its child Head Nods (HN) is the N~ child node bearing the SSUBJ value for the feature ROL, whereas the PPJZD child node always is a dependent node. The control features (CF) relevant for this structure are ~IU (number) and PS (person). Moreover, a sibling ADJ node may also be a Dependent Node, with control features GD (Gender) and NU (Number). This CTT entry controls the subject-predicate, and the subject-predlcativeadjective (in copulative sentences) agreement requirements, respectively.</Paragraph>
    <Paragraph position="25"> The same should be stated for each gra~mmtical category which may be a Root Node Of a local tree (CLS, PRED, NO, etc.).</Paragraph>
    <Paragraph position="26"> %~o things must be stressed about the CTT table: * Information about particular feature values can be given to distinguish between sategorins with the same n~s (for instance, to ensure that for the subject-predicate agreement, the controller is the ~ which bears the role of SUBJect, and not some other sibling ~).</Paragraph>
    <Paragraph position="27"> * Each CTT entry must have at lea~t a Head Node specified for each Root Node, and possibly ons nz mor~ Dependent Nodes, which may or may not be obligatory, with their corresponding control features. This accounts fo~: the possibility of having different local trees dominated by the same Root Node categoz T (the case of CLS, above).</Paragraph>
  </Section>
class="xml-element"></Paper>