File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/intro/94/c94-2202_intro.xml

Size: 3,539 bytes

Last Modified: 2025-10-06 14:05:41

<?xml version="1.0" standalone="yes"?>
<Paper uid="C94-2202">
  <Title>LEXICAL FUNCTIONS AND MACHINE TRANSLATION</Title>
  <Section position="3" start_page="1240" end_page="1241" type="intro">
    <SectionTitle>
REST {Magn(~l~)}
</SectionTitle>
    <Paragraph position="0"> Just as in the ECD the base contains a specific zone in which the collocates are listed. In our case, the feature 'COLLS' has a set of lexical entries as its value.</Paragraph>
    <Paragraph position="1"> Each collocate subentry bears the value of the lexical function in its semantics field. In this representation the lexical function is chosen as the real semantic value of the collocate. One should read the feature structure as specifying that the semantics of strong (as a collocate) is the predicate Magn(\[~).</Paragraph>
    <Paragraph position="2"> The collocate subentry only provides partial information. In fitct, it provides only the intbrmation that is specific to the occurrence of strong in its combination with criticism. In this case only the semantics is given. We further assume that the lexicon also contains a 'super-entry' which provides all the information that is shared by all the diflerent occurrences of strong.</Paragraph>
    <Paragraph position="3"> This entry is where the variable Sstrong points to. Of course, other architectures that try to avoid redundant specification of information are equally possible. For instance if one assumes a mechanism of default unification, one can have Sstrong refer to the full entry describing 'strong' in say its ordinary use, and have the values that are particular to the collocational strong overwrite the values provided in the ordinary entry, as in Mel'~uk's proposal.</Paragraph>
    <Paragraph position="4"> Collocations, Rules and Principles So far, we have not specified in what way one gets flom the lexical entries for the base and the collocate to the representation of the collocational expression.</Paragraph>
    <Paragraph position="5"> ill HPSG, tile descriptions of complex expressions arc constrained by principles. We will assume that collocations are snbject to the same constraints. The ordinary rules of combination (combining adjectives and nouns, for instance) thus account for lnost of the properties of the collocational combination. However, we are still left with the typical 'collocational restriction' which nceds to be accounted for.</Paragraph>
    <Paragraph position="6"> We havc therefore addcd a principle which says that constructions that are analysed as collocations (indi cated by tile type COLI.OCATION) are either head-adjunct structure or head-complement structures with specific rcstrietions holding between the head anti the adjunct or aNoticc that hcrc we use a simple VCl'Sion of HPSG based on (Pollard and Sag, 1987) whereas the actual ilnplmncntation was based on (Pollard and Sag, to appear).</Paragraph>
    <Paragraph position="7">  the head and the complement respectively. Let's consider the former case 4, illustrated by the heavy smoker example, The adjunct daughter will contain the adjective collocate. In such collocational constructions the collocate adjuncts have to be 'licensed' by the noun or the head daughter. This is implemented by requiring that the collocates field (C'OI,LS) of the head daughter contains a reference to a lexical entry that is compatible with the adjunct daughter. In the literal reading of an expression such as heavy smoker, the phrase will not be analysed as a COLL.OCATION and the principle does not apply.</Paragraph>
  </Section>
class="xml-element"></Paper>
Download Original XML