Ah, I see.
That makes sense, but I also am unsure how then I would handle situations with multiple holes because it seems like I would need to “know” what holes the lexical item has in order to apply rules correctly.
Off the top of my head it’s difficult for me to think of a situation in a referring expression involving multiple holes. But for example if I were dealing with verbs instead, and had
_give_v_1, which has (at least) two holes (
_give_v_1 : ARG0 e, ARG1 i, ARG2 u, [ ARG3 i ].), it seems that in the case of generation I would have to know which complement fills which hole, so just having an operator that fills a complement hole seems like it would result in possibilities where I put them in the wrong order sometimes.
I can’t immediately see how the paper addresses this, other than I think having different rules for comp1 and comp2.
So then I’m imagining say I had to generate
give a gift to them … the way my algorithm is going to work is that first it would just create the EP for the head of the whole phrase, so
give. Then it would go down the child nodes of that root node and build those phrases and then return back up to combine with the head. So my problem is when I go down to the
gift node and apply the right rules to get
a gift, how then when I come back up do I know that it belongs in
ARG1 and not
ARG2? I think I can see at least that putting
to them in
ARG1 would be unacceptable because it requires something of type
i, but nothing would stop me from mistakenly initially putting
a gift in
ARG2. (Or if I did
give me a gift then nothing would stop me from mixing that up either).
As I’m typing this I just had the thought that maybe whatever rule I would have in that case for my
give node would just have to be smart enough to know which child is the recipient and which child is the thing given. In which case it could shake out something like this:
give_mrs = ep('give_v_1')
item_mrs = build_phrase(give_node.get_child_with_edge_label('item'))
recipient_mrs = build_phrase(give_node.get_child_with_edge_label('recipient'))
arg2_filled_mrs = fill_arg2(give_mrs, recipient_mrs)
arg1_filled_mrs = fill_arg1(arg2_filled_mrs, item_mrs)
So in this case I have general rules that handle filling holes for an
ARG2 but then I have a more “high level” rule for handling the graph and its structure that employs these other rules.
The issue I see here would be that this is perhaps too general and doesn’t account for whether filling the hole is scopal or not and requires adding a qeq constraint.
I suppose I’ll just post this now as I continue to ponder and see if there’s any feedback on this initial thought.