How to determine which predications are restricting the domain of a variable?

First: I’ve hooked up my Perplexity ERG engine to Alexa worldwide. If you have one, just say “open Perplexity Game”. Somehow using your voice to interact feels like a much cooler experience.

I’m working to improve errors. For example, if there is no green door and you say “go through the green door”, Perplexity currently responds with “there isn’t a door”. Very confusing if there is one and it just doesn’t happen to be green.

The problem is that the error is generated in the predication for _door_n_1 in the first tree below. When executing that predicate, the only context it can add to the error is the variable x9 (since that is all it is passed). Currently, I generate the error response by looking up what predication introduced that variable (i.e. _door_n_1) and responding with “there isn’t a door”. Not a great error.

I really want to find a way to collect all the predications that are used to restrict x9 and respond with that. In this case that would be _green_a_2 and _door_n_1, which would generate the response “there isn’t a green door”, which is much better. Note that there are other predicates like _through_p_dir that have x9 as an argument, but aren’t restricting it, that I’d like to ignore.

A slightly more interesting example is at the bottom “go to the cave in the south”, where cave (x9) is also being restricted by a locative preposition _in_p_loc and used (but not restricted) by a directional preposition _to_p_dir. I’m looking for rules that will help me include the first, but exclude the second.

Question: Are there any rules that I can use (even if they are just “it mostly works” type heuristics) for determining which predications are restricting an x variable outside of “The predication that introduces the variable is restricting it”? Is there a way by telling from the argument signature? Or some other metadata? I am trying to avoid having to simply classify every predication by hand…

phrase: go through the green door

                            ┌pron__x:x3
     pronoun_q__xhh:x3,h5,h6┤
                            │                          ┌_green_a_2__ex:e14,x9
                            │                      ┌and┤
                            │                      │   └_door_n_1__x:x9
                            └_the_q__xhh:x9,h11,h12┤
                                                   │   ┌_through_p_dir__eex:e8,e2,x9
                                                   └and┤
                                                       └_go_v_1__ex:e2,x3

    Logic: pronoun_q__xhh(x3, pron__x(x3), _the_q__xhh(x9, and(_green_a_2__ex(e14, x9), _door_n_1__x(x9)), and(_through_p_dir__eex(e8, e2, x9), _go_v_1__ex(e2, x3))))
phrase: go to the cave in the south

                        ┌pron__x:x3
 pronoun_q__xhh:x3,h5,h6┤
                        │                       ┌_south_n_of__xi:x15,i20
                        └_the_q__xhh:x15,h17,h18┤
                                                │                          ┌_cave_n_1__x:x9
                                                │                      ┌and┤
                                                │                      │   └_in_p_loc__exx:e14,x9,x15
                                                └_the_q__xhh:x9,h11,h12┤
                                                                       │   ┌_to_p_dir__eex:e8,e2,x9
                                                                       └and┤
                                                                           └_go_v_1__ex:e2,x3

Logic: pronoun_q__xhh(x3, pron__x(x3), _the_q__xhh(x15, _south_n_of__xi(x15, i20), _the_q__xhh(x9, and(_cave_n_1__x(x9), _in_p_loc__exx(e14, x9, x15)), and(_to_p_dir__eex(e8, e2, x9), _go_v_1__ex(e2, x3)))))

I am not sure if I understood what is your question. Moreover, I have some extra effort to understand your outputs. The format we are all educated to easily read is

[ LTOP: h0
INDEX: e2 [ e SF: comm TENSE: pres MOOD: indicative PROG: - PERF: - ]
RELS: < 
 [ pronoun_q<0:25> LBL: h4 ARG0: x3 [ x PERS: 2 PT: zero ] RSTR: h5 BODY: h6 ]
 [ pron<0:25> LBL: h7 ARG0: x3 ]
 [ _go_v_1<0:2> LBL: h1 ARG0: e2 ARG1: x3 ]
 [ _through_p_dir<3:10> LBL: h1 ARG0: e8 [ e SF: prop TENSE: untensed MOOD: indicative PROG: - PERF: - ] ARG1: e2 ARG2: x9 [ x PERS: 3 NUM: sg IND: + ] ]
 [ _the_q<11:14> LBL: h10 ARG0: x9 RSTR: h11 BODY: h12 ]
 [ _green_a_2<15:20> LBL: h13 ARG0: e14 [ e SF: prop TENSE: untensed MOOD: indicative PROG: bool PERF: - ] ARG1: x9 ]
 [ _door_n_1<21:25> LBL: h13 ARG0: x9 ] >
HCONS: < h0 qeq h1 h5 qeq h7 h11 qeq h13 >
ICONS: < > ]

We can make it even cleaner for discussion if we remove the extra morpho-syntactic contents:

