Received-SPF: pass (google.com: best guess record for domain of kali9putra@yahoo.com designates 66.94.236.255 as permitted sender) client-ip=66.94.236.255;
References: <CAHxnAmJvBZ1_4S1OF45n3dd5g2iQmFEGiQbsyBTN6PwybsNkrA@mail.gmail.com> <51A379EF.3020803@gmx.de> <CAHxnAm+HZGvy=Ck9nvogsR_uHL=+BYPho6vDKe8WGp-H4xKmEA@mail.gmail.com> <51A38E6B.7080107@gmx.de> <CAPAJj9Jidw7LiYMfmZQkzHxFQ9Z5W_P3UPrVUSb8NCykcHu_JQ@mail.gmail.com> <51A4A920.3090104@gmx.de>
Message-ID: <1369749610.3062.YahooMailNeo@web184401.mail.bf1.yahoo.com>
Date: Tue, 28 May 2013 07:00:10 -0700 (PDT)
From: John E Clifford <kali9putra@yahoo.com>
Reply-To: lojban@googlegroups.com
Subject: Re: [lojban] cmevla as a class of brivla
To: "lojban@googlegroups.com" <lojban@googlegroups.com>
In-Reply-To: <51A4A920.3090104@gmx.de>
MIME-Version: 1.0
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: multipart/alternative; boundary="1009959307-2056595000-1369749610=:3062"
X-Spam_score: 0.0
X-Spam_score_int: 0
X-Spam_bar: /

--1009959307-2056595000-1369749610=:3062
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This raises the point that The Merge assumes dotside.


________________________________
 From: selpa'i <seladwa@gmx.de>
To: lojban@googlegroups.com=20
Sent: Tuesday, May 28, 2013 7:54 AM
Subject: Re: [lojban] cmevla as a class of brivla
=20

la .tijlan. cu cusku di'e
> On 27 May 2013 17:48, selpa'i <seladwa@gmx.de <mailto:seladwa@gmx.de>>
> wrote:>
>=A0 >> But what happens whether "la betsemes solvor" wants to marry "la
>=A0 >> selpa'i tsani"? Oops. What should we do with them? Do we forbid the=
m
>=A0 >> to marry because the child's name violates the language naming rule=
s?
>=A0 >
>=A0 >
>=A0 > You'd have to call them something like {la broda me la .betsemes.
> selpa'i}. It's very ugly, but because there is a way to make it work,
> it's not broken, just inconvenient. Or so goes the argument.
>=20
> In the Western academic tradition, citation is made with the source
> author's surname, and the whole name is inverted in the bibliography so
> that the surname comes first to be sorted. This practice would look like
> {solvor co betsemes} with the current anti-tanru order of cmene
> ({solvor} being the surname/modifier). Instead, we could be consistent
> with the general head-final order of tanru and have the "first" name
> come after the modifying surname(s):
>=20
> lo mlatu ratcu
> a rat which is related to a cat (e.g. caught or eaten by a cat)
>=20
> la solvor betsemes
> Betsemes who is related to Solvor (e.g. born to or raised by Solvor)

This brings up a point that has to be laid out clearly. Is a string of cmev=
la to be considered a single name, or is each cmevla to be seen seperately?=
 Currently, {la .solvor.betsemes.} is just a single name, without any real =
structure. The Merge must decide whether to keep CMEVLA strings atomic as a=
 whole (Option 1) or to split them apart just like normal tanru (Option 2).

Option 2 has the effect that some multi-cmevla would undergo a slight chang=
e in meaning, e.g. imagine {la .klaus.peter.} whose name consists of two eq=
ual parts, neither of which can be considered to modify the other. Or imagi=
ne someone whose name contains a glottal stop. The effect that Option 2 wou=
ld have on such names *might* be negligible, I'm not sure. {la .klaus.peter=
.} would be a tanru name, so it means a "klaus" type of "peter".

