Return-Path: Received: from kantti.helsinki.fi by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0rJzUf-00007DC; Tue, 20 Dec 94 10:00 EET Received: from fiport.funet.fi (fiport.funet.fi [128.214.109.150]) by kantti.helsinki.fi (8.6.9/8.6.5) with ESMTP id KAA22374 for ; Tue, 20 Dec 1994 10:00:24 +0200 Received: from SEARN.SUNET.SE (MAILER@SEARN) by FIPORT.FUNET.FI (PMDF V4.3-13 #2494) id <01HKUY0PTSXS000OEX@FIPORT.FUNET.FI>; Tue, 20 Dec 1994 07:59:29 +0200 (EET) Received: from SEARN.SUNET.SE (NJE origin LISTSERV@SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with BSMTP id 1602; Tue, 20 Dec 1994 08:57:12 +0100 Date: Tue, 20 Dec 1994 18:59:15 +1100 From: Nick Legend Nicholas Subject: Re: some outstanding issues In-reply-to: from "Logical Language Group" at Dec 6, 94 03:43:28 am Sender: Lojban list To: Veijo Vilva Reply-to: Nick Legend Nicholas Message-id: <01HKUY0PXS3M000OEX@FIPORT.FUNET.FI> X-Envelope-to: veion@XIRON.PC.HELSINKI.FI Content-transfer-encoding: 7BIT X-To: lojbab@access.digex.net X-cc: Lojban Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 6056 Lines: 121 Hu'tegh! nuq ja' Logical Language Group jay'? *Finally* tracked the thread down. The thread was the necessity for a rafsi for jai. =>Yes, I was mainly thinking of its standalone uses, things like: =>jazbai (jai bapli) x1(agent) forces x2 to happen by force x3 > =>and many other selbri that have causative events in x1 but usually =>make sense with an agent there. {-gau} is not very good for this =>because it leaves the causative event in x2, and often that's =>not the best order. =This is a problem with the lujvo-making rules then, because I would tend =to delete the causative event, or shift it to the end - which is exactly =what I think you have done in your examples above. Jorge responded to Lojbab why the lujvo-rules have to have this problem. I'll recast this, to drive the point home. Lujvo can have *a priori* any place structure you want; Jim Carter, in his own Loglan variant and in Lojban, was of the opinion that such absolute freedom was undesirable. I came to share that belief. Lojban has no case system, and only optionally uses a prepositional system. For newly-minted lujvo, there would be no way of knowing what the fourth or third argument meant, short of learning distinct dictionary entries for each lujvo. This would make the Lojban lujvo system impossible to bootstrap; so instead, it seemed to us preferable to exploit regularities already discernable in lujvo. Jim Carter conceived the kernel of these; I elaborated it into a loose algorithm. This algorithm is quite far from fixing the place structure of any lujvo, but it does greatly limit the possible structures it can have. The rules I set down, which are intended to allow Lojbanists to guess readily the plac structure of an unfamiliar lujvo, were the following: The places of a lujvo must be a subset of the places of its component gismu (veljvo). Otherwise, we would have an unworkable open set of places for all lujvo. The ordering of the places of a lujvo should reflect the ordering of the places in the expanded veljvo --- that is, of a veljvo with no tanru: each brivla in the expanded veljvo should be a gismu. Due to this restriction, there are only four operations you can perform on the place structures of the veljvo, to get that of the lujvo: * coreferencing; eg. .abu djica lenu by. viska cy. -> .abu djica lenu .abu viska cy.; * concatention; eg. .abu caxno by. cy. dy. gi'e barda .ebu fy. -> .abu caxybra .ebu fy. by. cy. dy.; * interpolation; eg. .abu djica lenu .abu viska by. kei cy. -> .abu viskydji by. cy. ; and * deletion; eg. .abu djica lenu .abu viska by. zo'e kei cy. -> .abu viskydji by. cy. Raising is not one of these four operations. Nor is arbitrary reordering. So when it comes to gafygau, .abu gansu lenu by. galfi cy. dy. could only yield the lujvo .abu gafygau by. cy. dy. This is not what we want to say when we use an agentive 'change': we want by., the event causing the change, out of the way completely. A changes B into C corresponds to .abu *gafygau cy. dy. But *this* 'change' *is* conveyed by using the raising particle jai: lenu .abu co'e cu galfi by. cy. -> .abu jai galfi by. cy. fai lenu co'e; cf. A changes B into C by doing D. I was loath to disrupt the lujvo rules, and the recoverability of lujvo place structures, by making an exception (not the only case of this, mind: I note in the paper that superlatives may well need an exception). Instead, I have -gau producing the 'wrong' place structure, and I would encourage lojbanists to use 'jai' instead --- since 'jai' does do what is required here. =But jai bapli does NOT necessarily agentify bapli - that is also an =assumption that would have to go into the lujvo paper (which obviously does =not cover the case since jai does not yet have the rafsi). I am opposed =to jai being automatically used as an agentifier, since the best arguyment =for accepting it is its genericness. As the statistics of jai usage Lojbab dug up confirmed, and contrary to what Jorge supposed, virtually all usage of jai to date (mine :) ), is *not* agentive, but extracts other roles from abstractions. But I have no problem with that kind of vagueness being legislated into a lujvo: jai zei broda means precisely what jai broda means --- no more, no less: it would *usually* be an agentifier in jai bapli, that would in fact be the default presumption, but, as is often the case with such presuppositions, it can be cancelled by the right contextual factors. For instance, jai bapli could equally as well extract an instrument. jai zei se zei bapli, of course, would have nothing to do with being an agentifier, rather tending to extract topics/ goals. Such ambiguity doesn't gel with existing lujvo policy (that each lujvo should have a unique, unambiguous meaning), but I find pursuing such a policy for jai lujvo impractical. (I also do so for SE + lujvo, although the converse has been argued.) =jai bapli merely takes SOME sumti out of the x1 place of bapli and raises it, =or am I misremembering the intent? Pragmatics must determine which sumti, =and lujvo-making hard-codes the pragmatics into the dictionary. Hm. I see that this is the real bone of contention, then. I don't think it should, for rafsi such as SE and JAI. There can be no algorithm or method to such hard-coding, unlike with brivla + brivla lujvo: it'd be pure convention. I really don't see why. But I know this isn't as obvious to Lojbab, so I dunno, maybe we shouldn't get a jai rafsi, if the string attached to it is compulsory hard-coding of which role is extracted. (Though other veljvo could do such disambiguation, surely.) -- @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ Nick Nicholas. Melbourne University, Aus. nsn@speech.language.unimelb.edu.au --- "Some of the English might say that the Irish orthography is very Irish. Personally, I have a lot of respect for a people who can create something so grotesque." -- Andrew Rosta , <9307262008.AA95951@link-1.ts.bcc.ac.uk>