File Information

File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/90/j90-3004_metho.xml

Size: 8,030 bytes

Last Modified: 2025-10-06 14:12:39

<?xml version="1.0" standalone="yes"?>
<Paper uid="J90-3004">
  <Title>DISJUNCTION WITHOUT TEARS</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Two USES OF DISJUNCTION
</SectionTitle>
    <Paragraph position="0"> The kind of representation in Figure 1 is appropriate when some specific piece of information about some item is known--in Figure 1, for instance, the fact that the word in question is a present participle. It often happens, however, that we know that some item can be described in several ways, but that we are not sure which is correct in the present circumstances. Consider for instance the word provided. This might be a past tense form, or a past participle, or a passive participle. There is nothing about the word itself that can help us decide which it is, though in any actual context only one of these descriptions will be appropriate.</Paragraph>
    <Paragraph position="1">  (1) He provided us with everything we needed.</Paragraph>
    <Paragraph position="2"> (2) He has provided us with everything we needed.</Paragraph>
    <Paragraph position="3"> (3) Everything we needed has been provided.</Paragraph>
    <Paragraph position="4">  We could produce three descriptions of the kind in Figure 1, one for each case. If we did this, however, we would find ourselves repeating all sorts of information--the fact that it's a verb, for instance, plus whatever we know about its subcategorization frame, and so on. It is therefore tempting to try to adapt our notation so that it allows disjunctive specifications for feature values, as shown in Figure 2. Figure 2 represents a description of an item that is either a past tense verb or a past or passive participle, with the curly bracket {used to indicate a range of options. This kind of Computational Linguistics Volume 16, Number 3, September 1990 171 Allan Ramsay Disjunction without Tears</Paragraph>
    <Paragraph position="6"> Figure I Present Participle, e.g. providing* disjunctive specification is widespread in unification grammer--the curly bracket, for instance, is standard notation in FUG, and most other notations provide some way of talking about disjunction. Kasper and Rounds (1986), among others, have taken up the question of exactly what such notations mean. We are more interested here in investigating the circumstances under which they are really necessary, and in trying to remove them wherever we can.</Paragraph>
    <Paragraph position="7"> Much the same sort of issue arises when we consider syntactic rules, particularly when we consider rules representing information about subcategorization frames. Consider, for instance, the interpretation of the verb be as an auxiliary. Be, as an auxiliary, can be combined with either a VP whose main verb is a present participle or one whose main verb is a passive participle. We might try to represent this information with the rule shown in Figure 3. Figures 2 and 3 are very perspicuous. Figure 2 describes a word that is a past tense verb, a past participle, or a passive participle. Figure 3 describes a grammatical constraint, namely that be may be followed by a VP whose main verb is either a present participle or a passive one. The placeholder ?H is used to indicate that the form of the VP that results from combining an instance of be with a suitable complement has the same HEAD features as the instance of be. Unfortunately, the introduction of disjunctions into our descriptions has drastic effects on the computational properties of unification, particularly when it is combined with the use of placeholders or other ways of specifying reentrance. To see this, suppose we want to see whether some VP whose main verb has the properties ascribed to provided fits the constraints imposed by be (in other words, we are trying to</Paragraph>
    <Paragraph position="9"/>
    <Paragraph position="11"/>
    <Paragraph position="13"> We will have to try various possibilities--is</Paragraph>
    <Paragraph position="15"> and so on. Eventually we will compare the part of the description of solved that says it might be a passive participle with the part of the rule that says that a VP whose main verb is a passive participle is acceptable here. At this point we will realize that the given text fits the rule, but only after trying out numerous options that led nowhere.</Paragraph>
    <Paragraph position="16"> Worse than this, there may be several locally compatible sets of options, only one of which may lead to a globally coherent description of the complete text being examined.</Paragraph>
    <Paragraph position="17"> If this is a possibility then the process of unifying two structures turns out to be NP-complete, a most undesirable consequence of our decision to allow disjunctive feature descriptions.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 EXTRA CONSTRAINTS
</SectionTitle>
    <Paragraph position="0"> If we look again at the descriptions in Figures 2 and 3 we see that we know rather more about the FORM part of these descriptions than is explicitly stated. In particular, we know that the FORM of any verb whatsoever is drawn from the range of options shown in Figure 4. Given this extra information, we see that a disjunctive description such as the one we have been using for provided can be replaced by a conjunctive one containing nothing but negative information. The descriptions of the FORM of the lexical item provided and the complement of be, for instance, can be replaced by the following purely conjunctive descriptions:</Paragraph>
    <Paragraph position="2"> The equivalence depends on the fact that in any specific case FORM has exactly one of the values given in Figure 4.</Paragraph>
    <Paragraph position="4"> If we know what values it doesn't have, we can infer the range that the value it does have must be drawn from.</Paragraph>
    <Paragraph position="5"> When we attempt to unify these two specifications, we find that they lead to the following more precise description:</Paragraph>
    <Paragraph position="7"> The only way for this to be compatible with the general constraint that the value of FORM must be drawn from the values in Figure 4 is if it is in fact a passive participle. We have obtained the required effect without complicating our unification algorithm, simply by making use of the extra information that the value in question must be drawn from a known finite range. Note that we do not need to refer explicitly to the information in Figure 4 when we want to know whether two specifications for FORM are compatible. Rather we have used this information to construct our specifications, which can be compared directly using ordinary unification.</Paragraph>
    <Paragraph position="8"> Many of the situations that seem to call for disjunctive descriptions can be dealt with this way. The NP the sheep could be either third person singular or third person plural? Then describe it as not first person singular or first person plural or second person singular or second person plural.</Paragraph>
    <Paragraph position="9"> The pronoun he is nominative, whereas it may be either nominative or accusative? Then describe he as not accusative, and say nothing about it. When we can replace disjunctive descriptions by ones that embody a conjunction of negations, we can save a considerable amount of work, since our unification algorithm no longer needs to plod through a series of possible analyses, keeping track of the options that have been tried and possibly backtracking when some analysis that looked plausible leads to a dead end. We cannot hope to eliminate disjunction from our grammar entirely, since if we could then parsing would become a trivial deterministic task, which it does not look like becoming. We can, however, eliminate it in a lot of places where it looks as though it would be useful; which doesn't make parsing a trivial task, but it does mean that we can avoid doing more work than we really need.</Paragraph>
  </Section>
class="xml-element"></Paper>
Download Original XML