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?