From pycyn@aol.com Wed Aug 29 08:20:55 2001
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_3_2); 29 Aug 2001 15:20:55 -0000
Received: (qmail 71237 invoked from network); 29 Aug 2001 15:18:27 -0000
Received: from unknown (10.1.10.26)
  by l7.egroups.com with QMQP; 29 Aug 2001 15:18:27 -0000
Received: from unknown (HELO imo-r01.mx.aol.com) (152.163.225.97)
  by mta1 with SMTP; 29 Aug 2001 15:18:27 -0000
Received: from Pycyn@aol.com
  by imo-r01.mx.aol.com (mail_out_v31_r1.4.) id r.5b.1ad7082b (4353)
  for <lojban@yahoogroups.com>; Wed, 29 Aug 2001 11:18:22 -0400 (EDT)
Message-ID: <5b.1ad7082b.28be61be@aol.com>
Date: Wed, 29 Aug 2001 11:18:22 EDT
Subject: Re: [lojban] Re: Another stab at a Record on ce'u
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_5b.1ad7082b.28be61be_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10531
From: pycyn@aol.com

--part1_5b.1ad7082b.28be61be_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 8/28/2001 10:17:24 PM Central Daylight Time, 
nicholas@uci.edu writes:


> (1) A Record, or even a Stab At A Record, is not a place to be making new
> proposals.
> 

