How to determine the "output" of a scopal argument in a predicate like _put_v_1(exxh)

I’m not sure of the right terms to use here, so I’ll try to muddle through: The phrase “put the rock on the table” generates a first parse using ACE that is shown below. It has the _put_v_1 predicate which has arguments: exxh. I’m looking for insight on how to interpret the last, scopal, arg h.

When scope-resolving the MRS into a tree, valid resolutions can put several different tree structures there, two are show below after the MRS. One is simply the predicate _on_p_loc__exx, and the other is a quantifier _the_q__xhh with two scopal arguments of its own.

That last scopal argument of _put_v_1 indicates where to put something and the attached tree indicates where. However, I’ve not been able to figure out a general approach to fishing out the “output variable” that holds the “where” in that tree (x16 in these two examples) .

Does anyone know of a good approach working this out?

[ TOP: h0
INDEX: e2
RELS: < 
[ _the_q__xhh LBL: h10 ARG0: x8 [ x PERS: 3 NUM: sg ] RSTR: h11 BODY: h12 ]
[ _rock_n_1__x LBL: h13 ARG0: x8 [ x PERS: 3 NUM: sg ] ]
[ _the_q__xhh LBL: h17 ARG0: x16 [ x PERS: 3 NUM: sg IND: + ] RSTR: h18 BODY: h19 ]
[ _table_n_1__x LBL: h20 ARG0: x16 [ x PERS: 3 NUM: sg IND: + ] ]
[ pronoun_q__xhh LBL: h4 ARG0: x3 [ x PERS: 2 PT: zero ] RSTR: h5 BODY: h6 ]
[ pron__x LBL: h7 ARG0: x3 [ x PERS: 2 PT: zero ] ]
[ _put_v_1__exxh LBL: h1 ARG0: e2 [ e SF: comm TENSE: pres MOOD: indicative PROG: - PERF: - ] ARG1: x3 ARG2: x8 ARG3: h9 ]
[ _on_p_loc__exx LBL: h14 ARG0: e15 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: x8 ARG2: x16 ]
>
HCONS: < h0 qeq h1 h5 qeq h7 h9 qeq h14 h11 qeq h13 h18 qeq h20 > ]

                       ┌_rock_n_1__x:x8
 _the_q__xhh:x8,h11,h12┤
                       │                       ┌_table_n_1__x:x16
                       └_the_q__xhh:x16,h18,h19┤
                                               │                       ┌pron__x:x3
                                               └pronoun_q__xhh:x3,h5,h6┤
                                                                       └_put_v_1__exxh:e2,x3,x8,h9┐
                                                                                                  └_on_p_loc__exx:e15,x8,x16
Logic: _the_q__xhh(x8, _rock_n_1__x(x8), _the_q__xhh(x16, _table_n_1__x(x16), pronoun_q__xhh(x3, pron__x(x3), _put_v_1__exxh(e2, x3, x8, _on_p_loc__exx(e15, x8, x16)))))


                       ┌_rock_n_1__x:x8
 _the_q__xhh:x8,h11,h12┤
                       │                       ┌pron__x:x3
                       └pronoun_q__xhh:x3,h5,h6┤
                                               └_put_v_1__exxh:e2,x3,x8,h9┐
                                                                          │                       ┌_table_n_1__x:x16
                                                                          └_the_q__xhh:x16,h18,h19┤
                                                                                                  └_on_p_loc__exx:e15,x8,x16
Logic: _the_q__xhh(x8, _rock_n_1__x(x8), pronoun_q__xhh(x3, pron__x(x3), _put_v_1__exxh(e2, x3, x8, _the_q__xhh(x16, _table_n_1__x(x16), _on_p_loc__exx(e15, x8, x16)))))

I’m not sure what’s meant by “output”.

I think this comes back to a previous discussion.

Maybe I could rephrase it like this. Each node in a scope tree defines a function from its free variables to a truth value. These are defined bottom-up through the tree: each non-terminal node’s function is defined in terms of its children’s functions. I think you’ve already implemented this for quantifier nodes, but the same principle applies for other nodes too (with the difference that no variables are bound).

How to combine the children’s functions depends on the particular predicate. In this case, you have to define how to go from a function that checks whether something is on a table to a function that checks whether someone is putting something on a table.

This can happen before or after quantification over tables – for “the”, the parses are equivalent. But suppose there are three tables side by side and you said “put the rock on every table”. This would be a weird request, but could either mean putting it on each table at a time (first parse above), or if it’s a large enough rock putting it on all three tables simultaneously (second parse above).

As you describe, each predicate I’ve encountered with a scopal argument is implemented differently and some have been relatively easy. For example can_v_modal__eh simply has to evaluate the tree represented by its last argument to see if there is a set of values that can be applied to make that tree true in the current world. If so, then it “can” be done (assuming its first event argument hasn’t been qualified in some way).

My issue with put_v_1__exxh might be more obvious by zooming in to look at its arguments:

  • the first variable is an event that represents the “putting” itself and variations like “slowly”
  • the second variable is an individual that is the one “doing the putting”
  • the third variable is an individual representing the “thing being put somewhere”
  • the final variable is a scope tree that represents “where to put the thing”