In any case, we could manipulate such names freely. We can {.klaus. bo .pet=
er.} or {.peter. co .klaus.} because once split, the above problem doesn't =
exist anymore (it's effectively a case of {BRIVLA bo/co BRIVLA}), though it=
 still makes a difference for the meaning of the unsplit cmevla string. It =
becomes especially apparent once you add a third component that is supposed=
 to modify the entire cmevla string:

lo xekri .ford.taurus.

Option 1 has it that {melbi} modifies {.ford.taurus.}
Option 2 would interpret it as {(melbi .ford.) .taurus.}

It can't be both, so a decision has to be made.

> "First" names are "first" in the sense that they precede the other parts
> of a person's name in certain natlangs. But it's surnames - also called
> "last" names - which historically come before newly given names that are
> historically "last/newest" names. In several Asian countries, the
> historically-first "last" name comes first, and the historically-last
> "first" name comes last. This is analogous to the biological
> nomenclature, where the generic name precedes the specific name, such as
> "Giraffa camelopardalis rothschildi". In a sense, "Giraffa" is a
> surname, shared by different descendents of the genus. If we were to
> Lojbanize this composite name, I wouldn't expect it to be inverted for
> no good reason. (And the fact that certain components of such biological
> names are readily available as non-cmevla (i.e. gismu, lujvo, fu'ivla)
> while others aren't, is another argument for allowing the use of both
> word-types in a seamless manner.) (FWIW, the order of surname is also
> somewhat related to endianness. Wikipedia often uses the big-endian YMD
> format, again most common in certain Asian countries, for easier sorting
> of dates in the table.)
>=20
> Or perhaps we could radically change the default tanru order to
> head-initial, which would be consistent with the right-branching NOI,
> GOI, ME, NU, etc:

Please no. The entire language is generally left-branching, apart from {bo}=
. Let's not revert something so fundamental.

In what way are ME or NU right-branching? To me, the term "branching" or "g=
rouping" in this context means the grouping of identical (or similar) items=
 in succession, for instance:

broda brode brodi -> (broda brode) brodi
X .e Y .a Z=A0 =A0 =A0  -> (X .e Y) .a Z

Some constructs are head-initial, but those have two different components i=
nteracting instead, e.g. {KOhA NOI}. I think we need to dinstinguish betwee=
n these different situations of branching.

I don't think it's a good idea to get rid of symmetry. The whole point of T=
he Merge is to *increase* symmetry, is it not?

mu'o mi'e la selpa'i

-- You received this message because you are subscribed to the Google Group=
s "lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to lojban+unsubscribe@googlegroups.com.
To post to this group, send email to lojban@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban?hl=3Den.
For more options, visit https://groups.google.com/groups/opt_out.

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


--1009959307-2056595000-1369749610=:3062
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt">This raises the point=
 that The Merge assumes dotside.<br><div><span><br></span></div><div><br></=
div>  <div style=3D"font-family: times new roman, new york, times, serif; f=
ont-size: 12pt;"> <div style=3D"font-family: times new roman, new york, tim=
es, serif; font-size: 12pt;"> <div dir=3D"ltr"> <hr size=3D"1">  <font face=
=3D"Arial" size=3D"2"> <b><span style=3D"font-weight:bold;">From:</span></b=
> selpa'i &lt;seladwa@gmx.de&gt;<br> <b><span style=3D"font-weight: bold;">=
To:</span></b> lojban@googlegroups.com <br> <b><span style=3D"font-weight: =
bold;">Sent:</span></b> Tuesday, May 28, 2013 7:54 AM<br> <b><span style=3D=
"font-weight: bold;">Subject:</span></b> Re: [lojban] cmevla as a class of =
brivla<br> </font> </div> <div class=3D"y_msg_container"><br>
la .tijlan. cu cusku di'e<br>&gt; On 27 May 2013 17:48, selpa'i &lt;<a ymai=
lto=3D"mailto:seladwa@gmx.de" href=3D"mailto:seladwa@gmx.de">seladwa@gmx.de=
</a> &lt;mailto:<a ymailto=3D"mailto:seladwa@gmx.de" href=3D"mailto:seladwa=
@gmx.de">seladwa@gmx.de</a>&gt;&gt;<br>&gt; wrote:&gt;<br>&gt;&nbsp; &gt;&g=
t; But what happens whether "la betsemes solvor" wants to marry "la<br>&gt;=
&nbsp; &gt;&gt; selpa'i tsani"? Oops. What should we do with them? Do we fo=
rbid them<br>&gt;&nbsp; &gt;&gt; to marry because the child's name violates=
 the language naming rules?<br>&gt;&nbsp; &gt;<br>&gt;&nbsp; &gt;<br>&gt;&n=
bsp; &gt; You'd have to call them something like {la broda me la .betsemes.=
<br>&gt; selpa'i}. It's very ugly, but because there is a way to make it wo=
rk,<br>&gt; it's not broken, just inconvenient. Or so goes the argument.<br=
>&gt; <br>&gt; In the Western academic tradition, citation is made with the=
 source<br>&gt; author's surname, and the whole name is inverted in the
 bibliography so<br>&gt; that the surname comes first to be sorted. This pr=
actice would look like<br>&gt; {solvor co betsemes} with the current anti-t=
anru order of cmene<br>&gt; ({solvor} being the surname/modifier). Instead,=
 we could be consistent<br>&gt; with the general head-final order of tanru =
and have the "first" name<br>&gt; come after the modifying surname(s):<br>&=
gt; <br>&gt; lo mlatu ratcu<br>&gt; a rat which is related to a cat (e.g. c=
aught or eaten by a cat)<br>&gt; <br>&gt; la solvor betsemes<br>&gt; Betsem=
es who is related to Solvor (e.g. born to or raised by Solvor)<br><br>This =
brings up a point that has to be laid out clearly. Is a string of cmevla to=
 be considered a single name, or is each cmevla to be seen seperately? Curr=
ently, {la .solvor.betsemes.} is just a single name, without any real struc=
ture. The Merge must decide whether to keep CMEVLA strings atomic as a whol=
e (Option 1) or to split them apart just like normal tanru (Option
 2).<br><br>Option 2 has the effect that some multi-cmevla would undergo a =
slight change in meaning, e.g. imagine {la .klaus.peter.} whose name consis=
ts of two equal parts, neither of which can be considered to modify the oth=
er. Or imagine someone whose name contains a glottal stop. The effect that =
Option 2 would have on such names *might* be negligible, I'm not sure. {la =
.klaus.peter.} would be a tanru name, so it means a "klaus" type of "peter"=
.<br><br>In any case, we could manipulate such names freely. We can {.klaus=
. bo .peter.} or {.peter. co .klaus.} because once split, the above problem=
 doesn't exist anymore (it's effectively a case of {BRIVLA bo/co BRIVLA}), =
though it still makes a difference for the meaning of the unsplit cmevla st=
ring. It becomes especially apparent once you add a third component that is=
 supposed to modify the entire cmevla string:<br><br>lo xekri .ford.taurus.=
<br><br>Option 1 has it that {melbi} modifies
 {.ford.taurus.}<br>Option 2 would interpret it as {(melbi .ford.) .taurus.=
}<br><br>It can't be both, so a decision has to be made.<br><br>&gt; "First=
" names are "first" in the sense that they precede the other parts<br>&gt; =
of a person's name in certain natlangs. But it's surnames - also called<br>=
&gt; "last" names - which historically come before newly given names that a=
re<br>&gt; historically "last/newest" names. In several Asian countries, th=
e<br>&gt; historically-first "last" name comes first, and the historically-=
last<br>&gt; "first" name comes last. This is analogous to the biological<b=
r>&gt; nomenclature, where the generic name precedes the specific name, suc=
h as<br>&gt; "Giraffa camelopardalis rothschildi". In a sense, "Giraffa" is=
 a<br>&gt; surname, shared by different descendents of the genus. If we wer=
e to<br>&gt; Lojbanize this composite name, I wouldn't expect it to be inve=
rted for<br>&gt; no good reason. (And the fact that certain
 components of such biological<br>&gt; names are readily available as non-c=
mevla (i.e. gismu, lujvo, fu'ivla)<br>&gt; while others aren't, is another =
argument for allowing the use of both<br>&gt; word-types in a seamless mann=
er.) (FWIW, the order of surname is also<br>&gt; somewhat related to endian=
ness. Wikipedia often uses the big-endian YMD<br>&gt; format, again most co=
mmon in certain Asian countries, for easier sorting<br>&gt; of dates in the=
 table.)<br>&gt; <br>&gt; Or perhaps we could radically change the default =
tanru order to<br>&gt; head-initial, which would be consistent with the rig=
ht-branching NOI,<br>&gt; GOI, ME, NU, etc:<br><br>Please no. The entire la=
nguage is generally left-branching, apart from {bo}. Let's not revert somet=
hing so fundamental.<br><br>In what way are ME or NU right-branching? To me=
, the term "branching" or "grouping" in this context means the grouping of =
identical (or similar) items in succession, for
 instance:<br><br>broda brode brodi -&gt; (broda brode) brodi<br>X .e Y .a =
Z&nbsp; &nbsp; &nbsp;  -&gt; (X .e Y) .a Z<br><br>Some constructs are head-=
initial, but those have two different components interacting instead, e.g. =
{KOhA NOI}. I think we need to dinstinguish between these different situati=
ons of branching.<br><br>I don't think it's a good idea to get rid of symme=
try. The whole point of The Merge is to *increase* symmetry, is it not?<br>=
<br>mu'o mi'e la selpa'i<br><br>-- You received this message because you ar=
e subscribed to the Google Groups "lojban" group.<br>To unsubscribe from th=
is group and stop receiving emails from it, send an email to lojban+<a ymai=
lto=3D"mailto:unsubscribe@googlegroups.com" href=3D"mailto:unsubscribe@goog=
legroups.com">unsubscribe@googlegroups.com</a>.<br>To post to this group, s=
end email to <a ymailto=3D"mailto:lojban@googlegroups.com" href=3D"mailto:l=
ojban@googlegroups.com">lojban@googlegroups.com</a>.<br>Visit this group at
 <a href=3D"http://groups.google.com/group/lojban?hl=3Den" target=3D"_blank=
">http://groups.google.com/group/lojban?hl=3Den</a>.<br>For more options, v=
isit <a href=3D"https://groups.google.com/groups/opt_out" target=3D"_blank"=
>https://groups.google.com/groups/opt_out</a>.<br><br><br><br><br></div> </=
div> </div>  </div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;lojban&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to lojban+unsubscribe@googlegroups.com.<br />
To post to this group, send email to lojban@googlegroups.com.<br />
Visit this group at <a href=3D"http://groups.google.com/group/lojban?hl=3De=
n">http://groups.google.com/group/lojban?hl=3Den</a>.<br />
For more options, visit <a href=3D"https://groups.google.com/groups/opt_out=
">https://groups.google.com/groups/opt_out</a>.<br />
&nbsp;<br />
&nbsp;<br />

--1009959307-2056595000-1369749610=:3062--