From pycyn@aol.com Mon Feb 05 19:47:04 2001 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_0_2_1); 6 Feb 2001 03:46:21 -0000 Received: (qmail 63674 invoked from network); 6 Feb 2001 03:46:20 -0000 Received: from unknown (10.1.10.27) by m8.onelist.org with QMQP; 6 Feb 2001 03:46:20 -0000 Received: from unknown (HELO imo-d06.mx.aol.com) (205.188.157.38) by mta2 with SMTP; 6 Feb 2001 03:46:20 -0000 Received: from Pycyn@aol.com by imo-d06.mx.aol.com (mail_out_v29.5.) id r.da.1f41e98 (2176) for ; Mon, 5 Feb 2001 22:46:16 -0500 (EST) Message-ID: Date: Mon, 5 Feb 2001 22:46:16 EST Subject: RE:su'u To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_da.1f41e98.27b0cd88_boundary" Content-Disposition: Inline X-Mailer: 6.0 sub 10501 From: pycyn@aol.com --part1_da.1f41e98.27b0cd88_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit As an at least occasional Nyayaika and Montagovian, I have to say that abstractions from sumti do make sense, since every individual (or group or mass) has an abstract "-ness." This is different from {ka/nu/.... me [sumti]}, since it holds of the individual even in worlds where the [sumti] does not (indeed, is how you trace the individual across worlds). It is also different from {nu/ka/... [sumti] ca'e}. Since it has been amply demonstrated here that {nu/ka/... [sumti]} does not parse, we need something else. Any suggestions? Notice xod's suggestion will not work either. --part1_da.1f41e98.27b0cd88_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit As an at least occasional Nyayaika and Montagovian, I have to say that
abstractions from sumti do make sense, since every individual (or group or
mass) has an abstract "-ness."  This is different from {ka/nu/.... me
[sumti]}, since it holds of the individual even in worlds where the [sumti]
does not (indeed, is how you trace the individual across worlds).  It is also
different from {nu/ka/... [sumti] ca'e}.  Since it has been amply
demonstrated here that {nu/ka/... [sumti]} does not parse, we need something
else.  Any suggestions?  Notice xod's suggestion will not work either.
--part1_da.1f41e98.27b0cd88_boundary--