From lojban-out@lojban.org Sat Nov 30 20:51:28 2002 Return-Path: X-Sender: lojban-out@lojban.org X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_2_3_0); 1 Dec 2002 04:51:28 -0000 Received: (qmail 93488 invoked from network); 1 Dec 2002 04:51:28 -0000 Received: from unknown (66.218.66.218) by m11.grp.scd.yahoo.com with QMQP; 1 Dec 2002 04:51:28 -0000 Received: from unknown (HELO digitalkingdom.org) (204.152.186.175) by mta3.grp.scd.yahoo.com with SMTP; 1 Dec 2002 04:51:28 -0000 Received: from lojban-out by digitalkingdom.org with local (Exim 4.05) id 18IM4m-00007j-00 for lojban@yahoogroups.com; Sat, 30 Nov 2002 20:51:28 -0800 Received: from digitalkingdom.org ([204.152.186.175] helo=chain) by digitalkingdom.org with esmtp (Exim 4.05) id 18IM4g-00007S-00; Sat, 30 Nov 2002 20:51:22 -0800 Received: with ECARTIS (v1.0.0; list lojban-list); Sat, 30 Nov 2002 20:51:21 -0800 (PST) Received: from cs6668125-184.austin.rr.com ([66.68.125.184] ident=root) by digitalkingdom.org with esmtp (Exim 4.05) id 18IM4Y-00007I-00 for lojban-list@lojban.org; Sat, 30 Nov 2002 20:51:14 -0800 Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1]) by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id gB14uuG9022464 for ; Sat, 30 Nov 2002 22:56:56 -0600 (CST) (envelope-from fracture@cs6668125-184.austin.rr.com) Received: (from fracture@localhost) by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id gB14uuEj022463 for lojban-list@lojban.org; Sat, 30 Nov 2002 22:56:56 -0600 (CST) Date: Sat, 30 Nov 2002 22:56:55 -0600 To: lojban-list@lojban.org Subject: [lojban] Re: Why we should cancel the vote or all vote NO (was RE: Official Statement- LLG Board approves new baseline policy Message-ID: <20021201045655.GA21914@allusion.net> References: <6182E3BC-04E0-11D7-B360-003065D4EC72@optushome.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <6182E3BC-04E0-11D7-B360-003065D4EC72@optushome.com.au> User-Agent: Mutt/1.5.1i X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: fracture@allusion.net Precedence: bulk X-list: lojban-list X-eGroups-From: Jordan DeLong From: Jordan DeLong Reply-To: fracture@allusion.net X-Yahoo-Group-Post: member; u=116389790 X-Yahoo-Profile: lojban_out --MW5yreqqjyrRcusr Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 01, 2002 at 02:52:58PM +1100, Nick Nicholas wrote: [...] > And: Experimental cmavo >=20 > If a sufficient number agree that a cmavo deserves to be official and=20 > documented, so it should be --- but the phonotactic distinctiveness of=20 > cmavo that have not yet attained that status has served us well, and I=20 > would fain it continue to. If we are running out of CVV space, we can=20 > still go to xVV. (I don't want to make that statement right now; I'd=20 > rather wait till we see how many exptal cmavo are looking like becoming=20 > official, first.) If we run out of THAT, then we can add a delimited=20 > area of CVVV. I am not envisioning mass addition of new cmavo, though,=20 > and sanctioning going into CVVV implies that we will, I do not wish to=20 > be bound by that now. But if we decide to disambiguate through two=20 > cmavo, then it would be my understanding that both cmavo should be=20 > official. I actually agree with AndR on this point: if we adopt new cmavo as part of the byfy stuff, I think we are obliged to not jump to use the shortest cmavo available by default. For example, if mu'ei were to be adopted, it wouldn't make sense (in my view) to assign it to ne'e or some such just because it's a CVV form. Furthermore, even if we felt the need to exhaust the rest of CVV before using other forms, why would we go to xVV, which contains the last of the unassigned single syllable forms, instead of CVVV? More below. [...] > And: Zipf >=20 > And, I hate to relay fundamentalist hatemail, but I have to. I have no=20 > confidence in a priori determinations of Zipf necessity, nor that we=20 > have enough usage yet to make such determinations even a posteriori. I=20 > will not consider frequency of usage as the only valid factor for=20 > introducing a new cmavo. I am not as confident as you about the 'saving=20 > syllables' imperative. I believe the fundamentalist imperative will=20 > trump the zipfean imperative (noone in Esperanto ever says "de l'" --=20 > even though it is in fact officially sanctioned.) And I doubt you'll=20 > get many takers for No Change Without Consensus. So I stand my ground=20 > on this. I think the lack of confidence in the a priori determination was And's entire viewpoint. Saving syllables is not something we should do just right now---instead we should feel free to use CVVV if new cmavo are assigned, and then in the (distant) future, i.e. post baseline (by a probably significant amount of years), forms which we find turned out to be said more frequently than their length justifies can be shortened. I support this idea, and I don't think there's anything anti-fundamentalist or anti-baseline about it, as it is about 'reserving rights', so to speak, for lojbanists after the baseline (presumably when lojbanists can discuss such things in lojban). [...] > And: Unintelligible cmavo >=20 > We will go with the supplicatory model before we decide we don't know=20 > what a cmavo is. The current statement of the baseline does not allow=20 > cmavo deletion, because all cmavo are documented in CLL, one way or=20 > another. To erase cmavo would be a major techfix, and I am opposed to=20 > such ventures on principle. >=20 > At the very most, if noone has ever ever ever used lau, I might accept=20 > turning lau into say xu'e, and releasing lau. But for a one syllable=20 > cmavo to be necessary for something Zipfeanly, it has to be something=20 > so urgent and obvious, I'd have thought the heavens would be clamoring=20 > for it by now. In my book, xa'o and mu'ei are the only ones even close=20 > to this (with mu'ei endangered by sumtcita ka'e); and they're not that=20 > close. I don't think anyone thinks it is urgent. (Or if they do, I think they're wrong, to be blunt). I think the BF should assign a new cmavo for lau, and probably a few others of the wasted-single-syllable-group (a list on the wiki), but *not* revoke their current assignments, so as not to invalidate the part of the book. Rather, the BF should issue a statement discouraging their use instead of their new assignments, so that in the (distant, post-baseline) future those few cmavo can be re-opened for zipfean shortenings that lojbanists at that time deem useful and neccesary, without invaliding any usage. --=20 Jordan DeLong - fracture@allusion.net lu zo'o loi censa bakni cu terzba le zaltapla poi xagrai li'u sei la mark. tuen. cusku --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Description: lojban translation Content-Language: art-lojban Content-Disposition: inline; filename=lojban_mime_part Content-Transfer-Encoding: quoted-printable On Sun, Dec 01, 2002 at 02:52:58PM +1100, Nick Nicholas wrote: [...] > And: Experimental cmavo >=20 > If a sufficient number agree that a cmavo deserves to be official and=20 > documented, so it should be --- but the phonotactic distinctiveness of=20 > cmavo that have not yet attained that status has served us well, and I=20 > would fain it continue to. If we are running out of CVV space, we can=20 > still go to xVV. (I don't want to make that statement right now; I'd=20 > rather wait till we see how many exptal cmavo are looking like becoming=20 > official, first.) If we run out of THAT, then we can add a delimited=20 > area of CVVV. I am not envisioning mass addition of new cmavo, though,=20 > and sanctioning going into CVVV implies that we will, I do not wish to=20 > be bound by that now. But if we decide to disambiguate through two=20 > cmavo, then it would be my understanding that both cmavo should be=20 > official. .i .ue mi la .and. tugni di'e .i ro mu'ei gi ma'a jdice tu'a loi cnino cmavo ca'i la byfyb. gi mi jivni ledu'u ma'a bilga lenu na pilno loi cmalyrai cmavo poi na ca'o pilno .i mu'a ro mu'ei zo mu'ei cu co'e gi mi na'e jimpe ledu'u ki'u makau pilno zo ne'e .a lo simsa be ri be'o .enai zo mu'ei mu'i le tamsmi po'o be le cnino cmavo .i ji'a ji'eku romu'ei gi nitcu lenu pilno ro le to'e pilno cmavo gi paunai mu'i ma cfari fa tu'a lei cmavo be la'o lo'u xVV le'u noi vasru ro le pavslaka cmavo poi na ca pilno ku'o .enai lo'u CVVV le'u .i mu'onai [...] > And: Zipf >=20 > And, I hate to relay fundamentalist hatemail, but I have to. I have no=20 > confidence in a priori determinations of Zipf necessity, nor that we=20 > have enough usage yet to make such determinations even a posteriori. I=20 > will not consider frequency of usage as the only valid factor for=20 > introducing a new cmavo. I am not as confident as you about the 'saving=20 > syllables' imperative. I believe the fundamentalist imperative will=20 > trump the zipfean imperative (noone in Esperanto ever says "de l'" --=20 > even though it is in fact officially sanctioned.) And I doubt you'll=20 > get many takers for No Change Without Consensus. So I stand my ground=20 > on this. .i ju'o la .and. ca'a jinvi ledu'u na'eka'e ba'e pu'o djuno ledu'u le cmavo kau cu cmalu se djica .i ro zu'o cmalygau cu na ca se djica vau pe'i .ibo ge ka'e pilno le cmavo be lo'u CVVV le'u romu'ei ledu'u loi cnino cmavo cu co'e kei gi ca le mutce balvi to ba'o la'o gy. baseline .gy. ze'uku toi loi cmavo poi ma'a facki ledu'u tu'a ke'a cu cmalymau se nitcu cu ka'e se cmalygau .i mi sarji le sidbo gi'e jinvi ledu'u naku ri natfe lesi'o stodi .i sa'enai mukti fa lenu ralte lei cumki seva'u loi balvi ke lojbo prenu [...] > And: Unintelligible cmavo >=20 > We will go with the supplicatory model before we decide we don't know=20 > what a cmavo is. The current statement of the baseline does not allow=20 > cmavo deletion, because all cmavo are documented in CLL, one way or=20 > another. To erase cmavo would be a major techfix, and I am opposed to=20 > such ventures on principle. >=20 > At the very most, if noone has ever ever ever used lau, I might accept=20 > turning lau into say xu'e, and releasing lau. But for a one syllable=20 > cmavo to be necessary for something Zipfeanly, it has to be something=20 > so urgent and obvious, I'd have thought the heavens would be clamoring=20 > for it by now. In my book, xa'o and mu'ei are the only ones even close=20 > to this (with mu'ei endangered by sumtcita ka'e); and they're not that=20 > close. .i mi to'e jinvi ledu'u noda jinvi ledu'u nitcu ba'e ca .i to romu'ei gi co'e gi mi na tugni toi .i mi jinvi ledu'u la byfyb. bilga lenu finti lo cnino cmavo poi basti zo lau to cumki nu so'o drata pe lei festi cmavo to cu'u la .uikis. toitoi .iku'i ba'eto'e vimcu le ca'a cmavo pe ri mu'i lenu le se xusra be le cukta cu ranji .i la byfyb. bilga lenu xusra ledu'u .ei ma'a lei ca'a cmavo cu to'e pilno gi'e pilno lei cnino basti vau ki'u lenu ca le mutce balvi ba'o la'o gy. baseline .gy. le cmalu cmavo ka'e se pilno mu'i ronu cmalygau kei secau ronu lei ca'a lojbo cu se galfi mu'o --=20 Jordan DeLong - fracture@allusion.net lu zo'o loi censa bakni cu terzba le zaltapla poi xagrai li'u sei la mark. tuen. cusku --3V7upXqbjpZ4EhLz-- --MW5yreqqjyrRcusr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE96ZaXDrrilS51AZ8RAgRvAKCJDtkgLpO+WUHMKGaVcm9DZtBTjgCfZ800 QiNjDSegPFDthcVZlT7urZs= =e1kx -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr--