Closed olzama closed 3 weeks ago
I just turned this one up, too. Also, this rule doesn't seem well integrated with other uses of head-adj. When adnominal possessives as modifiers are in the same grammar, ambiguity ensues. Who added this rule, and what is meant to be special about it? (The constraints added on the rule types seem redundant with the info that should be in the modifiers themselves, so I'm wondering what purposes they serve.)
I'm afraid I added it, and I know there was a reason but I no longer remember because it's been a few years. It is likely that this was a confused analysis on my part (what you say about the modifiers). The easiest way to check would be to change the references (in the customization system) to head-adj and see what breaks in the wh- regression tests.
@KerenR3 if you are interested in exploring more in this space, would you be up for trying the experiment that @olzama suggests in this thread? That is -- find all of the places in the code where there is my-head-adj and change those to head-adj (look for my-adj-head, too, just in case) and run the regression tests and then report back here on what breaks.
Sure, I can try that and see what happens.
Thank you!
It looks like doing the above causes two regression tests to fail (wh18-aux-inv-both and wh-dev-ckt-mini), both due to having extra parses.
Wh18-aux-inv-both fails because MOD is unconstrained on the subj-v-inv-rule (in the yes_no_questions library) which allows auxiliaries to serve as modifiers.
Wh-dev-ckt-mini fails because MOD is unconstrained on the specifier version of possessor_pron_lex (in the adnominal_possession library), allowing these possessor pronouns to act as modifiers.
It's mysterious to me why the extra head-adj rules would get around this, but it also sounds like those are issues that should be fixed anyway. Can you try adding [ MOD < > ] to both of those other places and see how that fares on the regression tests?
Adding MOD < > to the appropriate places causes the failing regression tests to pass without breaking any of the other tests. If I am understanding it correctly, the extra head-adj rules constrain the non-head daughter to be an adjective, adverb, or adposition which prevents either auxiliaries or possessor nouns from serving as modifiers.
Got it! Let's go with just the regular head-adj rules and then those two fixes then :)
Sure! Once those two rules are removed, the only thing adverbs_adpositions.py is doing is adding the head-adj rules to rules.tdl and adding [SYNSEM.LIGHT -] as a constraint for bare-np-phrase. Should I try to look for different places for these few lines and get rid of adverbs_adpositions.py, or just remove the rules and leave the rest as is?
(As discussed today) -- I think you want to remove the statements adding the my- rules and leave the rest as is. Presumably, at some future point, someone will work more on adverbs & adpositions and there will be more to add to this file.
@KerenR3 @emilymbender I was going through looking for the next bug to work on and saw that this is merged but the issue is not closed - can it be?
I think this one can be closed, although I also think it inadvertently caused bug #717 since whenever head-adj-int-phrase is added to rules.tdl it should be called head-adj-int and not just head-adj.
The rules are added by adverbs_adpositions.py. The name of the phrase should be something distinct from just head-adj-int, under the current analysis, but it should of course not be "my".