Relations lost in adjunct extraction with alists (emerson lists)

Here’s another question about how to use @guyemerson’s append lists (here’s the first question about that).

(1) Куда идет Иван?
    Kuda idet Ivan?
    where go.3SG.PRES Ivan.NOM
    `Where does Ivan go?' [rus]


The adjunct extraction rule below, which uses alists instead of diff-lists, applies without a unification failure to an S, and so I get a parse for sentences like (1).

extracted-adv-adp-adj-phrase := basic-extracted-adj-phrase &
                         MC #mc ],
             NON-LOCAL.SLASH 1-alist & [ LIST < [ CAT [ HEAD +rp &
                                                       [ MOD < [ LOCAL intersective-mod &
                                                                       [ CAT [ HEAD #head,
                                                                               VAL #val,
                                                                               POSTHEAD #ph,
                                                                               MC #mc ],
                                                                         CONT.HOOK #hook,
                                                                         CTXT #ctxt ] ] > ],
                                                  VAL [ SUBJ olist,
                                                        COMPS olist,
                                                        SPR olist ] ] ] > ] ],
    HEAD-DTR.SYNSEM canonical-synsem &
                    [ LOCAL local &
                            [ CAT [ HEAD verb & #head,
                                    VAL #val &
                                        [ SUBJ < > ],
                                    POSTHEAD #ph,
                                    MC #mc ],
                              CONT.HOOK #hook,
                              CTXT #ctxt ],
                      NON-LOCAL.SLASH 0-alist,
                      MODIFIED notmod ],
    C-CONT [ HOOK #hook,
             HCONS.LIST <  >,
             ICONS.LIST <  > ] ].

However, I lose the relations: in the resulting MRS, I only have relations associated with the adverb (in which place). The semantics of Kim goes is lost.

Inspecting the local AVMs for the S-subtree doesn’t immediately show anything alarming (like it would with diff-lists):

lower VP (intransitive verb):

In terms of the diff-lists, these look “healthy”. Of course they aren’t diff-lists so I don’t really know. Any feedback?

…What I probably should be inspecting though is the RELS lists.

I still have the following (good) RELS on the head daughter of the filler-gap rule:

So, the problem must be in the filler-gap rule…

Here’s where I think the RELS append happens for my filler-gap rule (I will post the full “pedigree” if needed):

basic-binary-phrase := phrase &
  [ SYNSEM.LOCAL.CONT [ RELS.APPEND < #r1, #r2, #r3 >,
			HCONS.APPEND < #h1, #h2, #h3 >,
			ICONS.APPEND < #i1, #i2, #i3 > ],
    C-CONT [ RELS #r1,
	     HCONS #h1,
	     ICONS #i1 ],
    ARGS < sign & [ SYNSEM.LOCAL local &
				 [ CONT [ RELS #r2,
					  HCONS #h2,
					  ICONS #i2 ] ] ],
	   sign & [ SYNSEM.LOCAL local &
				 [ CONT [ RELS #r3,
					  HCONS #h3,
					  ICONS #i3 ] ] ] > ].

So, for some reason looks like #r3 has gone missing? But the binary phrase itself is unlikely to be the culprit because head-subject and head-complement rules inherit from it also, and the MRS of sentences licensed by them look fine.

At a guess: Does the wh word itself have an Emerson-list-ified RELS value?

1 Like

It does (at least superficially):

wh-adverb-lex := adverb-lex-item & 
[ SYNSEM [ LOCAL.CONT [ RELS.LIST < [ ], [ ARG0 #arg0 ], quant-relation & [ PRED "which_q_rel" ] >  ],
           NON-LOCAL.QUE.LIST < #arg0 > ] ].

Maybe something more is needed here?

That doesn’t look like a good RELS list to me! Could you zoom out? You need to look at RELS.LIST, which should be an ordinary list. If RELS.LIST is actually the thing at the top of this screenshot ([10] list), then the append is broken, probably because a list is underspecified somewhere.

On closer inspection, I can see that [12] is of type list-copy, when it should be either cons-copy or null-copy. My guess is that the C-CONT is underspecified.

Thank you, Guy!

I will look into C-CONT (I don’t actually remember what it is for and what should happen there).

As for the well-formedness of the lists, does this look good? This belongs to the lowest S node, licensed by the head-subject rule:


…Constraining the extracted adjunct rule to be C-CONT.RELS.LIST < > fixed the MRS :).

This is something that isn’t in the matrix core though, so I am wondering: was this not an issue with diff-lists? We used to have good semantics for extracted adjuncts, I am pretty sure.

C-CONT is the constructional content i.e. the semantic contribution of the rule. Rules that aren’t adding any RELS should say so. In diff-list land, this would be RELS <! !>. Maybe this particular rule didn’t get updated when you switched over?

Currently in the matrix core, we have, for the adjunct extraction rule:

C-CONT [ HOOK #hook,
	     HCONS <! !>,
	     ICONS <! !> ]
  • nothing about RELS. Used to work, I am pretty sure?..

Are there subtypes that say something about RELS?

Well the unary-phrase is doing the appends. But I don’t think anything says directly that extracted-adj rule is RELS <! !>, at least I don’t see that.


Oh I see; I don’t know how it was used before by others; my Russian grammar wasn’t positing any additional constraints, I don’t think. But I’d need to restore from the repository to confirm that (not sure how relevant this is at this point).

Update: I went ahead and looked in the old commit, and I am pretty sure I am seeing good semantics with extracted adjuncts and not seeing the RELS <! !> constraint anywhere. We can look together some time next week maybe? If that sounds important.

append-lists aren’t any more likely to break than diff-lists – in both cases, every list needs to be specified. With diff-lists, RELS must be specified to be <! !> (rather than an underspecified diff-list), and with append-lists, RELS.LIST must be specified to be <> (rather than an underspecified list).

Understood; I am trying to figure out now why it seems to me that an older version of the grammar used to work without that constraint… but it is unrelated to the thread actually, so, apologies :).