Document Sample
Unification Powered By Docstoc

               LING 362
              Intro to NLP
Page 1
        Feature Structures and

        Unification-Based Grammars

        Chart Parsing with Unification-
         Based Grammars
        Type Hierarchies

Page 2
Feature structures
    We had a problem adding agreement to CFGs.         What we needed
         were features, e.g., a way to say:
           - [number sg
             person 3 ]
    A structure like this allows us to state properties, e.g., about a
         noun phrase
           - [cat NP
             number sg
             person 3 ]
    Each feature (e.g., „number‟) is paired with a value (e.g., „sg‟)
           - A bundle of feature-value pairs can be put into an
             attribute-value matrix (AVM)
Page 3
Feature paths
    Values can be atomic (e.g. „sg‟ or „NP‟ or „3‟), or can be complex,
         and thus we can define feature paths
         [cat NP
          agreement [number sg
                       person 3]]
    The value of the path [agreement number] is „sg‟
    A grammar with only atomic feature values can be converted to
         a CFG.
          - e.g. AVM on previous page  NP3,sg
          - However, when the values are complex, it is more
            expressive than a CFG  can represent more linguistic
Page 4
Reentrancy (structure-sharing)
    Feature structures embedded in feature structures can share
         the same values
    That is, two features have the exact same value—they share
         precisely the same object as their value
          - we‟ll indicate this with a tag like *1
          [cat S
           head [agr *1[num sg
                           per 3]
                   subj [agr *1 ]]]
    In this example, the agreement features of both the matrix
         sentence and the embedded subject are identical
    This is referred to as reentrancy
Page 5
Feature structures as graphs
    Technically, feature structures are directed acyclic graphs
    So, the feature structure represented by the attribute-value
         matrix (AVM):
         [cat NP
          agreement [number sg
                     person 3]]
    is really the graph:
             CAT         np        sg
                            NUM
               AGR           PER
                                   3
Page 6
    Unification (U) = a basic operation to merge two feature
         structures into a resultant feature structure (FS)
    The two feature structures must be compatible, i.e., have no
         values that conflict
    Identical FSs:
          - [number sg] U [number sg] = [number sg]
    Conflicting FSs:
          - [number sg] U [number pl] = Fail
    Merging with an unspecified FS:
          - [number sg] U [number []] = [number sg]

Page 7
Unification (cont.)
    Merging FSs with different features specified:
         - [number sg] U [person 3] = [number sg
                                      person 3]
    More examples:
         - [cat NP] U [agreement [number sg]] =
                                         [cat NP
                                         agreement [number sg]]
         - [agr [num sg]
           subj [agr [num sg]]]      U     [subj [agr [num sg]]]=
                                  [agr [num sg]
                                  subj [agr [num sg]]]
Page 8
Unification with Reentrancies
    Remember that structure-sharing means they are the same
   [agr *1[num sg    U   [subj [agr [per 3
           per 3]                    num sg]]]
    subj [agr *1]]
                            = [agr *1[num sg
                                      per 3]
                               subj [agr *1]]
    When unification takes place, shared values are copied over:
   [agr *1           U   [sub [agr [per 3
    subj [agr *1]]                  num sg]]]
                             =[agr *1
                               subj [agr *1[per 3
                                              num sg]]]

Page 9
Unification with Reentrancies (cont.)
    And remember that having similar values is not the same as
   [agr [num sg]           U   [sub [agr [per 3
    subj [agr [num sg]]]                  num sg]]]
                                    = [agr [num sg]
                                      subj [agr [per 3
                                                 num sg]]]
    With structure-sharing, you have to make sure the values are
     compatible everywhere that structure-sharing is specified
   [agr *1[num sg U [agr [num sg
           per 3]             per 3]           = Fail
    subj [agr *1]]       subj [agr [num pl
                                      per 3]]]

Page 10
    We can see that a more general feature structure (less values
      specified) subsumes a more specific feature structure
          (1) [num sg]
          (2) [per 3]
          (3) [num sg
              per 3]
    So, we have the following subsumption relations, where
          - (1) subsumes (3)
          - (2) subsumes (3)
          - (1) does not subsume (2), and (2) does not subsume (1)

Page 11
Implementing Unification
    How do we implement a check on unification?
          - i.e., given feature structures F1 and F2, return F, the
            unification of F1 and F2
    Unification is a recursive operation:
          - If a feature has an atomic value, see if the other FS has
            that feature with the same value
              [F a] unifies with [], [F ], and [F a]
          - If a feature has a complex value, follow the paths to see if
            they‟re compatible and have the same values at bottom
              Does [F G1] unify with [F G2]? We have to inspect G1
               and G2 to find out.
    To avoid cycles, we have to do an occur check to see if we‟ve
      seen a FS before or not
