Received: with ECARTIS (v1.0.0; list lojban-list); Thu, 22 Aug 2002 08:41:52 -0700 (PDT) Received: from n9.grp.scd.yahoo.com ([66.218.66.93]) by chain.digitalkingdom.org with smtp (Exim 4.05) id 17hu5l-0000bt-01 for lojban-in@lojban.org; Thu, 22 Aug 2002 08:41:49 -0700 X-eGroups-Return: sentto-44114-15222-1030030878-lojban-in=lojban.org@returns.groups.yahoo.com Received: from [66.218.66.97] by n9.grp.scd.yahoo.com with NNFMP; 22 Aug 2002 15:41:18 -0000 X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_1_0_1); 22 Aug 2002 15:41:17 -0000 Received: (qmail 39653 invoked from network); 22 Aug 2002 15:41:17 -0000 Received: from unknown (66.218.66.218) by m14.grp.scd.yahoo.com with QMQP; 22 Aug 2002 15:41:17 -0000 Received: from unknown (HELO imo-d03.mx.aol.com) (205.188.157.35) by mta3.grp.scd.yahoo.com with SMTP; 22 Aug 2002 15:41:16 -0000 Received: from Pycyn@aol.com by imo-d03.mx.aol.com (mail_out_v34.9.) id r.197.be1b4c2 (3980) for ; Thu, 22 Aug 2002 11:41:09 -0400 (EDT) Message-ID: <197.be1b4c2.2a966015@aol.com> To: lojban@yahoogroups.com X-Mailer: AOL 7.0 for Windows US sub 10509 From: pycyn@aol.com X-Yahoo-Profile: kaliputra MIME-Version: 1.0 Mailing-List: list lojban@yahoogroups.com; contact lojban-owner@yahoogroups.com Delivered-To: mailing list lojban@yahoogroups.com Precedence: bulk Date: Thu, 22 Aug 2002 11:41:09 EDT Subject: Re: [lojban] Re: I like chocolate Content-Type: multipart/alternative; boundary="part1_197.be1b4c2.2a966015_boundary" X-archive-position: 752 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: pycyn@aol.com Precedence: bulk Reply-to: lojban-list@lojban.org X-list: lojban-list Content-Length: 12902 Lines: 213 --part1_197.be1b4c2.2a966015_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/22/2002 8:10:26 AM Central Daylight Time, jjllambias@hotmail.com writes: << > ><< > > > Because it doesn't correspond to anything in natlangs as far > > > as I can tell. > > > >> > > > >The easiest similarity I can think of is indirect discourse: Jack says "I > >know the bitch is asleep" and you, being nice, report to others "Jack > knows > >that Jill is asleep." Different events but out of the same class and (in > >this case as we are constructing it) ones both of which Jack knows. > > But that is not a problematic case. A problematic case > would be: > > la djak na'e djuno lo du'u la djil sipna > Jack ignores (some) that Jill is asleep. > > Because, even though he does know the relevant 'that Jill is > asleep', he doesn't know all the 'that Jill is asleep' that > there are. Anything like {la djak na'e djuno lo du'u la > djil sipna} would be false in English, but the Lojban is true. >> > Well, I wasn't looking for a problematic case, just one where where English > usage parallels Lojban. This seems a pretty good one of that sort. As for > your problematic case, I don't see -- aside from uncertainty about what > {na'e djuno} includes -- what the problem is. It clearly is not "ignore" > which is generally an intentional act not to heed what one knows pretty > well. It does apparently take in just about anything other than knowing on > the cognition scale so it appears it would be generally true in English, if we could find a good way to phrase it: Jack has some cognitive stance other than knowledge with respect to some claims that amount to "Jill is asleep." As I said, he doesn't know nor even consider the one about his great grandsmother's great granddaughterm , he may even doubt a few, believe a few without the further conditions to knowledge, and so on. << That's why I said that {tu'o} is a non-quantifier, and that it does not quantify over the members of lo'i. Quantifiers always run over the extension, and tu'o blocks the move to the extension. >> But, on the face of it, {tu'o} IS a quantifier and I have not seen anything yet to suggest otherwise. And, further, it is a quantifier that is approriate here, since we are exactly going into the set and pulling out members. The set happens to be a set of intensional things, but the set itself is extensional (being a set and all). <<><< >is there any way to refer to occasions >in Lojban? > >> > >The way we always do: pin them down with an explicit or implicit hook to >the >real world, {ca} or {vi} or... or by the nature of the selbri to which they >attach. Then {re nu mi citka lo cakla} could be used to refer to occasions after all, if we assume an implicit hook to the real world. It could mean {re nu mi pu citka lo cakla}. But if {pu} hooks it to the real world, how do we get a token {nu mi pu citka lo cakla}? Now you're saying that it is the nature of the selbri to which it attaches that selects whether {lo nu broda} is taken from a set of tokens or a set of instances. Places that create token contexts. Something similar to places that create intensional contexts. That's not the Lojban I know. >> Well, I know that your Lojban deviates occasionally from CLL and the historical development, so that well may be. It is the Lojban adumbrated in The Book and so on. Yes, of course {re nu mi citka lo cakla} can be used to refer to occasions, just as {mi citka cakla} can be (but need not be and is not inherently). {re nu mi pu citka lo cakla} may also -- but need not -- refer to occasions, as {mi reroi citka lo cakla} does. I assume that "But if {pu} hooks it to the real world, how do we get a token {nu mi pu citka lo cakla}? " is asking for a type (event), not a token. And the answer is, at least in part, the same way that it works without the {nu}. We can guarantee token readings (occasions) by fiddling at the beginning {le ca nu} and the like pull it down, as does a {nau} inside, I think. I did not say that there are places that select token readings or that select type readings. What I said was that one of the factors in the contextual, implicit, identification of event or occasion is the place it occupies in the bridi it is in. And, of course, other things as well, perhaps pointing in a different direction -- whether the sentence itself is anchored or not, for example. If you are recovering from lo nu citka lo cakla, it is pretty likely an occasion, not an event. Of course, we do make mistakes and then we need to get explicit -- in the ways I suggested or others. << In my view, le/lo broda always selects instances (be they real or imaginary) from the class of broda (be it a class of concrete objects, events or anything else). >> Yup. Except that the instances selected are always real in the context where the selecting takes place (the context may, of course, be imaginational). And so here; the gadri select from the class of events that have the general property of being (in the current world) under the general rubric laid out: {nu la djil sipna}, {nu mi citka lo cakla}, and so on. It is, as you say, definitional. --part1_197.be1b4c2.2a966015_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit In a message dated 8/22/2002 8:10:26 AM Central Daylight Time, jjllambias@hotmail.com writes:

<<
><<
> > Because it doesn't correspond to anything in natlangs as far
> > as I can tell.
> > >>
>
>The easiest similarity I can think of is indirect discourse: Jack says "I
>know the bitch is asleep" and you, being nice, report to others "Jack knows
>that Jill is asleep."  Different events but out of the same class and (in
>this case as we are constructing it) ones both of which Jack knows.

