Received: from localhost ([::1]:57292 helo=stodi.digitalkingdom.org) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1TqzWJ-0005X3-5I; Thu, 03 Jan 2013 21:08:39 -0800 Received: from mail-vc0-f172.google.com ([209.85.220.172]:37263) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TqzWC-0005Ww-Sn for jbovlaste@lojban.org; Thu, 03 Jan 2013 21:08:37 -0800 Received: by mail-vc0-f172.google.com with SMTP id fw7so16217248vcb.31 for ; Thu, 03 Jan 2013 21:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BCbAMulmRloZSyQaLNpkvmGZ7qD49d+5Uhmf91jud/M=; b=QuI1M2W73tiGcOPBMh8pWl25mJGGaqS04ta8Dcx0ksICnUIiWqPGwdr9Yy42nFgydV 2Rf+Kzw2FPmOHxBFjLZ9RWeL0OoJIPbTA9Z7z3iQNrBNbZM3yho2omIqvm7Fo4xpKQGv XauQMNLoikCDcw19UsSE7oaoNBAWahjxcwgbWrRLwyjJp6yVuW7cR34FLwUgkP2JI/So ceUwlJw1wMCEHARSZs/YW9lY0pqSsz+YjFfwtdZZ57QRBrH1msKskAQSt/dDPDZfbWrP TkqF00xnXNNMz/21nmRdBofc8+iDYKPYVieBJ+l2VpbLh7GVZzihfsV3EN8g0067jbmu jmqw== MIME-Version: 1.0 Received: by 10.58.44.74 with SMTP id c10mr78527221vem.10.1357276106388; Thu, 03 Jan 2013 21:08:26 -0800 (PST) Received: by 10.220.13.197 with HTTP; Thu, 3 Jan 2013 21:08:26 -0800 (PST) In-Reply-To: References: <20130103201946.GA18038@stodi.digitalkingdom.org> <2496675.noDcb1HzR9@caracal> Date: Fri, 4 Jan 2013 00:08:26 -0500 Message-ID: From: Ian Johnson To: jbovlaste@lojban.org X-Spam-Score: 0.9 (/) X-Spam_score: 0.9 X-Spam_score_int: 9 X-Spam_bar: / X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I'm not sure between 1 and 2. The fact that the definition uses the word "form" seems to make #1 seem pertinent, but on the other hand the examples that we've noted seem to be more about {makcu binxo} than {barda zenba}. Of course in many, many species {makcu binxo} involves {barda zenba}. So perhaps {banro} is {barda zenba} with a subtext of {makcu binxo}. The problem with this is "what exactly is banro2", and that again ties into my objection to the notion of concrete binxo2. (Namely, that an object does not become a different object, it merely changes in properties. Saying {mi binxo lo cinki} should by a transparency argument be the same as {lo cinki cu binxo lo cinki}.) [...] Content analysis details: (0.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (blindbravado[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.0 FREEMAIL_REPLY From and body contain different freemails Subject: Re: [jbovlaste] [eitanp32@gmail.com: {banro} gets default sense of "grow"; conflicting with some lujvo] X-BeenThere: jbovlaste@lojban.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: jbovlaste@lojban.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5094292819194675910==" Errors-To: jbovlaste-bounces@lojban.org --===============5094292819194675910== Content-Type: multipart/alternative; boundary=089e013cc4082ef5a904d26f784e --089e013cc4082ef5a904d26f784e Content-Type: text/plain; charset=ISO-8859-1 I'm not sure between 1 and 2. The fact that the definition uses the word "form" seems to make #1 seem pertinent, but on the other hand the examples that we've noted seem to be more about {makcu binxo} than {barda zenba}. Of course in many, many species {makcu binxo} involves {barda zenba}. So perhaps {banro} is {barda zenba} with a subtext of {makcu binxo}. The problem with this is "what exactly is banro2", and that again ties into my objection to the notion of concrete binxo2. (Namely, that an object does not become a different object, it merely changes in properties. Saying {mi binxo lo cinki} should by a transparency argument be the same as {lo cinki cu binxo lo cinki}.) mi'e la latro'a mu'o .i ta'o lo nu zo latro'a cmene mi do cu zmadu lo nu lo glico cu cmene mi do kei lo ni mi nelci ce'u On Thu, Jan 3, 2013 at 11:37 PM, Eitan Postavsky wrote: > I discern three opinions on this apparent conflict between {banro} and > {brabi'o}: > 1. They're different: roughly speaking, {banro} is about the beginning and > ending /forms/, while {brabi'o} is about the beginning and ending /sizes/. > 2. {brabi'o} is superfluous; delete it. > 3. {brabi'o} is superfluous; restrict {banro} so that {brabi'o} not > superfluous. > > My respective responses (straw man much?): > 1. The gismu list is very clear that {banro} involves an increase in some > sense. ke'u it's not just changing from one form into another. {barda} (and > {zenba}) captures quite well "increase in some sense", so... > 2. I concur. Ian Johnson said it well (though I guess he later defected to > 1?): "Seems to me that {banro} is {barda zenba}, with all the possible > vagueness that barda2/barda3 introduce, and that {brabi'o} is superfluous." > 3. That's crazy. I'll talk to la pier directly. li'a you're suggesting > that we take {banro} to be restricted to increases resulting from life. > Your velji'i is either independent of {brabi'o}, or dependent on it; that > is, either {brabi'o} figures somewhere in your reasoning, or it figures > nowhere in your reasoning. If it is independent, then basically you're > interpreting the gismu list's definition of {banro} to be restricted to > increases resulting from life; the word "life" figures nowhere in there, so > clearly that is not the case. Therefore, your velji'i is dependent on > {brabi'o}. So basically, because {brabi'o} is so similar to {banro}, you > want to restrict {banro} so that it's not so similar. But the gismu list is > /known/ to be redundant; that is, it is known that, for many a gismu G, you > can construct a lujvo L out of gismu other than G so that L is so similar > to G. By your reasoning, for each such G and L, we ought to narrow G so > it's not so similar to L. That's absurd. By exhaustion, I conclude that > your reasoning is absurd (or "crazy"). (Likely you'll disagree with the two > parts of this paragraph that are labeled with the word "basically".) > > _______________________________________________ > jbovlaste mailing list > jbovlaste@lojban.org > http://mail.lojban.org/mailman/listinfo/jbovlaste > > --089e013cc4082ef5a904d26f784e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not sure between 1 and 2. The fact that the definition uses the wor= d "form" seems to make #1 seem pertinent, but on the other hand t= he examples that we've noted seem to be more about {makcu binxo} than {= barda zenba}. Of course in many, many species {makcu binxo} involves {barda= zenba}. So perhaps {banro} is {barda zenba} with a subtext of {makcu binxo= }. The problem with this is "what exactly is banro2", and that ag= ain ties into my objection to the notion of concrete binxo2. (Namely, that = an object does not become a different object, it merely changes in properti= es. Saying {mi binxo lo cinki} should by a transparency argument be the sam= e as {lo cinki cu binxo lo cinki}.)

mi'e la latro'a mu'o .i ta'o lo nu zo latro'a cmene= mi do cu zmadu lo nu lo glico cu cmene mi do kei lo ni mi nelci ce'u
On Thu, Jan 3, 2013 at 11:37 PM, Eitan Pos= tavsky <eitanp32@gmail.com> wrote:
I discern three opinions on this apparent co= nflict between {banro} and {brabi'o}:
1. They're different: roug= hly speaking, {banro} is about the beginning and ending /forms/, while {bra= bi'o} is about the beginning and ending /sizes/.
2. {brabi'o} is superfluous; delete it.
3. {brabi'o} is superflu= ous; restrict {banro} so that {brabi'o} not superfluous.

My resp= ective responses (straw man much?):
1. The gismu list is very clear that= {banro} involves an increase in some sense. ke'u it's not just cha= nging from one form into another. {barda} (and {zenba}) captures quite well= "increase in some sense", so...
2. I concur. Ian Johnson said it well (though I guess he later defected to = 1?): "Seems to me that {banro} is {barda zenba}, with all the possible= vagueness that barda2/barda3 introduce, and that {brabi'o} is superflu= ous."
3. That's crazy. I'll talk to la pier directly. li'a you're= suggesting that we take {banro} to be restricted to increases resulting fr= om life. Your velji'i is either independent of {brabi'o}, or depend= ent on it; that is, either {brabi'o} figures somewhere in your reasonin= g, or it figures nowhere in your reasoning. If it is independent, then basi= cally you're interpreting the gismu list's definition of {banro} to= be restricted to increases resulting from life; the word "life" = figures nowhere in there, so clearly that is not the case. Therefore, your = velji'i is dependent on {brabi'o}. So basically, because {brabi'= ;o} is so similar to {banro}, you want to restrict {banro} so that it's= not so similar. But the gismu list is /known/ to be redundant; that is, it= is known that, for many a gismu G, you can construct a lujvo L out of gism= u other than G so that L is so similar to G. By your reasoning, for each su= ch G and L, we ought to narrow G so it's not so similar to L. That'= s absurd. By exhaustion, I conclude that your reasoning is absurd (or "= ;crazy"). (Likely you'll disagree with the two parts of this parag= raph that are labeled with the word "basically".)

_______________________________________________
jbovlaste mailing list
jbovlaste@lojban.org
http://mail.lojban.org/mailman/listinfo/jbovlaste


--089e013cc4082ef5a904d26f784e-- --===============5094292819194675910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ jbovlaste mailing list jbovlaste@lojban.org http://mail.lojban.org/mailman/listinfo/jbovlaste --===============5094292819194675910==--