Date: Sat, 6 Dec 1997 04:54:13 -0500 (EST) Message-Id: <199712060954.EAA22682@locke.ccil.org> Reply-To: Logical Language Group Sender: Lojban list From: Logical Language Group Subject: Re: On logji lojbo discussions X-To: lojban@cuvmb.cc.columbia.edu To: John Cowan Status: OR X-Mozilla-Status: 0011 Content-Length: 9066 X-From-Space-Date: Sat Dec 6 04:54:23 1997 X-From-Space-Address: LOJBAN@CUVMB.CC.COLUMBIA.EDU >[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.