Used to get ICONS; now lost them; why?

And here’s a situation that seems symmetric to this one but less fortuitous, in that now I am losing ICONS instead of gaining them.

Here’s a type which in practice fails to propagate the ICONS from its daughter:

morphological-subord-clause-phrase := unary-phrase &
  [ SYNSEM.LOCAL [ CAT [ MC -,
                         VAL [ SUBJ #subj,
                               SPR < >,
                               COMPS < > ],
                         HEAD adp &
                              [ MOD < [ LOCAL scopal-mod &
                                              [ CAT [ HEAD verb,
                                                      VAL [ SPR < >,
                                                            COMPS < > ] ],
                                                CONT.HOOK [ LTOP #mcl,
                                                            INDEX #index ] ] ] > ] ],
                   COORD - ],
    C-CONT [ RELS.LIST < [ ARG1 #mch,
                           ARG2 #sch ] >,
             HCONS.LIST < qeq &
                          [ HARG #mch,
                            LARG #mcl ],
                          qeq &
                          [ HARG #sch,
                            LARG #scl ] >,
             HOOK.INDEX #index ],
    ARGS < [ SYNSEM.LOCAL [ CAT [ HEAD verb,
                                  MC na-or-+,
                                  VAL [ SUBJ #subj,
                                        SPR < >,
                                        COMPS < > ] ],
                            CONT.HOOK.LTOP #scl,
                            COORD - ] ] > ].

Except it inherits from the unary phrase, and the unary phrase does the append:

basic-unary-phrase := phrase &
  [ STEM #stem,
    SYNSEM [ L-PERIPH #lperiph,
	     R-PERIPH #rperiph,
	     LOCAL [ CAT.MKG #mkg,
		     CONT [ RELS.APPEND < #r1, #r2 >,
			    HCONS.APPEND < #h1, #h2 >,
			    ICONS.APPEND < #i1, #i2 > ] ] ],
    C-CONT [ RELS #r1,
	     HCONS #h1,
	     ICONS #i1 ],
    ARGS < sign & [ STEM #stem,
		    SYNSEM [ L-PERIPH #lperiph,
			     R-PERIPH #rperiph,
			     LOCAL local &
			      [ CAT.MKG #mkg,
				     CONT [ RELS #r2,
					    HCONS #h2,
					    ICONS #i2 ] ] ] ] > ].

The analogous version with diff-lists does the job properly… Why??.. Would this have to be something else, not related to these types? Should I be hunting for other diffs, something on the lexical level? But I see the ICONS just below this phrase applies, and then they are underspecified starting from it…

Actually, no I don’t think it is underspecified. Here’s what the PP (which is this phrase) looks like:

Screen Shot 2020-07-27 at 11.18.05 AM

So the info is there…

Aha. In this case (and probably in all other similar cases), I think what I need is for the unary phrase to do the append in the other order…

Although… I mean, changing the unary rule like so:

basic-unary-phrase := phrase &
  [ STEM #stem,
    SYNSEM [ L-PERIPH #lperiph,
	     R-PERIPH #rperiph,
	     LOCAL [ CAT.MKG #mkg,
		     CONT [ RELS.APPEND < #r1, #r2 >,
			    HCONS.APPEND < #h1, #h2 >,
			    ICONS.APPEND < #i1, #i2 > ] ] ],
    C-CONT [ RELS #r1,
	     HCONS #h1,
	     ICONS #i2 ],
    ARGS < sign & [ STEM #stem,
		    SYNSEM [ L-PERIPH #lperiph,
			     R-PERIPH #rperiph,
			     LOCAL local &
			      [ CAT.MKG #mkg,
				     CONT [ RELS #r2,
					    HCONS #h2,
					    ICONS #i1 ] ] ] ] > ].

Helps but does it make sense? The RELS and the HCONS seem to work correctly? Or do they? What should be appended to what here?

Here’s the old diff-list version:

basic-unary-phrase := phrase &
  [ STEM #stem,
    SYNSEM [ L-PERIPH #lperiph,
	     R-PERIPH #rperiph,
	     LOCAL [ CAT.MKG #mkg,
		     CONT [ RELS [ LIST #first,
				   LAST #last ],
			    HCONS [ LIST #scfirst,
				    LAST #sclast ],
			    ICONS [ LIST #icfirst,
				    LAST #iclast ] ] ] ],
    C-CONT [ RELS [ LIST #middle,
		    LAST #last ],
	     HCONS [ LIST #scmiddle,
		     LAST #sclast ],
	     ICONS [ LIST #icmiddle,
		     LAST #iclast ] ],
    ARGS < sign & [ STEM #stem,
		    SYNSEM [ L-PERIPH #lperiph,
			     R-PERIPH #rperiph,
			     LOCAL local &
			      [ CAT.MKG #mkg,
				CONT [ RELS [ LIST #first,
					      LAST #middle ],
				       HCONS [ LIST #scfirst,
					       LAST #scmiddle ],
				       ICONS [ LIST #icfirst,
					       LAST #icmiddle ] ] ] ] ] > ].

this one (the diff-list one) looks like it is appending to the daughter’s lists, right? So, the append-list version is doing it backwards, for all of the lists?

It’s possible for the diff-list append to ‘hide’ problems with the lists it is appending, depending on the order. That is, there might be something lower in the tree with a leaky (underspecified) list, but because of the order of the diff-list appends, this stays later in the list than anything contentful. Does that maybe help?

1 Like

I see; I think it is hard for me to tell right now what a healthy situation would be.

Here’s a tree, for example, along with what the S licensed by the subject drop looks like wrt its ICONS:

Screen Shot 2020-07-27 at 11.41.50 AM

It does not look fully underspecified (there is an identity between the LIST and the NEW-LIST inside the APPEND) but I am not sure this is all right. Ultimately, this leads to lack of ICONS at the top. I think the 34 here should actually be 37, and 34 is just an underspecified list.

If I reverse the order of the append in the unary phrase, then the ICONS will appear in this case and will disappear in some other cases. The same part of the AVM (the exact same test and sentence) would then look like this:

It seems like there are some regression tests which pass in this situation and some that fail, and if I change the order of the unary phrase append, then it is symmetrical (the tests which used to pass, fail, and vice versa). So it is just random in the sense that some gold MRS were stored with ICONS in them and others without. I am assuming that in most cases with ICONS is better (at least in cases where argument drop is involved).

But I still don’t know what the core issue is and why the same unary phrase type results in no ICONS in some cases but not others; Emily is saying the order of the append should not matter: although, is it only true for diff lists? Or for both diff and append lists? It seems to me that the append may be doing something funky in the above picture but I don’t really know.

Emily also says I should be looking that something leaky lower in the tree (but it’s hard until I have a better idea of what leaky vs. non-leaky means in the append land).

I can’t speak to what’s going on in append-land, but in diff-list-land, this certainly seems characteristic of something else lower in the trees having an underspecified ICONS value … leading to apparently empty ICONS lists at the top, depending on the order of the arguments to the diff-list append. @guyemerson – is there reason to believe something similar should happen with append lists?

I will try to find something that’s in common in those trees that’s other than the unary rule. Also I suppose I do have a hypothesis of what a “leaky” append list might look like…

It seems like some of the auxiliaries added by the customization system are underspecified for ICONS. I will try to track all of them down now…

So in some cases, I was able to locate a lexical item which was underspecified for ICONS and that fixed things. There are still remaining cases however where I am unable to located such item.

Here’s a tree:

Screen Shot 2020-07-27 at 12.55.37 PM

On the first glance, it seems to be losing the ICONS between the lower S and the PP.

The lower S, the dropped subject after the dropped complement:

The PP (the clausal-modifier phrase; I think I would like the 53 here be 55):

But this phrase, that is the PP, inherits from the unary phrase which I think we concluded is doing the append properly. I have checked each and every node below the PP, and they all look specified wrt ICONS:

Here’s the first lexical rule; I am not sure what is going on in the APPEND, but at any rate the LIST does not look underspecified? it is null. Perhaps the fact that it went from 0-alist to append-list is a problem though?

I think it is the exact same for the other two lexical rule V nodes.

Then the complement gets dropped (the VP node):

And then back to the beginning of this post, the subject drop, where everything also looks fine.

One thing I note is that this PP phrase has something to say about both its mother’s C-CONT HCONS and RELS but not ICONS.

I think I can fix the situation by adding that the ICONS on its C-CONT is empty. Does this sound like a meaningful change?

1 Like

Yes! That is just the kind of underspecification that would lead to leaky appends.

3 Likes

Yes, I completely agree with @ebender’s comments. It’s exactly as with diff-list appends: for the CONT lists, the order of the append should never matter; and if the append is defined correctly, then the problem is elsewhere.

My initial motivation for append-lists was to make defining the append easy. But when it comes to remembering to specify lists, it’s the same situation as with diff-lists.

1 Like