But that is not a problematic case. A problematic case
would be:

        la djak na'e djuno lo du'u la djil sipna
        Jack ignores (some) that Jill is asleep.

Because, even though he does know the relevant 'that Jill is
asleep', he doesn't know all the 'that Jill is asleep' that
there are. Anything like {la djak na'e djuno lo du'u la
djil sipna} would be false in English, but the Lojban is true.

>>

Well, I wasn't looking for a problematic case, just one where where English usage parallels Lojban. This seems a pretty good one of that sort.  As for your problematic case, I don't see -- aside from uncertainty about what {na'e djuno} includes -- what the problem is.  It clearly is not "ignore" which is generally an intentional act not to heed what one knows pretty well.  It does apparently take in just about anything other than knowing on the cognition scale so it appears it would be generally true in

English, if we could find a good way to phrase it: Jack has some cognitive stance other than knowledge with respect to some claims that amount to "Jill is asleep."  As I said, he doesn't know nor even consider the one about his great grandsmother's great granddaughterm , he may even doubt a few, believe a few without the further conditions to knowledge, and so on.

<<
That's why I said that {tu'o} is a non-quantifier, and that it
does not quantify over the members of lo'i. Quantifiers always run
over the extension, and tu'o blocks the move to the extension.
>>

But, on the face of it, {tu'o} IS a quantifier and I have not seen anything yet to suggest otherwise.  And, further, it is a quantifier that is approriate here, since we are exactly going into the set and pulling out members.  The set happens to be a set of intensional things, but the set itself is extensional (being a set and all).

<<><<
>is there any way to refer to occasions
>in Lojban?
> >>
>
>The way we always do: pin them down with an explicit or implicit hook to
>the
>real world, {ca} or {vi} or... or by the nature of the selbri to which they
>attach.

Then {re nu mi citka lo cakla} could be used to refer to
occasions after all, if we assume an implicit hook to the
real world. It could mean {re nu mi pu citka lo cakla}.
But if {pu} hooks it to the real world, how do we get
a token {nu mi pu citka lo cakla}? Now you're saying that
it is the nature of the selbri to which it attaches that
selects whether {lo nu broda} is taken from a set of tokens
or a set of instances. Places that create token contexts.
Something similar to places that create intensional contexts.
That's not the Lojban I know.
>>
Well, I know that your Lojban deviates occasionally from CLL and the historical development, so that well may be.  It is the Lojban adumbrated in The Book and so on.
Yes, of course {re nu mi citka lo cakla} can be used to refer to occasions, just as {mi citka cakla} can be (but need not be and is not inherently).  {re nu mi pu citka lo cakla} may also -- but need not -- refer to occasions, as {mi reroi citka lo cakla} does.
I assume that "But if {pu} hooks it to the real world, how do we get a token {nu mi pu citka lo cakla}? " is asking for a type (event), not a token.  And the answer is, at least in part, the same way that it works without the {nu}.  We can guarantee token readings (occasions) by fiddling at the beginning {le ca nu} and the like pull it down, as does a {nau} inside, I think.
I did not say that there are places that select token readings or that select type readings.  What I said was that one of the factors in the contextual, implicit, identification of event or occasion is the place it occupies in the bridi it is in.  And, of course, other things as well, perhaps pointing in a different direction -- whether the sentence itself is anchored or not, for example.  If you are recovering from lo nu citka lo cakla, it is pretty likely an occasion, not an event.  Of course, we do make mistakes and then we need to get explicit -- in the ways I suggested or others.

<<
In my view, le/lo broda always selects instances (be they real
or imaginary) from the class of broda (be it a class of concrete
objects, events or anything else).
>>
Yup.  Except that the instances selected are always real in the context where the selecting takes place (the context may, of course, be imaginational).  And so here; the gadri select from the class of events that have the general property of being (in the current world) under the general rubric laid out: {nu la djil sipna}, {nu mi citka lo cakla}, and so on. It is, as you say, definitional.
Yahoo! Groups Sponsor

To unsubscribe, send mail to lojban-unsubscribe@onelist.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--part1_197.be1b4c2.2a966015_boundary--