Received: from mail-iy0-f189.google.com ([209.85.210.189]:49642) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RMpkb-0003Ca-9V; Sat, 05 Nov 2011 16:34:21 -0700 Received: by iage36 with SMTP id e36sf6726024iag.16 for ; Sat, 05 Nov 2011 16:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to:x-pgp-key :x-pgp-keyid:x-cunselcu'a-valsi:user-agent:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=Oq8yuvqF3IuLItdCa8sU/hmSrNgBBAVV4FKl8SXI52M=; b=H7F3u42PWswmfmDL40ae70fU0jrhMfKWbTontCV4f/dP/oh9yS0wsSBsgSj5yJpdKl ml57eI2jWZVgZ1QrgIMOalC81J5Uy4RJ0b8OB9B/1DWODtsqsou2fwP5YiBCPjv1L8Hk x0uuuf/+3S1XWTifIOybbLRdgRl3lwXWrM4Qc= Received: by 10.50.179.4 with SMTP id dc4mr2661518igc.18.1320536044344; Sat, 05 Nov 2011 16:34:04 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.231.68.202 with SMTP id w10ls4132552ibi.7.gmail; Sat, 05 Nov 2011 16:34:03 -0700 (PDT) Received: by 10.42.246.3 with SMTP id lw3mr28841291icb.0.1320536043560; Sat, 05 Nov 2011 16:34:03 -0700 (PDT) Received: by 10.42.246.3 with SMTP id lw3mr28841288icb.0.1320536043548; Sat, 05 Nov 2011 16:34:03 -0700 (PDT) Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19]) by gmr-mx.google.com with ESMTPS id r5si10514643pbe.1.2011.11.05.16.34.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 16:34:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) client-ip=192.94.73.19; Received: from gonzales.homelinux.org (root@sverige.freeshell.org [192.94.73.4]) by sdf.lonestar.org (8.14.5/8.14.3) with ESMTP id pA5NY24a014291 for ; Sat, 5 Nov 2011 23:34:03 GMT Received: from martin by gonzales.homelinux.org with local (Exim 4.75) (envelope-from ) id 1RMpkQ-0002ep-ED for lojban@googlegroups.com; Sat, 05 Nov 2011 19:34:02 -0400 Date: Sat, 5 Nov 2011 19:34:02 -0400 From: Martin Bays To: lojban@googlegroups.com Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plural variable Message-ID: <20111105233402.GA2831@gonzales> References: <20111103234955.GA3758@gonzales> <4EB43035.6040407@gmail.com> <20111104233756.GB24058@gonzales> <4EB4A123.7030305@gmail.com> <20111105061247.GE24058@gonzales> <4EB526B7.7070008@gmail.com> <20111105172216.GI24058@gonzales> <20111105201536.GB835@gonzales> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://mbays.freeshell.org/pubkey.asc X-PGP-KeyId: B5FB2CD6 X-cunselcu'a-valsi: cicna User-Agent: Mutt/1.5.21 (2010-09-15) X-Original-Sender: mbays@sdf.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of mbays@sdf.org designates 192.94.73.19 as permitted sender) smtp.mail=mbays@sdf.org Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , X-Spam-Score: -0.0 (/) X-Spam_score: -0.0 X-Spam_score_int: 0 X-Spam_bar: / --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Saturday, 2011-11-05 at 18:18 -0300 - Jorge Llamb=EDas : > On Sat, Nov 5, 2011 at 5:15 PM, Martin Bays wrote: > > I think I've made clear by now the sense in which it is effectively > > ambiguous; if not, I can try to be clearer. >=20 > I think I do get it. I just don't think it has anything to do with > logical structure. Well that's a matter of definitions. But note e.g. that the classic example of scope ambiguity in english, "someone loves everyone", can be looked at this way: A: "Someone loves everyone." B: "Oh yeah? Who? A: "Their mother." A: {su'o prenu cu prami ro prenu} B: {ma prami ro prenu} A: {lo mamta} (Lojban can't seem to get at the "their" in "their mother", but that's not really important) (and yes, I know by now that you would consider A to be breaking your favoured domain conventions by having both mundane people and Mother as a person in the same domain; but (a) that's an informal rule, which appears to be flexible (you broke it in the xabju example), and (b) it's not important to the essence of the example that prenu is being used on both sides) > > Assuming that is how {klesi} works (I find the gimste definition rather > > unclear), we would have e.g. that a type of hat selkle su'o mapku gi'e > > nai mapku. >=20 > Consider "a beret is a type of hat". I would say "lo ranmapku cu klesi > lo mapku". In reality, I'd just say {ro ranmapku cu mapku}. But if you forced me to use kind terminology, I'd want a second predicate for "x1 is a subkind of x2". From the gimste definitions, I'd be more likely to use {klesi} for that than "x1 is an instance of x2", which is closer to {mupli}. In fact, {mupli} seems to want a property in x2, so maybe this could be {klemupli}. So for the rest of this mail, I'll assume: (i) klesi(x,y,z) means that x and y are kinds, and x is the subkind of y whose exemplars are those exemplars of y which satisfy the property z (ii) klemupli(x,y) means that x is an exemplar of the kind y. (that's for atoms; to define them on arbitrary bunches, let's say they're both distributive in all places) > You may have to resort to sets: "lo'i ranmapku cu klesi lo'i mapku", > but then you can't say something like "lo vi klesi be lo mapku cu > melmau lo va klesi be lo mapku". You'd have to resort to "lo('e) mapku > poi cmima lo vi klesi cu melmau lo('e) mapku poi cmima lo va klesi". > (And still explain how "lo'e" works.) We can just use tanru - {lo vi mapku selklemupli}, maybe, if we assume that an event of klemupli occurs where the exemplars in x1 are. {lo vi selklemupli poi ro klemupli be ke'a cu mapku} would be more precise. But maybe it's true that kinds are useful enough that the language should have special facilities for handling them - e.g. allowing {lo mapku} to get a kind. We just need to have ways to disambiguate. The "imaginaries" terminology of the other thread gives one plausible approach to this - treating kinds as analogous (and, in a sense, dual) to bunches. {su'o} would get neither bunches nor imaginaries, but {lo} could get either. I suspect that a system based on this could explain e.g. most if not all of the sentences in your alis, while also being sufficiently disambiguable to satisfy me. Would you reject such a solution out of hand? > >> Presumably in Ready-Made there is only one level of events, so what > >> does it mean for an event to rapli any number other than one? > > > > With events, something like Blobularity might well be appropriate - the > > crucial point being that we have the tense system to specify carvings. > > So a nu broda is like a quantity of water - you can carve it up > > however you like and still get a nu broda. >=20 > If it's only some predicates that you restrict to mundanes, why would > "lo fasnu" or "lo rinka" not have the same problems of "lo mapku"? Because we can use the tense system to disambiguate, is I think the answer. Feel free to challenge that with an example. > > The only obvious alternative would be to say something like that an > > atomic nu broda corresponds to a connected component of the subset of > > space-time at which {broda} holds, and that events with multiple > > connected components are bunches. But I feel that might be too > > restrictive - any examples to show that it is? >=20 > We may have different ideas about what counts as "too restrictive". I guess that means you think it is? I probably agree. But I freely confess that I don't have a very clear idea of how events (or tense in general) should work in lojban. Martin --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk61x+oACgkQULC7OLX7LNZltgCcDp5wTtfLyalbN5T7HiU5UcN/ AAAAn02nApKpThP0H5AEsuzKdabdPttl =3ilp -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--