From pycyn@aol.com Wed Aug 29 08:22:03 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_3_2); 29 Aug 2001 15:22:02 -0000 Received: (qmail 33344 invoked from network); 29 Aug 2001 15:18:43 -0000 Received: from unknown (10.1.10.142) by m8.onelist.org with QMQP; 29 Aug 2001 15:18:43 -0000 Received: from unknown (HELO imo-r02.mx.aol.com) (152.163.225.98) by mta3 with SMTP; 29 Aug 2001 15:18:42 -0000 Received: from Pycyn@aol.com by imo-r02.mx.aol.com (mail_out_v31_r1.4.) id r.11.19c29379 (4353) for ; Wed, 29 Aug 2001 11:18:29 -0400 (EDT) Message-ID: <11.19c29379.28be61c4@aol.com> Date: Wed, 29 Aug 2001 11:18:28 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_11.19c29379.28be61c4_boundary" X-Mailer: AOL 6.0 for Windows US sub 10531 From: pycyn@aol.com X-Yahoo-Message-Num: 10247 --part1_11.19c29379.28be61c4_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 5:36:55 AM Central Daylight Time, nicholas@uci.edu writes: > And I at least now think this is a quality, not a property, and {ka} no > longer is about properties. (Which I have translated into Lojban terms > already, 2 paragraphs above: property (one or two ce'u) but as a quality > (all or no ce'u). ) Further, I have been convinced we would more > profitably be thinking of as {si'o} (at most, {si'o... kei be zi'o} or > {du'u ... kei be zi'o} instead.) I am aware that you haven't bought this > yet; but the precise meaning of {si'o} is to me now a relatively minor > point. The consensus has been achieved where it matters -- as I said in my > own Record :-) , earlier this week. I don't get the distinction yet. I wonder if it is that (which we may come to one day) between the function in this world from tuples to truth values (the present {ka}) and that of the function from worlds to such functions in those worlds (the intension of a predicate, say, roughly). Oddly enough, I do see a role for {si'o} in that one, since, while everyone may agree about what things ARE broda, they may very well disagree about what {broda} means (I've been working on {xunre} for a hideous example and come down for spectrum position and color whorl position, but I know a lot would argue for angstrom units and others for one or another mixture technique. But, up to Ishikawa tests and the like, we agree what things are red.) --part1_11.19c29379.28be61c4_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/29/2001 5:36:55 AM Central Daylight Time,
nicholas@uci.edu writes:


And I at least now think this is a quality, not a property, and {ka} no
longer is about properties. (Which I have translated into Lojban terms
already, 2 paragraphs above: property (one or two ce'u) but as a quality
(all or no ce'u). ) Further, I have been convinced we would more
profitably be thinking of as {si'o} (at most, {si'o... kei be zi'o} or
{du'u ... kei be zi'o} instead.) I am aware that you haven't bought this
yet; but the precise meaning of {si'o} is to me now a relatively minor
point. The consensus has been achieved where it matters -- as I said in my
own Record :-) , earlier this week.


I don't get the distinction yet.  I wonder if it is that (which we may come
to one day) between the function in this world from tuples to truth values
(the present {ka}) and that of the function from worlds to such functions in
those worlds (the intension of a predicate, say, roughly).  Oddly enough, I
do see a role for {si'o} in that one, since, while everyone may agree about
what things ARE broda, they may very well disagree about what {broda} means  
(I've been working on {xunre} for a hideous example and come down for
spectrum position and color whorl position, but I know a lot would argue for
angstrom units and others for one or another mixture technique.  But, up to
Ishikawa tests and the like, we agree what things are red.)



--part1_11.19c29379.28be61c4_boundary--