[Prev][Next][Index]

# [xtag-meeting]: notes from last week's informal meeting

• To: xtag-meeting@cis.upenn.edu
• Subject: [xtag-meeting]: notes from last week's informal meeting
• From: Anoop Sarkar <anoop@linc.cis.upenn.edu>
• Date: Tue, 30 Oct 2001 14:53:17 EST
• Sender: owner-xtag@linc.cis.upenn.edu

```
Last week, we had an informal meeting instead of the XTAG meeting to discuss
the progress on the semantics implementation. Maribel, Ben Newman and I met
to discuss any remaining problems with going forward with an implementation.

Enclosed below are some notes that Ben wrote down after this meeting. If you
and Maribel <sanguesa@linc>.

-Anoop

------------------------------------------------------------------------------
Ben Newman's notes:

Proposed generalized system for variable extraction and unification

Under the current system, an elementary tree's semantics identifies

S		|	eats(e, x1, x2)
/ \		|	-------------------
NP!  VP		|	args: x1(0), x2(11)
/ \		|
V   NP!	|
eats		|

However, sometimes more than one variable is needed from the tree
substituted at a given address.  For example, the phrase "whose mother"
needs to pass up a variable for "mother" and a variable for "who."

A relative clause tree may need to extract both of these variables.  We
can do this by giving them different names:

/ \		|	----------------------------------
NP*  S		|	args: x1(10/N), x2(0/N), x3(10/Wh)
/ \		|
NP!  S	|	Here, "N" and "Wh" are descriptive
/ \	|	names for the two variables required
NP   VP	|	from the NP which substitutes in at
<tr>  |	|	the address <10>.
V	|
flies	|

The internal structure of a phrase such as "whose mother" must ensure
that these variables end up bound correctly within it:

NP	|	wh(Wh)
|	|	-------
who	|	args: -
|
|	N = Wh

NP	|	mother(N)
|	|	---------
mother	|	args: -

NP		|	se(x1,x2)
/ \		|	-----------------------
NP!  NP		|	args: x1(0/N), x2(11/N)
/ \		|
GEN  NP!	|	N  = 11/N
se		|	Wh = 0/Wh

Note the variable identifications associated with the tree for "se."
These tell that tree where to find its variables when asked by another
tree into which it has been substituted.  For example, the Wh-extracted
tree for "flies" asks for the 'Wh' variable of its <10> substituent.

"flies": "Give me your 'Wh' variable."

"se": "My 'Wh' is the 'Wh' of my <0> substituent."

This is necessary because the wh-word could be nested several trees
deep.  Thus, the distinction between the variables "N" and "Wh" cannot be
captured simply in terms of tree addresses.

Now, looking at verbs again:

S		|	eats(e, x1, x2)
/ \		|	-----------------------
NP!  VP		|	args: x1(0/N), x2(11/N)
/ \		|
V   NP!	|	S  = 0/N
eats		|	DO = 11/N

Here, descriptive names have been given to the variables that are
available within the semantics of "eats."  This can help modifiers that
adjoin into the "eats" tree to select the appropriate variable.  It also
provides a way of identifying the variables that is consistent across
different trees for the same verb, in which the addresses may differ,
enabling us to abstract the semantics away from the particular choice of
elementary tree (this may or may not be helpful).

For example:

S		|	eats(E, S, DO)
/ \		|	-----------------------
NP!  VP		|	args: S, DO
/ \		|
V   NP!	|	S  = 0/N
eats		|	DO = 11/N

S		|	eats(E, S, DO)
/ \		|	--------------
NP!  VP		|	args: S, DO
/  \	|
VP   PP	|	S  = 111/N
eaten  / \	|	DO = 0/N
P   NP!	|
by		|

Here, the semantics of "eat" is abstracted away from the tree structure,
so that the level at which the two trees have "the same semantics" is
more visible.  This may or may not work as part of our overall approach.
However, these variable names also do the work of variable *types*, e.g.:

S		|	P: eats(E, S, DO)
/ \		|	-----------------------
NP!  VP		|	args: S, DO
/ \		|
V   NP!	|	S  = 0/N
eats		|	DO = 11/N

VP		|	quick(E)
/ \		|	--------
quickly	|
|	E = 0/E

VP	|	alleged(P)
/ \	|	----------
allegedly	|
|	P = 1/P

Here, "E" is an event variable and "P" is a propositional label variable.

Anoop has suggested that a variable extraction and unification interface
like this could be implemented within the existing feature unification
mechanism through feature coindexing.

Any thoughts?

```