Preventing modifiers between nouns in a compound noun in the ERG

grammars ERG
1

I asked this question previously in a thread with multiple questions, so to make each thread address only one topic I’m reposting it as multiple threads.

I have an MRS that I’m intending to use to generate strings like “the black car key.” I do get those results out, but I also get things like “the car black key.”

Here is the MRS:

[ TOP: h13                                                                       
   INDEX: x1                                                                      
   RELS: < [ _black_a_1 LBL: h13 ARG0: i14 ARG1: x1 ]                             
           [ compound LBL: h13 ARG0: e10 ARG1: x1 ARG2: x3 ]                      
           [ udef_q LBL: h8 ARG0: x3 RSTR: h6 BODY: h7 ]                          
           [ _car_n_1 LBL: h4 ARG0: x3 ]                                          
           [ _key_n_1 LBL: h13 ARG0: x1 ] >                                       
   HCONS: < h6 qeq h4 > ]

Is there a way to constrain the MRS in such a way that it won’t generate strings like “the car black key”?

2

In my original question I also asked about why we need parses like “[[black car] key]” because that didn’t sound grammatical to me. But Dan clarified in his response that that’s fairly common (e.g. “open-source software”). So “[[black car] key]” would refer to a key specifically for a black car.

An acceptable construction but unusual in the context of a car key.

3

Dan also answered the question about “car black key” in his response, which I will paste here:

For the more objectionable [[N Adj] N] generator outputs like your “car black key”, they will only appear if you gave the generator the less likely MRS for “black car key” where “black” is modifying “car” instead of “key”. But if you want to protect yourself from these odd-sounding outputs in general, you could choose to block the two syntactic rules that license the [[N Adj] N] structures so the generator won’t use them. You do this by adding the following two lines to the end of the file erg/lkb/nogen-rules.set:

n-j_j-cpd_c
n-j_j-t-cpd_c

Then once you recompile the grammar (for ACE) or reload it (for the LKB), you won’t see such outputs from the generator even if the MRS was not quite what you intended. for “black car key”. Note that these two rules are needed for parsing, to account for examples like the following from corpora, often but not always with a hyphen connecting the first noun and the following adjective:

pain-free existence
toll free number
traffic-free road
state subsidized company
user friendly software
avalanche-safe site
water-repellent coat
school-internal shuttle
cost-effective solution
tax deductible contribution
family friendly beach
drought tolerant plants
world-famous actor
color blind policy
power hungry politician
rock steady grip
coal-black night
care-free existence
fur-clad ancestors

While I think these N-Adj nouns should have a somewhat different semantics from the corresponding Adj+N ones, I so far have not landed on a satisfying MRS for them, so the MRSs are sadly still the same, which is why the N-Adj ones get generated from the Adj+N ones. Hence it seems okay for you to block the two rules above for the generator.

4

Thanks @Dan for responding on the other thread. I’m splitting the threads up now to make it easier.

You mention in your response that I should only generate “car black key” if the MRS I use for generation has “black” modifying “car” instead of “key,” but I’m fairly certain the MRS I gave the generator does have “black” modifying “key” (unless I’m misunderstanding):

[ TOP: h13                                                                       
   INDEX: x1                                                                      
   RELS: < [ _black_a_1 LBL: h13 ARG0: i14 ARG1: x1 ]                             
           [ compound LBL: h13 ARG0: e10 ARG1: x1 ARG2: x3 ]                      
           [ udef_q LBL: h8 ARG0: x3 RSTR: h6 BODY: h7 ]                          
           [ _car_n_1 LBL: h4 ARG0: x3 ]                                          
           [ _key_n_1 LBL: h13 ARG0: x1 ] >                                       
   HCONS: < h6 qeq h4 > ]
5

Yes, sorry, I goofed in what I wrote about “car black key”: if “black” is modifying “key” as in your MRS, then you’ll get “car black key” from the generator, but not if it is modifying “car”, since “black” has to be a pre-modifier of its noun.

