Received-SPF: pass (google.com: best guess record for domain of kali9putra@yahoo.com designates 66.94.236.23 as permitted sender) client-ip=66.94.236.23;
Message-ID: <1323373742.18817.YahooMailRC@web81306.mail.mud.yahoo.com>
Date: Thu, 8 Dec 2011 11:49:02 -0800 (PST)
From: John E Clifford <kali9putra@yahoo.com>
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
To: lojban@googlegroups.com
MIME-Version: 1.0
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.0
X-Spam_score_int: 0
X-Spam_bar: /

Yes, I rather thought those were the rules you were using (or something lik=
e),=20
so what I am talking about is not a step backward so much as a step along a=
=20
different path.  Loglan claims to be a logical language, FOL spoken, with a=
ll a=20
sentence's  logical properties on the surface -- or as near as makes no nev=
er=20
mind.  We spend a lot of time worrying about, for example, what quantifier =
binds=20

what variable or within whose scope a certain item lies.  But when it comes=
 to=20
cashing in on this claim, to reconstructing the underlying FOL sentence, al=
l of=20
that is ignored. replaced by the crudest sort categorization, basically, "I=
f it=20
looks the same, it is the same."  Happily, apparently the same sort of rule=
s=20
work in constructing a Lojban sentence from from FOL and so everything work=
s out=20

all right. Except, of course, the claim that logical structure is on the=20
sentence's face.

To take the sentence you offer as an example, {ro nanla .enai ro nixli cu c=
itka=20
so'u plise}, presumably from something like {ro nanla cu citka su'o plise=
=20
.ijenai ro nixli cu citka su'o plise} and ultimately from {ro da poi nanlu =
ku'o=20
su'o de poi plise zo'u da citka de ,i je nai ro di poi nixli ko'u su'o da p=
oi=20
plise zo'u di citka da}.  The first move then is folding the quantifiers in=
 to=20
their active places -- not really a problem in this case, but a source of=
=20
several possible ones.  Next, all these infolded quantifiers are taken as t=
hough=20

they were fixed terms (which is a problem), the names of a bunch of boys=20
"all-boys", a bunch of girls "not all girls" (note the negation sign has he=
re=20
been reassigned as part of the quantifier) and two groups of apples, both c=
alled=20

"some apples", though not necessarily the same.  The two groups of apples c=
an=20
now be identified (by the rule above) and the two quantifiers, being just t=
erms,=20

can now be joined termally.  But the two apple "terms" are not the same and=
 the=20
two quantifier "terms" are not terms (nor are the apple "terms"); they are =
all=20
sentential operators, binding later terms. =20

At this point it is not clear how=20
Lojban offers any real advantages over English vis a vis the underlying log=
ic. =20
I personally wouldn't flinch at expanding {ganai su'o nanla cu klama gi ro =
lo=20
nixli cu kandansu ra} as {ro da zo'u ganai da ge nanla gi klama gi ro lo ni=
xli=20
cu kandasu da}, as it would be in English.

I suspect that this abomination is essential to making a language anyone ca=
n=20
speak, but I think we should moderate our boasting a bit in recognition of =
the=20
fact that we don't in fact do what we often claim.

----- Original Message ----
From: Jorge Llamb=EDas <jjllambias@gmail.com>
To: lojban@googlegroups.com
Sent: Thu, December 8, 2011 10:48:13 AM
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1

On Thu, Dec 8, 2011 at 12:02 AM, John E. Clifford <kali9putra@yahoo.com> wr=
ote:
> As I said, this was for one narrow case, where there were no further
> complications.  With more quantifiers (or modes) in play, more problems
> arise.

The unpacking rule I'm proposing handles every core grammatical
construct involving logical operators (negation, logical connectives
and singular quantifiers). So did the rule used by Martin, although it
differed from mine in some cases. If you are proposing a rule that
only handles a limited number of cases, you are taking us a step back
from what we already had..

> I am, for example, inclined to think that your test sentence is
> simply illegitimate, since the {su'o plise}  is within the scope of
> different quantifiers and thus is not guaranteed to have the same
> instantiation.

I think the assumption we are working with is that every grammatical
construct involving this core part of Lojban is legitimate, i.e.
grammatical means legitimate for this subset of the language. I don't
really see any problem with that assumption. The issue we are facing
is the abundance of potential unpacking rules, not a lack of them, so
we don't really need to discard some grammatical cases as
illegitimate.

> If you do want this to be legitimate,  then you have, in
> fact, "there are some apples of which every boy ate some, but not every g=
irl
> did" (disjunctive predication hypothesized).

That would be:

su'oi da poi plise zo'u ge ro de poi nanla ku'o su'o di poi me da zo'u
de di citka gi na ku ro de poi nixli ku'o su'o di poi me da zo'u de di
citka

That doesn't say anything different from what I had, but it is not
clear what you gain by introducing the plural quantification, nor
where the "su'oi" came from.

> Otherwise, the collapse is
> meaning-changing, a no-no in this game.

I don't follow. If we are considering any unambiguous unpacking rule,
whatever the rule is, it is by definition meaning-preserving. One may
have a preference for this or that coherent rule, and argue for the
merits of one rule over another, but it is the unpacking rule that
gives meaning to the packed sentence. The packed sentence doesn't come
with a predetermined meaning independent of the unpacking rule.

> To reconstruct as you would, does
> not correspond to a real collapse rule, for it treats a quantifier phrase
> like name.

Lojban's packing rules are (in part) something like:

(1) Qx:P(x,a)  <--->  P(Qx,a)
(2) P(a,c) & P(b,c)  <--->  P(a&b,c)
(3) P(a,b) & Q(a,c)  <--->  P(_,b)&Q(_,c) (a)

where "Q" stands for any quantifier and "&" for any logical
connective. Obviously the right hand side is nothing like the standard
notation of first order logic.

The problem is that these packing (or unpackinfg) rules are terribly
underspecified, since they can be further combined, and so when faced
with something like P(Ax&~Ay,Ez) the unpacking could go many different
ways depending on the order in which we apply (some generalized form
of) rules (1), (2) and (3).

My proposed rule is simple: unpack from left to right, with the caveat
that afterthought connectives can be converted to forethought first,
so that the first connectand is clearly shown to be within the scope
of the connective. That gives:

P(Ax&~Ay,Ez)
=3D P(&(Ax,~Ay),Ez)  (convert afterthought to forethought)
=3D&(P(Ax,Ez),P(~Ay,Ez))  (by rule 2)
=3D&(AxEz:P(x,z), ~AyEz:P(y,z))  (by rule 1 twice for each connectand)
=3DAxEz:P(x,z) & ~AyEz:P(y,z)  (convert to afterthought again, just to
make it look more familiar)

There are other possible coherent unpacking rules, but I'm convinced
these are the simplest and the ones that make most sense.

A somewhat separate issue is what to do with apparently unbound
variables. The basic rule is:

(4) Ex:P(x)  <--->  P(x)

but again this is underspecified as to the order in which it has to be
applied with respect to the other rules. If you want to unpack
P(Ax,y), you get something different if you apply (1) and then (4), or
if you apply (4) first and then (1).

My preferred rule is that whenever you run into a variable x which is
apparently unbound, it gets replaced by Ex, so P(x) must be read as
P(Ex) and only then apply the unpacking rules 1, 2 and 3 in the order
described above. But even better is to never omit the explicit
quantifier.

> And do you really want to talk about all boys and girls
> everywhere?

Not necessarily, I would have added a "fe'e ro roi" if I did.

But that's not relevant to the issue, is it?

mu'o mi'e xorxes

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

--=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.