Changing a lexeme-to-word lexical rule to simply an inflecting-lex-rule: LKB error when parsing

(related to this: Past participles and gender agreement in Spanish - #9 by olzama)

I have a rule:

vpart_ilr :=  verb_ilr & 
[ SYNSEM.LOCAL.CAT.HEAD [ TAM.MOOD ind_or_sub_mood,
                          VFORM part,
                          VOICE active,
                          PRD non-prd ] ].

I want a version of it that isn’t a subtype of verb_ilr and therefore of lexeme-to-word lexical rule, because I don’t want the whole daughter synsem to be identified with the mother’s. I want it to be simple an inflecting-lex-rule, like, for example the vppart_ilr which you can see by the link above (which in principle seems to work). However, when I try this:

vpart_ilr :=  inflecting-lex-rule &
;vpart_ilr :=  verb_ilr & 
[ SYNSEM.LOCAL.CAT.HEAD [ TAM.MOOD ind_or_sub_mood,
                          VFORM part,
                          VOICE active,
                          PRD non-prd ] ].

the grammar loads but I get the following error when trying to parse:

What does this error mean and how can I fix the rule?

Comparing to the previous rule, I wonder if the feature INFLECTED is important?

No, that’s part of the verb_ilr also… Through lexeme-to-word rule. I mean, I tried including it.

But have you tried including it separate form lexeme-to-word rule? (As it is in vppart_ilr)

Yes! I suppose I need to do a systematic exclusion of features from vppart_ilr. It’s a bit time consuming, so I was wondering if someone just happens to know… But it’s not INFLECTED, at least not according to my experiments so far.

That error message from the LKB “hypothesize-edge() failed to build even the 0th tree from a root” is indeed cryptic.

What’s happening is that the set of features in the *packing-restrictor* allow a parse forest to be constructed – but when attempting to unpack the forest the LKB finds that for one of the roots of the forest, its “0th tree” (i.e. the tree rooted at that point in which all nodes packed into it are ignored) is inconsistent if the restrictor features are taken into account.

In such a case the *packing-restrictor* does not correctly reflect what the grammar is doing. I suspect the RELS feature: is it still being used to eliminate analyses? If so, it shouldn’t be a packing restrictor. Unfortunately, though, if it isn’t a packing restrictor then the effectiveness of packing is likely to be diminished significantly.

You were probably unlucky with the sentence that caused this error; if the inconsistent tree had not been the 0th tree but instead had been made up from a combination of nodes packed into it, then you wouldn’t have got an error.

Do I get it right that the RELS feature (e.g. it being not mentioned in some type) could be the reason I am seeing the error?

I can trigger the error with any participle currently… If I have the participles go through that inflectional rule that I am trying to write…

No, I don’t think the absence of the RELS feature on a type could be the reason for this “0th tree” error. The scenario I had in mind is if the grammar were implemented such that a unification during parsing or generation could fail somewhere below RELS. If this might happen and you have packing turned on (the default) then RELS must not be in *packing-restrictor*.

What does “somewhere below RELS” mean? I am trying to understand what steps I can take to write the rule correctly, so that this does not happen…

I meant “somewhere inside RELS”. I’m thinking of our email exchange last month when you noticed odd things about the parse chart for “Es una tragedia.”, a symptom of which was unification failure when trying to display certain edges, e.g.

Unification of GENERIC_ENTITY_REL and _tragedia_n_rel failed at < SYNSEM : LOCAL : CONT : RELS : LIST : FIRST : PRED >

It might be that your new vpart_ilr is fine, but that applying it peturbs the order in which the parser applies other rules, leading to a rule with the RELS unification failure problem being applied first and creating an inconsistent “0th tree”.

If you want to avoid problems caused by RELS unification failures for the moment, you could remove RELS from *packing-restrictor*, or alternatively just turn packing off.

Okay, I continue looking into this. I checked with ACE now, and ACE can parse the sentence that breaks the LKB.

With the LKB-FOS, I can get rid of the error by deleting RELS from the packing-restrictor configuration in globals.lsp, however the grammar then doesn’t seem to ever finish parsing the sentence. Maybe something circular going on?

I’d still like to understand how to write the rule correctly… And why is it that the very similar vppart rule doesn’t cause such issues…

I note that ACE is telling me (I haven’t noticed this before, but I don’t know how this would be related to the new vppart-ilr):

WARNING: grammar rule `hd_xcmp-v_c' is loopy
WARNING: edge #1733 [hd_xcmp-v_c] == edge #1462 [hd_xcmp-v_c]
WARNING: grammar rule `hd_xcmp-v_c' is loopy
WARNING: edge #1827 [hd_xcmp-v_c] == edge #1526 [hd_xcmp-v_c]
WARNING: grammar rule `hd_xcmp-v_c' is loopy

…and so on (many messages of this kind).

Here’s the rule in question:

basic-extracted-comp-phrase := basic-extracted-arg-phrase & head-compositional & 
  [ SYNSEM canonical-synsem &
	   [ LOCAL [ CAT [ VAL [ SUBJ #subj,
                                 SPR #spr,
                                 COMPS #comps,
                                 CLTS #clts ],
                           MC #mc ],
                     CONT #cont ] ],
                                        SPR #spr,
                                        COMPS < gap 
                                                . #comps >,
                                        CLTS #clts ],
                                  MC #mc ],
                            CONT #cont ],
    C-CONT [ RELS <! !>,
	     HCONS <! !> ] ].

extcomp-v_phrase := basic-extracted-comp-phrase &
  [ HEAD-DTR.SYNSEM.LOCAL.CAT.HEAD verb & [ KEYS.KEY v_event_rel ] ].

I haven’t noticed problems with it before… Furthermore, if I don’t use the new vpart-ilr rule and use the similar vppart-ilr instead, I don’t see these messages from ACE regarding the extracted complement rule.

…and if I disable the extracted complement rule, I start getting such messages regarding the optional complement rule (which also normally doesn’t cause issues).

This happens if you create something with an underspecified COMPS list — both of those rules can then cycle (become “loopy”) because they’re just taking the first thing off that list and there’s an unlimited number of first things.

I see! Indeed, constraining the COMPS fixed that. Thanks, Emily!

@olzama If you were to run ACE with generalisation packing turned off, but with RELS in the packing restrictor then you might run into something like LKB-FOS’s "0th tree from a root” failure, since then ACE would then be using the same packing strategy as LKB-FOS. Could you try that? The option is --disable-generalization

With COMPS constrained (and with RELS still deleted from the packing restrictor) it could well be that LKB-FOS successfully parses your test sentence. The LKB doesn’t check for rule loopiness during parsing.

1 Like