Received: from mail-pz0-f61.google.com ([209.85.210.61]:49156)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhC3ke_zBBoEKZNUpA@googlegroups.com>)
	id 1R6sxy-0001Nl-D5; Thu, 22 Sep 2011 16:46:14 -0700
Received: by pzk32 with SMTP id 32sf2367944pzk.16
        for <multiple recipients>; Thu, 22 Sep 2011 16:46:00 -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=2autfDpeXq33Vf4iltl2B0I0oHBwAd4fySdVcAWMs0E=;
        b=oq3jDxyYuNefHQN4FxzP6cXsKioDselrHHW1kC//AhJW1a4RuD9qK+OLjeuoveQeSg
         WPWb0VfNNtLZH7esNvO9mSvIDz+JPT7v5Inv6f4lPkaskqZyRG1qtmOnm+WmUZdOHM8k
         p+ZtpPY/t+koXn16WT81OVSa0UZlfWc1pjVuQ=
Received: by 10.68.28.162 with SMTP id c2mr999153pbh.13.1316735159047;
        Thu, 22 Sep 2011 16:45:59 -0700 (PDT)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.19.131 with SMTP id f3ls9703880pbe.5.gmail; Thu, 22 Sep
 2011 16:45:58 -0700 (PDT)
Received: by 10.68.38.134 with SMTP id g6mr4240541pbk.6.1316735158125;
        Thu, 22 Sep 2011 16:45:58 -0700 (PDT)
Received: by 10.68.38.134 with SMTP id g6mr4240540pbk.6.1316735158111;
        Thu, 22 Sep 2011 16:45:58 -0700 (PDT)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id p6si12108604pbc.0.2011.09.22.16.45.57
        (version=TLSv1/SSLv3 cipher=OTHER);
        Thu, 22 Sep 2011 16:45:57 -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.4/8.14.3) with ESMTP id p8MNjt1h006213
	for <lojban@googlegroups.com>; Thu, 22 Sep 2011 23:45:55 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1R6sxn-0001nf-Ez
	for lojban@googlegroups.com; Thu, 22 Sep 2011 19:45:55 -0400
Date: Thu, 22 Sep 2011 19:45:55 -0400
From: Martin Bays <mbays@sdf.org>
To: lojban@googlegroups.com
Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plural variable
Message-ID: <20110922234555.GB24443@gonzales>
References: <E5F310CB-A415-43EE-BE16-634C7F651DE7@yahoo.com>
 <20110918172927.GA4310@gonzales>
 <CAO7tK2cF45Vc1WNktVGg0PHtE0cMRutok7_1fLDwTu6kHGvUWA@mail.gmail.com>
 <20110918213323.GB6878@gonzales>
 <CAO7tK2cZuVV-1+UMZpyeitXt+waox6SskNyYUWAzNUN-EuSMTA@mail.gmail.com>
 <20110919013653.GC6878@gonzales>
 <CAO7tK2cAG0okZRcop0CiHTs0f-HsS-PmKkQb1ZwiWBDOLMDXQg@mail.gmail.com>
 <1316535587.5338.YahooMailRC@web81305.mail.mud.yahoo.com>
 <20110921000757.GR4310@gonzales>
 <1316618218.15694.YahooMailRC@web81304.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv"
Content-Disposition: inline
In-Reply-To: <1316618218.15694.YahooMailRC@web81304.mail.mud.yahoo.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: renvi
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: <lojban.googlegroups.com>
X-Google-Group-Id: 1004133512417
List-Post: <http://groups.google.com/group/lojban/post?hl=en_US>, <mailto:lojban@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:lojban+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/lojban?hl=en_US>
Sender: lojban@googlegroups.com
List-Subscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/lojban/subscribe?hl=en_US>, <mailto:lojban+unsubscribe@googlegroups.com>
X-Spam-Score: -0.0 (/)
X-Spam_score: -0.0
X-Spam_score_int: 0
X-Spam_bar: /


--A6N2fC+uXW/VQSAv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Wednesday, 2011-09-21 at 08:16 -0700 - John E Clifford <kali9putra@yahoo.=
com>:

> I am probably obtuse (as well as abstruse), but I don't see the
> problems here.  In the ckina sentence, the {lo} phrases are all in the
> scope of the universal quantifier on events and so are defined for
> each particular case as need be, different bunches for different
> contexts.

But wasn't one of the main selling-points of xorlo that {lo} ignores
such scope issues?

I assumed the rule you were going for was that {lo [selbri]} gives
a Skolem function whose only arguments are the quantified variables
which literally appear in the selbri, as in {broda ro da lo broda be
da}.

If not that, then what rule?

