What should the ICONS look like in argument drop? (WAS: in a clausalmod sentence)

If you remove the constraints you added on morphological-subord-clause-phrase and then look at its expanded type, is the ICONS-KEY already identified with something?

No, I don’t think so; looks underspecified:

Screen Shot 2020-07-29 at 3.41.18 PM

The #index is shared though, between the PP’s CCONT and the event that’s on its MOD list…

I meant that the PP doesn’t matter for creating the ICONS. It still needs to have specified ICONS so that appends work. But if I’ve understood you correctly, the subject drop rule is the one that actually puts something non-empty on ICONS. (And the rule applies to both clauses, each time adding one element to the ICONS list.)

The ICONS element [non-focus] isn’t expanded so I can’t see whether it is pointing to the event. That’s where I think the missing re-entrancy is.

Hmm. It looks like you are right but, given the TDL, I don’t understand why this is:

rules.tdl:

decl-head-opt-subj := decl-head-opt-subj-phrase.

matrix.tdl from this particular grammar (scroll down):

basic-head-opt-subj-phrase := head-valence-phrase & head-only &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL.CAT [ VAL [ SUBJ < >,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    POSTHEAD #ph ],
		MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ HEAD.MOD olist,
	       	      	      	      VAL [ SUBJ < unexpressed-reg &
						   [ OPT +,
						     LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST in-foc ],
								       ICONS-KEY #ikey,
								       CLAUSE-KEY #ckey ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

; ERB 2007-01-21 Subtypes for declaratives and imperatives

decl-head-opt-subj-phrase := basic-head-opt-subj-phrase & declarative-clause &
  [ SYNSEM.LOCAL.CAT.MC #mc,
    HEAD-DTR.SYNSEM.LOCAL.CAT.MC #mc ].

Isn’t TDL correctly linking the event to the information structure?

I’m not very familiar with how the values of ICONS-KEY and CLAUSE-KEY are propagated. But this rule identifies the ICONS element’s IARG1 with the dropped subject’s CLAUSE-KEY. Looking at the derived feature structure, it looks like it should be the head daughter’s own CLAUSE-KEY.

2 Likes

Yay!

Screen Shot 2020-07-30 at 3.04.37 PM

So I changed the type as so:

basic-head-opt-subj-phrase := head-valence-phrase & head-only &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL [ CAT [ VAL [ SUBJ < >,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    POSTHEAD #ph ],
		             CONT.HOOK [ ICONS-KEY #ikey, CLAUSE-KEY #ckey ] ],
		     MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ HEAD.MOD olist,
	       	      	      	      VAL [ SUBJ < unexpressed-reg &
						   [ OPT +,
						     LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST in-foc ],
								       ICONS-KEY #ikey,
								       CLAUSE-KEY #ckey ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].
1 Like

fwiw it looks like some other tests have this problem too, e.g. evidentials-infl-aux-kaz.

Yes. It is the argument drop rule issue, not a clausal mod issue (as it turns out).

So the question then is, what should happen when there is both a subject drop and an object drop in a sentence.

Consider the following pseudo-Lakota sentence from a valence change regression test (valchg-lkt):

1SgAgt-2SgPat-ičháGA-CAUS

It should be associated with this sort of tree:

Screen Shot 2020-07-31 at 10.26.40 AM

The top two nodes are head-opt-comp and head-opt-subj, respectively.

I have now changed the head-opt-subj rule as follows, to get proper ICONS:

basic-head-opt-subj-phrase := head-valence-phrase & head-only &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL [ CAT [ VAL [ SUBJ < >,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    POSTHEAD #ph ],
		             CONT.HOOK [ ICONS-KEY #ikey,
		                         CLAUSE-KEY #ckey ] ],
		     MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ HEAD.MOD olist,
	       	      	      	      VAL [ SUBJ < unexpressed-reg &
						   [ OPT +,
						     LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST in-foc ] ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

This gives me one good set of ICONS (e2-x3)but the one that should be associated with the dropped complement will still be disconnected (the e8-x6):

Screen Shot 2020-07-31 at 10.29.02 AM

However it does not seem that the solution is to change the head-opt-comp rule in the same way because these appear to be two different events, at least in this case, because this is valence change (?)…

Should the argument drop rules in fact be doing an explicit append to their head daughter’s ICONS, somehow?

Hmm no I think it is actually probably the causing that drops both arguments, so, should be the same event, e2.

And, inspecting the basic-head-opt-comp phrase, what goes on its C-CONT.ICONS is already the APPEND of the ICONS on its CONT… So it should work, really, hmm.

The failure I get trying to feed the mother of head-opt-comp as the daughter of head-opt-subj is the following:

Screen Shot 2020-07-31 at 11.39.33 AM

So, I confused it somehow about what’s the subject what’s the object.

I think this may be a valence change issue specifically. I believe that in other cases, e.g. in clausalmods-lavukaleve, this is working correctly, meaning both the subject and the object can be dropped and both ICONS items are present in the end and linked properly. But with valence change, there is this problem with the items, well, changing valence (and I am as of now still confused how to fix it). But if it is just valence change, then it may be a separate bug.

1 Like

Except… It may still be an issue with specifying the argument drop rules because now there is this asymmetry:

basic-head-opt-subj-phrase := head-valence-phrase & head-only &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL [ CAT [ VAL [ SUBJ < >,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    POSTHEAD #ph ],
		             CONT.HOOK [ ICONS-KEY #ikey,
		                         CLAUSE-KEY #ckey ] ],
		     MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ HEAD.MOD olist,
	       	      	      	      VAL [ SUBJ < unexpressed-reg &
						   [ OPT +,
						     LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST in-foc ] ] ] >,
					    COMPS #comps,
					    SPR #spr,
					    SPEC #spec ],
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

basic-head-opt-comp-phrase := head-valence-phrase & head-only &
                              head-compositional &
  [ INFLECTED #infl,
    SYNSEM canonical-synsem &
	      [ LOCAL.CAT [ VAL [ SUBJ #subj,
				  COMPS #comps,
				  SPR #spr,
				  SPEC #spec ],
			    MC #mc,
			    POSTHEAD #ph ],
		MODIFIED #mod ],
    HEAD-DTR [ INFLECTED #infl & infl-satisfied,
	       SYNSEM [ LOCAL [ CAT [ VAL [ SUBJ #subj,
					    COMPS < unexpressed &
						    [ OPT +,
						      OPT-CS #def,
						      LOCAL.CONT.HOOK [ INDEX #index & [ COG-ST #def ],
									ICONS-KEY #ikey,
									CLAUSE-KEY #ckey ] ] . #comps >,
					    SPR #spr,
					    SPEC #spec ],
				      MC #mc,
				      POSTHEAD #ph ],
				CONT.HOOK.INDEX event ],
			MODIFIED #mod ] ],
    C-CONT [ RELS.LIST < >,
	     HCONS.LIST < >,
	     ICONS.LIST < #ikey & non-focus & [ IARG1 #ckey,
					    IARG2 #index ] > ] ].

I only changed how the subject drop rule works and left the object drop rule as it was. It happens to bring improvements to the tests we have (partial, in case with valchg-lkt), but this kind of asymmetry can’t be right can it? They should be doing a similar thing? But I can’t simply make them do a similar thing (as explained above; I start losing parses at that point).

This is this guthub issue.

I agree that it would make sense to treat the subject drop and object drop rules in the same way, but there isn’t enough information in this thread to debug the problem. If we’re going to use this forum like the Stackexchange sites, then we should probably have the same policy of always having a minimal working example.

The unification failure shows up on the XARG, so this doesn’t seem directly to do with ICONS directly. But there is also a problem with the ICONS, because the LIST has the same element (#11) showing up twice in the list.

My guess would be that the items on the HOOK are not being passed up correctly – in particular, I suspect there are unnecessary and conflicting HOOK re-entrancies. As I said before, I’m not fully familiar with how ICONS-KEY and CLAUSE-KEY are supposed to propagate, but I don’t think the dropped subject and object ICONS should be propagated up on the ICONS-KEY. Both rules need to add something to the ICONS list, but these are presumably as specified as they need to be, and so don’t need to be referred to again.

Hm. I think an MWE might be tricky with things like matrix grammars though; you cannot attach files. But, I suppose, possible; long files will just be truncated for the view.

Attaching the whole grammar would give a working example, but not a minimal one. In this case, the unification failure is in the XARG, but none of the given type definitions refer to XARG, so the supertypes are necessary to reproduce the problem.

Right; wouldn’t this ultimately turn into almost the full matrix core though? If I were to include all the supertypes which are involved. I think trying to turn a matrix grammar into a MWE might not always be worth the while (although in this case it might be), so I would not make it a requirement (as in, don’t post until you’ve done it). This might be the first case which seems to motivate an MWE, and it is likely because none of us actually knows what should be done with ICONS…

Speaking of which, I agree that there is unlikely to be a need in linking ICONS-KEY to that of the dropped argument. I did try removing that constraint and since that did not fully fix the issue and none of us has a good idea what actually needs to happen (someone who will officially be working on infostructure would, eventually; my job was to fix any failing regression tests which it would be easy to fix), I decided to shelf this one for now… But, I will look again whether making the rules consistent introduces any problems.