<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-0613">
  <Title>Nominal Metonymy Processing</Title>
  <Section position="4" start_page="94" end_page="95" type="intro">
    <SectionTitle>
3. Framework for Metonymy Processing
</SectionTitle>
    <Paragraph position="0"> The metonymy identification and resolution mechanism described here is an integral part of the overall semantic dependency structure-building process (a process that builds the interlingual meaning representation for the input text in a Machine Translation application) in our paradigm, as it is for other applications in Hobbs and Martin (1987) or Chamiak and Goldman (1988), as opposed to relegating metonymy processing to an error-recovery process, as in Fass (1986b). Because it is an integral part of the word-sense disambiguation (WSD) process, we gain efficiency and unified control, which has a high payoff because of the high prevalence of metonymy in text from real corpora. The context of this work is the MikroKosmos knowledge-based MT effort; see Onyshkevych and Nirenburg (1995) for discussion of the lexicon and other knowledge in the approach, and see Mahesh et aL (1997) for an overview of the WSD mechanism.</Paragraph>
    <Paragraph position="1"> Our approach to metonymy resolution for nominals relies on a fundamental observation about metonymy, namely that it reflects (conventional) semantic contiguity, as described in Gibbs (1993) or Jakobsen and Halle (1956). The premise of our approach is that relations in our ontology 1 coincide with the relations of semantic contiguity at some level, thus the task of the metonymy resolution/WSD process is to identify the nature of contiguity in each case by identifying the best path in the ontology from the candidate meaning of a word to a constraining concept (see Mahesh et al. (1997) for a discussion of the richness and specificity of semantic constraints in our approach, which projected an average of 15 constraints on each open-class word in our Spanish test corpus).</Paragraph>
    <Paragraph position="2"> By relying on the ontology to capture selectional restriction features (instead of the lexicon), and by making extensive use of inheritance in the ontology, we find that we can use a very wide range of features for constraining relations; in fact, any of the 7000 concepts in the ontology can serve as constraints, and eact/concept has an average of 14 constrained relations. Gibbs (1983) identifies that prior context can set up a mutually-understood local referring function: &amp;quot;any given instance of a referring function needs to be sanctioned by a body of beliefs encapsulated in an appropriate frame&amp;quot;. But there are infinite such local contexts that can generate locally-sanctioned referring functions (all the &amp;quot;ham sandwich&amp;quot; types of metonymies, for example), thus an unrestricted range of notions of contiguity. While we aren't able to fully make use of context at this stage of development, the metonymy resolution/WSD process can make use of any ontological relation or predicate (event) in establishing a metonymic link. So any of the 300+ (non-inventory) relations in the ontology can all be identified as the contiguity relation and establish the metonymic link, if they provide the most plausible explanation for an apparently necessary constraint relaxation (if describing the problem from an abductive inference perspective).</Paragraph>
    <Paragraph position="3">  1. Our meaning representation is defined in terms of concepts in an ontology; in addition to the traditional  taxonomic (IS-A) links, we have an extensive set of other relations between concepts in the ontology, selected from over 300 possible relations. Currently the ontology consists of about 7000 concept nodes, with an average of 14 (local or inherited) relations from each concept to others in the ontology. The ontology may be examined at http ://crl. nmsu. edu/Research/Vrojects/mikro/htanls/ ontology-htmls/onto, index, html. References for the ontology are also available at that site.</Paragraph>
    <Paragraph position="4">  This approach allows furl use of the relations defined in the ontology. If only the strict IS-A relations from the ontology were used, with either vertical relaxation of constraints or a relaxation utilizing a small set of topological relations over a hierarchy (such as Fass 1986, 1988), then the wealth of metonymic expressions would be unprocessable without either allowing excessive ambiguity or not recognizing numerous uninventoried examples of metonymy. The framework outlined here allows metonymic expressions to be processed by utilizing semantic constraint checking and relaxation over the full range of metonymic relations, combined with taxonomic generalization; note, however, that not all combinations of relations or arcs in the ontology identify paths of acceptable weights, that is, the arc weight mechanism allows for identifying varying degrees of acceptability of relations that comprise potential paths between filler and constraint.</Paragraph>
    <Paragraph position="5"> Our inventory of raetonymic arcs reflects the types of metonymic relations which have been identified, such as PART.OF for the Part-for-Whole metonymy, LOCATION.OF for the Place-for-Event metonymy, PRODUCTS for the Producer-for-Product metonymy, etc. Thus for each idendfied metonymy, the arc(s) is found in the ontology that reflects the metonymy in defining the path from the metonym to the constraint. For example, in he drove his V8... the constraint on what can be driven is ENGINE-PROPELLED-VEHICLE, but the candidate filler is ENGINE (ofa certain type). The part is the engine, the whole is the vehicle, and the arc from ENGINE to ENGINE-PROPELLED-VEHICLE is PART-OF; the potential filler is the metonym, and the constraint identifies what is being replaced. Thus in Producer-for-Product, a candidate filler (such as Chevrolet) has a certain relation, identified by the metonymic arc (such as PRODUCER.OF), to the constraint, which is what is being replaced (such as an automobile).</Paragraph>
    <Paragraph position="6"> Thus the metonymy-processing approach described below essentially consists of two steps: a) the application of the general constraint-satisfaction process (a graph search process over the ontology), and b) identification of the concept that was replaced by the metonym in the path returned by the graph search process.</Paragraph>
    <Paragraph position="7"> Run-time processing therefore involves finding the arc or arcs in the ontology that reflect a metonymy in the source text. Metonymic arcs would be less expensive than the rest of the unmentioned arcs, but more expensive than the weights for straightforward constraint satisfaction (i.e., IS-A and INSTANCE.OF). Yet if a straightforward constraint satisfaction path is found, the metonymic paths need not be pursued, thus not adding to the computational cost. Once a metonyrnic relation is found by the constraint satisfaction process, the metonym needs to be represented. The metonymic relation is represented by a slot on the metonym, which is filled by an instantiation of the concept that the metonyrn replaces. In other words, if Xfor-Y is the metonymy, X is the metonym actually used, and Y is what it replaces, then in addition to instantiating X (from the lexical trigger), we also instandate Y, and we connect X and Y with the metonymic arc reflecting the relation. Since every relation in the ontology has an inverse, X will have a slot FU filled by Y, and Y will have a slot FU &amp;quot;I which is frilled by X. A specific example of this appears below.</Paragraph>
    <Paragraph position="8"> The general problem of acquiring the necessary static knowledge to support this approach involves identifying the list of metonymic relations, establishing relations in the ontology to reflect these metonymic relations, and assigning weights to these arcs.</Paragraph>
    <Paragraph position="9"> For some of the metonymic relations (such as Part-for-Whole), the chaining of more than one traversals of a metonymic arc (such as the PART-OF arc) is acceptable; for others (such as Place-for-Event), we have a state-transition-table-based mechanism, but which is not described here.</Paragraph>
  </Section>
class="xml-element"></Paper>