Received-SPF: pass (google.com: best guess record for domain of kali9putra@yahoo.com designates 98.139.91.202 as permitted sender) client-ip=98.139.91.202;
References: <1323373742.18817.YahooMailRC@web81306.mail.mud.yahoo.com> <CAO7tK2dghkmpansUrBCZY7HkcH0sBGWzDpv+d8hB7ge9MuV9Ag@mail.gmail.com>
In-Reply-To: <CAO7tK2dghkmpansUrBCZY7HkcH0sBGWzDpv+d8hB7ge9MuV9Ag@mail.gmail.com>
Mime-Version: 1.0 (iPad Mail 8G4)
Message-Id: <C261B304-A8BC-4955-9016-72D1F24B5471@yahoo.com>
From: "John E. Clifford" <kali9putra@yahoo.com>
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Date: Thu, 8 Dec 2011 17:39:07 -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: /

I suppose my point is just that, when we make all these claims about being =
logical ( even in the narrow sense), one expects that the way that sentence=
s are constructed has some rational connection to the logic below, not just=
 helper smelter rules which happen to work, in some practical sense.  So, w=
hat I sketched briefly was one case of trying to make such a rule, where th=
e sentences clearly meant the same thing from beginning to end, not just en=
ding up right.  As I  say later, such rules may not be possible, but they d=
o deserve a look.

As for what is ignored, the list in this case is fairly short: binding, ins=
tantiation, and role.  The one particular quantifier is governed by two uni=
versals ( more or less), which means it's instantiation has to take both in=
to account, while in the final analysis, the two particular quantifiers are=
 each governed by a single quantifier and needs only to take that into acco=
unt.  Neither of the two ultimate instantiations would be the one the singl=
e case would give,  and, while you may say that the quantifier expressions =
are not terms, they are certainly treated as such (the claim that that they=
 can't shift positions doesn't enter here, nor, I would think, in analysis =
generally);they are, after all, joined just like names, not the overarching=
 structural elements the are ( ultimately).=20

