Received: from mail-pz0-f61.google.com ([209.85.210.61]:59693)
	by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76)
	(envelope-from <lojban+bncCOTEtqyUDhDDxcT0BBoEZ4Mknw@googlegroups.com>)
	id 1RCkzU-0000rf-55; Sat, 08 Oct 2011 21:28:05 -0700
Received: by pzk32 with SMTP id 32sf4953202pzk.16
        for <multiple recipients>; Sat, 08 Oct 2011 21:27:50 -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=Uw4p+yzsYxuc4yEjqWycxhHSSIiI843eaLTdj9U8Sug=;
        b=RyFDzAbEkJlQlBknB3GyfkWnv3ggOMLtBFa7aTV/PIe5DIH+mCGL3TSoxRtt5UCNav
         LK7fj77Ro0AYEUnmdmH/YsZ6nK5dfekTb4EZDql1GsqJdnEU0H9LPOSiy+l4igzsoXIc
         /U0BN3WvA+u1vhk239mvJcCj19LQv35FiA2dk=
Received: by 10.68.37.102 with SMTP id x6mr1293834pbj.18.1318134467279;
        Sat, 08 Oct 2011 21:27:47 -0700 (PDT)
X-BeenThere: lojban@googlegroups.com
Received: by 10.68.19.131 with SMTP id f3ls12381346pbe.5.gmail; Sat, 08 Oct
 2011 21:27:46 -0700 (PDT)
Received: by 10.68.8.135 with SMTP id r7mr19444463pba.8.1318134466508;
        Sat, 08 Oct 2011 21:27:46 -0700 (PDT)
Received: by 10.68.8.135 with SMTP id r7mr19444462pba.8.1318134466493;
        Sat, 08 Oct 2011 21:27:46 -0700 (PDT)
Received: from sdf.lonestar.org (mx.sdf.org. [192.94.73.19])
        by gmr-mx.google.com with ESMTPS id lf12si3146690pbb.2.2011.10.08.21.27.46
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 08 Oct 2011 21:27:46 -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 p994RjZU024964
	for <lojban@googlegroups.com>; Sun, 9 Oct 2011 04:27:45 GMT
Received: from martin by gonzales.homelinux.org with local (Exim 4.75)
	(envelope-from <mbays@sdf.org>)
	id 1RCkzJ-0004th-BN
	for lojban@googlegroups.com; Sun, 09 Oct 2011 00:27:45 -0400
Date: Sun, 9 Oct 2011 00:27:45 -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: <20111009042745.GB4634@gonzales>
References: <20110916000632.GD7274@gonzales>
 <E5F310CB-A415-43EE-BE16-634C7F651DE7@yahoo.com>
 <CAKOEKkSZppVHdtXhAZax72guOUG-g=ytjkYvtqoOeT4LGb4y+w@mail.gmail.com>
 <1317917098.8073.YahooMailRC@web81303.mail.mud.yahoo.com>
 <CAKOEKkTOdX_kc0oojPXBRwsWL-sxTKAnp_HG2rS_kSf7Td68=Q@mail.gmail.com>
 <1317924653.89892.YahooMailRC@web81302.mail.mud.yahoo.com>
 <20111006193514.GC8826@gonzales>
 <3166A594-07BE-4D24-AA0F-C56D07C223A5@yahoo.com>
 <20111007003217.GD8826@gonzales>
 <A9DCCC65-B17C-4B53-AFA1-64E03C14875C@yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD"
Content-Disposition: inline
In-Reply-To: <A9DCCC65-B17C-4B53-AFA1-64E03C14875C@yahoo.com>
X-PGP-Key: http://mbays.freeshell.org/pubkey.asc
X-PGP-KeyId: B5FB2CD6
X-cunselcu'a-valsi: cinta
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: /


--uZ3hkaAS1mZxFaxD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Saturday, 2011-10-08 at 19:56 -0400 - John E. Clifford <kali9putra@yahoo.=
com>:

> Lying on abed of pain, I have been thinking about this a bit and want
> to revise my position somewhat. =20

