Re: On logji lojbo discussions

[Logical Language Group <lojbab@ACCESS.DIGEX.NET>]

>[I can't tell from message headers whether messages come from
>Lojban list or not.]

Interesting.  All my list messages start with this FROM line (subject to
date change):
>From LOJBAN@CUVMB.CC.COLUMBIA.EDU Fri Dec  5 10:56:23 1997

>Tanru modifiers do not affect truth-conditional meaning. To find
>out the sense of a gismu, one needs to examine it as a selbri.

Well they can, but I understand what you are saying.

>What Jorge and others pointed out was an apparent inconsistency
>in the refgrammar. That this inconsistency was due to sumti-raising
>errors was only one possible way of resolving the problem.

True, but it is the type of resolution that people (especially Jorge)
seem partiocularly adept at finding.  Yet it recieved no emphasis if it
were even mentioned.

>Also, calling the erroneous usage of ni/jei "sumti-raising" is
>unhelpful, since using "tu`a le ni/jei" still does not fully
>capture the intended meaning. Others called it "indirect question"
>which is far clearer.

Ch 11 section8 of the refgrammar discusses this, and describes tu'a/jai as
resolutions to sumti-raising.  "Indirect questions" constitute one class of
utterances where sumti-raising is common, and th use of
abstractions with
kau/du'u (and tu'a when
 dealing with the x2 of djuno when sumti r
aising is
present) is the suggested resolution.  "Indirect question" is a description
of the porblem that this use of jei is attempting to solve (though Cowan
did not mark it as such in section 7 and may not have recognized it as such),
while "sumti-raising" is a description of the language feature
that was
ignored, which caused the example to be in error (or at least poor and
misleading - it is clear that we have said that umarked sumti raising is a
"bad thing" because it kills logical rigor, but we have also recognized that
this tyoe of mistake will be common among people not used to thinking in
Lojban and thus I am not sure it has quite risen to the status of "error".
Obviously for your purposes it is indeed an error, but from the standpoint fo
the refgrasmmar which we have now found includes such errors, while of course
being officially perfect it is not so clearly an error %^)

