Re: abstractor place structures

[Logical Language Group <lojbab@ACCESS.DIGEX.NET>]

>>>>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.