[logon] reflexives

[Stephan Oepen]

hi again,

> > This works unless the input is a zero pronoun, which doesn't get
> > generated as we were looking for a "u" and it has become an "x".
> > This means we have to generate the zero pronouns before the num_equate
> > rules.   I will try some more jiggling.
> 
> Reordering the zero-pronoun rules sort of work, but now I will need
> rules specializing all possible combinations (which leads to transfer
> fan blowout).  I really, really want to pass them to the ERG marked as
> linked, and have Dan hook up PNG on the index.

hmm, i realize this aspect of what we are doing feels quite clunky, but
i doubt we can off-load the problem to the ERG (possibly the generator,
but then it would have to be pre- or post-processing, i think).  but i
also noticed my `gend_equate_null_cf' rule ended up specializing GEND,
even though that is clearly undesirable.  i concluded that testing for
underspecified variable properties by looking for more specific `anti'
types is just wrong.

part of why this is clunky, i think, is owed to arbitrary restrictions
in the transfer formalism.  currently, one cannot use meta variables on
varible properties, i.e. there is no way to just say: pick up whatever
value you see for this property over here, and make that the value over
there.  i am afraid, i cannot eliminate this restriction short-term, so
we are stuck with enumerating the various possible values in `families'
of related rules.

but i did eliminate another restriction.  as of today, one can use the
FLAGS.EQUAL mechanism (or SUBSUME, though i did not test that) also on 
variable properties.  with that extension in the code, i now have:

  gend_equate_null_cf := monotonic_mtr &
  [ CONTEXT.RELS < [ ARG0 #x1 & x & [ GEND #gender & gender ] ] >,
    INPUT.RELS < [ PRED gend_equate, ARG0 #x0, ARG1 #x1 ] >,
    FLAGS.EQUAL < #x1, #gender > ].

and the problem of accidentally over-specifying a property disappears.
i have checked in this revision (and a new build), and also created the
missing `pers_equate' family of rules.  this now seems to work well for
NoEn, and i think it should be fully applicable to your case too.  the
general goal, in my view, should be to copy over whatever information
is available on the antecedent.  for variable properties, we have good
underspecification. ideally, these rules should not have to multiply
out combinations of most specific syb-types, i.e. not introduce extra
ambiguity.  --- but i realize i know too little about zero prounouns in
JaEn, so maybe this point of view is too optimistic?

                                                        cheers  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at ifi.uio.no; oe at csli.stanford.edu; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++