Page 12
      Feature Structures and

      Unification-Based Grammars

      Chart Parsing with Unification-
       Based Grammars
      Type Hierarchies

Page 13
Grammars with Feature Structures

   CFG skeleton augmented with feature structure path
    equations, i.e., each category has a feature structure
   CFG skeleton
     S  NP VP
   Path equations
    <NP agreement> = <VP agreement>

    1. There can be zero or more path equations for each rule
       skeleton  no longer atomic
    2. When a path equation references constituents, they can only
       be constituents from the CFG rule
       e.g., <D agreement> = <Nom agreement> is an illegal equation
Page 14
          for the above rule! (But it would be fine for NP  Det Nom)
Agreement in Feature-Based Grammars
                                        Compare with the CFG case:
   <S head> = <VP head>
   <NP head agr> = <VP head agr>         S  3sgNP 3sgVP
                                         S  PluralNP PluralVP
   <VP head> = <V head>                  3sgVP 3sgVerb
                                         3sgVP  3sgVerb NP
NP  Det Nom(inal)
   <NP head> = <Nom head>                3sgVP  3sgVerb NP PP
   <Det head agr> = <Nom head agr>
                                         3sgVP  3sgVerb PP
Nom  Noun                           etc.
  <Nom head> = <Noun head>

Noun  flights
  <Noun head agr num> = pl
Page 15
Percolating Agreement Features
   <NP head agr> = <VP head agr>


   <VP head> = <V head>

NP  Det Nom

   <NP head> = <Nom head>

   <Det head agr> = <Nom head agr>

Nom  Noun
   <Nom head> = <Noun head>

Page 16
Head features in the grammar
    An important concept shown in the previous rules is that heads
      of grammar rules share properties with their mothers
          - VP  V NP
             <VP head> = <V head>
    Knowing the head will tell you about the whole phrase
          - This is important for many parsing techniques

Page 17
    We could specify subcategorization like so:
          - VP  V
             <VP head subcat> = intrans
          - VP  V NP
             <VP head subcat> = trans
          - VP  V NP NP
             <VP head subcat> = ditrans
    But values like „intrans‟ do not correspond to anything that the
      rules actually look like
    To make SUBCAT better match the rules, we can make it a list
      of a verb‟s arguments, e.g. <NP,PP>

