748
edits
Archive:Frame: Difference between revisions
m
Uakci moved page Frame (beta) to Archive:Frame without leaving a redirect
No edit summary |
m (Uakci moved page Frame (beta) to Archive:Frame without leaving a redirect) |
||
| (15 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
A '''frame''' is a class of verbs that all, in a certain specific sense, | A '''frame''' is a class of verbs that all, in a certain specific sense, take the "same" types of arguments in the same order, giving rise to the same grammatical behavior. There are two types of frames, corresponding to two different senses in which a pair of predicates can have the "same" argument structure. The types are '''semantic''' frames and '''serial''' frames. | ||
== Semantic frames == | == Semantic frames == | ||
A '''semantic frame''' is a class of verbs that all have the same | A '''semantic frame''' is a class of verbs that all have the same number of argument places, of the same '''types''', in the same order. | ||
<div style="border:1px solid black;padding:5px 15px;background:#ffd"> | <div style="border:1px solid black;padding:5px 15px;background:#ffd"> | ||
| Line 13: | Line 13: | ||
* <code>1</code> means the place must be filled with a ''property''. | * <code>1</code> means the place must be filled with a ''property''. | ||
** Often such slots are filled with a {{Tone|5}} content clause with one {{t|ja}} in it. | ** Often such slots are filled with a {{Tone|5}} content clause with one {{t|ja}} in it. | ||
** In the dictionary, | ** In the dictionary, look for the words "satisfying property ___" to recognize these slots. | ||
* <code>2</code> means the place must be filled with a ''binary relation''. | * <code>2</code> means the place must be filled with a ''binary relation''. | ||
** Often such slots are filled with a {{Tone|5}} content clause with ''two'' instances of {{t|ja}} in it. | ** Often such slots are filled with a {{Tone|5}} content clause with ''two'' instances of {{t|ja}} in it. | ||
** In the dictionary, | ** In the dictionary, look for the words "relation ___" to recognize these slots. | ||
</div> | </div> | ||
| Line 23: | Line 23: | ||
For example: {{t|leo}} ("tries to") and {{t|juoq}} ("should") both take one ''concrete'' argument followed by one ''property'' argument. This is expressed by the type signature <code>(c 1)</code>. These verbs have the same type signature, so they belong to the same semantic frame. | For example: {{t|leo}} ("tries to") and {{t|juoq}} ("should") both take one ''concrete'' argument followed by one ''property'' argument. This is expressed by the type signature <code>(c 1)</code>. These verbs have the same type signature, so they belong to the same semantic frame. | ||
Furthermore, each semantic frame in Toaq has an arbitrary '''representative''' chosen for it, used as a handy way to refer to the frame. For example, the semantic frame of all verbs with type signature <code>(c 1)</code> is called the '''LEO (semantic) frame'''. LEO consists of all the verbs whose argument places are just like {{t|leo}}'s. | Furthermore, each semantic frame in Toaq has an arbitrary '''representative''' chosen for it, used as a handy way to refer to the frame. For example, the semantic frame of all verbs with type signature <code>(c 1)</code> is called the '''{{class|LEO|c 1}} (semantic) frame'''. {{class|LEO}} consists of all the verbs whose argument places are just like {{t|leo|{{x}} tries to satisfy property {{x}}}}'s. | ||
We say that “{{t|juoq}} is in the LEO frame” or “{{t|juoq}} is in | We say that “{{t|juoq}} is in the {{class|LEO}} frame” or “{{t|juoq}} is in {{class|LEO}}”. We also often just say that “{{t|juoq}} is <code>(c 1)</code>”. | ||
== Serial frames == | == Serial frames == | ||
| Line 35: | Line 32: | ||
Again, each such frame is identified by a '''serial signature''' and a representative. | Again, each such frame is identified by a '''serial signature''' and a representative. | ||
But this time, the elements of the signature describe "what happens to this argument slot, when this verb is the first | But this time, rather than describing "what can this argument slot be filled with?", the elements of the signature describe: "what happens to this argument slot, when this verb is the first (left-hand) verb in a serial verb?" | ||
<div style="border:1px solid black;padding:5px 15px;background:#ffd"> | <div style="border:1px solid black;padding:5px 15px;background:#ffd"> | ||
* | These are the possible '''serial types''' an argument place can have: | ||
* <code>c</code> means that this argument place remains untouched and will still be there in the resulting serial verb. | |||
* <code>0</code> means that this place will be subsumed by all of the right-hand verb's arguments: | * <code>0</code> means that this place will be subsumed by all of the right-hand verb's arguments: | ||
** <span style="background:#ddf;padding:4px"><b style="color:red"> | ** <span style="background:#ddf;padding:4px"><b style="color:red">c</b> wants <b style="color:gray">0</b> to be the case</span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0">c</b> sits on <b style="color:green">c</b></span> = <span style="background:#ddf;padding:4px"><b style="color:red">c</b> wants <b style="color:#ba0">c</b> to sit on <b style="color:green">c</b></span> | ||
* <code>1</code> means that this place will be subsumed by all of the right-hand verb's arguments, '''merging''' with its first one: | * <code>1</code> means that this place will be subsumed by all of the right-hand verb's arguments, '''merging''' with its first one: | ||
** <span style="background:#ddf;padding:4px"><b style="color:red"> | ** <span style="background:#ddf;padding:4px"><b style="color:red">c</b> tries to satisfy <b style="color:gray">1</b></span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0">c</b> sits on <b style="color:green">c</b></span> = <span style="background:#ddf;padding:4px"><b style="color:red">c</b> tries to sit on <b style="color:green">c</b></span> | ||
* <code>2</code> means that this place will be subsumed by all of the right-hand verb's arguments, '''merging''' with its first two: | * <code>2</code> means that this place will be subsumed by all of the right-hand verb's arguments, '''merging''' with its first two: | ||
** <span style="background:#ddf;padding:4px"><b style="color:red"> | ** <span style="background:#ddf;padding:4px"><b style="color:red">c</b> all reciprocally satisfy <b style="color:gray">2</b></span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0">c</b> agrees with <b style="color:green">c</b> that <b style="color:teal">0</b> is the case</span> = <span style="background:#ddf;padding:4px"><b style="color:red">c</b> all agree that <b style="color:teal">0</b> is the case</span> | ||
* <code>e</code> means that this place will disappear, '''merging''' with "[[Kind|{{t|baq}}]] '' | * <code>e</code> means that this place will disappear, '''merging''' with "[[Kind|{{t|baq}}]] ''right-hand-verb''". | ||
** <span style="background:#ddf;padding:4px"><b style="color:red"> | ** <span style="background:#ddf;padding:4px"><b style="color:red">c</b> takes care of <b style="color:gray">e</b></span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0">a</b> is a cat</span> = <span style="background:#ddf;padding:4px"><b style="color:red">c</b> takes care of cat(s).</span> | ||
** Such a slot is known as an '''exhibitor slot''' (hence <code>e</code>), and the resulting serial is a '''genitival serial'''. | ** Such a slot is known as an '''exhibitor slot''' (hence <code>e</code>), and the resulting serial is a '''genitival serial'''. | ||
* <code>a</code> means that this '''adjectival''' place will disappear, and the following verb's first place is modified, attributively when appropriate or otherwise predicatively, by this adjective: | * <code>a</code> means that this '''adjectival''' place will disappear, and the following verb's first place is modified, attributively when appropriate or otherwise predicatively, by this adjective: | ||
** <span style="background:#ddf;padding:4px"><b style="color:red">a</b> is small</span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0"> | ** <span style="background:#ddf;padding:4px"><b style="color:red">a</b> is small</span> + <span style="background:#ddf;padding:4px"><b style="color:#ba0">a</b> is a cat</span> = <span style="background:#ddf;padding:4px"><b style="color:#ba0">c</b> is a small cat.</span> | ||
</div> | </div> | ||
The signature is again written by writing down all the types in parentheses, like <code>( | The signature is again written by writing down all the types in parentheses, like <code>(c c 0)</code> or <code>(c e)</code>. | ||
There is '''at most''' one non-<code> | There is '''at most''' one non-<code>c</code> in a serial signature. This is because all the other slot types define ''the'' serialization behavior for the verb, and a verb must have one unambiguous serialization behavior! So while <code>(c 0 0)</code> is a valid semantic frame, there cannot be a <code>(c 0 0)</code> serial behavior, as it wouldn't be clear which of the <code>0</code> slots accepts the right-hand verb arguments. | ||
Some verbs cannot participate in serials, and are not part of any serial frame. | Some verbs cannot participate in serials, and are not part of any serial frame. | ||
=== Table of | === Table of serial frames === | ||
The frames currently found in the [https://toaq.github.io/dictionary/ official dictionary] are: | |||
*; Subordinating | |||
*: <code>(c 0)</code> {{class|tua}} | |||
*: <code>(c 1)</code> {{class|leo}} | |||
*: <code>(c 2)</code> {{class|cheo}} | |||
*: <code>(c c 0)</code> {{class|duasue}} | |||
*: <code>(c c 1)</code> {{class|huaq}} | |||
*: <code>(c c 2)</code> {{class|jeq}} | |||
*; Adjectival | |||
*: <code>(a)</code> {{class|gı}} | |||
*; Genitival | |||
*: <code>(c e)</code> {{class|muoq}} | |||
== How do they relate? == | == How do they relate? == | ||
''(This is the author's unofficial theory.)'' | : ''(This is [[User:Lynn|the author]]'s unofficial theory.)'' | ||
There is a predictable partial function from semantic frame signatures to serial frame signatures. | There is a predictable partial function from semantic frame signatures to serial frame signatures. | ||
| Line 74: | Line 85: | ||
* Semantic frame <code>(c c)</code> corresponds to serial frame <code>(x e)</code>. Example: {{t|hea}}, {{t|kıaı}}, {{t|tuı}}. | * Semantic frame <code>(c c)</code> corresponds to serial frame <code>(x e)</code>. Example: {{t|hea}}, {{t|kıaı}}, {{t|tuı}}. | ||
* Otherwise (i.e. <code>(c c c)</code> and beyond, like {{t|kuq}}), the verb cannot serialize. | * Otherwise (i.e. <code>(c c c)</code> and beyond, like {{t|kuq}}), the verb cannot serialize. | ||
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 the last slot of the '''type signature''' is a 0 or a 1 (or presumably any higher number), 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. | |||