Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 11: Parsing with Unification Grammars Heshaam Faili University of Tehran.

Similar presentations


Presentation on theme: "Chapter 11: Parsing with Unification Grammars Heshaam Faili University of Tehran."— Presentation transcript:

1 Chapter 11: Parsing with Unification Grammars Heshaam Faili hfaili@ece.ut.ac.ir University of Tehran

2 2 Overview Feature Structures and Unification Unification-Based Grammars Chart Parsing with Unification-Based Grammars Type Hierarchies

3 3 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)

4 4 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  NP 3,sg However, when the values are complex, it is more expressive than a CFG  can represent more linguistic phenomena

5 5 An Example for FS

6 6 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

7 7 FS with shared value

8 8 Feature structures as graphs Technically, feature structures are directed acyclic graphs (DAGs) So, the feature structure represented by the attribute-value matrix (AVM): [cat NP agreement [number sg person 3]] is really the graph: CAT AGR    NUM PER   sg 3 np

9 9 Unification 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]

10 10 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]]]

11 11 Unification with Reentrancies Remember that structure-sharing means they are the same object: [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]]]

12 12 Unification with Reentrancies (cont.) And remember that having similar values is not the same as structure- sharing: [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]]]

13 13 Subsumption 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)

14 14 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

15 15

16 16

17 17

18 18 Overview Feature Structures and Unification Unification-Based Grammars Chart Parsing with Unification-Based Grammars Type Hierarchies

19 19 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 = 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., = is an illegal equation for the above rule! (But it would be fine for NP  Det Nom)

20 20 Agreement in Feature-Based Grammars S  NP VP = VP  V NP = NP  Det Nom(inal) = Nom  Noun = Noun  flights = pl Compare with the CFG case: S  3sgNP 3sgVP S  PluralNP PluralVP 3sgVP  3sgVerb 3sgVP  3sgVerb NP 3sgVP  3sgVerb NP PP 3sgVP  3sgVerb PP etc.

21 21 Percolating Agreement Features S  NP VP = VP  V NP = NP  Det Nom = Nom  Noun =

22 22 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 = Knowing the head will tell you about the whole phrase This is important for many parsing techniques

23 23 Sub-categorization We could specify subcategorization like so: VP  V = intrans VP  V NP = trans VP  V NP NP = 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.

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

25 25 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] He asked [ NP her] [ NP a question]

26 26 Long-Distance Dependencies TOP (fill gap): S  WH-word Be-copula NP = MIDDLE (pass gap): NP  D Nom = Nom  Nom RelClause = RelClause  RelPro NP VP = BOTTOM (identify gap): VP  V = What is the earliest flight that you have _? S Wh-wdBe-copulaNP DNom RelClause RelProNPVP V [gap *1] [head *1] [gap *1] [subcat ]

27 27 Overview Feature Structures and Unification Unification-Based Grammars Chart Parsing with Unification-Based Grammars Type Hierarchies

28 28 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

29 29 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], DagS The predictor, scanner, and completer have to pass in the DAG, so all three operations have to be altered

30 30 Earley Chart Parser with Unification

31 31 Predictor The predictor starts with the DAG from the context- free rule S  NP VP = PREDICTOR: S   NP VP, [0,0], dagS where dagS is [S [head *1] NP [head [agr *2]] VP [head *1[agr *2]]]

32 32 Completer The completer combines two rules and unifies the two feature structures associated with them … COMPLETER: When an NP is completed, the DagS will get updated: S  NP  VP, [0,1], DagS where DagS is now: [S [head *1] NP [definite yes head [lex students agr *2[num pl]]] VP [head *1 [agr *2]]]

33 33 Predictor, Scanner, Completer

34 34 Unify States

35 35 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.

36 36 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].

37 37 Overview Feature Structures and Unification Unification-Based Grammars Chart Parsing with Unification-Based Grammars Type Hierarchies

38 38 Using Type Hierarchies Instead of simple feature structures, formalisms like Head-Driven Phrase Structure Grammar (HPSG) use typed feature structures Two problems right now: What prevents us right now from specifying the following? 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

39 39 Type Systems 1. Each feature structure is labeled by a type. [noun 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.

40 40 Simple Type Hierarchy

41 41 Type Hierarchy So, if CASE is appropriate for noun, and the value of CASE is case, and we have the following type hierarchy case nom acc dat Then, the following are possible feature structures: [noun[noun[noun CASE nom] CASE acc][CASE dat]

42 42 Unification of types Now, when we unify feature structures, we have to unify types, too: [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 obj Then, we have the following unification: [CASE acc] U [CASE dat] = [CASE obj]

43 43 Practices 11.2, 11.7, 11.8


Download ppt "Chapter 11: Parsing with Unification Grammars Heshaam Faili University of Tehran."

Similar presentations


Ads by Google