On Sun, Aug 26, 2012 at 10:45 PM, And Rosta
<and.rosta@hidden.email> wrote:
Mike S., On 26/08/2012 15:47:
> but
> could you please tell me more about Davidsonian event semantics,
> explaining roughly how events relate to time and possible worlds?
> Montague Semantics makes heavy use of possible worlds and time
> indices, but somehow I think these event things are different.
I see them as not having anything to do with possible worlds. They can have to do with time. Take "X kisses y on Monday". You could represent that by allowing a syntactic predication to be an argument: "on-monday(kiss(x,y))". Or you could add an event argument to kiss, being the state of affairs in which x kisses y: "kiss(x, y, z) + on-monday(z)". (I used "+" rather than "&", because the predications should only be juxtaposed, not logically conjoined, for reasons I will explain further if need be.
Let's see... pdjd = monday, cnb = kiss
cnbakefu
"U is the event of A kissing E"
Or maybe: "A kissing E is in event U"
In Xorban, "on-monday(kiss(x,y))" is not possible of course. Ignoring free variables, would this formula work for "kiss(x, y, z) + on-monday(z)":
su pdjdu cnbakefu
"In some event-on-Monday, A kisses E."
I am starting to see a subtlety made available in the use of this approach, and how it can clear up things. A minor mystery in my mind has always been how the prohibitive works, and why so many natlangs had a marked negative form to cover it. "Don't eat the cookies" =/= "Be in a state of not eating the cookies" because you could comply by achieving such a state at 3pm and then proceed eat the cookies at 4pm, and "Never eat the cookies" doesn't feel right. Maybe it means "make it so that event e does not exist such that you eat the cookies in e."
You will have to explain what juxtaposition is and why that is to be preferred. It usually seems pretty efficient to make use of restrictions in Xorban; in the above, "u" becomes implicitly to mean "the event on Monday". [CV??], vska'aku = Yes, I saw that.
Conjunctions and negation can also be reduced to combinations of quantification and predicates with event arguments.
Starting to understand, partially based on the XorbanDev thread. Basically ~Pxy => ~Ew Pxyw, where event(w) is true, correct?
In Livagian, only a tiny handful of closed-class predicates have more than 4 (3 + event) arguments. For open-class the maximum is 3 plus event argument. Recent changes to Livagian might allow me to relax that maximum without difficulty, but there aren't that many predicates that seem to call for more than three arguments.
It's good to see that our perceptions are not so far apart!
But Livagian in one way or another or more probably does stretch ordinary innate human abilities beyond their breaking point. My aim is find an optimal design and then consider whether humans can cope with it.
In what sense could an optimal design be anything but human-copable? Whom are we designing these languages for if not ourselves?
I can see that so long as the grammar captures that the saying and telling are aspects of the same situation, then "X say Y tell Z" suffices. After your earlier messages explaining your Morneauan system, I now roughly grock it.
Okay, good. "Same situation" is the key principle.
> For example, rather than "False(angry(x))" ("It's false that x is angry"), Livagian would have "false(x1[e],x2) angry(x2[e],x3)".
>
> > Could you please give me a gloss of the second formula?
"false(x1,x2) angry(x2,x3)" where the first argument of each is the event argument -- "it is false that x3 is angry", "x1 is the state of affairs in which there is no state of affairs x2, where x2 is a state of affairs in which x3 is angry".
Is that a bit clearer?
Yes, it is.
What perplexed me, and sent my mind on wild goose chases, is why it would be required to say "exists(x1) event(x1): not exists(x2) event(x2): angry(x2, x3)" when "not exists(x2) event(x2): angry(x2, x3)" appears to suffice. Then it dawned on me that, in your system, "false(x1,x2)" would be grammatically crippled if it too did not also have its own event argument x1. Now what perplexes me is the motivation behind this design choice.
Most formalizations of natural language (and not that I have seen a million of them, but I have seen a few floating around, incl. Montague's stuff) treat logical operators as a closed class that interacts with the grammar in special ways. Likewise, the corresponding semantic rules are special: They are unique in that their semantic value does not vary wrt the model (universe of discourse) nor wrt to possible worlds and time indices. Could you explain in a little detail what advantage you find in shoehorning them into the class of open predicates?
> If all (A, T) were merged into into (P, T) then there were would be
> no way to express instruments and other themes/objects used by the
> agent on the patient, such as messages. John-A {push} the barrel-P
> {use} a forklift-T. John-A {tell} Alice-P {say} the story-T.
I'm trying to remember why there can only be one A and one P per clause, and why {use} and {say} can't be (A,P).
Once an agent or patient argument is introduced into the clause, an implicit variable A or P is bound with the argument imposing the restriction. The variable is then applied implicitly to all other predicates in the clause in the proper slot. There can't be more than one argument imposing the restriction.
I think {use} and {say} are (A, T) simply because that grammaticizes the most frequent pattern. Cf. natural languages: usually the instrument is oblique and the patient core. There is no hard and fast semantic difference between P and T; P definitely tends to be higher on the animacy hierarchy than T, but that's just on average.
> What do the three cases and four predicate types buy us?
>
> What about a system of binary serial verbs, forgetting about the 'cases': e.g. "John wield knife cut bread become slices"?
>
> In a language that worked as in your example, I think you would need
> two predicates for "cut", one with an agent-x1 and one with an
> instrument-x1.
Yes. Or just say "I wield cut cake".
Yes, that'd work. I did tinker with a system like that but I seemed to always get a better result using a more systematic approach.
>Secondly, it would be tricky to reorder the
> constituents without changing the meaning, except perhaps by again
> defining alternate predicates.
Yes, reordering would by tricky. any particular reasons why you want reordering to be possible?