Since nobody has piped in, I’ll take my best shot: I only get one MRS for “How is your salad?”, which is the one above. So I’m assuming there isn’t a “better” interpretation available and we need to figure this one out.
Ignoring the straightforward predications that make x3 represent “your salad” leaves this part of the tree which is the challenging part:
┌────── property(x6)
└─ which_q(x6,RSTR,BODY) ┌──── unspec_adj(e2,x3)
└─ prpstn_to_prop(e9,ARG1,x6)
It seems like this subtree is attempting to do a “meta” or “second order” type operation on x3 where x6 ends up with all the actual predication names like _delicious_a_1 or _cold_a_1 that “would have been true” had they replaced the name unspec_adj in unspec_adj(e2, x3).
Using that as a working theory, I’d say that:
property(x6) restricts x6 to be predicate names like _delicious_a_1 that are shaped like an adjective (i.e. have arguments (e,x)). I’m assuming that is what “property” is implying.
prpstn_to_prop(e9,ARG1,x6) doesn’t appear anywhere in the docs and might mean “proposition to property” or “preposition to property”. I’m guessing the former. Further, I’m guessing that its job is to unify the “property” in x6 (where “property” is a predication name as described above) to the name of the predication in ARG1 (as part of the “second-orderness”). Finally, I suspect that prpstn_to_prop is also only true if its ARG1 is true after it has been successfully name-unified with the property in x6.
So, for example, this would be true – but only if x3 is “cold”:
prpstn_to_prop(e9, _cold_a_1(e2,x3), _cold_a_1) --> true
but this would be false, even if x3 is “cold” since _dirty_a_1 doesn’t unify with _cold_a_1:
prpstn_to_prop(e9, _cold_a_1(e2,x3), _dirty_a_1) --> false
Also, if x3 is “cold”, you could do this:
prpstn_to_prop(e9, _cold_a_1(e2,x3), x99) --> now: x99 == _cold_a_1
I’m then assuming that the unspec_adj in unspec_adj(e2, x3) acts like a kind of “predication name variable”. Kind of like saying: x9(e2, x3). It allows the name unspec_adj to act like a variable which can be unified with any predication name. This is another key part of the “second-orderness” of the tree.
So: unspec_adj(e2,x3) will be true if any adjective in the universe is true of x3, and unspec_adj will be unified with the name of any that were.
With all of that in place, I’d describe what is happening like this:
┌────── property(x6)
└─ which_q(x6,RSTR,BODY) ┌──── unspec_adj(e2,x3)
└─ prpstn_to_prop(e9,ARG1,x6)
prpstn_to_prop finds all adjectives in the universe that are true of x3 by evaluating unspec_adj(e2,x3). For each adjective that was true of x3 it takes the predication name that got unified with unspec_adj and compares it with x6. Since x6 is restricted to “any adjective in the universe”, it will always succeed, and thus x6 will hold the predication name of all adjectives that are true of x3.
Of course, this wouldn’t account for “The salad is lit” (as my son would say) since “lit” has the arguments: _light_v_cause(e2,i8,x3) so some part of my theory must be wrong…
@Dan (or anyone), is this theory remotely true?
