april 2010underspecified representations1. april 2010underspecified representations2 the issue every...

April 2010 Underspecified Representations 1

UnderspecifiedRepresentations


The Issue

• Every boxer loves a woman1. Ax(BOXER(X) => Ey(WOMAN(Y) & LOVE(X,Y))

2. Ey(WOMAN(Y) & Ax( BOXER(X) =>LOVE(X,Y))

• Reading 1: every boxer has scope over or outscopes a woman

• Reading 2: a woman has scope over or outscopes every boxer

• Cause is semantic not syntactic


4 Approaches

• Do nothing

• Montague’s original method

• Robin Cooper’s stores

• Keller Storage

• Hole semantics


Do Nothing

• Is it really such a problem?• Given

1. Ax(BOXER(X) => Ey(WOMAN(Y) & LOVE(X,Y))2. Ey(WOMAN(Y) & Ax( BOXER(X) =>LOVE(X,Y))

Couldn’t we just choose the weaker reading and argue that because that is entailed by the stronger reading, it is the ‘real’ reading?Then a method would be to always generate the weakest reading and construct the stronger reading via pragmatics

• Which is the weaker reading?


The Problem

• Every owner of a hash bar gives every criminal a big kahuna burger

• There are 18 readings1. Ax((Ey(HBAR(y) & OF(x,y)) & OWNER(x)) => Az(CRIM(x) => Eu(BKB(u) &

GIVE(x,z,u))))2. Ax(CRIM(x) => Ay((Ex (HBAR(z) & OF(y,z)) & OWNER(y)) => Eu(BKB(u) &

GIVE(y,x,u))))3. [..]18. Ex(BKB(x) & Ay(CRIM(y) => Ex(HBAR(z) & Au((OF(u,z) & OWNER(U) =>

VIVE(u,y,x))))

• Some of these are logically equivalent, namely {1,2}, {8,9}, {6,7}, {10,11}, {13,14,16,17}

• If we take these equivalences into account there are 11 distinct readings

• Moreover if we examine these readings closely we discover they are partitioned into two distinct groups


Groups of Readings

{13,14,15,16}

{12} {15} {18}

{10.11} {6,7}

{5}

{8,9}

{4} {3}

{1,2}

NB arrows represent logical implication


Doing Nothing: The Problem

• In general there may not be a unique weakest reading

• Even when a weakest reading does exist, there is no guarantee that it will be generated by the methods discussed so far.

• Even in the simple case presented first, semantic construction generated by the parse tree yields the stronger reading


Montague’s Approach

• Motivated in part by quantifier scope ambiguities Montague had introduced quantifier raising

• Instead of directly combining syntactic entities with the quantifying NP, we are permitted to introduce an “indexed pronoun” and combine the syntactic entity with it.

• Such indexed pronouns are placeholders for the quantifying NPs

• When this placeholder has moved high enough in the tree to give the scoping we want, we replace it by the quantifying NP of interest.


Every boxer loves her-3 (S)Ax(BOXER(x) => LOVE(x,z3)

Every boxer (NP)u.Ax(BOXER(x) => u@x)

loves her-3 (VP)y.LOVE(y,z3)

loves (TV)v.y.([email protected](y,x))

her-3 NPw.(w@z3)

a woman

Parse Tree with Logical Forms


Placeholder Pronouns

• Key point: this tree is totally normal• Instead of combining loves with the quantifying

term a woman we have combined it with the placeholder pronoun her-3.

• her-3 has a semantic representation which is familiar – just like a proper noun except that the name is an indexed variable instead of a constant

• [her-3] = w.(w@z3)• [vincent] = w.(w@vincent)


Next Step

• Aim: a woman must outscope every boxer• By using the placeholder pronoun, we have so

far delayed introducing a woman into the tree.• Now we introduce it using the following rule:• Given a quantifying NP (a woman) and a

sentence containing a placeholder pronoun (every boxer loves her-3), we can construct a new sentence by substituting the QNP for the placeholder.

• i.e. we can extend the previous tree as follows


Extending the Tree

Every boxer loves a woman (S)

a woman (NP)u.Ey(WOMAN(y)& u@y)

Every boxer loves her-3 (S,3)Ax(BOXER(x) => LOVE(x,z3)

previoustree


Getting the Semantics to Work (1)

u.Ey(WOMAN(y)& u@y) @ Ax(BOXER(x) => LOVE(x,z3))

Ey(WOMAN(y)& Ax(BOXER(x) => LOVE(x,z3)) @y)[stop]

• The problem is that if we apply a woman to every boxer loves her3 directly, no further reduction is possible.

• We need to perform lambda abstraction over every boxer loves her3, i.e. from– Ax(BOXER(x) => LOVE(x,z3)) to z3.Ax(BOXER(x) => LOVE(x,z3)) to


Getting the Semantics to Work (2)

u.Ey(WOMAN(y)& u@y) @ z3.Ax(BOXER(x) => LOVE(x,z3))

Ey(WOMAN(y)& z3.Ax(BOXER(x) => LOVE(x,z3)) @y)

Ey(WOMAN(y)& Ax(BOXER(x) => LOVE(x,y)))

[stop - success]


This is a solution, but ….

• Although this is a solution of a kind we had to modify the grammar in order to introduce, and then eliminate the placeholder pronoun.

• Bad use of syntax to control semantics

• Situation worsens (more rules required) to handle, e.g., interaction between negation and quantifier scope ambiguities.


Cooper Storage

• Technique invented by Robin Cooper to handle quantifier scope ambiguities

• Key idea is to associate each node of the parse tree with a store containing– core semantic representations– quantifiers associated with lower nodes

• Scoped representations are generated after the sentence is parsed.

• The particular scoping generated depends on the order in which quantifiers are retrieved from the store


The Store

• A store is an n-place sequence– first item is always the core semantic

representation i.e. a -expression F– subsequent items are pairs (B,i) where B is

the semantic representation of an NP (another -expression and i is an index which picks out a certain variable in F.

– <F,(B,j), ...,(B’,k)>


Using Cooper Storage

• If <F,(B,j), ...,(B’,k)> is a semantic representation for an NP, then the store<u.(u@zi), (F,i), (B,j), ...,(B’,k)>where i is some unique index, is also a representation of that NP

• KEY POINT: The index i associated with F is identical with the subscript on the free variable in u.(u@zi)

• When we encounter an NP, we are faced with a choice.


Using Cooper Storage

• When we encounter a quantified NP, we can either pass on <F, ..other pairs..>

• or else we can pass on <u.(u@zi), (F,i), ..other pairs.. >

• In the second case the effect is to ‘freeze’ the quantifier F for later use.

• NB storage rule is not recursive. We just get the two choices.


Every boxer loves a woman (S)<LOVE(z6,z7), (u.Ax(BOXER(x)=>u@x),6), (u.Ey(WOMAN(y)& u@y),7)>

Every boxer (NP)< w.(w@z6), (u.Ax(BOXER(x) => u@x,6)>

loves a woman (VP)< u.LOVE(u,z7), (u.Ey(WOMAN(Y)&u@y),7)>

loves (TV)<z.u.([email protected](u,v))>

a woman NP<w.(w@z7), (u.Ey(WOMAN(y)& u@y),7)>



Remarks

• Note first of all that the two noun phrases are associated with 2-place stores

• Why is this?• In the pre-storage era we had a woman:

u.Ey(WOMAN(y) & u@y.• In the storage era this would be

<u.Ey(WOMAN(y) & u@y>• But now we have the choice of using

<w.(w@z7), (u.Ey(WOMAN(y) & u@y,7)>


Combining Stores

• If a functor node is associated with

<F,(B,j), ..., (B,k)>• and an argument node is associated with

<G,(C,m), ..., (C,n)>• The the store associated with the result of

applying the first to the second is:

<F@G, (B,j), ..., (B,k) ,(C,m), ..., (C,n)>• It may be possible to do beta reduction on F@G


Retrieval

• We now have an unscoped abstract representation

• We want to extract an ordinary scoped representation from it.

• That is the task of retrieval• Retrieval removes one of the elements

from the store and combines it with the core representation to form a new core representation.


Cooper Retrieval Rule

• Let s1 and s2 be (possibly empty) sequences of binding operators.

• If the store

<F,s1,(B,i),s2>

is associated with an expression of category S, then the store

<[email protected], s1,s2>

is also associated with this expression


Embedded NPs

Every piercing that is done with a gun goes against the entire idea behind it

Mia knows every owner of a hash bar

Both of these are ambiguous

Both contain sub-NPs


< KNOW(MIA,z2),

(u.Ay(OWNER(y) & OF(y,z1) => u@y), 2),

(w.Ex(HASHBAR(x) & w@x),1) >

• Now we have a choice as to which item in the store to use

• Suppose we choose to take the Universal quantifier first


Taking the Universal first …

< KNOW(MIA,z2),



<u.Ay(OWNER(y) & OF(y,z1) => u@y)@

z2. KNOW(MIA,z2),



< KNOW(MIA,z2),



<Ay(OWNER(y) & OF(y,z1) => KNOW(MIA,y),



….. It works

<Ay(OWNER(y) & OF(y,z1) => KNOW(MIA,y),(w.Ex(HASHBAR(x) & w@x),1) >

<w.Ex(HASHBAR(x) & w@x) @z1.Ay(OWNER(y) & OF(y,z1) => KNOW(MIA,y)

Ex(HASHBAR(x) & z1…..OF(y,z1) … @ x

Ex(HASHBAR(x) & Ay(OWNER(y) & OF(y,x) => KNOW(MIA,y)


Taking the Existential first …

< KNOW(MIA,z2),



< w.Ex(HASHBAR(x) & w@x)@

z1. KNOW(MIA,z2),

(u.Ay(OWNER(y) & OF(y,z1) => u@y), 2),>


Taking the Existential first …

< w.Ex(HASHBAR(x) & KNOW(MIA,z2)), (u.Ay(OWNER(y) & OF(y,z1) => u@y), 2),>

[…]Ay(OWNER(y) & OF(Y,z1) =>

Ex(HASHBAR(X) & KNOW(MIA,y)))• This is not what we wanted• The result is a formula with a free variable


What went wrong

• The Cooper storage mechanism ignores the hierarchical structure of the NP

• a hash bar contributes the free varable z1, but z1 has been moved out of the core representation and is put in the store.

• Hence lambda abstracting the core representation wrt z1 is not guaranteed to take into account z1’s contribution – which is made indirecty through the stored universal quantifier every owner.

• Everything is ok if we restore UQ first since that restores z1 to the core representation.


What went wrong

• However, if we choose to retrieve the existential quantifier first then then we get a problem.

• Cooper storage does not impose enough discipline on storage and retrieval

• Keller (1988) suggests a solution: allow nested stores

• As before, nested stores are associated with a storage rule and a retrieval rule.


Keller Storage Rule

• If the nested store

<F,s>

• s an interpretation for an NP, then the nested store

<u.(u@zi),(<F,s>,i)>

for some unique index i, is also an interpretation of that NP


Every owner of a hash bar (NP)<u.u@z2), (<u.Ay(OWNER(y)&OF(y,z1) => u@y), (<w.Ex(HASHBAR(x) & w@x)>,1)>,2)>

Every (DET)<w.u.Ay(w@y => u@y)>

Owner of a hash bar (VP)<u.OWNER(u)&OF(u,z1)),(<w.Ex(HASHBAR(x)&w@x)>,1)>

owner (N)<x.OWNER(x)>

of a hash bar (PP)<v .u.(v@u&OF(u,z1)), (<w.Ex(HASHBAR(x)&w@x)>,1)>



Keller Retrieval Rule

• Let s, s1 and s2 be (possibly empty) sequences of binding operators

• If the nested store

• <F,s1,(<G,s>,i),s2>

• is an interpretation for an expression of category S, then so is

• <[email protected],s1,s,s2>


Keller Retrieval

<F,s1,(<G,s>,i),s2>

<[email protected],s1,s,s2>


Keller Retrieval

• Any operators stored whilst processing G become accessible only after G has been retrieved, i.e.

• Nesting overcomes the problem of generating readings with free variables.


Example of a Nested Store

Mia knows every owner of a hash bar

<KNOW(MIA,z2),

(<u.Ay(OWNER(y)&OF(y,z1)=>u@y),

(<w.Ex(HASHBAR(x) & w@x)>,1)>,2)>

There is only one reading


Keller Retrieval

<F,(<G,s>,2)> => <[email protected],s><KNOW(MIA,z2), (<u.Ay(OWNER(y)&OF(y,z1)=>u@y), (<w.Ex(HASHBAR(x) & w@x) >,1) >,2)>

=>


Keller Retrieval

<u.Ay(OWNER(y)&OF(y,z1)=>u@y)@ z2.KNOW(MIA,z2), (<w.Ex(HASHBAR(x) & w@x)>,1)>

<Ay(OWNER(y)&OF(y,z1)=>KNOW(MIA,y), (<w.Ex(HASHBAR(x) & w@x)>,1)>

(<w.Ex(HASHBAR(x) & w@x)@ z1.Ay(OWNER(y)&OF(y,z1)=>KNOW(MIA,y)>,


(<w.Ex(HASHBAR(x) & w@x)@

z1.Ay(OWNER(y)&OF(y,z1)=>KNOW(MIA,y)>,

<Ex(HASHBAR(x) & Ay(OWNER(y)&OF(y,x)=>KNOW(MIA,y)>


Every owner of a hash bar (NP)<u.u@z2), (<u.Ay(OWNER(y)&OF(y,z1) => u@y),2)>

Every (DET)<w.u.Ay(w@y => u@y)>

Owner of a hash bar (VP)z.(OWNER(z)&Ex(HASHBAR(x)&OF(z,x)))>

owner (N)<x.OWNER(x)>

of a hash bar (PP)<u.z. (u@z&Ex(HASHBAR(x)&OF(z,x)))>



Hole Semantics• Storage methods are useful but have their

limitations• Expressivity:

– allows all possible readings to be expressed, but not some subset

One criminal knows every owner of a hash bar.

– 5 readings, but suppose we want only the subset where every owner outscopes hash bar?

• Oriented to Quantifier scope ambiguities and not other constructs.– Interaction between negation and quantification– every boxer doesn't love a woman


Hole Semantics

• Neither Cooper nor Keller storage can represent all the ambiguities.

• A special mechanism is necessary to handle negation.

• But we would like to have a uniform mechanism for handling all scope ambiguities and not a special mechanism for each construct.

• The quest for a more abstract kind of under-specified representation is the rationale behind Hole Semantics

april 2010underspecified representations1. april 2010underspecified representations2 the issue every...

Documents