> I can't comment on {zo'e} since I don't know what it means,
> but in most of the readings, including the quantifier version,
> negation doesn't seem to be a problem. What problems there are, if
> any, seem to be with picking that interpretation of {zo'e} (I'm not
> sure that there is a universally acceptable interpretation -- why
> I prefer {zi'o}).

I'm not really sure what you mean here. But the point was that if we
want zo'e to have the obvious meaning in

A: xu do pu klama su'o zarci
B: mi na klama

(and I just did a quick poll on irc, which seemed to confirm that some
quite experienced lojban speakers expect zo'e to work this way),
then zo'e can't be a simple Skolem function if we keep everything else
simple (by which I mean: no funny business with kinds, or distributive
predication).

Martin

> ----- Original Message ----
> From: Martin Bays <mbays@sdf.org>
> To: lojban@googlegroups.com
> Sent: Tue, September 20, 2011 7:07:57 PM
> Subject: Re: [lojban] {zo'e} as close-scope existentially quantified plur=
al=20
> variable
>=20
> (posting here for now; feel free not to read if theorising annoys you)
>=20
> * Tuesday, 2011-09-20 at 09:19 -0700 - John E Clifford <kali9putra@yahoo.=
com>:
>=20
> > We seem to be in a three-way cross-purpose conversation.  As far as
> > I can understand, for xorxes {lo broda} refers to broda-kind,
> > a something or other (xorxes has always had trouble when we get down
> > to defining it) which has individual brodas as manifestations
> > (avatars, etc.).
> >
> > MB seems usually to think {lo broda} is down up broda, the set (C-?)
> > of brodas assigned to the world of the present conversation by the
> > function which is the meaning of {broda}. which world he seems also to
> > define in a fairly restricted way, a situation.
>=20
> I wouldn't agree with that summary.
>=20
> The C was an attempt to get directly at certain uses of {zo'e} and {lo}
> which involve, effectively, existential quantification. There was not
> intended to be any funny business with intensionality - the expansion to
> the existential was meant to be done in a world, so in particular
> C would depend on the world. (Which may sound at first like funny
> business, but hopefully not at second.)
>=20
> Xorxes would prefer to explain these existential uses of {zo'e} and {lo}
> by going via kinds. He might prefer not to put it in those terms,
> however.
>=20
> JC would, if I understand correctly, explain them by appealing to
> disjunctive predication - i.e. we have a plural predication which
> resolves itself as a disjunction over atoms.
>=20
> > I think {lo broda} refers to a L-set of brodas (or just a bunch of
> > them, without the set-talk) selected by the context.
>=20
> When you talk of L-sets and bunches, I am taking you to mean that we are
> working in a domain like Chierchia's - essentially an atomic boolean
> algebra - and an L-set/bunch is a not-necessarily-atomic element of the
> domain.
>=20
> My only problem with having {lo broda}, and indeed {zo'e}, give simply
> Skolem functions with value one of these bunches is that they are often
> used in expressions which seem to be about usual individuals rather than
> kinds, but whose meanings can't be explained by this treatment of {lo}
> and {zo'e} without going via kinds or introducing distributive
> predication. Since I consider routing via kinds to be something of
> a hack, and don't really understand how the hack works in general, and
> consider distributive predication for this purpose even more of a hack,
> I was hoping for another approach.
>=20
> Examples of such usage:
> For {zo'e}, pretty much any negated sentence.
> For {lo}, the skina sentence from the gadri BPFK section page,
> which I mentioned in a previous mail, will do:
> {ca ro nu mi rere'u catlu lo skina kei mi cpacu lo so'i se cusku poi mi
> na cpacu ca lo pamoi}
>=20
> I've no real idea how to explain that using kinds...
>=20
> Similarly for many of the other sentences on that page.
>=20
> > When it comes to using these different definitions, we generally get
> > about the same results, but some definitions appear to require more
> > mechanisms than others.  (I have passed over xorxes' insistence on
> > bringing in person segments necessarily along with persons and his
> > contrarian refusal to have brodas along with broda kind in the
> > universe of a discussion).
> >
> > They are also terminologically unified in that both MB 's and my view
> > would hold that the maximal set of brodas in a given situation is
> > broda-kind in that situation,
>=20
> Not really... I'm currently understanding kinds as Chierchia does:
> they're actual atoms in our universe, and predications which involve
> only kinds are true in all worlds or none.

--A6N2fC+uXW/VQSAv
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk57yLMACgkQULC7OLX7LNYZVQCgn6TkeB8JMEKYB0I2CITD4OND
IggAn15fIT0mg+itQznTwQpCyJwnS7Bi
=h3Ta
-----END PGP SIGNATURE-----

--A6N2fC+uXW/VQSAv--