>Right, but to actually get across the intended meaning, it should
>have been
>
>  mi djuno lo du`u xu kau la frank cu bebna


Or perhaps "mi djuno tu'a lejeikau la frank cu bebna"

>Had jei meant "whether" it would have been VERY useful.
Since xukau and lejeikau exist this seems incorrect.  It would be unique
among indirect questions in not requiring indirect question marking.

>(b) most users
>realized that using "jei" to mean "whether" would be erroneous
>(even though I am sure that "jei" was created with the intention
>that it mean "whether"

No, since I created it.  It was created specifically to talk about the truth
of a proposition.  The 0/1 scale was adopted from standard computer logic
representations, and for being compatible with fuzzy logic, whihc has been in
the back ofmy designing mind since the earliest days (it was discussed at the
first Logfest held at my house) even tho8gh it was then claear that we did not
know what exactly would be needed to support it.  Note that a
t this time
we had ONLY nu, ka, and ni - all of the other abstractors came later, and I
think I was among other things trying to keep this one meaning away from "ni"
(a close-ended truth functionality abstractor).

du'u did not exist as an abdtractor then - it or its predescessor was a
part of Mex at the beginning used to talk about the equation rather than
the value.  sumti-raising was something pc apparently had identified as a
problem to JCB, but nothing had ever appeared in print about it.

If I recall, cu'o was added to MOI early on as another way of dealing with
fuzzy logic, since at that time I had the apparently mistaken assumption
that fuzzy logic was akin to probability.  I am not all that sure that we will
not find sufficient *linguistic* similarities to justify uniting expression
of fuzzy logic and probability, even though I have been told that they are
totally unrelated.  But I was fixated at the time on the 0/1 truth functiona
l
scale which applies to both probability and some fuzzy logics.

"whether" had certainly never been discussed, nor any other sort of indirect
question.

>Note that I do not then go on to advocate any change of the
>baseline, or anything like that. Rather, I would like us to
>discuss unresolved issues, and what the best resolution would
>be, even though the results of the discussion are non-binding
>(at least not until/unless usage entrenches them).
>
>Are you reassured by that? Are we moving towards agreement?

I suggest that I will be reassured only when there is a mechanism, formal or

informal  whereby when people think they are discussiong an unresolved
problem, they document said problem at least to the level of Cowan's old
change proposals before the discussion starts.  Let us agree that there
 is
an unresolved problem before trying to resolve it, and then use the
prewritten problem statement as a basis to track resolutions.  Th
e "solution"
wold have to be written up as a summary.  Since the bulk of such is
sues are
semantics, I would prefer that discussions be marked "unresolved sem
antics
issue #XXX: sumti raising" or something like thatm, and keeop all the
issue descriptions on the ftp/web site with their eventual resolutions when
decently sumarized.

The key point is to make clear to the unitiated that we aren't changing
the
language design, but exploring how to say things clearly.  Use of the
term "error" or "contradiction" to  describe something in
 the language design
when it is yet uncertasin that the designis mistaken or what the error
is,
are risky of the attitudes of lurkers and learner-lurkers.

I understand that you prefer to tackle such semantic issues analytically,
whereas I prefer to do so in the context of trying to express a real idea
in Lojban in order to communicate it.  When I do so, and Jorge comes back
with "this is unclear" or "this violates XXX in the refgrammar" and we then

launch into how I might better have expressed it, we can then get to the
same answer, but it looks different to the outsider (and feels different to
me as a user of the language).  It is possible that when dealing with such
expressions, we will indentify a more general unresolved issue, but I
would argue that we need to do more solving of specific and concrete
exprssion problems in order to truly uderstand their nature before we can truly

generalize the problem and analyze it generally to a solution.  This is why I
argue that usage needs to come first.

This is not to say that there are NOT known unresalved issues from previous
discussions. "Only" comes to mind as an of-repeated one, as does "just" and
"even".  But again, I think these are best resolved in the context of
particular problems, perhaps making reference to a documented unresolved
issue.
We can then accumulate specific problem solutions, then later when we have
several such solutions, they can be analyzed more rigorously to see if we
really know what we are doing.

I guess that I was hoping to see a burst of usage and a relative mo
ratorium in
technical discussion about the language design for a little while after the
regrammar was published.  This seems to have been unrealistic, and I

understand thatthe rekindled interest in the language caused by the publi
cation
may indeed be causing increases in all kinds of Lojbanic acticvity, of which
unfortunately long-threaded technical discussions tend to become most easily vis
able.

>Problems tend to be discovered by alert users, and resolved by
>analytical discussion.
Lojban problems have more often been resolved through recognition of some
serendipitous feature in the language that, if exercised properly, makes
 the
problem go away.  Alternatively we have ended up adding a cmavo (which is
not permissible now), or very rarely reanalyzing an entire section of the
language (this was done for tense, Mex, relative clauses, attitudinals, and
abstractors and negation - 6 areas in rougjly 10 years, and is also not a
possible solution these days).

Thus, solutions to problems are limited to using a feature for some purpose
other than its original intent, discovering that it is not really a problem,
or deciding that this is a flaw in the language that can only be worked around
rather than solved.  (Combinations of the above are possible).

I suggest, BTW that we call them "issues" rather than "problems" if they are
unresolved, since we haven't necessarily all agreed that they are problems.

lojbab
----
lojbab                                                lojbab@access.digex.net
Bob LeChevalier, President, The Logical Language Group, Inc.
2904 Beau Lane, Fairfax VA 22031-1303 USA                        703-385-0273
Artificial language Loglan/Lojban: ftp.access.digex.net /pub/access/lojbab
    or see Lojban WWW Server: href="http://xiron.pc.helsinki.fi/lojban/";
    Order _The Complete Lojban Language_ - see our Web pages or ask me.