Received-SPF: pass (google.com: domain of felipeg.assis@gmail.com designates 2a00:1450:4010:c03::22c as permitted sender) client-ip=2a00:1450:4010:c03::22c;
MIME-Version: 1.0
In-Reply-To: <CAO7tK2c+_D=puWni4S-XRefyUR+tvTPh7nxQeKCFTF9vRzKQZA@mail.gmail.com>
References: <CALMa68pAATH-Vs_S8mwH+9m31WoTCdZ-c_sGfe0GGNE05cEhRQ@mail.gmail.com>
	<CAKOEKkQ9cmDxN8wap15qeYPFdu6LiusmNYrOF90esZpp86qemg@mail.gmail.com>
	<CALMa68qdWo6ZyrYjDZ_3gSy65770N4-oticVyb7BoS0iFJhu1Q@mail.gmail.com>
	<CAO7tK2ebL0DEmzhkp_STdRNJnMYmYhe8-Tz2CeuHbC7J3OzDSQ@mail.gmail.com>
	<CALMa68ppO6KTmWqLXgvDiR7VV-MF-x5DVm_SZuo0yL7FNNhp7w@mail.gmail.com>
	<CAO7tK2dPujdfvchn2QLcaAmU1n0FLuK=fSfFmfT_r=SO+=PtUA@mail.gmail.com>
	<CALMa68oeK_0bSqbuh6cbrzzk=f5RPvcJb4-An_pkAfXuOZ+wkg@mail.gmail.com>
	<CAO7tK2c+_D=puWni4S-XRefyUR+tvTPh7nxQeKCFTF9vRzKQZA@mail.gmail.com>
Date: Sat, 8 Feb 2014 15:09:59 -0200
Message-ID: <CALMa68qf7PeY7gheuxxtDA087FwdUkX9ULTyQ2behCz6tpCXZQ@mail.gmail.com>
Subject: Re: [lojban] [oz] {ny poi cy ke'a falcru}
From: =?ISO-8859-1?Q?Felipe_Gon=E7alves_Assis?= <felipeg.assis@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=047d7b3431ea2df6c304f1e82dd7
X-Spam_score: 0.0
X-Spam_score_int: 0
X-Spam_bar: /

--047d7b3431ea2df6c304f1e82dd7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 8 February 2014 12:11, Jorge Llamb=EDas <jjllambias@gmail.com> wrote:

>
>
>
> On Fri, Feb 7, 2014 at 11:34 PM, Felipe Gon=E7alves Assis <
> felipeg.assis@gmail.com> wrote:
>
> It turns out we would arrive at exactly the same conclusions from your
>> reasoning. The topic of this thread is one of the few examples in which =
a
>> conflict appears.
>>
>
> Right. The only situation in which the two approaches will differ seems t=
o
> be when "poi" is attached to a sumti that already has its referents
> determined beforehand. Then when the poi-clause is a proper restriction o=
n
> those referents, it will be fine with the poi-as-restriction approach, bu=
t
> it will fail with the poi-as-referent-determiner approach. But then what =
is
> the advantage of this second approach? When both approaches work, they me=
an
> the same thing, and when they don't mean the same thing, it's because the
> second approach breaks down, not because it has an alternative use.
>
>
Firstly, my approach doesn't limit expression, as I already pointed with
{lo me ko'a}. Secondly, you do gain a lot, only you have to go into the
realm of pragmatics in order to appreciate it.

When I say {ti poi toldi}, I am making it clear what I am pointing to,
while when I say {ti noi toldi}, I expect you to understand what I am
pointing to, and I am giving the information that it is a butterfly. In the
latter case, I might be presuming, for example, that you don't know that
the colourful thing I am pointing at is in fact a butterfly. In the former,
the information in the relative clause has a clear purpose: it is there to
clarify the reference.

These pragmatic markings are useful to manage the so called Common Ground,
which is to say that it helps one to keep track of what the other knows
(about what one knows, etc.). If it were obvious to you that what I was
pointing at was a butterfly, and there was no apparent reason for me to
remark that, {ti noi toldi} would be a pragmatic failure, triggering some
response from you that could help us re-establish the Common Ground. {ti
poi toldi}, on the other hand, would be fine.

Under the alternative convention, this distinction can't be made: when I
point at a definite thing, only {noi} makes sense.

mu'o
mi'e .asiz.

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

--047d7b3431ea2df6c304f1e82dd7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 8 February 2014 12:11, Jorge Llamb=EDas <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jjllambias@gmail.com" target=3D"_blank">jjllambias@gmail.co=
m</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div>On Fri, Feb =
7, 2014 at 11:34 PM, Felipe Gon=E7alves Assis <span dir=3D"ltr">&lt;<a href=
=3D"mailto:felipeg.assis@gmail.com" target=3D"_blank">felipeg.assis@gmail.c=
om</a>&gt;</span> wrote:<br>


</div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>It turn=
s out we would arrive at exactly the same conclusions from your reasoning. =
The topic of this thread is one of the few examples in which a conflict app=
ears.<br>


</div></div></div></div></blockquote><div><br></div></div><div>Right. The o=
nly situation in which the two approaches will differ seems to be when &quo=
t;poi&quot; is attached to a sumti that already has its referents determine=
d beforehand. Then when the poi-clause is a proper restriction on those ref=
erents, it will be fine with the poi-as-restriction approach, but it will f=
ail with the poi-as-referent-determiner approach. But then what is the adva=
ntage of this second approach? When both approaches work, they mean the sam=
e thing, and when they don&#39;t mean the same thing, it&#39;s because the =
second approach breaks down, not because it has an alternative use.</div>

<div>
<div><br></div></div></div></div></div></blockquote><div><br>Firstly, my ap=
proach doesn&#39;t limit expression, as I already pointed with {lo me ko=
9;a}. Secondly, you do gain a lot, only you have to go into the realm of pr=
agmatics in order to appreciate it.<br>

<br></div><div>When I say {ti poi toldi}, I am making it clear what I am po=
inting to, while when I say {ti noi toldi}, I expect you to understand what=
 I am pointing to, and I am giving the information that it is a butterfly. =
In the latter case, I might be presuming, for example, that you don&#39;t k=
now that the colourful thing I am pointing at is in fact a butterfly. In th=
e former, the information in the relative clause has a clear purpose: it is=
 there to clarify the reference.<br>
<br></div><div>These pragmatic markings are useful to manage the so called =
Common Ground, which is to say that it helps one to keep track of what the =
other knows (about what one knows, etc.). If it were obvious to you that wh=
at I was pointing at was a butterfly, and there was no apparent reason for =
me to remark that, {ti noi toldi} would be a pragmatic failure, triggering =
some response from you that could help us re-establish the Common Ground. {=
ti poi toldi}, on the other hand, would be fine.<br>
</div><div><br>Under the alternative convention, this distinction can&#39;t=
 be made: when I point at a definite thing, only {noi} makes sense.<br><br>=
</div><div>mu&#39;o<br>mi&#39;e .asiz.<br></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 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">http:=
//groups.google.com/group/lojban</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 />

--047d7b3431ea2df6c304f1e82dd7--