Archive:Frame: Difference between revisions

1,168 bytes added ,  17:00, 28 September 2021
no edit summary
mNo edit summary
No edit summary
Line 1: Line 1:
A '''frame''' is a class of verbs that all, in a certain specific sense, have the "same" argument places, giving rise to the same grammatical behavior. There are two senses of "same", giving rise to two types of frames: '''semantic''' and '''serial''' frames.
A '''frame''' is a class of verbs that all, in a certain specific sense, have the "same" argument places, giving rise to the same grammatical behavior. There are two types of frame: '''semantic''' and '''serial''' frames.


== Semantic frames ==
== Semantic frames ==
Line 77: Line 77:


TODO: what happens to {{t|jıe}}?
TODO: what happens to {{t|jıe}}?
== Why complicate things? ==
If semantic frames can be predictably mapped to serial frames (serial behaviors), we could just describe the rules for serialization in terms of semantic frames. In fact, this is pretty much what the [[refgram]] does.
<div style="border:1px solid black;padding:5px 15px;background:#ffd">
* If there is exactly one non-concrete argument place in the '''type signature''', subordinate and merge there.
* If the '''type signature''' is <code>(c c)</code>, perform genitival serialization in the second argument place.
* If the '''type signature''' is <code>(c)</code>, perform adjectival serialization.
* Otherwise, the verb cannot serialize.
</div>
So it might seem unnecessary to talk about serial frames as a separate "thing".
However, for a long time it has been unclear if there is such a predictable mapping (and it still is a little), and for a long time it was thought that verbs like {{t|she}} can participate in serials, and it was hotly debated whether its <code>(0 0)</code> type signature should have <code>(x 0)</code> or <code>(0 x)</code> serial behavior.
At the very least, a separate notation for serial behaviors still lets us theorize about these things.