Edge not in parse chart but no unification failure

LKB
#1

I am hitting this situation:

http://moin.delph-in.net/GeFaqUnifySurprise

Specifically I am not seeing an edge for extracted complement rule in the chart, above the head-subject node highlighted in red (the one that’s there, highlighted in blue, is the adjunct extraction rule).

Can’t figure out why so far. Double checked the chart; there is only one daughter in the rule I am looking at (complement extraction). The rule ex-comp is in rules.tdl. I am not redisplaying the parse. It doesn’t seem to have to do with lexical entries or lexical rules?.. Help!!!

Rules:

basic-extracted-comp-phrase := basic-extracted-arg-phrase &
                               head-compositional &
  [ SYNSEM canonical-synsem &
       [ LOCAL.CAT [ VAL [ SUBJ #subj,
                           SPR #spr,
                           COMPS #comps ],
                     MC #mc ] ],
    HEAD-DTR [ SYNSEM
               [ LOCAL.CAT [ VAL [ SUBJ #subj,
                                   SPR #spr,
                                   COMPS < gap & [ NON-LOCAL.SLASH #slash ]
                                          . #comps > ],
                             MC #mc ],
                 NON-LOCAL.SLASH #slash ] ],
    C-CONT [ RELS.LIST < >,
             HCONS.LIST < >,
             ICONS.LIST < > ] ].

extracted-comp-phrase := basic-extracted-comp-phrase &
  [ SYNSEM.LOCAL.CAT.HEAD verb,
    HEAD-DTR.SYNSEM.LOCAL.CAT.VAL [ COMPS 0-1-list  ]].

Below the parse chart for the sentence:

Сhto     vidit Ivan?
what.ACC sees  Ivan.NOM
`What does Ivan see?' [rus]
  • with some annotations which hopefully give some useful info.

parse-chart
parse-chart1275×1650 396 KB

Edge can be built interactively, but isn't in the chart
#2

I can’t give a specific diagnosis, but one thing you could try is turning off ambiguity packing. Sometimes packing makes it more difficult to work out what’s going on in the chart.

In the LKB: (setq *chart-packing-p* nil) at the terminal prompt
In ACE: -p command line option

#3

All the causes of that situation that I know about are listed in that FAQ page. So when you figure out what’s going on here, if it’s not one of those, please add it :slight_smile:

#4

Is this what it should look like?

Screen Shot 2019-12-18 at 1.24.12 PM

I am always confused about what counts as a “prompt”. This is emacs+LKB on the Ubuntu VM (not LKB-FOS).

#5

You’ll need to tell the LKB that, not TSNLP

:pa lkb
(setq *chart-packing-p* nil)
1 Like
#6

Could you possibly clarify this one?

" Edges you are trying to use as daughters appear to be contiguous in the chart, but actually are not. This can happen because if the LKB can’t construct an edge for a lexical entry, it won’t put anything for that entry in the chart. It will, however, record the fact that there is something there, and not let constituents bridge the material it can’t account for. On the possible causes of this situation, see this FAQ."

I don’t understand what it is saying and the link to the FAQ is broken… It sounds like it would have to do with a terminal node though? Which definitely isn’t the case here.

#7

Thanks!

OK, I’ve now done that and am not seeing any differences in the parse chart, unfortunately.

#8

Update: I don’t know why the edge was not in the chart (or conversely: why I was getting a unification result for it interactively), but for now, I was able to fix this using the solution mentioned here: Emerson (append) lists for subject extraction

Specifically, in the current version of matrix.tdl, we have the apparently unnecessary constraints in extracted-subject as well as extracted-complement rules. We should be able just to say that head-daughter’s SUBJ (or COMPS) contains a gap, and there is no need to say anything about head-daughter’s NONLOCAL.SLASH value.

So I made this change and now I do get a parse for a sentence with an extracted complement. Interestingly, I still haven’t removed the similar constraint from the subject extraction rule in this particular grammar, and subject extraction appears to work fine.

So, it is still all a bit mysterious.

#9

This would only make sense when you are trying to construct an edge using a binary rule.