Received-SPF: pass (google.com: best guess record for domain of kali9putra@yahoo.com designates 98.138.91.164 as permitted sender) client-ip=98.138.91.164;
References: <1322084099.71575.YahooMailRC@web81302.mail.mud.yahoo.com> <20111125034454.GI6112@gonzales>
In-Reply-To: <20111125034454.GI6112@gonzales>
Mime-Version: 1.0 (iPad Mail 8G4)
Message-Id: <1BC62F1A-FC02-415D-8863-BA795809DB95@yahoo.com>
From: "John E. Clifford" <kali9putra@yahoo.com>
Subject: Re: [lojban] No title, since the subject will have changed by the
 time it gets there
Date: Fri, 25 Nov 2011 12:38:20 -0600
To: "lojban@googlegroups.com" <lojban@googlegroups.com>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /


Sent from my iPad

On Nov 24, 2011, at 9:44 PM, Martin Bays <mbays@sdf.org> wrote:

> * Wednesday, 2011-11-23 at 13:34 -0800 - John E Clifford <kali9putra@yaho=
o.com>:
>=20
>> Summary
>=20
> Good idea!
>=20
>> 1. {zo'e}, as implicit in unfilled places, can't mean either "what I (wo=
uld=20
>> have) had in mind" or a particular quantifier, because there are too man=
y cases=20
>> where it has to mean the other.
>=20
> Pardon?

What is obscure here? =20
{zo'e} can't be either one of these because both of them occur as reasonabl=
e expansions into the blank space and being one would preclude being the ot=
her.  Unless you mean that a particular quantifier is one thing I might hav=
e had in mind.  But that creates the problem of mixing variables with names=
, which is not where we want to go, I think.

>=20
>> It can't be {zi'o} either, since that really=20
>> does both the sense and reference of the underlying predicate (think of =
all=20
>> those places which can't be gone to from anywhere by any route on any me=
ans of=20
>> transportation -- the center of the Earth, say, pace Edgar Rice Burrough=
s).
>=20
>> Ideally (I think), unfilled places should be particular quantifiers,
>=20
> Surely not just that. {ta melbi} is quite a different assertion from {ta
> melbi da}.

