From pycyn@aol.com Sat Mar 09 16:26:59 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: unknown); 10 Mar 2002 00:26:58 -0000 Received: (qmail 20810 invoked from network); 10 Mar 2002 00:26:58 -0000 Received: from unknown (216.115.97.167) by m2.grp.snv.yahoo.com with QMQP; 10 Mar 2002 00:26:58 -0000 Received: from unknown (HELO imo-m06.mx.aol.com) (64.12.136.161) by mta1.grp.snv.yahoo.com with SMTP; 10 Mar 2002 00:26:58 -0000 Received: from Pycyn@aol.com by imo-m06.mx.aol.com (mail_out_v32.5.) id r.38.2474ef9e (3984) for ; Sat, 9 Mar 2002 19:26:54 -0500 (EST) Message-ID: <38.2474ef9e.29bc024d@aol.com> Date: Sat, 9 Mar 2002 19:26:53 EST Subject: Re: [lojban] Re: Quantifiers, Esistential Import, etc. To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_38.2474ef9e.29bc024d_boundary" X-Mailer: AOL 7.0 for Windows US sub 118 From: pycyn@aol.com X-Yahoo-Group-Post: member; u=2455001 X-Yahoo-Profile: kaliputra --part1_38.2474ef9e.29bc024d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/9/2002 12:49:42 PM Central Standard Time, jjllambias@hotmail.com writes: > and it allows all the transformations > that my system allows (section starting on page 405). It also says > explicitly that {su'o da poi verba naku klama su'o de poi ckule} > is identical in meaning to {su'o verba naku klama su'o ckule}, > which is what my system allows, but not yours. The kindest thing to say about 16.9 (401) and 16.11 (405) is that they were done without thinking about the existential import problem (and without paying attention to what people were doing already -- so much for "let usage decide"), Actually, since 16.9 is all about unrestricted quantifiers, the question doesn't arise: the domain is always non-null, so the simplest conversions occur. I suspect this got stuck in Cowan's mind when he got to 16.11 and restricted quantifiers of some sort or other. I suppose it is possible that {ro da poi} and {su'o da poi} have opposite import (I suppose A- and I+) but I don't see any evidence that this is what was intended (or even thought of). Is that where you got your stange mixes of types? The identification of {su'o da poi broda} with {su'o broda} appears to back up the I+ identification; the identification of {ro da poi broda} with {ro broda} goes against it, but does support the hypotheses that 1) {da poi} belongs in + and 2) 16.11 forgot about import. Well, for wha it is worth, I seem to have the book's backing for my preferred system, but, as noted, I have reason to believe that, like a tidy way of dealing with {ce'u}, it will not fly. --part1_38.2474ef9e.29bc024d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/9/2002 12:49:42 PM Central Standard Time, jjllambias@hotmail.com writes:

and it allows all the transformations
that my system allows (section starting on page 405). It also says
explicitly that {su'o da poi verba naku klama su'o de poi ckule}
is identical in meaning to {su'o verba naku klama su'o ckule},
which is what my system allows, but not yours.

The kindest thing to say about 16.9 (401) and 16.11 (405) is that they were done without thinking about the existential import problem (and without paying attention to what people were doing already -- so much for "let usage decide"), Actually, since 16.9 is all about unrestricted quantifiers, the question doesn't arise: the domain is always non-null, so the simplest conversions occur. I suspect this got stuck in Cowan's mind when he got to 16.11 and restricted quantifiers of some sort or other. I suppose it is possible that {ro da poi} and {su'o da poi} have opposite import (I suppose A- and I+) but I don't see any evidence that this is what was intended (or even thought of). Is that where you got your stange mixes of types? The identification of {su'o da poi broda} with {su'o broda} appears to back up the I+ identification; the identification of {ro da poi broda} with {ro broda} goes against it, but does support the hypotheses that 1) {da poi} belongs in + and 2) 16.11 forgot about import.
Well, for wha it is worth, I seem to have the book's backing for my preferred system, but, as noted, I have reason to believe that, like a tidy way of dealing with {ce'u}, it will not fly. --part1_38.2474ef9e.29bc024d_boundary--