From a.rosta@dtn.ntl.com Wed Aug 29 06:11:39 2001 Return-Path: X-Sender: a.rosta@dtn.ntl.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2); 29 Aug 2001 13:11:39 -0000 Received: (qmail 6721 invoked from network); 29 Aug 2001 13:10:17 -0000 Received: from unknown (10.1.10.142) by l8.egroups.com with QMQP; 29 Aug 2001 13:10:17 -0000 Received: from unknown (HELO mta05-svc.ntlworld.com) (62.253.162.45) by mta3 with SMTP; 29 Aug 2001 13:10:17 -0000 Received: from andrew ([62.255.41.12]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010829131015.UPSQ20588.mta05-svc.ntlworld.com@andrew> for ; Wed, 29 Aug 2001 14:10:15 +0100 Reply-To: To: Subject: RE: [lojban] Another stab at a Record on ce'u Date: Wed, 29 Aug 2001 14:09:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010828175101.C820@twcny.rr.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 From: "And Rosta" Rob: > On Tue, Aug 28, 2001 at 07:14:16PM +0100, And Rosta wrote: > > 1. All empty sumti places within du'u fill with zo'e. > > 2. In ka abstractions, the first empty place fills with ce'u and the > > rest fill with zo'e. > > Exception (or generalization): where context indisputably demands > > a ka abstraction expressing an n-adic relation, where the value of > > n is certain, the first n empty places fill with ce'u and the rest > > with zo'e. > > 3. EITHER (XOR): > > 3a. In a ka abstraction, if an overt ce'u fills the x1 then all > > following empty places fill with ce'u. > > XOR: > > 3b. In a ka abstraction, if a ce'u precedes the first empty place > > then all following empty places fill with ce'u. > > Whoa! How did we end up here? My attempt to make sense (in my eyes) of pc's latest proposal. > I still haven't seen any useful sentences involving more than 2 > {ce'u}s. unfortunately that doesn't tell us much. If people understood when they need ce'u and if they never elided it, then you would have seen it. And in discussions of, say, definitional issues (e.g. "Is daterape rape?") you'd get a lot of all-ce'us. > 3a and > 3b both turn {le ka ce'u klama} into {le ka ce'u klama ce'u ce'u ce'u ce'u}, > completely obliterating the meaning and actually _forcing_ you to elide the > first {ce'u} in order to actually say {le ka ce'u klama}. If I understand that > right. Yes. pc appears to be of the opinion that this is the overall best compromise solution. I've come round to the view that ka is unsalvageable. > I still support Jorge's proposal. If the only objection is that it takes over > {si'o}, then I'd be happy enough without that part of the proposal, too. The > all-{ce'u} ka seems to be only useful in metalingustics, though pycyn's and > And's proposal seems to make it the default when you use ce'u anywhere. Don't call it my proposal. Okay, I formulated it, but I didn't propose it. I forget now what Jorge's proposal was. AFAIR, he supported my ka/du'u/si'o proposal (which is on the wiki). > I'd be much happier if the metalinguistic "all-places-{ce'u}" word > were made an > experimental cmavo, or a mode in which people agree that {si'o} would refer to > this precise concept instead of its normal, vague meaning of an idea. > > So what's left is: > > 1. All empty sumti places within du'u fill with zo'e. > 2. In ka abstractions *without any ce'u*, the first empty place fills > with ce'u > and the rest fill with zo'e. Where context indisputably demands an n-adic > relation where the value of n is certain, the first n empty places > fill with > ce'u and the rest with zo'e. > 3. There is no rule 3. > > And I'll be happy to relent if you can show me what benefit there is > to filling > every empty place with {ce'u}. I think I'd go for the experimental cmavo for abstracting selbri, plus a hardcore glorkbog ka to which a Government Health Warning is attached. There doesn't seem much point in formalizing conventions for ka; they'd be leaky and not very robust or effectual in making current usage that much less vague. --And.