Page 18
Handling Subcategorization
     <VP head> = <Verb head>
     <VP head subcat> = <NP,PP>
 V  leaves
                                                      [head: *1[subcat < *2, *3> ]]
     <V head agr num> = sg                             VP
     <V head subcat> = <NP,PP>

 There is also a longer, more
    formal way to specify                   V           NP          PP
    lists:                               leaves      [cat *2]     [cat *3]
                                  [head: *1[agr [num sg]
 <NP,PP> is equivalent to:                  subcat < [cat np],
 [FIRST NP                                           [cat pp] >
           REST = <>]]

Page 19
Subcategorization frames
    Subcategorization, or valency, or dependency is a very
      important notion in capturing syntactic regularity
    And there is a wide variety of arguments that a verb (or noun
      or adjective) can take.
    Some subcategorization frames for ask:
          - He asked [Q “What was it like?”]
          - He asked [S[wh] what it was like]
          - He asked [NP her] [S[wh] what it was like]
          - He asked [VP[to] to see you]
          - He asked [NP her] [VP[to] to tell you]
          - He asked [NP a question]

Page 20
          - He asked [NP her] [NP a question]
Long-Distance Dependencies
 TOP (fill gap):
                                           What is the earliest flight that you
 S  WH-word Be-copula NP                    have _?
     <NP gap> = <WH-word head>

 MIDDLE (pass gap):                           S
                                        Wh-wd Be-copula           NP [gap *1]
 NP  D Nom
                                       [head *1]
     <NP gap> = <Nom gap>
                                                   D         Nom [gap *1]
 Nom  Nom RelClause
                                                                        [gap *1]
                                                       Nom         RelClause
     <Nom gap> = <RelClause gap>

 RelClause  RelPro NP VP                          RelPro    NP       VP [gap *1]
     <RelClause gap> = <VP gap>
 BOTTOM (identify gap):                                [subcat <NP, *1>]
 VP  V

Page 21     gap> = <V subcat second>
      Feature Structures and

      Unification-Based Grammars

      Chart Parsing with Unification-
       Based Grammars
      Type Hierarchies

Page 22
Modifying a Chart Parser to handle Unification
    Our grammar still has a context-free backbone, so we could
      just parse a sentence with a CFG and use the features to filter
      out the ungrammatical sentences

    But by utilizing unification as we parse, we can eliminate parses
      that won‟t work in the end
    e.g., we‟ll eliminate NPs that don‟t match in agreement features
      with their VPs as we parse, instead of ruling them out later

Page 23
Changes to the Chart Representation
    Each state will be extended to include the LHS DAG (which
      can get augmented as it goes along).
    i.e., Add a feature structure (in DAG form) to each state
          - So, S   NP VP, [0,0]
          - Becomes S   NP VP, [0,0], Dag

    The predictor, scanner, and completer have to pass in the
      DAG, so all three operations have to be altered

Page 24
    The predictor starts with the DAG from the context-free rule
    S  NP VP
          <S head> = <VP head>
          <NP head agr> = <VP head agr>

          S   NP VP, [0,0], Sdag
          where Sdag is
            [S [head *1]
            NP [head [agr *2]]
            VP [head *1[agr *2]]]
Page 25
   The most important change is the COMPLETER step:

   procedure COMPLETER ((B   , [j, k], dagB))
     foreach (A    B , [i, j], dagA) in chart [j] do
          if dagAB <- unify-states(dagB, dagA, B)  fail then
             enqueue ((A  B  , [i, k], dagAB), chart[k])

Page 26
 The completer combines two rules and unifies the two feature
  structures associated with them …

 When an NP is completed, the Sdag will get updated:
    S  NP  VP, [0,1], Sdag
    where Sdag is now:
      [S [head *1]
          NP   [definite yes
                head [lex students
                      agr *2[num pl]]]
          VP   [head *1 [agr *2]]]

Page 27
Change to ENQUEUE
    The enqueue procedure should also be changed to use a
      subsumption test:
          - Do not add a state to the chart if an equivalent or more
            general state is already there.
          - So, if Enqueue wants to add a singular determiner state at
            [x, y], and the chart already has a determiner state at [x,
            y] unspecified for number, then Enqueue will not add it.

   procedure ENQUEUE (state, chart-entry)
      if state is not subsumed by state in chart-entry then
          Push(state, chart-entry)
Page 28
Why a Subsumption Test?
    If we don't impose a subsumption restriction, enqueue will add
      two states at [x, y], one expecting to see a singular
      determiner, the other just a determiner.
          - On seeing a singular determiner, the parser will advance
            the dot on both rules, creating two edges (since singular
            will unify with both singular and with unspecified).
          - As a result, we would get duplicate edges.
    If we impose the restriction, and we see either a single or
      plural determiner, and we advance the dot, only one edge
      (singular or plural) gets created at [x, y].

Page 29

         Feature Structures and

         Unification-Based Grammars

         Chart Parsing with Unification-
          Based Grammars
         Type Hierarchies

Page 30
Using Type Hierarchies
    Instead of simple feature structures, formalisms like Head-
      Driven Phrase Structure Grammar (HPSG) use typed feature
    Two problems right now:
          - What prevents us right now from specifying the following?
           <number feminine>
          - How can we capture the fact that all values of NUMBER
            are the same sort of thing, i.e., make a generalization?

    Solution: use types

Page 31
Type Systems
    1. Each feature structure is labeled by a type.
          CASE case]
    2. Each type has appropriateness conditions specifying what
      features are appropriate for it.
          - noun  [CASE case]
          - verb  [VFORM vform]
    3. Types are organized into a type hierarchy.
    4. Unification is modified to allow two different types to unify.

Page 32
Type Hierarchy
    So, if
          - CASE is appropriate for noun, and
          - the value of CASE is case, and
          - we have the following type hierarchy

      nom acc dat
    Then, the following are possible feature structures:
          [noun                [noun               [noun
          CASE nom]             CASE acc]          [CASE dat]

Page 33
Unification of types
    Now, when we unify feature structures, we have to unify types,
          [CASE case] U [CASE nom] = [CASE nom]
          [CASE nom] U [CASE acc] = fail

    Let‟s also assume that acc and dat have a common subtype, obj
             acc dat

    Then, we have the following unification:
          [CASE acc] U [CASE dat] = [CASE obj]
Page 34