For the put_v_1__exxh my hypothesis is that, if you find a set of values for the variables of the last argument’s scope tree that are true in a given world, one of those variables will represent “where to put the thing”. This is what I’m calling the “output”. With that output, I can then easily implement the logic for put_v_1__exxh since it now has a set of e or x variables to work with and not a tree. I’m struggling to find the set of rules that tell me, by looking at the MRS and the scope tree, which of those variables is that “output”.

Currently, for put_v_1__exxh, I have a simple rule that checks to see if the “tree” is a single locative preposition. If it is, then I can fish out the “where” systematically since locative prepositions all have a well known form and behavior (in my implementation). This obviously doesn’t work for the second case where there actually is a tree. In that case, it turns out the “output” of the tree is still the second argument of the locative preposition _on_p_loc__exx but I can only tell that because I’m looking at it as a human and it is “obvious”, I haven’t found a good rule.

Looking at phrases that would have two locative prepositions in the put_v_1__exxh tree like “put the card on the desk that the box is in” it seems like a rule could be something like:

Look for a locative preposition in the tree that shares its second argument with the third argument of put_v_1__exxh (the ‘thing being put somewhere’). That locative preposition is the one that indicates ‘where’ to put the thing

So maybe that’s my answer?

                       ┌_card_n_1__x:x8
 _the_q__xhh:x8,h11,h12┤
                       │                       ┌pron__x:x3
                       └pronoun_q__xhh:x3,h5,h6┤
                                               └_put_v_1__exxh:e2,x3,x8,h9┐
                                                                          │                       ┌_box_n_of__xi:x22,i26
                                                                          └_the_q__xhh:x22,h23,h24┤
                                                                                                  │                       ┌_on_p_loc__exx:e15,x8,x16
                                                                                                  └_the_q__xhh:x16,h18,h19┤
                                                                                                                          │   ┌_desk_n_1__x:x16
                                                                                                                          └and┤
                                                                                                                              └_in_p_loc__exx:e27,x22,x16

Logic: _the_q__xhh(x8, _card_n_1__x(x8), pronoun_q__xhh(x3, pron__x(x3), _put_v_1__exxh(e2, x3, x8, _the_q__xhh(x22, _box_n_of__xi(x22, i26), _the_q__xhh(x16, and(_desk_n_1__x(x16), _in_p_loc__exx(e27, x22, x16)), _on_p_loc__exx(e15, x8, x16))))))

I find the notion that there is guaranteed to be a unique “x” that is the place to put something a bit optimistic. I believe the ERG aims to handle resultatives such as this by having that scopal argument correspond to a state of affairs that is true following the verb’s action but not before, so in the context of interpreting commands in your game world, the solution might be to assert the truth of that 4th argument rather than trying to heuristically navigate through its contents. Otherwise might you not run afoul of examples like “Put the chocolate chip cookies out of sight and out of your mind.”? My expectation would be that the 4th argument of “put” will be very approximately: and_c(out_of(x, sight), out_of(x, mind)). If I recall correctly you already have a way of causing assertions like “the cookie is on the table” to come true, so this would seem a clean extension. Ideally you need to take the lexical semantics of “put” into consideration regarding the manner in which the result clause comes true, but to a first approximation the most important thing about it is how the state of the world has changed when the dust settles, which is what is encoded in that scopal argument.

1 Like

Interesting! I never thought to look at it that way. I could see that working for the case of put_v_1__exxh but I have a similar issue with, for example: “what do you see on the first page?” and that is a case where I definitely need to fish out the “output” of the subtree, unless I’m missing something…

                          ┌pron__x:x3
 pronoun_q__xhh:x3,h11,h12┤
                          │                     ┌thing__x:x5
                          └which_q__xhh:x5,h7,h8┤
                                                └_see_v_1__exxh:e2,x3,x5,h13┐
                                                                            │                       ┌_on_p_loc__exx:e15,x5,x16
                                                                            └_the_q__xhh:x16,h18,h19┤
                                                                                                    └ord__cexh:1,e22,x16,h46992┐
                                                                                                                               └_page_n_1__x:x16

Logic: pronoun_q__xhh(x3, pron__x(x3), which_q__xhh(x5, thing__x(x5), _see_v_1__exxh(e2, x3, x5, _the_q__xhh(x16, and(ord__cex(1, e22, x16), _page_n_1__x(x16)), _on_p_loc__exx(e15, x5, x16)))))

In the case of “What do you see on the first page?”, I would expect you would want to interpret “you see (some proposition)” as asserting the truth of “some proposition.” That is, shouldn’t your interpretation, at least in this case, of “see(you,thing,on(x,page1))” be “on(x,page1) & see(you,thing)”? Again I don’t see why you would fish around inside the subtree; just promote it. Of course if you have a theory of when “you” can “see” some proposition holding of some thing that is more developed than my proposal, i.e. the “thing” being visible to “you” and the proposition holding, use that. Certainly verbs like “believe” or “deny” demand more nuanced treatments.

1 Like

Ahh, OK, now I understand what you mean. That’s a great point. You are totally right, it does seem like simply evaluating the subtree before evaluating (or during the evaluation of) see_v_1 (or put_v_1) would work great since Prolog would naturally fill in the variables. No fishing needed.

Good idea!

This turns out to be exactly what I was doing with scopal arguments for quantifiers. I somehow never made the connection with non-quantifiers that had scopal arguments since I was thinking about them as a “different class” of predicate. :roll_eyes:

This really clears up a hole in my processing of scope resolved trees that has been bothering me for a while. Thank you!

1 Like