{ta melba} presumably means {ta melba mi}, so is a case where the fill shou=
ld be made or=20
{ zo'e} used.  (I don't expect this to happen except in really  formal writ=
ing -- and probably not even there -- but we're talking about feed into sem=
antics her and how to fill in gaps.)=20
>=20
>> {zo'e} should be stated when a fixed, though perhaps unspecified,
>> referent is intended.
>=20
> I think having a word which literally acts as if the place were unfilled
> is a useful enough feature that we shouldn't do away with it unless
> necessary.
>=20
> Perhaps we can use {lo du} for the meaning you suggest?

I think I am missing your point here. {zi'o} says the place is unfilled.  {=
zo'e} says the place is filled but I'm but telling you by what.  And what d=
oes {lo du} do?  It is either the self-identical things, which provides no =
information, or it is the things identical with some unnamed thing, which i=
s just the problem we are out to solve, so doesn't help.
>=20
>> While I'm at it, we should change {ce'u} over to a variable-binding
>> operator so we can do abstractions right.
>=20
> Pardon

Make it be lambda and put variables after it, so we can distinguish when tw=
o arguments are the same from when they are different.
>=20
>> 2. {lo broda} refers to a bunch of brodas (either an L-set or a plural=
=20
>> reference, as your ontological conscience guides you), fixed by context =
but=20
>> possibly not terribly specific. The bunch may have a single member or en=
compass=20
>> all brodas that have ever been and maybe more (all in this universe of=
=20
>> discourse, of course, though maybe not in this world
>=20
> But all satisfying broda(_) in this world, right, whether or not
> zasti(_)?
>=20
Yes, I suppose so.

> (This relates to maikxlx's intensionality remarks)
>=20
>> ). These latter, maximal, bunches  represent brodakind for all
>> practical purposes. Because of the transparency of bunches, such
>> a bunch of brodas is also a bunch of kinds of brodas, etc.  These
>> maximal bunches might usefully have a separate gadri.
>>=20
>> Another bunch type which could use its own gadri is a mass, which can be=
 viewed=20
>> either as the kind parts of brodas which can still broda (atoms, molecul=
es,=20
>> cells, ....) or as constructed by going through all the parts of brodas,=
 sorting=20
>> out ones that are not broda and gathering the rest into the new bunch, t=
o be=20
>> further analyzed.
>> Some few problems remain: letters (though this can be made to fit in, if=
 you=20
>> don't mind considering all the even transient occurrences of a character=
 in=20
>> 4-space), geometric figures, things with the order type of the reals, an=
d so on=20
>> (mainly mekso, so we can forget about them for another twenty years).
>>=20
>> 3. Bunches relate to predicates in a variety of ways, for none of which =
does=20
>> Lojban have an explicit marker, though some can be inferred from other f=
actors=20
>> (quantifiers, modals -- though we are somewhat defective there as well, =
or maybe=20
>> just more pragmatic or rhetorical devices -- I'm not sure what generaliz=
ation or=20
>> stereotype is).  I don't have a complete list and am unsure about the st=
atus of=20
>> some I do have, so some discussion would be welcome.
>=20
> Right, this is the part of your approach I'm unhappy with. I'm loath to
> give up the simple version of plural semantics, whereby a selbri is
> interpreted in a given world just as a relation on the set of bunches.
>=20
But as far as I can see, you are the one who has given that up.  I certainl=
y have not.  I have nothing but bunches of broda all the way up (or down, a=
s the case may be).  I am deliberately avoiding the use of"set", since that=
 raises other problem.  So far as I am concerned, the domain of the functio=
ns can be just bunches (of bunches, if you like).

> Complicating this with your "modes of predication" (conjunctive,
> disjunctive, collective, statistical...) seems to fit lojban ill,
> precisely because lojban has no way to mark them.

So far as I can tell, this jumble just comes with plural reference, togethe=
r with an attempt to realistically with how various things we say are relat=
ed to the things we talk about.  I don't suppose the list is complete yet, =
but that is only a practical problem.  As for not fitting Lojban, Lojban wa=
s designed without plural reference (or L-sets) and so makes no allowance f=
or them.  What it does partly make allowance for is using (C-)sets to repre=
sent plurals.  But just what that involved was never spelled out too clearl=
y (and much of what was originally spelled out was lost in xorlo), so we ca=
nnot merely take it over for L-sets.  Restoring some of that, or devising n=
ew conventions, can cover much of the difficulty and perhaps all, depending=
 on how wide our convention net spreads.

> The alternative is to further complicate the domain - adding more
> derived entities beyond bunches. The marking can then be done with gadri
> and quantifiers.

I'm not sure what you mean here.  I don't see how adding new entities (what=
, I wonder) will help with the modes of predication issue.  A few nice adve=
rbs seem to be the most natural way to proceed.  Gadri, we decided long ago=
, are not going to help with issue -- well, except that marking off those g=
igantic bunches does flag that some "statistical" predication is intended, =
or, perhaps, genetic.
>=20
> I don't have a coherent scheme to propose for that, though... in
> particular, although the "bunches of slices" approach And & I were
> formulating the other week seems to deal with many problems, I don't see
> how it fits with generic predication.

I haven't looked back to see you earlier system nor what, if anything, I sa=
id about it, so i'm not sure what problems you think it solves (I'm not eve=
n sure what problems you think you have to solve).  Nor am I sure what you =
mean by generic predication, unless that is just another mode, involving th=
ose large bunches again.
>=20
>> 4.  We need a way to sort out the official meaning (sense, a function on=
 worlds)=20
>> and the ordinary meaning, an area in in the web of  other meanings (prob=
ably not=20
>> a spot in the Platonic tetrahedron anymore).  And then say which one we =
are=20
>> talking about.
>=20
> Pardon?

Well, it seems to me that people (myself included) flop back and forth amon=
g "lion" represents a function from(or relation between) things and truth v=
alues and "lion' represents a function from worlds to a set of objects in t=
hat world and "lion" represents the property of being a large cat (genus Pa=
nthera) ... .  Trying to satisfy the various conditions these impose is a p=
roblem, since they are very different .  I think part of our problem is tha=
t we often are at cross purposes here.
>=20
>> 5.  I always told my students that, for me, memory is not a pramana, but=
 tends=20
>> to be spotty and self-aggrandizing, so I won't argue with Lojban about w=
hat I=20
>> said twenty yeara ago; he has the records (but I bet he can't find 'em).=
  And,=20
>> of course, I may well have changed my mind over the years.  But still I =
am=20
>> shocked to think I ever was pleased with a modal "can and does".  The ne=
ed for a=20
>> logical necessity operator is less pressing that a variety of strong mod=
als and=20
>> their duals for the major kinds of compulsions (logic is rarely relevant=
 except=20
>> in the most hair-splitting arguments).  I am not sure about where they b=
elong=20
>> grammatically, but in Logic they function pretty much exactly like negat=
ion and=20
>> tense.
>=20
> I'm liking xorxes' suggestion that some "irrealis" UI act like modal
> operators - e.g. {ei} for deontic, {ia} for doxastic etc - using
> a correctly placed e.g. {ca'a ei} when we want non-default scope.

Probably right.  There are also some looser ornaments that might be useful =
in this general area.  But, in a logical language of the sort Lojban claims=
 to be, they should all have grammar.

--=20
You received this message because you are subscribed to the Google Groups "=
lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegrou=
ps.com.
For more options, visit this group at http://groups.google.com/group/lojban=
?hl=3Den.