Yes, every particular quantifier ( and universal, for that matter) is the s=
ame in function, but surely not in content, a {su'o plise} in one sentence =
points to different apples from that in another sentence. And similarly for=
 a universal, if we are restricting our domain to just the immediately rele=
vant groups, as seems to be the (unacknowledged) case here.

Sent from my iPad

On Dec 8, 2011, at 3:01 PM, Jorge Llamb=EDas <jjllambias@gmail.com> wrote:

> On Thu, Dec 8, 2011 at 4:49 PM, John E Clifford <kali9putra@yahoo.com> wr=
ote:
>> Yes, I rather thought those were the rules you were using (or something =
like),
>> so what I am talking about is not a step backward so much as a step alon=
g a
>> different path.
>=20
> Show the path already, then.
>=20
>>  Loglan claims to be a logical language, FOL spoken, with all a
>> sentence's  logical properties on the surface -- or as near as makes no =
never
>> mind.
>=20
> Indeed, at least for the logical core of the language. And that's what
> Martin and I were concerned with.
>=20
>>  We spend a lot of time worrying about, for example, what quantifier bin=
ds
>> what variable or within whose scope a certain item lies.
>=20
> Right.
>=20
>>  But when it comes to
>> cashing in on this claim, to reconstructing the underlying FOL sentence,=
 all of
>> that is ignored.
>=20
> Huh?
>=20
>> replaced by the crudest sort categorization, basically, "If it
>> looks the same, it is the same."
>=20
> The quantifier "su'o" is always the same, yes.
>=20
>>  Happily, apparently the same sort of rules
>> work in constructing a Lojban sentence from from FOL and so everything w=
orks out
>> all right.
>=20
> Indeed.
>=20
>> Except, of course, the claim that logical structure is on the
>> sentence's face.
>=20
> How is it not?
>=20
>> To take the sentence you offer as an example, {ro nanla .enai ro nixli c=
u citka
>> so'u plise}, presumably from something like {ro nanla cu citka su'o plis=
e
>> .ijenai ro nixli cu citka su'o plise}
>=20
> Yes.
>=20
>> and ultimately from {ro da poi nanlu ku'o
>> su'o de poi plise zo'u da citka de ,i je nai ro di poi nixli ko'u su'o d=
a poi
>> plise zo'u di citka da}.
>=20
> That's ungrammatical, but if you add a couple of tu'e-tu'u, or switch
> to "ge ... ginai ...", yes.

Sorry, this reads out fine, both with and without the {je}.  Probably I hav=
e an old parser.

>=20
>>  The first move then is folding the quantifiers in to
>> their active places -- not really a problem in this case, but a source o=
f
>> several possible ones.
>=20
> Tell us about those problems, then! The first move is about expanding
> an ek into an ijek (it would be better to do it with geks, but you can
> do it with ijeks too if you are careful). What possible problems do
> you see, and what alternative rule do you propose, given that Lojban
> has eks (which are not part of standard notation) and they need to be
> dealt with somehow.
>=20
Well, of course, I am not thrilled with the multitude of versions of the lo=
gical connectives, but, since we have sliced and diced the sentence so many=
 ways, surely distinguishing between a quantifier phrase and a name can cla=
im as much right to have it's own connective as bridi tails and some other =
odd items.  Except, I suppose, that this lumping together never gives a wro=
ng analysis in the end, whereas confusing a tanru internal connective with =
a predicate one does.

>> Next, all these infolded quantifiers are taken as though
>> they were fixed terms (which is a problem), the names of a bunch of boys
>> "all-boys", a bunch of girls "not all girls"
>=20
> Not at all. If they were fixed terms they could be moved freely
> around, but they are not. They are bridi operators and therefore their
> position in the sentence is crucial. They are indeed the same bridi
> operator every time they appear, just like "na ku" is the same
> operator every time it appears, and just like "ge ... gi ..." is the
> same operator every time it appears. Is that what worries you? Do you
> think "su'o da poi plise zo'u" could be a different operator each
> time?
>=20
I find this question to ambiguous to deal with easily, but see my comments =
earlier about instantiations.=20

>> (note the negation sign has here
>> been reassigned as part of the quantifier)
>=20
> Who has done that? Do you think it's a problem? I'm not sure if the
> parenthetical was meant as criticism or merely as a description of
> what you were doing. "ge ... gi nai ro da zo'u..." is of course
> equivalent to "ge ... gi na ku ro da zo'u ..." which in turn is
> equivalent to "ge ... gi me'i da zo'u ...", so the move of the
> negation from the connective to the quantifier would be quite
> legitimate, even though I had not done that in my expansions.
>=20
The objection is, of course, to burying a negation ( another structural ele=
ment) in a term, a non-structural element.

>> and two groups of apples, both called
>> "some apples", though not necessarily the same.
>=20
> There are no groups of apples involved at all. There is only the bridi
> operator "su'o da poi plise zo'u" appplied two times. The domain of
> this quantifier is the restriction from everything in the domain of
> discourse to those things that satisfy the predicate "plise".

Well, sometimes two ( each under a single quantifier)  and sometimes one (u=
nder two quantifiers).  In either each case the have different result, even=
 if the same function.
>=20
>>  The two groups of apples can
>> now be identified (by the rule above) and the two quantifiers, being jus=
t terms,
>> can now be joined termally.
>=20
> What two groups of apples?
>=20
>>  But the two apple "terms" are not the same
>=20
> Why not?
>=20
>> and the
>> two quantifier "terms" are not terms (nor are the apple "terms"); they a=
re all
>> sentential operators, binding later terms.
>=20
> Exactly so, they are not terms! They are two instances of one and the
> same sentential operator, just like two instances of "na ku" would be
> two instances of one and the same sentential operator. (They are
> "terms" only in the sense that Lojban's formal grammar calls them
> that, but that's just Lojban being sloppy with technical terms as
> usual.)
>=20
Except that quantifiers, unlike negations, introduce references to things.
"'
>> At this point it is not clear how
>> Lojban offers any real advantages over English vis a vis the underlying =
logic.
>=20
> I still can't identify what it is that bothers you.
>=20
>> I personally wouldn't flinch at expanding {ganai su'o nanla cu klama gi =
ro lo
>> nixli cu kandansu ra} as {ro da zo'u ganai da ge nanla gi klama gi ro lo=
 nixli
>> cu kandasu da}, as it would be in English.
>=20
> That involves a donkey pronoun, and we don't as yet have spelled out
> proper rules to handle them. This is not part of the kind of unpacking
> rules we were discussing.
>=20
But it is just the kind of rule that needs to be discussed.  Does Lojban al=
low donkey sentences or not.  As you seem to have set up the rules at the m=
oment, it apparently does not, so no more need Bessie.  But I expect someon=
e to produce one any day now and be unhappy if it comes out meaning "if a b=
oy comes, all the girls will dance with somebody or other"
'
>> I suspect that this abomination is essential to making a language anyone=
 can
>> speak, but I think we should moderate our boasting a bit in recognition =
of the
>> fact that we don't in fact do what we often claim.
>=20
> Be that as it may, it's not what this discussion was about.
>=20
True enough; it is just a passing remark that might conceivably relevant to=
 your project, since it bears on what you claim to be doing in the light of=
 the usual Lojban ads.
> mu'o mi'e xorxes
>=20
> --=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@googlegr=
oups.com.
> For more options, visit this group at http://groups.google.com/group/lojb=
an?hl=3Den.
>=20

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