Sorry to hear about the circumstances; I trust {zo'e} issues distract
rather than contribute.

> About {zi'o}, there are two possible ways of reading, say, {zi'o
> klama}. One as a relation among places, paths and modes of
> transportation that hold of a quartet of such just in case some
> traveler take the path from the second place to the first along the
> path using the transportation mode. The second is much the same except
> that the traveller does not enter in, we just have a relation among
> the quartets with no further indication of why they are in that
> relation.  The second view, while formally possible, is surely not
> what is intended; why would we use {klama} if the things related were
> never part of a trip?  But, as a result, {zi'o} becomes equivalent to
> your friend, the short-scope particular quantifier.

That may be the case with {klama}, but e.g. in {zi'o kancu}, the
intention really is that no counter need be involved; similarly with
{zi'o darlu}. Of course you could say that there are *potential*
counters and arguers... but that's still different from the likely
meaning of e.g. {zo'e darlu ko'a ko'e}.

> So, I drop that suggestion.  Which brings us back to {zo'e} and
> unfilled places.  I take it as a given that {zo'e} is a constant ( at
> each use -- not an ideal situation)and never a variable.  The
> appearance that it is sometimes a variable comes from the fact that
> unfilled places clearly are variables sometimes, combined with the
> claim that every unfilled space is a covert occurrence of {zo'e}.
> This last now seems to me to just be flat wrong, as the examples
> bandied about here seem clearly to prove.

So by an unfilled place being a variable, you mean acting as I was
suggesting {zo'e} does?

> On the other hand, some
> unfilled spaces are clearly covert {zo'e} or some constant, at least.
> The constant seems to be subsumable under the "thing I have in mind"
> reading, whether obvious anaphora, obvious deixis, or less obvious
> personal whim (cf. the definitions of descriptors).  This leaves
> a totally unacceptable situation, at least for a logical language,
> whose transformations are supposed to be on the surface: an unfilled
> space is four ways ambiguous.

Well... absorbing anaphora and deixis into the "things I have in mind"
category seems harmless.

> It seems the only logically sensible
> out is to allow unfilled spaces only for variables (the general case)
> and require something more specific for the rest,preferably the
> appropriate pronouns in those case and {zo'e} on the last, though
> I suppose that in most cases {zo'e} could do for all three.

But unless I'm misunderstanding what you mean by variables, the other
three cases (which are arguably really just one case) are just special
cases of the variable case - namely, where the glorked domain of the
existential quantification is a singleton (whose single element might be
a plurality, of course).

So I'm understanding you as having {zo'e} force the domain to be
a singleton, but otherwise to work like an unfilled place.

It seems reasonable to want a word for that. Maybe it should be {zo'e},
I'm not sure. If it were, we'd need to find another word with the
meaning of an unfilled place, say {zo'e'e} - if only because {lo broda}
would then be {zo'e'e noi broda} rather than {zo'e noi broda} (to
whatever extent that equivalence ever works).

> So, back to the question case: the appropriate negative responses to
> the question { xu do klama le zarci} are {na}(or should that
> be{naku}?), {na go'i}, {mi na klama zy} ( or some more official
> pronoun), and the basic {mi na klama le zarci}, with {mi na klama
> zo'e} as a marginal possibility.

And {mi na klama} as a definite possibility, yes?

> On Oct 6, 2011, at 20:32, Martin Bays <mbays@sdf.org> wrote:
>=20
> > * Thursday, 2011-10-06 at 17:21 -0400 - John E. Clifford <kali9putra@ya=
hoo.com>:
> >=20
> >> Which is why I added "or would have I intended if he had thought of
> >> it". So you are saying he might have intended a variable.
> >=20
> > Ah, I was reading your "something" in "something I have in mind (or
> > would have, if I thought about it)" as being an ordinary something (or
> > somethings, presumably), i.e. just some element (possibly plural) of th=
ee.=20
> > universe.
> >=20
> > Having it be a variable is roughly right, yes. This can't be dealt with
> > at a textual level - simply substituting {da xi ci ze} for {zo'e} -
> > because {zo'e ro da broda} should be the same as {ro da zo'u zo'e da
> > broda}. Hence the "close-scoping (plural) existential with glorked
> > domain" suggestion made in this thread.
> >=20
> > Do you still think that suggestion is wrong/bad in some way?
> >=20
> >> I personally think it is {zi'o}, but that probably has problems
> >> too--though I can't think of one.
> >=20
> > My main problem with that is just the icky ambiguity it would introduce.
> > In principle, {zi'o klama} is an entirely new 4-place predicate, whose
> > semantics are related to those of {klama} but not in any very
> > predictable way. So if an omitted place can be {zi'o}, understanding the
> > possible meanings of any expression would, in principle, involve
> > understanding many such zi'o-derived selbri.
> >=20
> > Martin
> >=20
> >> On Oct 6, 2011, at 15:35, Martin Bays <mbays@sdf.org> wrote:
> >>=20
> >>> * Thursday, 2011-10-06 at 11:10 -0700 - John E Clifford <kali9putra@y=
ahoo.com>:
> >>>> Well, I am not sure just what the all the complications that MB and
> >>>> xorxes have stirred up are, but, so far as I can follow it, the
> >>>> position seems to be that {zo'e} stands for something I have in mind
> >>>> (or would have, if I thought about it).  It is a constant (a differe=
nt
> >>>> one at each occurrence -- an ongoing problem in Lojban), not
> >>>> a variable and not under any quantifier.  Then {lo broda} is that wi=
th
> >>>> the additional information that the something is in some way, broda.
> >>>> So, it can refer to anything from a single broda to all brodas, past,
> >>>> present, future, and possible but not actualized.  This referent can
> >>>> then be said to have a further property in a variety of ways, mainly
> >>>> to be grokked from context, since the ways to specify them are not y=
wr
> >>>> well-established.  My understanding is that MB disagrees with this
> >>>> specification of {zo'e} and xorxes with the extrapolation to the
> >>>> referent, but juast why is hard to see.
> >>>=20
> >>> Because it doesn't seem to explain the behaviour of {zo'e} with respe=
ct
> >>> to negation and quantifiers - at least if we accept that an unfilled
> >>> place is implicitly filled with a {zo'e}, and if we don't use kinds.
> >>>=20
> >>> To dig out the old example, in
> >>> A: xu do pu klama lo zarci
> >>> B: mi na klama
> >>> , and assuming that there's only one market in question, B probably
> >>> intends to refer to that market by the implicit {zo'e} in {klama}'s x=
2.
> >>> But B is unlikely to mean only to mean that for some specific route,
> >>> B didn't go to the market by that route. B probably means that B didn=
't
> >>> go to the market via *any* route, or means of transport.
> >>>=20
> >>> Your explanation of {zo'e} seems not to deal with that.

--uZ3hkaAS1mZxFaxD
Content-Type: application/pgp-signature

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

iEYEARECAAYFAk6RIsEACgkQULC7OLX7LNahuQCgyPXJvgVTp/jm6Br6SCH/z0wQ
v40AmwZuXrs0eoqinkuRdxkEkMf0roVP
=0oeg
-----END PGP SIGNATURE-----

--uZ3hkaAS1mZxFaxD--