[ LTOP: h0
INDEX: e2 
RELS: < 
 [ pronoun_q<0:25> LBL: h4 ARG0: x3  RSTR: h5 BODY: h6 ]
 [ pron<0:25> LBL: h7 ARG0: x3 ]
 [ _go_v_1<0:2> LBL: h1 ARG0: e2 ARG1: x3 ]
 [ _through_p_dir<3:10> LBL: h1 ARG0: e8  ARG1: e2 ARG2: x9  ]
 [ _the_q<11:14> LBL: h10 ARG0: x9 RSTR: h11 BODY: h12 ]
 [ _green_a_2<15:20> LBL: h13 ARG0: e14  ARG1: x9 ]
 [ _door_n_1<21:25> LBL: h13 ARG0: x9 ] >
HCONS: < h0 qeq h1 h5 qeq h7 h11 qeq h13 >
ICONS: < > ]

Now we can see that _green_a_2 and _door_n_1 share the same LBL h13. In the HCONS constraints, h11 qeq h13 which says that this is the context introduced as RSTR for the variable x9 by the quantifier _the_q.

Yes, sorry, I should have used the straight MRS.

My question is this: semantically x9 represents a “green door” in this MRS. However, x9 is referenced as an argument by _through_p_dir, _the_q, _green_a_2 and _door_n_1. I want an algorithm that takes the MRS and a variable (x9) and returns only the predicates that restricted x9, i.e. _green_a_2 and _door_n_1 (I guess _the_q should be counted as restricting it too…).

Is there a way to write such an algorithm without having special knowledge of what every predicate semantically does? I.e. are there heuristics based on the argument types, order, the names of the predicates, etc?

A quantifier’s RSTR stands for “restriction”. The subtree in the scope tree is precisely what you need.

In your first example: and(_green_a_2__ex(e14, x9), _door_n_1__x(x9)

In your second example: and(_cave_n_1__x(x9), _in_p_loc__exx(e14, x9, x15)). (In this case, x15 is quantified higher in the tree, so you would presumably want to find the restriction of x15’s quantifier, too.)

1 Like

I believe what you want is the logical subexpression in the RSTR (i.e. restriction) argument of the quantifier, after scope resolution. In this case that should be green(x)&door(x). The “through” predicate should end up in the BODY of the quantifier. As pointed out by Alexandre, a close approximation would be the set of predicates whose label is QEQ the RSTR in the un(der)scoped MRS.

1 Like

Seems very logical that the restriction would be the answer. Perfect, thanks! I’ll try that out.

1 Like

Looping back after implementing this to report on how it worked. First off, it is a vast improvement in error reporting: Now I get the following interaction (in a world where there are doors, but no green ones):

Me: "go through the green door”
Perplexity: “there isn’t a green door" 

which makes a ton more sense than “there isn’t a door”. To make it work, I had to finally buck up and use a simple surface generator (which I’ve been avoiding) because responses are now more complex. I ended up using SimpleNLG.

It turns out there are improvements left, though. Using just the RSTR doesn’t give me what I’d expect for this (in a world where the diamond isn’t rough or yellow):

Me: "the rough diamond is yellow"
Perplexity: "No, that isn't true: There is not a rough diamond."

While this is true, as a human I guess I’d expect “there is not a rough yellow diamond”. This isn’t generated because yellow_a_1 is in the BODY:

[ TOP: h0
INDEX: e2
RELS: <
[ _the_q LBL: h4 ARG0: x3 [ x PERS: 3 NUM: sg IND: + ] RSTR: h5 BODY: h6 ]
[ _rough_a_1 LBL: h7 ARG0: e8 [ e SF: prop TENSE: untensed MOOD: indicative PROG: bool PERF: - ] ARG1: x3 ]
[ _diamond_n_1 LBL: h7 ARG0: x3 [ x PERS: 3 NUM: sg IND: + ] ]
[ _yellow_a_1 LBL: h1 ARG0: e2 [ e SF: prop TENSE: pres MOOD: indicative PROG: - PERF: - ] ARG1: x3 ]
>
HCONS: < h0 qeq h1 h5 qeq h7 > ]

                     ┌_yellow_a_1__ex:e2,x3
 _the_q__xhh:x3,h5,h6┤
                     │   ┌_rough_a_1__ex:e8,x3
                     └and┤
                         └_diamond_n_1__x:x3

For now it is good enough, especially since getting the error I want will (I think) involve doing a logical analysis of everything to see what is true or not (so I know whether the yellow part should be included in the error) which is definitely not natural with Perplexity’s processing model. Perplexity naturally wants to fail and report an error at the first point the logic fails, which is rough(X) and diamond(X).

Anyway, no question here unless someone has a deep insight to share. Just wanted to close the loop on how the approach worked.

Thanks for your help!

Actually, I think this example illustrates the distinction between assertion and presupposition. If you say “the rough diamond is yellow”, this presupposes that there is a unique object that is rough and a diamond, and it asserts that that object is yellow. If the presupposition is true, it’s easy to agree or disagree (e.g. there is only one diamond, and it is both rough and yellow: true; there is only one diamound, and it is rough but blue: false). But if the presupposition is false, the sentence is very strange. I think the problem is saying “that isn’t true” in response to a presupposition failure.

Maybe this is clearer if we look at a question, because questions don’t assert anything, but can still have presuppositions:

(context: there is only one diamond; it is not rough)
“is the rough diamond yellow?”

It would be strange to give any of the responses “yes” or “no” or “that isn’t true”.