Received-SPF: pass (google.com: domain of jjllambias@gmail.com designates 2a00:1450:4010:c03::22d as permitted sender) client-ip=2a00:1450:4010:c03::22d;
MIME-Version: 1.0
In-Reply-To: <20141009233031.GC1592@gonzales>
References: <20141005214350.GC1974@gonzales>
	<CAO7tK2fdDnOG5OSU5wJ=MQaDMroy3Ht45WjkMnCKBG1o9ofUTg@mail.gmail.com>
	<20141005234958.GD1974@gonzales>
	<CAO7tK2cr1GSJAsvyr_vCTPb_d-wwagdStfxA67NN4WbDzN80sw@mail.gmail.com>
	<20141006025048.GE1974@gonzales>
	<CAO7tK2fzy2Uz1sGBvX0WacV+uubGE5zugvKUi66m-LRrXAaYEQ@mail.gmail.com>
	<20141008015245.GB17866@gonzales>
	<CAO7tK2fokLXQ3queR+jP88xaoxMPQBQUojsAOZrF49hKTY=-LQ@mail.gmail.com>
	<20141009010533.GF18854@gonzales>
	<CAO7tK2erLDXJy5jOAx7--+vamH9brWJNSH2K82ACJgKbDVvD8g@mail.gmail.com>
	<20141009233031.GC1592@gonzales>
Date: Thu, 9 Oct 2014 22:04:14 -0300
Message-ID: <CAO7tK2cpdLRm8AOtHjADMKMP10uFu_N4mfddsP0-q07YnFzSLA@mail.gmail.com>
Subject: Re: [lojban] Re: tersmu 0.2
From: =?UTF-8?Q?Jorge_Llamb=C3=ADas?= <jjllambias@gmail.com>
To: 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: multipart/alternative; boundary=001a1135fb42afc2bb05050720f4
X-Spam_score: -2.6
X-Spam_score_int: -25
X-Spam_bar: --

--001a1135fb42afc2bb05050720f4
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 9, 2014 at 8:30 PM, Martin Bays <mbays@sdf.org> wrote:

>
> Anyway. Regarding whether sumti qualifiers and non-logical connectives
> should be transparent or opaque: there doesn't seem to be a clear
> argument either way based on utility. The transparent option is simpler
> and results in clear meanings in all cases, so doesn't it make sense to
> go for that?
>

For me there's no doubt that for LAhE/NAhE BO it has to be opaque. I don't
have a strong opinion on JOI, but I would want to make it opaque just by
analogy.


Meanwhile, regarding the "maximality presupposition" of {lo}, I wanted
> to bring up again Cherchia's version of the Frege-Russel iota. Quoting
> from Chiercha "Reference to kinds across languages" 1998:
> \iota X = the largest member of X if there is one (else, undefined).
> (where "largest" is with respect to AMONG).
>
> So {lo broda} refers to \iota of the extension of broda(_), with the
> presupposition that this is defined?
>
> So rather than representing {lo broda cu brode} as
>     Presupposition: broda(c1)
>     brode(c1)
> could we then just represent it as
>     brode(\iota broda(_))?


> That would make me happy.
>

How would you express it in Lojban? (Hopefully nothing involving mekso. :)

We'd also have
>     ro da lo broda be da cu brode
>     -> FA x. brode(\iota broda(_,x))
> with no need to skolemise.
>
> I'm confused about getting, kinds, though. Is it the intention that
> kinds are maximal, even when there are instances also in the domain?
> That doesn't actually agree with the ontology sketched in that paper,
> which has kinds being atoms, but perhaps we shouldn't read too much into
> that.
>

I don't know. I think it's hard for kinds and instances to co-exist in a
domain with both being described by the same predicate, but that's a
conflict more general than for kinds only. Even for groups and their
members: if a group does something, and each of the members does it, that
doesn't mean that we have to count the group as an additional doer when
counting the doers.

Or is the idea that {lo} often accompanies a shift to a domain which
> only has the kind?
>

That's how I tend to think of it.

mu'o mi'e xorxes

-- 
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 email 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.
For more options, visit https://groups.google.com/d/optout.

--001a1135fb42afc2bb05050720f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Thu, Oct 9, 2014 at 8:30 PM, Martin Bays <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mbays@sdf.org" target=3D"_blank">mbays@sdf.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><br>
Anyway. Regarding whether sumti qualifiers and non-logical connectives<br>
should be transparent or opaque: there doesn&#39;t seem to be a clear<br>
argument either way based on utility. The transparent option is simpler<br>
and results in clear meanings in all cases, so doesn&#39;t it make sense to=
<br>
go for that?<br></blockquote><div><br></div><div>For me there&#39;s no doub=
t that for LAhE/NAhE BO it has to be opaque. I don&#39;t have a strong opin=
ion on JOI, but I would want to make it opaque just by analogy.</div><div>=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Meanwhile, regarding the &quot;maximality presupposition&quot; of {lo}, I w=
anted<br>
to bring up again Cherchia&#39;s version of the Frege-Russel iota. Quoting<=
br>
from Chiercha &quot;Reference to kinds across languages&quot; 1998:<br>
\iota X =3D the largest member of X if there is one (else, undefined).<br>
(where &quot;largest&quot; is with respect to AMONG).<br>
<br>
So {lo broda} refers to \iota of the extension of broda(_), with the<br>
presupposition that this is defined?<br>
<br>
So rather than representing {lo broda cu brode} as<br>
=C2=A0 =C2=A0 Presupposition: broda(c1)<br>
=C2=A0 =C2=A0 brode(c1)<br>
could we then just represent it as<br>
=C2=A0 =C2=A0 brode(\iota broda(_))?=C2=A0</blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>
That would make me happy.<br></blockquote><div><br></div><div>How would you=
 express it in Lojban? (Hopefully nothing involving mekso. :)=C2=A0</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
We&#39;d also have<br>
=C2=A0 =C2=A0 ro da lo broda be da cu brode<br>
=C2=A0 =C2=A0 -&gt; FA x. brode(\iota broda(_,x))<br>
with no need to skolemise.<br>
<br>
I&#39;m confused about getting, kinds, though. Is it the intention that<br>
kinds are maximal, even when there are instances also in the domain?<br>
That doesn&#39;t actually agree with the ontology sketched in that paper,<b=
r>
which has kinds being atoms, but perhaps we shouldn&#39;t read too much int=
o<br>
that.<br></blockquote><div><br></div><div>I don&#39;t know. I think it&#39;=
s hard for kinds and instances to co-exist in a domain with both being desc=
ribed by the same predicate, but that&#39;s a conflict more general than fo=
r kinds only. Even for groups and their members: if a group does something,=
 and each of the members does it, that doesn&#39;t mean that we have to cou=
nt the group as an additional doer when counting the doers.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Or is the idea that {lo} often accompanies a shift to a domain which<br>
only has the kind?<br></blockquote><div><br></div><div>That&#39;s how I ten=
d to think of it.</div><div><br></div><div>mu&#39;o mi&#39;e xorxes</div><d=
iv>=C2=A0</div></div></div></div>

<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 <a href=3D"mailto:lojban+unsubscribe@googlegroups.com">lojban+unsub=
scribe@googlegroups.com</a>.<br />
To post to this group, send email to <a href=3D"mailto:lojban@googlegroups.=
com">lojban@googlegroups.com</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/group/lojban">http:=
//groups.google.com/group/lojban</a>.<br />
For more options, visit <a href=3D"https://groups.google.com/d/optout">http=
s://groups.google.com/d/optout</a>.<br />

--001a1135fb42afc2bb05050720f4--