Note that it was NOT a record but a place to discuss what the record should 
be. But second, it contains nothing new (except the all-{ce'u} proposal, 
which seems to have been about all anyone saw) and merely tried to organize 
what was presented (the addition filling a gap in those presentations).

<(2) PC, you will be maddened, but Hier steh' ich, ich kann nich anders:
I'm with Rob. For bound {ka}, we *always* want {ka} to be a property. So I
should be able to say all of the following:

mi sisku leka se prami
mi sisku leka ce'u se prami
mi sisku leka prami ce'u
To propose that these would mean different things (different ce'u
readings) *still* looks capricious, and there is no precedent for it. We
use {ce'u} as a disambiguator; so such a scheme cannot fly>

Also Gebrueder Martin, the last two would mean the same thing, but not what 
you want, on a bet, i.e. both are {ka ce'u prami ce'u} on my scheme, and the 
first means just what you want on my scheme as yours. The trouble is that 
any scheme that omits some {ce'u} will have this result in some 
configuration. The task was to minimize bad results, minimize the number of 
words needed, and keep the originals as much as possible. Without glorking. 
Unfortunately you nor anyone else wants to do without glorking, so this -- 
and every other schme wiht these golas, will not do. This was why I have 
said a few dozen times now "Decide what you want and declare it to be so" but 
in general y'all would rather keep up the prentense of wanting pure clarity 
while in fact holding out for clsoe to maximal imprecision.

<(3) ke'a does not resolve what to do when there are embedded places in
*its* abstraction;coincidentally, I was thinking of this just this morning, 
walking to work.
(More evidence I've been doing too much Lojban.) Since the verdict is that
they behave similarly, let's not fix ce'u in those contexts before we have
a clear tendency on ke'a.>

Sounds reasonable to me, as does And's proposal. This is not yet something 
to decide then.

<(4) If the Wiki has proven one thing, it's that accounts of
proposals as disembodied, without details of who proposed and who agreed,
rankle people. OK, they rankle me. Please take the time to name names; we
are not at such an Olympian stage that we can afford to abstract people
out.>

It is often hard to figure out who actually said what in a pile of nested 
quotations that span the entire histroy of the issue (people have stopped 
copying the routings at least), so I am unsure in many cases; I screwed up 
the one attribution I made, notice. But I think, xod spotted that {du'u} is 
{ka} with no implicit {ce'u} (scheme 1), And provided the "all implict are 
{ce'u}" version (scheme 5), though he assigned it to {si'o}. Scheme 4 was 
mine. Scheme 1 and 2 are various people's attempts to figure out what people 
were doing before {ce'u} -- probably Cowan formulated then\m at some time.

<(5) If Michael is speaking of lesi'o gerku, it is clear to me that (as
with much of what he writes :-) ) he is very much speaking about his own
personal construct -- here, his personal construct of doghood. So I'm
completely sanguine about {le si'o gerku} = {le si'o ce'u gerku
ce'u kei be mi}. The claim you are now making is that si'o is
particular to a thinker, ka isn't. (Btw I don't recall seeing
this argument made explicit
before -- and the onus is, again, on you NOT to be making these arguments
in a record, which is supposed to summarise discussion, not covertly
introduce new arguments.)>

The argument, which was given explicitly to someone suggsting that {si'o} is 
in with {ka} is 1) {si'o} has a place for the ideationizer and {ka} does not 
and 2) the referent of {ka} is a function from tuples to truth values (a 
property) and {si'o} is a mental event or something closely related to one 
(its content, say). The latter needs expansion but holds in so far as it has 
gone. This was not the place to carry that particular point on.






--part1_5b.1ad7082b.28be61be_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><BODY BGCOLOR="#ffffff"><FONT SIZE=2>In a message dated 8/28/2001 10:17:24 PM Central Daylight Time, 
<BR>nicholas@uci.edu writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">(1) A Record, or even a Stab At A Record, is not a place to be making new
<BR>proposals.
<BR></BLOCKQUOTE></FONT><FONT COLOR="#000000" SIZE=3 FAMILY="SANSSERIF" FACE="Arial" LANG="0">
<BR>
<BR>Note that it was NOT a record but a place to discuss what the record should 
<BR>be. &nbsp;But second, it contains nothing new (except the all-{ce'u} proposal, 
<BR>which seems to have been about all anyone saw) and merely tried to organize 
<BR>what was presented (the addition filling a gap in those presentations).
<BR>
<BR>&lt;(2) PC, you will be maddened, but Hier steh' ich, ich kann nich anders:
<BR>I'm with Rob. For bound {ka}, we *always* want {ka} to be a property. So I
<BR>should be able to say all of the following:
<BR>
<BR>mi sisku leka se prami
<BR>mi sisku leka ce'u se prami
<BR>mi sisku leka prami ce'u
<BR>To propose that these would mean different things (different ce'u
<BR>readings) *still* looks capricious, and there is no precedent for it. We
<BR>use {ce'u} as a disambiguator; so such a scheme cannot fly&gt;
<BR>
<BR>Also Gebrueder Martin, the last two would mean the same thing, but not what 
<BR>you want, on a bet, i.e. both are {ka ce'u prami ce'u} on my scheme, and the 
<BR>first means just what you want on my scheme as yours. &nbsp;The trouble is that 
<BR>any scheme that omits some {ce'u} will have this result in some 
<BR>configuration. &nbsp;The task was to minimize bad results, minimize the number of 
<BR>words needed, and keep the originals as much as possible. &nbsp;Without glorking. &nbsp;
<BR>Unfortunately you nor anyone else wants to do without glorking, so this -- 
<BR>and every other schme wiht these golas, will not do. &nbsp;This was why I have 
<BR>said a few dozen times now "Decide what you want and declare it to be so" but 
<BR>in general y'all would rather keep up the prentense of wanting pure clarity 
<BR>while in fact holding out for clsoe to maximal imprecision.
<BR>
<BR> &lt;(3) ke'a does not resolve what to do when there are embedded places in
<BR>*its* abstraction;coincidentally, I was thinking of this just this morning, 
<BR>walking to work.
<BR>(More evidence I've been doing too much Lojban.) Since the verdict is that
<BR>they behave similarly, let's not fix ce'u in those contexts before we have
<BR>a clear tendency on ke'a.&gt;
<BR>
<BR>Sounds reasonable to me, as does And's proposal. &nbsp;This is not yet something 
<BR>to decide then.
<BR>
<BR>&lt;(4) If the Wiki has proven one thing, it's that accounts of
<BR>proposals as disembodied, without details of who proposed and who agreed,
<BR>rankle people. OK, they rankle me. Please take the time to name names; we
<BR>are not at such an Olympian stage that we can afford to abstract people
<BR>out.&gt;
<BR>
<BR>It is often hard to figure out who actually said what in a pile of nested 
<BR>quotations that span the entire histroy of the issue (people have stopped 
<BR>copying the routings at least), so I am unsure in many cases; I screwed up 
<BR>the one attribution I made, notice. &nbsp;But I think, xod spotted that {du'u} is 
<BR>{ka} with no implicit {ce'u} (scheme 1), And provided the "all implict are 
<BR>{ce'u}" version (scheme 5), though he assigned it to {si'o}. &nbsp;Scheme 4 was 
<BR>mine. &nbsp;Scheme 1 and 2 are various people's attempts to figure out what people 
<BR>were doing before {ce'u} -- probably Cowan formulated then\m at some time.
<BR>
<BR>&lt;(5) If Michael is speaking of lesi'o gerku, it is clear to me that (as
<BR>with much of what he writes :-) ) he is very much speaking about his own
<BR>personal construct -- here, his personal construct of doghood. So I'm
<BR>completely sanguine about {le si'o gerku} = {le si'o ce'u gerku
<BR>ce'u kei be mi}. The claim you are now making is that si'o is
<BR>particular to a thinker, ka isn't. (Btw I don't recall seeing
<BR>this argument made explicit
<BR>before -- and the onus is, again, on you NOT to be making these arguments
<BR>in a record, which is supposed to summarise discussion, not covertly
<BR>introduce new arguments.)&gt;
<BR>
<BR>The argument, which was given explicitly to someone suggsting that {si'o} is 
<BR>in with {ka} is 1) {si'o} has a place for the ideationizer and {ka} does not 
<BR>and 2) the referent of {ka} is a function from tuples to truth values (a 
<BR>property) and {si'o} is a mental event or something closely related to one 
<BR>(its content, say). &nbsp;The latter needs expansion but holds in so far as it has 
<BR>gone. &nbsp;This was not the place to carry that particular point on.
<BR>
<BR>
<BR>
<BR> 
<BR></FONT></HTML>

--part1_5b.1ad7082b.28be61be_boundary--

