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

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
have any comments please send them directly to Benjamin Newman <bnewman@linc>
and Maribel <sanguesa@linc>.


Ben Newman's notes:

Proposed generalized system for variable extraction and unification

Under the current system, an elementary tree's semantics identifies
arguments by their tree addresses: 

	   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		|	flies(e,x1) && link(x2,x3)
	  / \		|	----------------------------------
	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)
	  / \		|	--------
	VP*  Adv	|	args: E
	    quickly	|
			|	E = 0/E

	        VP	|	alleged(P)
	       / \	|	----------
	     Adv  VP*	|	args: 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?