Native lexical entry not triggered for some tokens

grammars SRG
#1

When trying to parse Los gatos ladran:

Mysteriously, in that chart, the appropriate edge for the token gatos, a native lexical entry for a plural common noun, is missing:

Screen Shot 2023-01-04 at 7.29.09 PM

The highlighted thing is (a) something that originates from a generic lexical entry; and (b) something that underwent a rule which made it require a complement (NOTE! This is a rule similar to the one missing from the chart here!). So the head-specifier rule cannot apply, since the complement is missing.

Why??..

In the grammar, I have of course:

ncmp000 := 
%suffix (ncmp000 ncmp000)
n_masc-pl_ilr.

I also of course have the lexical entry:

n_-_c_native_le := n_-_c_lex & native_le
  """
  This is a native lexical entry type, for words that are in the lexicon.
  """.

The corresponding sentence with a singular subject parses:

Screen Shot 2023-01-04 at 7.27.20 PM
Screen Shot 2023-01-04 at 7.27.20 PM718×410 19.9 KB

why could this be?

Lexical entry filtered out? How to understand why?
#2

I suppose what might be happening is, perro (pr gato or whatever) is found in the lexicon so of course everything works:

perro_n := n_-_c_native_le &
  [ STEM < "perro" >,
    SYNSEM.LKEYS.KEYREL [ ARG0.SORT ani,
                          PRED "_perro_n_rel" ] ].

But perros is not in the lexicon, and I suppose something is still missing in the grammar to link the input to the lexical entry?.. In the YY input, both the TAG and the FORM are present:

(1, 0, 1, <0:3>, 1, "el" "los", 0, "da0mp0", "da0mp0" 0.992728) (2, 1, 2, <4:10>, 1, "perro" "perros", 0, "ncmp000", "ncmp000" 1) (3, 2, 3, <11:17>, 1, "ladrar" "ladran", 0, "vmip3p0", "vmip3p0" 1) (4, 3, 4, <18:19>, 1, "." ".", 0, "fp", "fp" 1)

Should work but I guess something is still missing.

#3

This is basically the same issue as this one.

Some of the lexical rules inherit, in the original grammar, from basic-lex-rule and thus have their TRAITS undespecified and as a result they get filtered out by lexical filtering rules.

The solution is not obvious because having the rules inherit from lex-rule instead leads to regressions (parses lost elsewhere) and introducing TRAITS at the level of basic-lex-rule leads to regressions also (although fewer). So, the specific solution still needs to be worked out but the reason is the same as in the issue linked above.

#4

Why not create another subtype of basic-lex-rule that just adds the TRAITS identity?

basic-lex-rule – as is
traits-lex-rule := basic-lex-rule & [ … add TRAITS identity ].
lex-rule := traits-lex-rule.

Then the problematic rules can inherit from traits-lex-rule.

1 Like
#5

Yes, that is my plan for now. It would be nice to not have to fish them out and just be able to “simply” fix everything in one go but given the regressions, that’s not an option.

#6

Actually, I may be additionally confused by my test suite setup right now… I am seeing weird things :). I will talk about it in the meeting and might then create a new post about it. Right now I am seeing regressions in tsdb but not when I individually parse sentences with ACE. Given that I use ACE separately, this may be an issue with how I set up the tsdb profiles…