Difference in approach between compound(e, x, x) and _and_c(x, x, x)

The ERG models one type of conjunction, as in “I want a soup and a carrot” with a predication that introduces a new variable that represents the combined object. But it represents compound words, as in “I want carrot soup” without such a new variable. Here are the predications used (the full MRS is at the bottom):

_soup_n_1(x13), _carrot_n_1(x18), _and_c(x8,x13,x18)
_soup_n_1(x8), _carrot_n_1(x14), compound(e13,x8,x14)

Is there some underlying linguistic principle that forces the difference here? For my work and scenarios so far, I’d much prefer that compound be shaped like _and_c. Absent that, in the implementation of compound, I end up actually modifying x8 above to be the combined result, which feels icky since normally variables retain their same value through the MRS.

This has puzzled me for a long time and has caused me to do those unnatural feeling gymnastics in Perplexity that I’d like to fix or at least understand.

[ "I want a soup and a carrot"
  TOP: h0
  INDEX: e2 [ e SF: prop TENSE: pres MOOD: indicative PROG: - PERF: - ]
  RELS: < [ pron<0:1> LBL: h4 ARG0: x3 [ x PERS: 1 NUM: sg IND: + PT: std ] ]
          [ pronoun_q<0:1> LBL: h5 ARG0: x3 RSTR: h6 BODY: h7 ]
          [ _want_v_1<2:6> LBL: h1 ARG0: e2 ARG1: x3 ARG2: x8 [ x PERS: 3 NUM: pl ] ]
          [ udef_q<7:26> LBL: h9 ARG0: x8 RSTR: h10 BODY: h11 ]
          [ _a_q<7:8> LBL: h12 ARG0: x13 [ x PERS: 3 NUM: sg IND: + ] RSTR: h14 BODY: h15 ]
          [ _soup_n_1<9:13> LBL: h16 ARG0: x13 ]
          [ _and_c<14:17> LBL: h17 ARG0: x8 ARG1: x13 ARG2: x18 [ x PERS: 3 NUM: sg IND: + ] ]
          [ _a_q<18:19> LBL: h19 ARG0: x18 RSTR: h20 BODY: h21 ]
          [ _carrot_n_1<20:26> LBL: h22 ARG0: x18 ] >
  HCONS: < h0 qeq h1 h6 qeq h4 h10 qeq h17 h14 qeq h16 h20 qeq h22 > ]
[ "I want carrot soup"
  TOP: h0
  INDEX: e2 [ e SF: prop TENSE: pres MOOD: indicative PROG: - PERF: - ]
  RELS: < [ pron<0:1> LBL: h4 ARG0: x3 [ x PERS: 1 NUM: sg IND: + PT: std ] ]
          [ pronoun_q<0:1> LBL: h5 ARG0: x3 RSTR: h6 BODY: h7 ]
          [ _want_v_1<2:6> LBL: h1 ARG0: e2 ARG1: x3 ARG2: x8 [ x PERS: 3 NUM: sg ] ]
          [ udef_q<7:18> LBL: h9 ARG0: x8 RSTR: h10 BODY: h11 ]
          [ compound<7:18> LBL: h12 ARG0: e13 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: x8 ARG2: x14 [ x IND: + ] ]
          [ udef_q<7:13> LBL: h15 ARG0: x14 RSTR: h16 BODY: h17 ]
          [ _carrot_n_1<7:13> LBL: h18 ARG0: x14 ]
          [ _soup_n_1<14:18> LBL: h12 ARG0: x8 ] >
  HCONS: < h0 qeq h1 h6 qeq h4 h10 qeq h12 h16 qeq h18 > ]

Hi,

carrot soup is soup (that is in some way related to carrots, in this case made from it, but this is not always the case e.g. baby food). So referring to it using x8 is the right thing to do, and what the MRS does, the second argument ARG2 of want, the wanted, is x8. a soup and a carrot on the other hand, is neither a soup nor a carrot, but a combination, and so you need to make a new referent, and, which becomes the the second argument ARG2 of want.

Did that make sense?

Very clear!

I think I confused myself because I’m implementing support for referring expressions and not working with actual instances of objects. E.g. if you say “I want stone soup” and there isn’t actually any in the world. The engine still needs to represent it so downstream code could say, “Hahah, yeah I loved that book!”. In that case, there isn’t a way to know that “stone soup” is “soup”, but it has to get represented so later code can inspect it. To do that, I end up modifying the value x8 = "soup" to add a “stone” criteria. That was the icky part, but I think now that it is just an artifact of how I’m modeling these referring expressions and the “instance” case works as you say.

Thanks!