Date: Sat, 25 Oct 1997 02:36:37 -0500 (EST) Message-Id: <199710250736.CAA26131@locke.ccil.org> Reply-To: Logical Language Group Sender: Lojban list From: Logical Language Group Subject: Re: abstractor place structures X-To: jorge@INTERMEDIA.COM.AR X-cc: lojban@cuvmb.cc.columbia.edu To: John Cowan X-Mozilla-Status: 0011 Content-Length: 6692 Lines: 131 >>>>But I would prefernot to stretch klani/ni to be used >>>>for counts of objects. >>>How do you interpret the "enumerated by x2" bit in the gi'uste >>>definition of klani? >>I was specifically pointing to the x2 be a number/quantifier. >>I am sure that there is SOME x3 (whether we can agree on what it is) >whereby >>le ni mlatu cu klani li xo le broda >>asks for how many cats there are in which case the ni abstraction is >>enumerated by that count. (Enumerated can means imply that it has a >> specific number applicable to it). > >Then why do you say that it is stretching it to use klani for number >of things? Because I am not sure that everyone (including me when I am caught up on sleep and rational) accepts that klani with any scale is equivalent to kancu with no counter. Klani was designed so as to be definitional of ni, and thus for it to be used for counts, i think that ni abstractions also have to be usable for counts. I don't know if this works or not, and I am no longer ex-officio the decider of such things. (no one is). >>>>I am willing to have a count always to imply a counter. >>>That's fine. I am not, and so I look for ways to say in Lojban >>>what I want to say. >>zi'o forever %^) >--More-- > >I thought that disliking zi'o was one of the few things you >and I agreed on! Oh well... Of course I dislike it. Whenever I use it, I am to some extent poking fun atthe whole concept of needing it. To my mind, a count without a counter is more or less meaningless. Coujnting is the placing of objects in one to one correspondence with some kind fo numbering scheme. The numbering scheme is artificial, and that implies an artificer to choose and apply the numbering scheme to the counting process. >>> >mitre and >>>>the like are units (gradu), >>>If you mean {ro mitre cu gradu} then I disagree. >> >>Maybe I mean anti-ka(le ka mitre) cu gradu %^) > >And what is that? > >>Or maybe I need an anti-si'o. What I mean by these comments is that out of the mass of all events of da mitre li pa, we distil an idea or set of properties that constitute the concept of "meter". But a meter is not a set of properties, it is a thing that has those properties. Thus we need to turn the abstraction into a non-abstract which the abstraction applies to. I don't know if this makes any sense or not. I am usually half asleep when I post to the list these days because all of my waking time is going to kid support and the mangling of the LLG address list, or recovery from these. >No I am saying that the rational analysis must follow the needs of the >>language user and is secondary to it. > >But I do, as a language user, need a rational way of creating new >measure words with the same place structure as the basic measure >words. Regularity of place structures is a plus for language users. Fine, butthat regularity may be a convention that is specific to the problem to be solved and not necessarily as generalized as the dikyjvo conventions of Chapter 12. My main constraint on ad hoc conventions is that we don't end up with things like JCBs use of the TLI equivalent of zbasu as the tertanru for all manner of causal lujvo, because that is what we do in English. Maybe the place struture of gradu is useless for the purpose I intended and we should have changed itto fit the intended purpose and to be consistent with dikyjvo conventions. But I do not undertsand those conventions well enough to do this, and could not justify yet another pass through the gismu list to optimize it for a lujv-making system that I do not really understand. Still and all, many gismu are in the gisdmu list in order to be used in lujvo. I am quite sure that gradu was added specifically to allow the creation of new units. I am not sure that it has much use if it cannot be used in such lujvo (specifically, I see no value in a 10**0 metric prefix, and if anyone else had, there would already be one in all the languages) Meanwhile we have a baseline, and changing the place structure is a closed topic. Violating the dikyjvo conventions, specifically permitted by the Book, is still permitted. I agree that we want the "violations" as such to be conventional in their own way, so as to allow easy creation of new lujvo. But I am less wedded than most people to following the existing conventions religiously if they do not serve the needs of the community. >>>How do you use {gradu} to say "the sugar is 3 in cups", in a way that >>>parallels {le sakta cu grake li xanono} for "the sugar is 600 in grams"? >>You can't, but a certain pattern of lujvo involving gradu should >>have that pattern of sumti structure. Thus, I THINK I have >>"newton" in my files as "baplygradu" assuming that metric unist would have >>preeminent use of shortest lujvo. And baplygradu would have a place >structure >>such that you would say x1 is measured in newtons as x2, with other >parameters >>x3, x4, x5 as required my place struture analysis. > >Sounds extremely ad hoc to me. Of course it is ad hoc. Most of the language design was ad hoc, especially in the area of semantics. Until Nick tackled lujvo, there was no real interest in TRYING to make the semantics more than rudimentarily systematic, and the systems that were created were QUITE ad hoc. >Why not "baplai"? You can't argue against it on the basis >of the place structure of klani if you are going to absolutely ignore >the places of gradu in forming yours anyway. Of course not. But gradu is in the language for this purpose and klani is in the language for a different purpose. gradu got its rafsi based on being uised for unit lujvo. klani got rafsi based on other kinds of lujvo (not sure what kind). I don't pretend to have a rational way to explain it all away. It was and is ad hoc. Maybe serendipity will strike as it has so often before in this project and we will realize that a "better way" has fallen out of the complexity of the language system that solve our problem without our intending to. But until/unles it does, I prefer to stick with the patterns that have been used in the past. lojbab ---- lojbab lojbab@access.digex.net Bob LeChevalier, President, The Logical Language Group, Inc. 2904 Beau Lane, Fairfax VA 22031-1303 USA 703-385-0273 Artificial language Loglan/Lojban: ftp.access.digex.net /pub/access/lojbab or see Lojban WWW Server: href="http://xiron.pc.helsinki.fi/lojban/" Order _The Complete Lojban Language_ - see our Web pages or ask me.