6

So would you say that the MRS I have is incorrect for what I’m trying to do? I thought it was right since what I’m trying to communicate is that it’s a [black [car key]]. Is there a way to prevent modifiers inserting themselves in between the tokens of a compound noun like this?

7

I’m confused here too – I thought @ecconrad ‘s MRS has black modifying key, and car as compounded with key. So why is the modifier of key allowed to interrupt the compound?

8

Bumping this thread again!

I’m still having issues where I unexpectedly get a modifier of a compound noun in between the two elements of the compound noun:

[ TOP: h25
  INDEX: e22
  RELS: < [ unknown LBL: h21 ARG: x17 ARG0: e22 ]
          [ def_udef_a_q LBL: h20 ARG0: x17 RSTR: h18 BODY: h19 ]
          [ _black_a_1 LBL: h12 ARG0: i1 ARG1: x17 ]
          [ compound LBL: h12 ARG0: e13 [ e PROG: - ] ARG1: x17 ARG2: x6 ]
          [ udef_q LBL: h11 ARG0: x6 RSTR: h9 BODY: h10 ]
          [ _car_n_1 LBL: h7 ARG0: x6 ]
          [ _key_n_1 LBL: h12 ARG0: x17 ] >
  HCONS: < h9 qeq h7 h18 qeq h12 h25 qeq h21 > ]

A black car key
The black car key.
The car black keys
The car black keys.
Car black keys
...

Interestingly, I also tried “tasty vanilla cake” and did not get the same results:

[ TOP: h25
  INDEX: e22
  RELS: < [ unknown LBL: h21 ARG: x17 ARG0: e22 ]
          [ def_udef_a_q LBL: h20 ARG0: x17 RSTR: h18 BODY: h19 ]
          [ _tasty_a_1 LBL: h12 ARG0: e1 ARG1: x17 ]
          [ compound LBL: h12 ARG0: e13 [ e PROG: - ] ARG1: x17 ARG2: x6 ]
          [ udef_q LBL: h11 ARG0: x6 RSTR: h9 BODY: h10 ]
          [ _vanilla_n_1 LBL: h7 ARG0: x6 ]
          [ _cake_n_1 LBL: h12 ARG0: x17 ] >
  HCONS: < h9 qeq h7 h18 qeq h12 h25 qeq h21 > ]

The tasty vanilla cakes
Tasty vanilla cakes
Tasty vanilla cake
The tasty vanilla cake
A tasty vanilla cake
The tasty vanilla cakes.
Tasty vanilla cakes.
The tasty vanilla cake.
Tasty vanilla cake.
A tasty vanilla cake.
Tasty vanilla cake
Tasty vanilla cake.

But when I switched out “tasty” for a color I did:

[ TOP: h25
  INDEX: e22
  RELS: < [ unknown LBL: h21 ARG: x17 ARG0: e22 ]
          [ def_udef_a_q LBL: h20 ARG0: x17 RSTR: h18 BODY: h19 ]
          [ _white_a_1 LBL: h12 ARG0: i1 ARG1: x17 ]
          [ compound LBL: h12 ARG0: e13 [ e PROG: - ] ARG1: x17 ARG2: x6 ]
          [ udef_q LBL: h11 ARG0: x6 RSTR: h9 BODY: h10 ]
          [ _vanilla_n_1 LBL: h7 ARG0: x6 ]
          [ _cake_n_1 LBL: h12 ARG0: x17 ] >
  HCONS: < h9 qeq h7 h18 qeq h12 h25 qeq h21 > ]

The white vanilla cakes
White vanilla cakes
White vanilla cake
The white vanilla cake
Vanilla white cakes
Vanilla white cake
...

So I thought maybe something was odd about colors but then I replaced “black” in the “black car key” example with “tasty” (lol) and still had the problem:

[ TOP: h25
  INDEX: e22
  RELS: < [ unknown LBL: h21 ARG: x17 ARG0: e22 ]
          [ def_udef_a_q LBL: h20 ARG0: x17 RSTR: h18 BODY: h19 ]
          [ _tasty_a_1 LBL: h12 ARG0: e1 ARG1: x17 ]
          [ compound LBL: h12 ARG0: e13 [ e PROG: - ] ARG1: x17 ARG2: x6 ]
          [ udef_q LBL: h11 ARG0: x6 RSTR: h9 BODY: h10 ]
          [ _car_n_1 LBL: h7 ARG0: x6 ]
          [ _key_n_1 LBL: h12 ARG0: x17 ] >
  HCONS: < h9 qeq h7 h18 qeq h12 h25 qeq h21 > ]

Cars tasty key
Tasty car key
A cars tasty key
The cars tasty key
The cars tasty keys.
The cars tasty keys
...

For all of these examples the process of composition is that I first build the compound noun (resulting in the TOP and INDEX coming from the compound predicate, whose own TOP and INDEX come from the ARG1 i.e. the head of the compound)

However, I also had another example where I was trying to make a compound out of a proper noun + an adj+N (Adirondack Regional Airport … ignore that we discussed this isn’t really the analysis, I wanted to try it to see the results anyway) and a similar thing happened:
```

[ TOP: h25
  INDEX: e22
  RELS: < [ unknown LBL: h21 ARG: x17 ARG0: e22 ]
          [ def_udef_a_q LBL: h20 ARG0: x17 RSTR: h18 BODY: h19 ]
          [ compound LBL: h12 ARG0: e13 [ e PROG: - ] ARG1: x17 ARG2: x6 ]
          [ udef_q LBL: h11 ARG0: x6 RSTR: h9 BODY: h10 ]
          [ named LBL: h7 ARG0: x6 CARG: "Adirondack" ]
          [ _regional_a_1 LBL: h12 ARG0: e1 ARG1: x17 ]
          [ _airport_n_1 LBL: h12 ARG0: x17 ] >
  HCONS: < h9 qeq h7 h18 qeq h12 h25 qeq h21 > ]

A Adirondacks, regional airport
The Adirondacks regional airport
The regional Adirondacks airports
An Adirondacks, regional airport
The regional Adirondacks, airports.
The regional Adirondacks airport
...

I see now that even though I conceptualized these as being different because of the order that I composed them (one being NN that then gets composed with an adjective, the other being Adj+N that then participates in a compound) the MRS itself actually ends up being the same structure…

I’m sort of at a loss here. I feel like these two things should have different MRSs but I’m not seeing how to achieve the results I want.

I will admit that the Adirondack Regional Airport example is troublesome because I tried to build it compositionally rather than using either of the proper noun suggestions from the other thread, and I can’t really think of a “normal” string that’s a compound between an N and an Adj+N, so maybe I can forget about this type of construction.

But I still feel like “car black key” should be something I can block while retaining the fact that it is the key that is black and not the car.

9

As noted in our recent conversation, your query led to identifying a rather long-present bug in the ERG that allowed the unwanted analysis of “[car [black key]]” that you rightly object to. Below is a patch to the relevant lexical type for color adjectives which will exclude that analysis. You can replace the existing definition in lextypes.tdl for the type aj_-_i-color_lexent with the following, either for the 2023 or the 2025 version of the ERG:

aj_-_i-color_lexent := norm_adj_word &
[ SYNSEM adj_unsp_ind_onearg_synsem &
[ LOCAL [ CAT [ HEAD.MINORS.MIN color_rel,
VAL.SPR.FIRST.LOCAL.CONT.HOOK.XARG #xarg ],
CONT [ HOOK [ INDEX #xarg,
XARG #ind ],
RELS <! relation !> ] ],
MODIFD.LPERIPH bool,
LKEYS.KEYREL.ARG1 #ind & basic_non_expl-ind ] ].